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
Re: [gentoo-dev] Handling of keywording bugs with only one arch
On Sat, Mar 27, 2010 at 04:26:46PM +0200, Petteri Räty wrote: > 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 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. Ofcourse, individual cases (such as slacking arches) can be handled independently. -- Alex Alexander :: wired Gentoo Developer www.linuxized.com pgpupeyfobUFd.pgp Description: PGP 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 : > 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 wrote: > * Petteri Räty : >> 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 > wrote: > > On Fri, Mar 26, 2010 at 4:08 PM, Dale 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 : > > 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 : > > > 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
Re: [gentoo-dev] RFC: changing ssl use flag descriptions and unify behavior
On Sat, Mar 27, 2010 at 9:54 AM, Petteri Räty wrote: > 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 > > I seriously hate changing USE flags for the sake of changing use flags. This provides a moderate amount of annoyance for anyone that maintains more then one Gentoo box because they need to then tinker with their /etc/make.conf and /etc/portage/package.use to get everything right again. And oh no what if the one box is on ~arch and one isn't and what if one is x86 and one isn't. Its just such a configuration nightmare. So unless there's any real benefit, I'm against this. Also two little side points... USE defaults happened in EAPI 1. And the method by which you're asking people to select would be nice if we had some method for saying USE X and Y are subset of USE A. -- Doug Goldstein
Re: [gentoo-dev] when to use a function and an implementation use flag.
On Sat, Mar 27, 2010 at 9:44 AM, Petteri Räty wrote: > 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? I didn't point him anywhere. I merely asked him for a policy on this. Because senseless changes in USE flags will require my 9 VM servers will need to be tweaked around for a pointless USE flag change and I don't need administrative burden for the sake of administrative burden. > >> 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. Again, this policy is stated but no one can point me to anything. The closest thing to a "policy" is you sending a follow up e-mail to the dev list to make this a policy. -- Doug Goldstein
usemove [was Re: [gentoo-dev] RFC: changing ssl use flag descriptions and unify behaviour]
On Sun, Mar 28, 2010 at 01:03:43AM -0500, Doug Goldstein wrote: > I seriously hate changing USE flags for the sake of changing use > flags. This provides a moderate amount of annoyance for anyone that > maintains more then one Gentoo box because they need to then tinker > with their /etc/make.conf and /etc/portage/package.use to get > everything right again. And oh no what if the one box is on ~arch and > one isn't and what if one is x86 and one isn't. Its just such a > configuration nightmare. > > So unless there's any real benefit, I'm against this. I'm not arguing for arbitrary changes, but if the change makes sense and isn't trivial it should be done. What is needed is to tweak the tools for such a move- specifically adding a new command to the update machinery (profiles/updates). Something roughly like usemove [atom] original_flag new_flag If an atom is specified, the move applies only to w/in that pkg; if no atom, it's a global shift in the configuration (meaning all ebuilds now use gtk instead of gtk2 for example). Examples: usemove gtk gtk2 usemove app-admin/gtkrellm gnutls ssl usemove dev-cpp/sptk:3 gnutls ssl usemove >=app-editors/emacs-22.3 gzip-el gzip Etc. Per the norm for updates, usual rules apply- since it's a string of delta commands, once a command is in there it cannot be changed in purpose (although folk can tweak existing commands to update for a final target, eg: A -> B, B -> C; changing it to A -> C, B -> C). > Also two little side points... USE defaults happened in EAPI 1. And > the method by which you're asking people to select would be nice if we > had some method for saying USE X and Y are subset of USE A. USE_EXPAND, roughly- I wouldn't say it's fully there, but it certainly would be where I'd start for any proposal... ~harring pgp2eWZOr7rAL.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Reworking package stabilization policies
> On Saturday 27 of March 2010 21:58:41 William Hubbs wrote: > > It's really freaking silly to wait months for stabilization of some random > php/perl library that's known to work. Have you ever just considered closing the stabilization bug and ignoring the arch. If they take so long to mark your packages as stable why do you care about them enough to even attempt to stabilize anything on their arch.
Re: [gentoo-dev] [RFC] Reworking package stabilization policies
On Sun, Mar 28, 2010 at 07:31:10PM +1300, Alistair Bush wrote: > > On Saturday 27 of March 2010 21:58:41 William Hubbs wrote: > > > > It's really freaking silly to wait months for stabilization of some random > > php/perl library that's known to work. > > Have you ever just considered closing the stabilization bug and ignoring the > arch. If they take so long to mark your packages as stable why do you care > about them enough to even attempt to stabilize anything on their arch. If the pkg isn't a leaf node, you wind up keeping older and older versions lingering across multiple pkgs to keep it from breaking stable. This is assuming that it's still heavily frowned upon to remove the only stable version available for a non-dead arch... ~harring pgpPnF5xnRygw.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Reworking package stabilization policies
> On Sun, Mar 28, 2010 at 07:31:10PM +1300, Alistair Bush wrote: > > > On Saturday 27 of March 2010 21:58:41 William Hubbs wrote: > > > > > > It's really freaking silly to wait months for stabilization of some > > > random php/perl library that's known to work. > > > > Have you ever just considered closing the stabilization bug and ignoring > > the arch. If they take so long to mark your packages as stable why do > > you care about them enough to even attempt to stabilize anything on > > their arch. > > If the pkg isn't a leaf node, you wind up keeping older and older > versions lingering across multiple pkgs to keep it from breaking > stable. Oh no, I mean you stop filing stable requests for the arch *period*. So it just means you have to keep the last stable release for that arch around. > > This is assuming that it's still heavily frowned upon to remove the > only stable version available for a non-dead arch... > ~harring
