Re: [gentoo-dev] Handling of keywording bugs with only one arch
On 03/12/2010 09:18 PM, Petteri Räty wrote: There seems to be two different schools on who to assign a keywording bug with only a single arch. I have myself assigned it to the arch in question but there's a difference of opinion here: http://bugs.gentoo.org/show_bug.cgi?id=272160#c5 Let's get agreed on a single approach and I will add a note here: http://devmanual.gentoo.org/keywording/index.html I naturally support the approach I have been doing as I think the arch team is the one in charge. Regards, Petteri So let's summarize for assigning to the single arch: Against (and my comments on why they don't apply): - Comments would only go to arch team after resolving: * maintainer is still in Cc or Reporter - Arch teams not in charge of fixing problems * If problems come up they deserve a new bug as a dependency * one bug per issue and a stabilization bug is about stabilization - Maintainer being able to decide when to go stable * Bug wranglers should still assign to maintainers for their ack * The maintainer assigns it to the arch team In support (and my comments in support): - Can be used as a gentle reminder for slacker arches - The arch teams are actually ones doing the work to resolve the bug * As they are the ones to mark it as resolved it makes sense for them to be the assignees So based on this I propose that I will write this down in appropriate places in to our documentation and commit a week from now. Please object if you don't agree and we can discuss some more. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] when to use a function and an implementation use flag.
On 03/24/2010 08:30 PM, Peter Hjalmarsson wrote: For qemu-kvm the problem is that there is only one implementation (i.e. gnutls), and if I want to have ssl support I have to enable gnutls for this package. In this case the ebuild should have only ssl use flag. When I wrote a bug about this I got a rather short reply from maintainer about pointing me to the policy about this. Where did he point you to? So I have a question: Is there no policy about this? The policy is that USE=ssl controls whether to enable ssl support in general. Then the specific use flags like gnutls and openssl control what implementation to use if the package supports multiple. USE=ssl -- should always give you ssl support If there is could someone please point me towards it and also it in that case may be time to update the gentoo development guide. [1] http://devmanual.gentoo.org/general-concepts/use-flags/index.html#conflicting-use-flags If you read the example code you see what I said is already done in the example code. Opened a bug for qemu-kvm: http://bugs.gentoo.org/show_bug.cgi?id=311627 Opened a bug for repoman: http://bugs.gentoo.org/show_bug.cgi?id=311629 Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] RFC: changing ssl use flag descriptions and unify behavior
See this thread for background: http://archives.gentoo.org/gentoo-dev/msg_0673a33fe75961e510872fd2c1044ced.xml I think we should go through all the ssl use flag using packages and unify the use flag descriptions and behavior to the following standing policy (handed down probably): 1) packages always have the general ssl use flag to control whether to enable ssl at all 2) If the package supports multiple backends then there's use flags for gnutls, openssl or nss. EAPI 2 use defaults will be used to communicate upstream defaults if any. If they are all turned of select the default (ssl being on). No objections and I will open a tracker a week from now and let's see who joins up to go through packages and open bugs. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Handling of keywording bugs with only one arch
On 03/27/2010 04:51 PM, Alex Alexander wrote: The only reason I don't really like this is because it breaks consistency. We have a ground rule, assign to maintainer, CC arch(es). Why make it more complicated? I have a feeling people will continue CCing arches out of habit. I don't think we should punish people for not doing it this way but consider it the preferred way when doing new bugs. The initial point here was to tell arches that assigning bugs directly to them is not wrong. Regards, Petteri signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: Handling of keywording bugs with only one arch
* Petteri Räty betelge...@gentoo.org: So let's summarize for assigning to the single arch: In support (and my comments in support): - Can be used as a gentle reminder for slacker arches And if not only one arch or single arch is slacking? I guess you would find another gentle way to remind them. How about a tool generating mails to arch teams, which lists all STABLEREQ, KEQWORDREQ bugs to which the arch team is CC'ed for a month? (Or probably easier or possible at all: which weren't changed for 30 days.)
Re: [gentoo-dev] Re: Handling of keywording bugs with only one arch
On Sat, Mar 27, 2010 at 4:45 PM, Torsten Veller ml...@veller.net wrote: * Petteri Räty betelge...@gentoo.org: So let's summarize for assigning to the single arch: In support (and my comments in support): - Can be used as a gentle reminder for slacker arches And if not only one arch or single arch is slacking? I guess you would find another gentle way to remind them. How about a tool generating mails to arch teams, which lists all STABLEREQ, KEQWORDREQ bugs to which the arch team is CC'ed for a month? (Or probably easier or possible at all: which weren't changed for 30 days.) I'd opt for a webpage personally. I have found that push-nag systems work well at first until the nagging increases to a level where the nag-ee just filters the mail away. This happens often at work. For example I get emails telling me to delete unused perforce clients; but those mails just get marked as read by a filter and archived. Could we generate a bugzilla search for arch teams? Do arch teams already use existing bugzilla functionality? -A
Re: [gentoo-dev] Re: Handling of keywording bugs with only one arch
Alec Warner wrote: Could we generate a bugzilla search for arch teams? Do arch teams already use existing bugzilla functionality? At least when i was with the ppc team, we had a bugzie search. And bugzie already sorts your query for you. I guess it could be made to only show keyword=STABLEREQ, bug changed = -1month since bug creation, assigned OR cc contains ppc@ or something like that. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Python 3.1: Stabilization and news item
On Fri, Mar 26, 2010 at 05:27:46PM +, Jeremy Olexa wrote: On Fri, 26 Mar 2010 16:28:29 +, Alec Warner anta...@gentoo.org wrote: On Fri, Mar 26, 2010 at 4:08 PM, Dale rdalek1...@gmail.com wrote: As a user, I still think this could turn into a real mess. ??I think there will be quite a few that will see python being updated, run python-updater and switch it to the new python. ??At that point, it is going to hit the fan. ??I know because this is what I always do. ??News item or not, when python gets updated, I run python-updater and make sure it is selected. If you don't bother reading news items or messages from packages, there is nothing we can do. I don't feel that this is an excuse for holding up stabilization. * Messages for package dev-lang/python-3.1.2: * * WARNING! * Many Python modules haven't been ported yet to Python 3.*. * Python 3 hasn't been activated and Python wrapper is still configured to use Python 2. * You can manually activate Python 3.1 using `eselect python set python3.1`. * It is recommended to currently have Python wrapper configured to use Python 2. * Having Python wrapper configured to use Python 3 is unsupported. The message above looks pretty clear to me. It works, but don't make it the default. Having it marked stable and being able to use it as the default python are two separate things, and the maintainer is making it very clear in this message that it can't be the default python. William pgp5kJU5CN4ta.pgp Description: PGP signature
[gentoo-dev] reminding slacker arch's to handle bugs
On Sat, Mar 27, 2010 at 05:45:51PM +0100, Torsten Veller wrote: * Petteri R?ty betelge...@gentoo.org: So let's summarize for assigning to the single arch: In support (and my comments in support): - Can be used as a gentle reminder for slacker arches And if not only one arch or single arch is slacking? I guess you would find another gentle way to remind them. How about a tool generating mails to arch teams, which lists all STABLEREQ, KEQWORDREQ bugs to which the arch team is CC'ed for a month? (Or probably easier or possible at all: which weren't changed for 30 days.) I know that I have several bugs right now with minor arch's on them waiting to be stabilized. A couple have been waiting for a very long time. I have even pinged some of the bugs several times with no response. Is there anything else I can do to get these arch teams attention? William pgpYXc6L6Xlux.pgp Description: PGP signature
[gentoo-dev] List of User projects
I was just thinking how nice it could be if we acknowledged some of the projects that contribute to gentoo but are actually developed primarily outside of gentoo's dev community. How about a page on gentoo.org So lets me start with a couple of obvious ones. kportagetray pkgcore paludis There must be more than these or else gentoo really is dead. - Alistair ps. I would like the packages to be specifically for gentoo, but there are exceptions to this. as an example openrc (and even paludis to a degree). If you think that there is a package not specifically targetting gentoo that deserves a mention please make it clear why.
Re: [gentoo-dev] [RFC] Reworking package stabilization policies
On Saturday 27 of March 2010 21:58:41 William Hubbs wrote: On Sat, Mar 27, 2010 at 05:45:51PM +0100, Torsten Veller wrote: * Petteri R?ty betelge...@gentoo.org: So let's summarize for assigning to the single arch: In support (and my comments in support): - Can be used as a gentle reminder for slacker arches And if not only one arch or single arch is slacking? I guess you would find another gentle way to remind them. How about a tool generating mails to arch teams, which lists all STABLEREQ, KEQWORDREQ bugs to which the arch team is CC'ed for a month? (Or probably easier or possible at all: which weren't changed for 30 days.) I know that I have several bugs right now with minor arch's on them waiting to be stabilized. A couple have been waiting for a very long time. I have even pinged some of the bugs several times with no response. Is there anything else I can do to get these arch teams attention? Yes, I think getting from them the privilege of being the only ones able to stabilize applications should do the job. No, seriously - given the fact that some of my packages were even stabilized without contacting me (app-misc/hal-cups-utils, app-admin/system-config- printer-common) - I think it should be: * solely up to the package maintainers to stabilize application on arches they're using or on any arch if package is arch-agnostic (optionally, but preferably with some peer review from other project members or arch team members). * to arch team members in other cases (like now) * other rules (30 days 'waiting' period, bugzilla bug with STABLEREQ) applied as they are now Role of arch teams would be decreased to peer review and solving KEYWORD requests. It's really freaking silly to wait months for stabilization of some random php/perl library that's known to work. Comments? -- regards MM
