7:52 a.m.
Dear all,
I have been working for some time on the next version of packagedb/pkgdb [1].
I am at a point where I think it starts to look good, the unit-tests are passing
and I seem to be able to do what I want with it. Thus I thought this would be a
good time to call for testers and collect bug reports and RFE.
The development instance of pkgdb2 is at:
http://209.132.184.188/
I contains the data from pkgdb1 from about a month ago.
It has a dedicated API (which need some more documentation), the documentation
of pkgdb2 itself isn't written yet (so the link in the footer won't work).
Among the changes:
- The idea of "owner" of a package disapear. There are only maintainers on
which
one of them appears to be the dedicated "point of contact" for this package
(ie:
the person that gets the bugs in bugzilla).
- No more javascript and ajax call to do basic ACLs management
- The possibility to have ACL for FAS groups is implemented with the following
limitations:
- It needs a change in FAS (pull-request merged) and a new FAS release (no ETA)
- These groups have a dedicated type, 'pkgdb', in FAS, this mean one can join
the perl-sig FAS group, get the email, follow the discussions while not
getting 'commit' ACL on the packages.
- These groups will require the user to be in the packager group before they
can be added.
- Groups cannot have the 'approveacls' ACL, they are only there to serve as
point
of contact and provide 'commit' ACLs to the group members.
This means that when the package is created in pkgdb2, it will be created for
the user that submitted the review, who can then 'give' it to the SIG of
his/her
choice. This user will be the only one with 'approveacl' (unless he/she gives
this right to someone else).
- Pending ACLs
When you log in, you will see a 'Pending ACLs' item in the menu, this will give
you an overview of all the ACLs 'Awaiting Review'.
So please, have a look at it, play with it, break it (no seriously, do, but don't
forget to report how you did it afterward) and if you have any problem/RFE feel
free to note them at:
https://github.com/fedora-infra/packagedb2/
The read API should be in place and working, the write API is still work in
progress with regards to managing authentication.
So, if you have tools using it/relying on it, on its API, feel free to poke at
it and let me know how it behaves.
Pkgdb-cli will be updated in a near future to the new API, once the
authentication question has been solved.
Happy testing!
Pierre
8:20 a.m.
On Wed, Nov 13, 2013 at 02:52:27PM +0100, Pierre-Yves Chibon wrote:
- The idea of "owner" of a package disapear. There are only
maintainers on which
one of them appears to be the dedicated "point of contact" for this package
(ie:
the person that gets the bugs in bugzilla).
Why this new terminology? I think
it'll just lead to confusion, since
the new term is hard to use in casual conversation ("I'm the point of
contact on x in Fedora" feels awkward compared "I'm the owner of x
in Fedora") and people will probably stick to the old one. Maybe
even using "maintainer" + "co-maintainer" might be better, because
in normal circumstances who is the owner and who is the co-maintainer
matters only to the people involved in the package, and is irrelevant
for most uses.
Zbyszek
8:54 a.m.
On Wed, Nov 13, 2013 at 03:20:30PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Nov 13, 2013 at 02:52:27PM +0100, Pierre-Yves Chibon wrote:
> - The idea of "owner" of a package disapear. There are only maintainers on
which
> one of them appears to be the dedicated "point of contact" for this
package (ie:
> the person that gets the bugs in bugzilla).
Why this new terminology? I think it'll just lead to confusion,
since
the new term is hard to use in casual conversation ("I'm the point of
contact on x in Fedora" feels awkward compared "I'm the owner of x
in Fedora") and people will probably stick to the old one. Maybe
Well, you can always use maintainer instead of owner ;-)
even using "maintainer" + "co-maintainer" might
be better, because
in normal circumstances who is the owner and who is the co-maintainer
matters only to the people involved in the package, and is irrelevant
for most uses.
The idea is that we do not have two levels of maintainers anymore. We are all
maintainers, just one of them has accepted the task of being the person to
contact for bug reports.
What I would like to see is the disappearance of post/email saying "why did XYZ
touch *my* package?". Now it's not your package anymore, it's a package you
maintain, you do not "own" it. I do realize the change in terminology on pkgdb
might not stop these emails but I would like to try.
In theory, this might also help collaboration as it presents package
maintainance as a shared task which is something that we always want to improve.
I hope this makes sense,
Pierre
9:05 a.m.
Dne 13.11.2013 14:52, Pierre-Yves Chibon napsal(a):
So please, have a look at it, play with it, break it (no seriously,
do, but don't
forget to report how you did it afterward) and if you have any problem/RFE feel
free to note them at:
https://github.com/fedora-infra/packagedb2/
Do I get it right that I can play with ACLs and it will not be pushed to
real Fedora infrastructure?
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
9:27 a.m.
On Wed, Nov 13, 2013 at 04:05:10PM +0100, Miro Hrončok wrote:
Dne 13.11.2013 14:52, Pierre-Yves Chibon napsal(a):
>So please, have a look at it, play with it, break it (no seriously, do, but
don't
>forget to report how you did it afterward) and if you have any problem/RFE feel
>free to note them at:
>
> https://github.com/fedora-infra/packagedb2/
Do I get it right that I can play with ACLs and it will not be
pushed to real Fedora infrastructure?
You do, this is only a testing instance, everything stays on this machine and
when we do the move from pkgdb1 to pkgdb2 we'll re-convert the most recent
pkgdb1 database.
Play as much as you like :)
Pierre
9:57 a.m.
On Wed, 13 Nov 2013 14:52:27 +0100, Pierre-Yves Chibon wrote:
The development instance of pkgdb2 is at:
http://209.132.184.188/
That page says "Version 1.0.0" at the top and "0.1.0" at the bottom,
and you refer to it as pkgdb2.
- The idea of "owner" of a package disapear. There are only
maintainers on which
one of them appears to be the dedicated "point of contact" for this package
(ie:
the person that gets the bugs in bugzilla).
Why not call it "Bugzilla assignee" then?
"Point of contact" is misleading. Other maintainers may acquire the
"watchbugzilla" access and may be contacted, too. It's just a limitation
of bugzilla that there can only be a single default assignee.
What will happen to the SRPM-owner@ email alias?
10:59 a.m.
On Wed, Nov 13, 2013 at 04:57:38PM +0100, Michael Schwendt wrote:
On Wed, 13 Nov 2013 14:52:27 +0100, Pierre-Yves Chibon wrote:
> The development instance of pkgdb2 is at:
>
> http://209.132.184.188/
That page says "Version 1.0.0" at the top and "0.1.0" at the bottom,
and you refer to it as pkgdb2.
> - The idea of "owner" of a package disapear. There are only maintainers on
which
> one of them appears to be the dedicated "point of contact" for this
package (ie:
> the person that gets the bugs in bugzilla).
Why not call it "Bugzilla assignee" then?
Because I do not want us to be linked to a specific bug tracker.
"Point of contact" is misleading. Other maintainers may
acquire the
"watchbugzilla" access and may be contacted, too. It's just a limitation
of bugzilla that there can only be a single default assignee.
Agree on the second part (limitation of bugzilla), but watchbugzilla basically
puts you on the cc list of the bug report while being the point of contact
actually assigns the bug to you.
If we ever get to a place/time where tickets can be assigned to multiple people,
then I guess the notion of 'point of contact' will just vanish and we will be
able to assign tickets to all the maintainers of the package.
What will happen to the SRPM-owner@ email alias?
Currently I believe it sends email to all the users any ACL on the package.
At the moment we didn't plan on making any changes so it should work just the
same.
There has been some thoughts about changing this with maybe two aliases:
- SRPM-maintainers(a)fp.o to go to all people having 'commmit' ACL on the package
- SRPM-watchers(a)fp.o to go to all people with an ACL (whatever the ACL) on the
package
But nothing planned/decided/fixed in stone.
Pierre
8:11 a.m.
On 13 November 2013 16:59, Pierre-Yves Chibon <pingou(a)pingoured.fr> wrote:
On Wed, Nov 13, 2013 at 04:57:38PM +0100, Michael Schwendt wrote:
> On Wed, 13 Nov 2013 14:52:27 +0100, Pierre-Yves Chibon wrote:
>
> > The development instance of pkgdb2 is at:
> >
> > http://209.132.184.188/
>
> That page says "Version 1.0.0" at the top and "0.1.0" at the
bottom,
> and you refer to it as pkgdb2.
>
> > - The idea of "owner" of a package disapear. There are only
maintainers on which
> > one of them appears to be the dedicated "point of contact" for this
package (ie:
> > the person that gets the bugs in bugzilla).
>
> Why not call it "Bugzilla assignee" then?
Because I do not want us to be linked to a specific bug tracker.
Bugee?
--
imalone
http://ibmalone.blogspot.co.uk
5:50 p.m.
Pierre-Yves Chibon wrote:
So please, have a look at it, play with it, break it (no seriously,
do,
but don't forget to report how you did it afterward) and if you have any
problem/RFE feel free to note them at:
https://github.com/fedora-infra/packagedb2/
Why is this on GitHub and not on fedorahosted? Having this on fedorahosted
would allow us to file bugs using our existing Fedora accounts. It would
also make you independent of third-party proprietary (sure, they use git,
but everything else is proprietary!) infrastructure. Fedora stuff should
really be developed on Fedora infrastructure!
One thing which is probably an issue with the import process: I looked at
the package kdelibs-experimental which has been retired, as seen on pkgdb1:
https://admin.fedoraproject.org/pkgdb/acls/name/kdelibs-experimental
(see Status=Deprecated). Yet in pkgdb2 it shows up as a regular orphan:
http://209.132.184.188/package/kdelibs-experimental/
and offers me to retire it (which it already is) or pick it up.
Should I file a ticket for that on GitHub?
Kevin Kofler
7:01 p.m.
On Sat, 16 Nov 2013 00:50:42 +0100
Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Pierre-Yves Chibon wrote:
> So please, have a look at it, play with it, break it (no seriously,
> do, but don't forget to report how you did it afterward) and if you
> have any problem/RFE feel free to note them at:
>
> https://github.com/fedora-infra/packagedb2/
Why is this on GitHub and not on fedorahosted? Having this on
fedorahosted would allow us to file bugs using our existing Fedora
accounts. It would also make you independent of third-party
proprietary (sure, they use git, but everything else is proprietary!)
infrastructure. Fedora stuff should really be developed on Fedora
infrastructure!
We discussed this a few years ago! We decided that it was not up to us
to dictate what hosting upstream projects use, and have left it up to
developers of those projects. We have talked about getting some kind of
syncing setup so we have things also at fedorahosted for those projects
that desire it, but we don't have that in place currently.
It is sad that github doesn't support openid. ;(
One thing which is probably an issue with the import process: I
looked at the package kdelibs-experimental which has been retired, as
seen on pkgdb1:
https://admin.fedoraproject.org/pkgdb/acls/name/kdelibs-experimental
(see Status=Deprecated). Yet in pkgdb2 it shows up as a regular
orphan: http://209.132.184.188/package/kdelibs-experimental/ and
offers me to retire it (which it already is) or pick it up.
Should I file a ticket for that on GitHub?
Yes, if you can, or possibly wait and see if Pierre can just look into
the issue now that you have noted it.
kevin
7:47 p.m.
Kevin Fenzi wrote:
We discussed this a few years ago! We decided that it was not up to
us
to dictate what hosting upstream projects use, and have left it up to
developers of those projects.
But this is NOT an UPSTREAM project, it is a project developed specifically
for Fedora by Fedora people. I see no valid reason whatsoever this is being
developed on third-party infrastructure. Of course, we cannot force the
whole distro to be developed on fedorahosted (not even Ubuntu can do that
with Launchpad), but for our custom infrastructure code, it would make
everyone's lives easier.
Kevin Kofler
7:10 a.m.
Dne 16.11.2013 02:47, Kevin Kofler napsal(a):
But this is NOT an UPSTREAM project, it is a project developed
specifically
for Fedora by Fedora people. I see no valid reason whatsoever this is being
developed on third-party infrastructure. Of course, we cannot force the
whole distro to be developed on fedorahosted (not even Ubuntu can do that
with Launchpad), but for our custom infrastructure code, it would make
everyone's lives easier.
I am not developer of pkgdb2 but if I would, I would also choose github
over fedorahosted.
The reason is simple. Fedorahosted lacks features, is unplesant and need
byrocracy even to create a repository. I've already discussed that on
devel long time ago and I was told that we do not want to make
fedorahosted more like github -- most of you didn't even care. But
unless we do, don't except the developers to use it if it's such a pain
compared to github.
https://lists.fedoraproject.org/pipermail/devel/2013-May/183573.html
From the ideological and polictal side, of course: Using github over
fedorahosted is bad. From the practival part it's oposite.
I admire any Fedora dev who cooses fedorahosted, I really do. It's very
nice of them. But please do not insist on it, while we lacks the level
of user experience that github has. We aren't even close.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
9:09 a.m.
Maybe an RFE:
pkgdb2 should be able to scratch the %{summary} in RPM specfile as the
short summary of the package automatically, especially when some
packages change their summary in the spec.
7:34 a.m.
Miro Hrončok wrote:
The reason is simple. Fedorahosted lacks features, is unplesant and
need
byrocracy even to create a repository.
Creating a repository is actually the only time "bureaucracy" is required.
Giving write permissions just works over FAS. (There's a FAS group for every
repository that is created, the developer only needs to request group
membership through FAS and you can approve it, all self-service in FAS.)
Clones, commits, pushes etc. are plain git (or SVN or whatever you chose!
Fedorahosted is much more flexible than GitHub there) just as on GitHub or
anywhere else. A Trac site is automatically created along with the
repository if requested (you're expected to say in the repository request
whether you want Trac or not, normally you should always say "yes"), it has
bug trackers which work with FAS accounts (and Trac's issue tracker is no
worse than GitHub's, they're actually very similar), a repository browser,
and a wiki that you can edit (no "bureaucracy"). You also get a directory
for file releases below https://fedorahosted.org/releases/ that accepts SCP
uploads.
I really don't see what is missing there, apart from missing automation for
the one-time creation process.
Kevin Kofler
7:50 a.m.
On Fri, Nov 22, 2013 at 02:34:28PM +0100, Kevin Kofler wrote:
Miro Hrončok wrote:
> The reason is simple. Fedorahosted lacks features, is unplesant and need
> byrocracy even to create a repository.
Creating a repository is actually the only time "bureaucracy" is required.
Giving write permissions just works over FAS. (There's a FAS group for every
repository that is created, the developer only needs to request group
membership through FAS and you can approve it, all self-service in FAS.)
Clones, commits, pushes etc. are plain git (or SVN or whatever you chose!
Fedorahosted is much more flexible than GitHub there) just as on GitHub or
anywhere else. A Trac site is automatically created along with the
repository if requested (you're expected to say in the repository request
whether you want Trac or not, normally you should always say "yes"), it has
bug trackers which work with FAS accounts (and Trac's issue tracker is no
worse than GitHub's, they're actually very similar), a repository browser,
and a wiki that you can edit (no "bureaucracy"). You also get a directory
for file releases below https://fedorahosted.org/releases/ that accepts SCP
uploads.
I really don't see what is missing there, apart from missing automation for
the one-time creation process.
You're forgeting, patch/code reviews, possibility to close or refer to a ticket
from the git commit, the possibility to easily follow a project and be informed
of its changes (yes, I know, you can create mailing list and have all the
commits and action from the trac be sent to said list, I already do this for
fedocal) and probably some more feature I'm forgetting.
Anyway, did you see the link in the footer? The one that says 'pkgdb'?
Pierre
5:34 p.m.
By using github you are also eliminating the possibility of some people to contribute to
your project. I personally won't create an account on github. Just because I believe
that open projects should be hosted on open platforms. I'd rather us work out a way to
have an open patch submission and review process.
There is pros and cons of each.
Dennis
Pierre-Yves Chibon <pingou(a)pingoured.fr> wrote:
On Fri, Nov 22, 2013 at 02:34:28PM +0100, Kevin Kofler wrote:
> Miro Hrončok wrote:
> > The reason is simple. Fedorahosted lacks features, is unplesant and
need
> > byrocracy even to create a repository.
>
> Creating a repository is actually the only time "bureaucracy" is
required.
> Giving write permissions just works over FAS. (There's a FAS group
for every
> repository that is created, the developer only needs to request group
> membership through FAS and you can approve it, all self-service in
FAS.)
> Clones, commits, pushes etc. are plain git (or SVN or whatever you
chose!
> Fedorahosted is much more flexible than GitHub there) just as on
GitHub or
> anywhere else. A Trac site is automatically created along with the
> repository if requested (you're expected to say in the repository
request
> whether you want Trac or not, normally you should always say "yes"),
it has
> bug trackers which work with FAS accounts (and Trac's issue tracker
is no
> worse than GitHub's, they're actually very similar), a repository
browser,
> and a wiki that you can edit (no "bureaucracy"). You also get a
directory
> for file releases below https://fedorahosted.org/releases/ that
accepts SCP
> uploads.
>
> I really don't see what is missing there, apart from missing
automation for
> the one-time creation process.
You're forgeting, patch/code reviews, possibility to close or refer to
a ticket
from the git commit, the possibility to easily follow a project and be
informed
of its changes (yes, I know, you can create mailing list and have all
the
commits and action from the trac be sent to said list, I already do
this for
fedocal) and probably some more feature I'm forgetting.
Anyway, did you see the link in the footer? The one that says 'pkgdb'?
Pierre
--
devel mailing list
devel(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
5:56 a.m.
On Sat, Nov 23, 2013 at 05:34:19PM -0600, Dennis Gilmore wrote:
By using github you are also eliminating the possibility of some
people to
contribute to your project. I personally won't create an account on
github. Just because I believe that open projects should be hosted on open
platforms. I'd rather us work out a way to have an open patch submission
and review process.
I accept patches coming in any forms, email, fpaste, pull-request via github,
git request-pull from git itself...
If an upstream only accepts patches coming from the github pull-request
mechanism then I would agree with you, but the fact that you don't want to
create an account on github is not a reason to not contribute on a project.
Pierre
8:41 a.m.
Dne 24.11.2013 00:34, Dennis Gilmore napsal(a):
There is pros and cons of each.
Agreed. And therefore forcing someone to use one of them or cricitice
someone for having Fedora project on Github is something I don't like.
Unless it's a proper policy and if such policy is proposed I would be
against it.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
5:57 a.m.
Pierre-Yves Chibon wrote:
You're forgeting, patch/code reviews,
Export patch from git, attach to new issue in the bug tracker; as the
maintainer, apply it with git am and push it; where's the problem?
possibility to close or refer to a ticket from the git commit,
Referring just works in Trac (use '#' + ticket number, it will create a link
in Trac's display of the commit message).
the possibility to easily follow a project and be informed of its
changes
The Trac timeline has an RSS feed.
Anyway, did you see the link in the footer? The one that says
'pkgdb'?
But the pkgdb2 code is not in there, is it?
Kevin Kofler
6:48 a.m.
On Sun, Nov 24, 2013 at 12:57:25PM +0100, Kevin Kofler wrote:
Pierre-Yves Chibon wrote:
> You're forgeting, patch/code reviews,
Export patch from git, attach to new issue in the bug tracker; as the
maintainer, apply it with git am and push it; where's the problem?
It is possible, but I have to agree that github is more
convenient/efficient than the workflow you describe.
> possibility to close or refer to a ticket from the git commit,
Referring just works in Trac (use '#' + ticket number, it will create a link
in Trac's display of the commit message).
Will it add a notification in the issue tracker?
Regards
Till
8:26 a.m.
On Sun, Nov 24, 2013 at 01:48:53PM +0100, Till Maas wrote:
On Sun, Nov 24, 2013 at 12:57:25PM +0100, Kevin Kofler wrote:
> Pierre-Yves Chibon wrote:
> > You're forgeting, patch/code reviews,
>
> Export patch from git, attach to new issue in the bug tracker; as the
> maintainer, apply it with git am and push it; where's the problem?
It is possible, but I have to agree that github is more
convenient/efficient than the workflow you describe.
> > possibility to close or refer to a ticket from the git commit,
>
> Referring just works in Trac (use '#' + ticket number, it will create a link
> in Trac's display of the commit message).
Will it add a notification in the issue tracker?
If the proper git hooks and trac settings are enabled, it is in theory possible.
I didn't manage to get it to work on the fedocal project when I looked at it.
Pierre
8:48 p.m.
Till Maas wrote:
It is possible, but I have to agree that github is more
convenient/efficient than the workflow you describe.
Huh? The "export patches, attach to issue tracker" workflow allows me to
work with a normal local clone. The GitHub pull request workflow forces me
to create a fork on GitHub and push my clone there (and for some projects,
users who don't know how GitHub works will most likely attempt to use those
forks, even though they aren't actually meant to be used other than as a
source for pull requests; for pkgdb2, this is probably not an issue though
;-) ), then juggling with the 2 different "upstreams" (the true upstream and
the clone it forced me to create).
And GitHub tries to enforce that broken workflow in all silly ways possible.
For example, their issue tracker arbitrarily only accepts image (picture)
files as file uploads, no patches (nor even any other non-image content,
e.g. log files). It is also not possible to file a pull request from
anything other than a repo located on GitHub, you cannot even use a clone
hosted elsewhere, let alone submit an exported patch (the way ReviewBoard,
used e.g. on reviewboard.kde.org, works, a much better patch review
interface, which I guess would be easy to set up on Fedora Hosted if
maintainers think the issue tracker is not good enough).
So from the patch submitter's point of view, GitHub is much worse!
And from the maintainer's point of view, I don't see what's wrong with git
am and git push either. Those are normal git commands you can issue on the
command line, or if (like me) you prefer point-and-click UIs, you can apply
the patch with qgit and push it with git-cola. (By the way, don't ask me why
git-cola doesn't have a menu entry for "git am", or why qgit doesn't
support
even basic repository manipulation such as "git push". At least I can fire
up qgit from git-cola, having it set up as the history viewer.) So you can
just use the same tools you use for your own development, you don't have to
go through some crappy proprietary web interface.
Kevin Kofler
8:25 a.m.
On Sun, Nov 24, 2013 at 12:57:25PM +0100, Kevin Kofler wrote:
Pierre-Yves Chibon wrote:
> You're forgeting, patch/code reviews,
Export patch from git, attach to new issue in the bug tracker; as the
maintainer, apply it with git am and push it; where's the problem?
> possibility to close or refer to a ticket from the git commit,
Referring just works in Trac (use '#' + ticket number, it will create a link
in Trac's display of the commit message).
> the possibility to easily follow a project and be informed of its changes
The Trac timeline has an RSS feed.
> Anyway, did you see the link in the footer? The one that says 'pkgdb'?
But the pkgdb2 code is not in there, is it?
And pkgdb2 is in prod? And your conclusions of the fact that this link is
there are?
Pierre
9:03 a.m.
On Fri, Nov 22, 2013 at 02:34:28PM +0100, Kevin Kofler wrote:
I really don't see what is missing there, apart from missing
automation for
the one-time creation process.
Something I just noticed:
- Github allows to reply to ticket notifications via email instead of
requiring to change to a browser and to re-login there.
Regards
Till
4:19 a.m.
On Sat, Nov 16, 2013 at 12:50:42AM +0100, Kevin Kofler wrote:
One thing which is probably an issue with the import process: I
looked at
the package kdelibs-experimental which has been retired, as seen on pkgdb1:
https://admin.fedoraproject.org/pkgdb/acls/name/kdelibs-experimental
(see Status=Deprecated). Yet in pkgdb2 it shows up as a regular orphan:
http://209.132.184.188/package/kdelibs-experimental/
and offers me to retire it (which it already is) or pick it up.
Should I file a ticket for that on GitHub?
The question is more likely, when did it get retired?
As in:
> It contains the data from pkgdb1 from about a month ago.
I have on my todo to update the database to a more recent version, I'll make
sure to check the status of kdelibs-experimental then.
Thanks for the report!
Pierre
6:03 a.m.
On Sat, Nov 16, 2013 at 11:19:35AM +0100, Pierre-Yves Chibon wrote:
On Sat, Nov 16, 2013 at 12:50:42AM +0100, Kevin Kofler wrote:
> One thing which is probably an issue with the import process: I looked at
> the package kdelibs-experimental which has been retired, as seen on pkgdb1:
> https://admin.fedoraproject.org/pkgdb/acls/name/kdelibs-experimental
> (see Status=Deprecated). Yet in pkgdb2 it shows up as a regular orphan:
> http://209.132.184.188/package/kdelibs-experimental/
> and offers me to retire it (which it already is) or pick it up.
>
> Should I file a ticket for that on GitHub?
The question is more likely, when did it get retired?
As in:
>> It contains the data from pkgdb1 from about a month ago.
I have on my todo to update the database to a more recent version, I'll make
sure to check the status of kdelibs-experimental then.
I have since updated the database and it turned out to be really a bug in pkgdb2
which I fixed:
http://209.132.184.188/package/kdelibs-experimental
Best regards,
Pierre
7:07 p.m.
On Wed, Nov 13, 2013 at 6:52 AM, Pierre-Yves Chibon <pingou(a)pingoured.fr> wrote:
- The idea of "owner" of a package disapear. There are only
maintainers on which
one of them appears to be the dedicated "point of contact" for this package
(ie:
the person that gets the bugs in bugzilla).
Koji also has a notion of the "owner" of a package. It treats owners
specially in at least two ways:
1. The owner of a package is sent e-mails for all actions in the
buildsystem regarding packages they own, regardless of who initiated
them.
2. Only the owner of a package is permitted to tag or untag all builds
for that package. Co-maintainers may only tag or untag builds they
submitted.
#1 can hopefully be fixed by the famed fedmsg->e-mail gateway, so it
can probably be safely ignored.
#2, not so much. You rarely need to manually mess around with koji
tags, but when you do need it, you *really* need it. ;-)
Do you all plan to fix koji to permit all comaintainers to perform tag
operations on a package as part of enabling SIG maintainership? If
not, the "point of contact" terminology wouldn't be very accurate.
-T.C.
7:31 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
El Fri, 15 Nov 2013 18:07:41 -0700
"T.C. Hollingsworth" <tchollingsworth(a)gmail.com> escribió:
On Wed, Nov 13, 2013 at 6:52 AM, Pierre-Yves Chibon
<pingou(a)pingoured.fr> wrote:
> - The idea of "owner" of a package disapear. There are only
> maintainers on which one of them appears to be the dedicated "point
> of contact" for this package (ie: the person that gets the bugs in
> bugzilla).
Koji also has a notion of the "owner" of a package. It treats owners
specially in at least two ways:
1. The owner of a package is sent e-mails for all actions in the
buildsystem regarding packages they own, regardless of who initiated
them.
True.
2. Only the owner of a package is permitted to tag or untag all
builds
for that package. Co-maintainers may only tag or untag builds they
submitted.
Not at all true. Any one can tag a build into an unlocked tag such as
f20-updates-candidate tags such as f20-updates-testing are protected
and can only be tagged into by an admin in koji. Koji has no concept of
acls, It doesn't know about co-maintainers or treat them any
differently.
#1 can hopefully be fixed by the famed fedmsg->e-mail gateway, so
it
can probably be safely ignored.
#2, not so much. You rarely need to manually mess around with koji
tags, but when you do need it, you *really* need it. ;-)
Do you all plan to fix koji to permit all comaintainers to perform tag
operations on a package as part of enabling SIG maintainership? If
not, the "point of contact" terminology wouldn't be very accurate.
there is actually nothing to change here.
Dennis
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJShsrZAAoJEH7ltONmPFDRtBoP/A8UxS1clKDTR6LJN3cY1Tca
pWtIGx/EfGitNjZMimy3jeC6XMq2gq6b+9ZywsezDJ7zt0+GreW7niPlneuhHL9G
66h50TsDRaKfFUM6AT3G/MkLyr5nvUwxJZ/HQjDVtJo6yZqUin6wOLLevtk7xOuq
jpqiVxJTCbmLIG3FEfH+agkgvE6APAuni6JoFXB0xE7zy7QboY95AwGnWRn3YYp1
QG+9ZzdQd8lyzv3zReNnErdzv1vXwgmOC3Llcjrtq2hbMOw9v9tJKmdSjgoUPoUz
zSNvqQo1i7xX+8iujSnLf9Z1hz5p+7q9Rk7PFEnCxYGp4gL/TeTAlvswm2uMKgkx
/4ea8rHBHcwHeeoYbbC/MrIMzsc4tUe5gXflSdUCd2G4gAzMiDvWvY0rYVPW3JT+
0esn7nnC7DR2dhJsFyon3CHrA7jv//hIASjcnBp9ZK1Gt3dalb9mNYyWCX++o8MX
qUo24IPFP6ZCb3TOpuCtvD4MRu/soMjCwn/XXg+obv128K5d6l5KYGOlExHh1s50
OiHnzELDMuXvokFEVA0YU8R+vo9FuVY+bSbXm2IgNuKcJEqUqK7xA46Ez++XFsuo
6vfR8UzR4GZvQLA5+iNmgxiJVTGIAVIxNvbaR3oEpk0cet5jjgaq76VCqgWXOLnd
JKsmmxhYaT+NBZqxp2fS
=H9+L
-----END PGP SIGNATURE-----
8:14 p.m.
On Fri, Nov 15, 2013 at 6:31 PM, Dennis Gilmore <dennis(a)ausil.us> wrote:
Not at all true. Any one can tag a build into an unlocked tag such
as
f20-updates-candidate tags such as f20-updates-testing are protected
and can only be tagged into by an admin in koji. Koji has no concept of
acls, It doesn't know about co-maintainers or treat them any
differently.
Weird, I couldn't make koji untag a package from rawhide once and had
to bug the owner to do so. I thought this was why, but I guess it was
just PEBKAC. ;-)
Sorry for the noise.
-T.C.
9:43 a.m.
On 11/13/2013 02:52 PM, Pierre-Yves Chibon wrote:
Dear all,
So please, have a look at it, play with it, break it (no seriously, do, but don't
forget to report how you did it afterward) and if you have any problem/RFE feel
free to note them at:
https://github.com/fedora-infra/packagedb2/
Hey,
that looks great!
I just tried to file an RFE against it, sadly github just returns a 404.
My idea was that it makes sense for end users to search for packages and
sub-packages as well. This would make reporting bugs against
sub-packages way easier, because one could find that information way easier.
Matthias
7:20 a.m.
On Wed, Nov 13, 2013 at 02:52:27PM +0100, Pierre-Yves Chibon wrote:
I am at a point where I think it starts to look good, the unit-tests
are passing
and I seem to be able to do what I want with it. Thus I thought this would be a
good time to call for testers and collect bug reports and RFE.
The development instance of pkgdb2 is at:
http://209.132.184.188/
[...]
So please, have a look at it, play with it, break it (no seriously,
do, but don't
forget to report how you did it afterward) and if you have any problem/RFE feel
free to note them at:
Just a heads-up, christmas holidays are coming our way and our agenda is to push
pkgdb2 in production as soon as possible after the release of F20.
This means that if you want to poke at it, if you find bugs or have any RFE you
should really do this as early as possible so that there is time to fix/improve
before we release.
Pierre
1:29 p.m.
On Tue, Dec 10, 2013 at 5:20 AM, Pierre-Yves Chibon <pingou(a)pingoured.fr> wrote:
On Wed, Nov 13, 2013 at 02:52:27PM +0100, Pierre-Yves Chibon wrote:
> I am at a point where I think it starts to look good, the unit-tests are passing
> and I seem to be able to do what I want with it. Thus I thought this would be a
> good time to call for testers and collect bug reports and RFE.
>
> The development instance of pkgdb2 is at:
>
> http://209.132.184.188/
[...]
> So please, have a look at it, play with it, break it (no seriously, do, but
don't
> forget to report how you did it afterward) and if you have any problem/RFE feel
> free to note them at:
Just a heads-up, christmas holidays are coming our way and our agenda is to push
pkgdb2 in production as soon as possible after the release of F20.
This means that if you want to poke at it, if you find bugs or have any RFE you
should really do this as early as possible so that there is time to fix/improve
before we release.
Can we get a "my packages" button? Or am I blind and not seeing one?
Dan
2:58 a.m.
On Wed, 2013-12-11 at 09:55 +0100, Emmanuel Seyman wrote:
* Dan Mashal [10/12/2013 11:29] :
>
> Can we get a "my packages" button? Or am I blind and not seeing one?
There's a "Restrict to owner:" form where you can enter your FAS username.
Also works if you just click on your nick on the top right corner.
Pierre
2:52 p.m.
On 12/10/2013 02:20 PM, Pierre-Yves Chibon wrote:
> So please, have a look at it, play with it, break it (no seriously, do, but
don't
> forget to report how you did it afterward) and if you have any problem/RFE feel
> free to note them at:
Just a heads-up, christmas holidays are coming our way and our agenda is to push
pkgdb2 in production as soon as possible after the release of F20.
This means that if you want to poke at it, if you find bugs or have any RFE you
should really do this as early as possible so that there is time to fix/improve
before we release.
Wow, looks great in general.
I'd love to see a feature, where it's possible to search for
sub-packages as well. It would make many things easier.
Matthias
2:19 a.m.
On Tue, Dec 10, 2013 at 09:52:58PM +0100, Matthias Runge wrote:
On 12/10/2013 02:20 PM, Pierre-Yves Chibon wrote:
>
>> So please, have a look at it, play with it, break it (no seriously, do, but
don't
>> forget to report how you did it afterward) and if you have any problem/RFE feel
>> free to note them at:
>
> Just a heads-up, christmas holidays are coming our way and our agenda is to push
> pkgdb2 in production as soon as possible after the release of F20.
>
> This means that if you want to poke at it, if you find bugs or have any RFE you
> should really do this as early as possible so that there is time to fix/improve
> before we release.
>
Wow, looks great in general.
Thanks
I'd love to see a feature, where it's possible to search for
sub-packages as well. It would make many things easier.
hm, the problem here is that pkgdb per definition does not know about
sub-packages.
What is the idea behing? Knowing the ACL on a specific sub-package or knowing
generic information about a specific sub-package?
In the first case, I don't know yet how to handle it, in the second case I
believe /packages might be a better application for this:
https://apps.fedoraproject.org/packages
(Note the link from packages to pkgdb even on a sub-package page:
https://apps.fedoraproject.org/packages/qt-devel )
Pierre
10:18 a.m.
On 12/11/2013 09:19 AM, Pierre-Yves Chibon wrote:
On Tue, Dec 10, 2013 at 09:52:58PM +0100, Matthias Runge wrote:
> On 12/10/2013 02:20 PM, Pierre-Yves Chibon wrote:
>>
>>> So please, have a look at it, play with it, break it (no seriously, do, but
don't
>>> forget to report how you did it afterward) and if you have any problem/RFE
feel
>>> free to note them at:
>>
>> Just a heads-up, christmas holidays are coming our way and our agenda is to push
>> pkgdb2 in production as soon as possible after the release of F20.
>>
>> This means that if you want to poke at it, if you find bugs or have any RFE you
>> should really do this as early as possible so that there is time to fix/improve
>> before we release.
>>
> Wow, looks great in general.
Thanks
> I'd love to see a feature, where it's possible to search for
> sub-packages as well. It would make many things easier.
hm, the problem here is that pkgdb per definition does not know about
sub-packages.
What is the idea behing? Knowing the ACL on a specific sub-package or knowing
generic information about a specific sub-package?
The idea behind is:
you have some application with an issue/error. You'll do rpm -qf
<filename> and will get a package name, not necessarily the source
package name.
When filing a bug against a package, you'll need to know the source
package name.
Since packages should know their sub-packages, this would be easiest to
link them both from here.
Matthias
9:19 p.m.
On Wed, 2013-12-11 at 17:18 +0100, Matthias Runge wrote:
The idea behind is:
you have some application with an issue/error. You'll do rpm -qf
<filename> and will get a package name, not necessarily the source
package name.
When filing a bug against a package, you'll need to know the source
package name.
rpm -qi gives you the source package.
--
Mathieu
2:02 a.m.
On 12/12/2013 04:19 AM, Mathieu Bridon wrote:
On Wed, 2013-12-11 at 17:18 +0100, Matthias Runge wrote:
> The idea behind is:
>
> you have some application with an issue/error. You'll do rpm -qf
> <filename> and will get a package name, not necessarily the source
> package name.
> When filing a bug against a package, you'll need to know the source
> package name.
rpm -qi gives you the source package.
So, why do we hide it this way?
How is a new user or a GUI-only person able to find the right package to
file a bug against? A nasty person might even say: this is by purpose ;-)
Matthias
2:15 a.m.
On Thu, 2013-12-12 at 09:02 +0100, Matthias Runge wrote:
On 12/12/2013 04:19 AM, Mathieu Bridon wrote:
> On Wed, 2013-12-11 at 17:18 +0100, Matthias Runge wrote:
>> The idea behind is:
>>
>> you have some application with an issue/error. You'll do rpm -qf
>> <filename> and will get a package name, not necessarily the source
>> package name.
>> When filing a bug against a package, you'll need to know the source
>> package name.
>
> rpm -qi gives you the source package.
>
>
So, why do we hide it this way?
How is a new user or a GUI-only person
Well, you were talking about someone who had just used rpm -qf, so in
that context rpm -qi made a lot of sense.
able to find the right package to
file a bug against? A nasty person might even say: this is by purpose ;-)
As far as I know, pkgdb is not targeted at end users but at package
maintainers (as it handles the ACLs on packages).
/packages is more targeted at users, and it does show what is the base
package for a given subpackage.
For example: https://apps.fedoraproject.org/packages/libcangjie-devel
In case you miss the "Subpackage of XXX", you can just click on the
"Bugzilla" link, which will open a bug against the proper base package.
You could argue that the two apps should be only one, but that's a
different discussion. (and the people actually doing the work to
implement and maintain those apps feel that it's better to separate
them)
--
Mathieu
2:25 a.m.
On 12/12/2013 09:15 AM, Mathieu Bridon wrote:
> How is a new user or a GUI-only person
Well, you were talking about someone who had just used rpm -qf, so in
that context rpm -qi made a lot of sense.
Yes, you're right, in that context, it makes sense.
For example:
https://apps.fedoraproject.org/packages/libcangjie-devel
In case you miss the "Subpackage of XXX", you can just click on the
"Bugzilla" link, which will open a bug against the proper base package.
OK; that looks better; I didn't knew that, so we might promote it a bit
more?
Thanks!
Matthias
6:23 a.m.
Dne 10.12.2013 14:20, Pierre-Yves Chibon napsal(a):
On Wed, Nov 13, 2013 at 02:52:27PM +0100, Pierre-Yves Chibon wrote:
> I am at a point where I think it starts to look good, the unit-tests are passing
> and I seem to be able to do what I want with it. Thus I thought this would be a
> good time to call for testers and collect bug reports and RFE.
>
> The development instance of pkgdb2 is at:
>
> http://209.132.184.188/
[...]
> So please, have a look at it, play with it, break it (no seriously, do, but
don't
> forget to report how you did it afterward) and if you have any problem/RFE feel
> free to note them at:
Just a heads-up, christmas holidays are coming our way and our agenda is to push
pkgdb2 in production as soon as possible after the release of F20.
This means that if you want to poke at it, if you find bugs or have any RFE you
should really do this as early as possible so that there is time to fix/improve
before we release.
Pierre
Actually, are you using some error monitoring? For example the
"packages" [1] application quite often does not work as expected, e.g.
today I have clicked on sources tab and nothing happens, just later I
was able to get 500 error. I am too lazy to investigate and report such
issues, so I am wondering, if you are going proactively monitor such
issues in pkgdb2.
Vít
[1] https://apps.fedoraproject.org/packages/
7:42 a.m.
On Thu, Dec 12, 2013 at 01:23:12PM +0100, Vít Ondruch wrote:
Dne 10.12.2013 14:20, Pierre-Yves Chibon napsal(a):
>On Wed, Nov 13, 2013 at 02:52:27PM +0100, Pierre-Yves Chibon wrote:
>>I am at a point where I think it starts to look good, the unit-tests are passing
>>and I seem to be able to do what I want with it. Thus I thought this would be a
>>good time to call for testers and collect bug reports and RFE.
>>
>>The development instance of pkgdb2 is at:
>>
>> http://209.132.184.188/
>[...]
>
>>So please, have a look at it, play with it, break it (no seriously, do, but
don't
>>forget to report how you did it afterward) and if you have any problem/RFE feel
>>free to note them at:
>Just a heads-up, christmas holidays are coming our way and our agenda is to push
>pkgdb2 in production as soon as possible after the release of F20.
>
>This means that if you want to poke at it, if you find bugs or have any RFE you
>should really do this as early as possible so that there is time to fix/improve
>before we release.
>
Actually, are you using some error monitoring? For example the
"packages" [1] application quite often does not work as expected,
e.g. today I have clicked on sources tab and nothing happens, just
later I was able to get 500 error. I am too lazy to investigate and
report such issues, so I am wondering, if you are going proactively
monitor such issues in pkgdb2.
Well pkgdb2 and packages are quite different from a technology point of view,
but this might answer your question:
http://jenkins.cloud.fedoraproject.org/job/PackageDB2/
:)
Pierre
9:45 a.m.
Dne 12.12.2013 14:42, Pierre-Yves Chibon napsal(a):
On Thu, Dec 12, 2013 at 01:23:12PM +0100, Vít Ondruch wrote:
> Dne 10.12.2013 14:20, Pierre-Yves Chibon napsal(a):
>> On Wed, Nov 13, 2013 at 02:52:27PM +0100, Pierre-Yves Chibon wrote:
>>> I am at a point where I think it starts to look good, the unit-tests are
passing
>>> and I seem to be able to do what I want with it. Thus I thought this would be
a
>>> good time to call for testers and collect bug reports and RFE.
>>>
>>> The development instance of pkgdb2 is at:
>>>
>>> http://209.132.184.188/
>> [...]
>>
>>> So please, have a look at it, play with it, break it (no seriously, do, but
don't
>>> forget to report how you did it afterward) and if you have any problem/RFE
feel
>>> free to note them at:
>> Just a heads-up, christmas holidays are coming our way and our agenda is to push
>> pkgdb2 in production as soon as possible after the release of F20.
>>
>> This means that if you want to poke at it, if you find bugs or have any RFE you
>> should really do this as early as possible so that there is time to fix/improve
>> before we release.
>>
> Actually, are you using some error monitoring? For example the
> "packages" [1] application quite often does not work as expected,
> e.g. today I have clicked on sources tab and nothing happens, just
> later I was able to get 500 error. I am too lazy to investigate and
> report such issues, so I am wondering, if you are going proactively
> monitor such issues in pkgdb2.
Well pkgdb2 and packages are quite different from a technology point of view,
but this might answer your question:
http://jenkins.cloud.fedoraproject.org/job/PackageDB2/
:)
Pierre
I was not speaking about CI, but about case when something wrong happens
to users. It will probably generate exception in your application, so if
you are notified about such errors?
Vít
5:15 a.m.
On Thu, Dec 12, 2013 at 04:45:22PM +0100, Vít Ondruch wrote:
Dne 12.12.2013 14:42, Pierre-Yves Chibon napsal(a):
>On Thu, Dec 12, 2013 at 01:23:12PM +0100, Vít Ondruch wrote:
>>Dne 10.12.2013 14:20, Pierre-Yves Chibon napsal(a):
>>>On Wed, Nov 13, 2013 at 02:52:27PM +0100, Pierre-Yves Chibon wrote:
>>>>I am at a point where I think it starts to look good, the unit-tests are
passing
>>>>and I seem to be able to do what I want with it. Thus I thought this
would be a
>>>>good time to call for testers and collect bug reports and RFE.
>>>>
>>>>The development instance of pkgdb2 is at:
>>>>
>>>> http://209.132.184.188/
>>>[...]
>>>
>>>>So please, have a look at it, play with it, break it (no seriously, do,
but don't
>>>>forget to report how you did it afterward) and if you have any
problem/RFE feel
>>>>free to note them at:
>>>Just a heads-up, christmas holidays are coming our way and our agenda is to
push
>>>pkgdb2 in production as soon as possible after the release of F20.
>>>
>>>This means that if you want to poke at it, if you find bugs or have any RFE
you
>>>should really do this as early as possible so that there is time to
fix/improve
>>>before we release.
>>>
>>Actually, are you using some error monitoring? For example the
>>"packages" [1] application quite often does not work as expected,
>>e.g. today I have clicked on sources tab and nothing happens, just
>>later I was able to get 500 error. I am too lazy to investigate and
>>report such issues, so I am wondering, if you are going proactively
>>monitor such issues in pkgdb2.
>Well pkgdb2 and packages are quite different from a technology point of view,
>but this might answer your question:
> http://jenkins.cloud.fedoraproject.org/job/PackageDB2/
I was not speaking about CI, but about case when something wrong
happens to users. It will probably generate exception in your
application, so if you are notified about such errors?
That is something we have been thinking about for some time but we have nothing
in place at the moment.
Pierre
3795
days inactive
3825
days old
44 comments
16 participants
participants (16)
-
Christopher Meng -
Dan Mashal -
Dennis Gilmore -
Emmanuel Seyman -
Ian Malone -
Kevin Fenzi -
Kevin Kofler -
Mathieu Bridon -
Matthias Runge -
Michael Schwendt -
Miro Hrončok -
Pierre-Yves Chibon -
T.C. Hollingsworth -
Till Maas -
Vít Ondruch -
Zbigniew Jędrzejewski-Szmek