Re: [gentoo-dev] [RFC Maintainer-Wanted Bugs/Cleaning]
On Monday 29 May 2006 20:13, Jakub Moc wrote: > Otherwise, some review used to be done, but there's been a negative > opinion about closing bugs w/ sucky broken ebuilds as WONTFIX/CANTFIX > expressed by some of the devs probably because neither of those resolutions are generally correct sucky broken ebuilds get feedback as to what needs to change and a LATER resolution WONTFIX means the package itself is inappropriate for the tree -mike pgpRLRLrtt6gz.pgp Description: PGP signature
Re: [gentoo-dev] [RFC Maintainer-Wanted Bugs/Cleaning]
Mark Loeser wrote: > Basically, it would be something that allowed you to "browse" the current > tree of submitted ebuilds. This way users that submit something can > categorize it for devs to easily look for ebuilds they may be interested > in, and we can make it so we could easily grab the ebuilds from this hacked > up idea of a tree. It would make it a lot easier to do automated checks > against submitted ebuilds for QA issues, and we would offload all of those > submissions from bugs.g.o to this app. I guess you could think of it as > the overlays.g.o idea, but I tend to think overlays are experimental > things that aren't necessarily going to be added to the tree. This > would be for ebuilds/packages that are ready to be added to the tree, > but just lack someone that wants to maintain them. A big advantage of the current system is that people tend to add bug reports to those maintainer-wanted ebuild bugs, so the community can actually iterate through ebuilds for a non-tree package without too much pain. Separating the pending ebuilds from bugs would make that harder. -g2boojum- signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC Maintainer-Wanted Bugs/Cleaning]
Robin H. Johnson wrote: > Could we establish policies for closing them or leaving them to sit > open? > > - Upstream dead, previously submitted URLs no longer functional (yes, > there are actually some like this!). > - No ebuild included. > - Upstream says obsolete in favour of another package. > - Dev notes obsolete in favour of another package - suggest it to the > submitter, and see what they say. > - Major unresolved security issues. > - Excessive complexity / unsuitable for ebuild installs (eg apps that > are meant to be built and run from the same directory). More or less what I've been doing for past few months... Today, I've also closed all ebuild requests 1+ year old w/ zero activity as CANTFIX, asking the reporter to attach an ebuild. Bugs like "I'd like to see foo/bar in portage, ktnxbye" don't need to sit in bugzilla for ages if noone is interested, not really useful. (And - as mentioned before, some automation of the process would be nice ;) > At the same time, existing developers and teams should be encouraged to > look at those under maintainer-wanted, and consider stuff there. > I try to keep an eye out for app-backup and other fields that I'm > involved in. Also, please really close useless cruft when you come across it (see above). -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC Maintainer-Wanted Bugs/Cleaning]
On Mon, May 29, 2006 at 07:30:25PM -0400, Alec Warner wrote: > So we created this awesome alias to put ebuilds that need a maintainer. > Good idea at the time, decent idea still. The problem? We have nearly > 2000 open bugs assigned to maintainer-wanted[1]. I would like to > discuss policy on these. Do we keep them, do we get a group of people > to slowly review and discard them? Do we mind having a ton of things > open like this (a quasi-ebuild db of sorts). Is bugs the right place > FOR THIs sort of thing, or can we improve somewhere/how? Could we establish policies for closing them or leaving them to sit open? - Upstream dead, previously submitted URLs no longer functional (yes, there are actually some like this!). - No ebuild included. - Upstream says obsolete in favour of another package. - Dev notes obsolete in favour of another package - suggest it to the submitter, and see what they say. - Major unresolved security issues. - Excessive complexity / unsuitable for ebuild installs (eg apps that are meant to be built and run from the same directory). I'm in favour of leaving stuff sitting there, until a developer with a need comes along (I wouldn't use an untrusted tree even if there was one). At the same time, existing developers and teams should be encouraged to look at those under maintainer-wanted, and consider stuff there. I try to keep an eye out for app-backup and other fields that I'm involved in. -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpEHE0qwEgfq.pgp Description: PGP signature
Re: [gentoo-dev] [RFC Maintainer-Wanted Bugs/Cleaning]
On 30/05/06, Mark Loeser <[EMAIL PROTECTED]> wrote: Basically, it would be something that allowed you to "browse" the current tree of submitted ebuilds. This way users that submit something can categorize it for devs to easily look for ebuilds they may be interested in, and we can make it so we could easily grab the ebuilds from this hacked up idea of a tree. Hmm something like a tree, containing ebuilds, that people can check out and browse... :) Comments on this idea are appreciated. I wouldn't mind helping write it and maintain it, but having interest and support in doing something like this is definately going to be needed :) The idea of an unmaintained tree has come up before and been shot down because (paraphrasing) 1. "nobody will check the ebuilds" 2. "nobody will maintain it" 3. "nobody will bother marking stuff stable" and 4."it will be a security nightmare". Personally I think it would be fun to just throw open the gates and have an open git (or other dscms) "no-guarantees" repository that pulls from the main tree every day, and which anyone with an email address can sign up for and then push their own stuff to. Or maybe some wiki-frontend to a branch of the portage tree. Yeah there would be some security issues and vandalism just like any open content system. Nevertheless, It would be a very interesting experiment in opening ebuild development and maintenance to a larger audience. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC Maintainer-Wanted Bugs/Cleaning]
Mark Loeser wrote: > Yea, the current situation has quickly turned into a mess. I definately > think that QA should definately be watching > maintainer-wanted/maintainer-needed and helping clean up new ebuilds, or > removing old unmaintained packages that no one cares about anymore. A bugzilla feature to automatically close bugs these bugs after a set period of inactivity would certainly help. Dunno if it's possible, though. :) Otherwise, some review used to be done, but there's been a negative opinion about closing bugs w/ sucky broken ebuilds as WONTFIX/CANTFIX expressed by some of the devs; as it stands now - it's basically impossible to reasonably track the bugs unless it can be sorted by status and users reopen the bugs when they think they've fixed the outstanding issues... Finally - I'd suggest marking all ebuild *requests* as CANTFIX or NEEDINFO or whatever you think would be best resolution, there's tons of bugs w/ ebuilds submitted that can't find a maintainer. If you want something in portage, do you homework at least and attempt an ebuild. Just my $0.02... -- Best regards, Jakub Moc mailto:[EMAIL PROTECTED] GPG signature: http://subkeys.pgp.net:11371/pks/lookup?op=get&search=0xCEBA3D9E Primary key fingerprint: D2D7 933C 9BA1 C95B 2C95 B30F 8717 D5FD CEBA 3D9E ... still no signature ;) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC Maintainer-Wanted Bugs/Cleaning]
Alec Warner <[EMAIL PROTECTED]> said: > So we created this awesome alias to put ebuilds that need a maintainer. > Good idea at the time, decent idea still. The problem? We have nearly > 2000 open bugs assigned to maintainer-wanted[1]. I would like to > discuss policy on these. Do we keep them, do we get a group of people > to slowly review and discard them? Do we mind having a ton of things > open like this (a quasi-ebuild db of sorts). Is bugs the right place > for this sort of thing, or can we improve somewhere/how? Yea, the current situation has quickly turned into a mess. I definately think that QA should definately be watching maintainer-wanted/maintainer-needed and helping clean up new ebuilds, or removing old unmaintained packages that no one cares about anymore. The problem with maintainer-wanted is the pure number of possible packages we *could* have in the tree, but no one wants to add. After discussing this briefly with antarus, I agree that it might be cool to write up our own homebrewed app to handle this. Basically, it would be something that allowed you to "browse" the current tree of submitted ebuilds. This way users that submit something can categorize it for devs to easily look for ebuilds they may be interested in, and we can make it so we could easily grab the ebuilds from this hacked up idea of a tree. It would make it a lot easier to do automated checks against submitted ebuilds for QA issues, and we would offload all of those submissions from bugs.g.o to this app. I guess you could think of it as the overlays.g.o idea, but I tend to think overlays are experimental things that aren't necessarily going to be added to the tree. This would be for ebuilds/packages that are ready to be added to the tree, but just lack someone that wants to maintain them. Comments on this idea are appreciated. I wouldn't mind helping write it and maintain it, but having interest and support in doing something like this is definately going to be needed :) -- Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgp5aKA0jGhzU.pgp Description: PGP signature
[gentoo-dev] [RFC Maintainer-Wanted Bugs/Cleaning]
So we created this awesome alias to put ebuilds that need a maintainer. Good idea at the time, decent idea still. The problem? We have nearly 2000 open bugs assigned to maintainer-wanted[1]. I would like to discuss policy on these. Do we keep them, do we get a group of people to slowly review and discard them? Do we mind having a ton of things open like this (a quasi-ebuild db of sorts). Is bugs the right place for this sort of thing, or can we improve somewhere/how? [1] http://tinyurl.com/m3dmq signature.asc Description: OpenPGP digital signature