Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Friday 17 January 2014 02:02:51 gro...@gentoo.org wrote: Maybe, a good solution is to introduce a special arch, noarch, for such packages (similar to what's done in the rpm world). Then, if a package is ~noarch, it is automatically considered ~arch for all arches. Similar for stable. The maintainer should be able to keyword ~noarch and to stabilize noarch. Comments? you mean * ? this already works today (at least with portage): KEYWORDS=~* KEYWORDS=* in fact, i was planning on converting Chromium OS over to use this instead of a list of arches. but that's because we run a simpler system of there really only being two sets of ebuilds in the tree -- stable for all and unstable for all. for the ebuilds that are truly arch-specific (or otherwise need restricting), then we'll do: KEYWORDS=-* ~arm -mike signature.asc Description: This is a digitally signed message part.
Add a KEYWORD representing any arch (was: Re: [gentoo-dev] rfc: revisiting our stabilization policy)
El dom, 19-01-2014 a las 03:36 -0500, Mike Frysinger escribió: On Friday 17 January 2014 02:02:51 gro...@gentoo.org wrote: Maybe, a good solution is to introduce a special arch, noarch, for such packages (similar to what's done in the rpm world). Then, if a package is ~noarch, it is automatically considered ~arch for all arches. Similar for stable. The maintainer should be able to keyword ~noarch and to stabilize noarch. Comments? you mean * ? this already works today (at least with portage): KEYWORDS=~* KEYWORDS=* in fact, i was planning on converting Chromium OS over to use this instead of a list of arches. but that's because we run a simpler system of there really only being two sets of ebuilds in the tree -- stable for all and unstable for all. for the ebuilds that are truly arch-specific (or otherwise need restricting), then we'll do: KEYWORDS=-* ~arm -mike I had no idea that existed :O, I guess something related with specification is missing? :/
Re: Add a KEYWORD representing any arch (was: Re: [gentoo-dev] rfc: revisiting our stabilization policy)
On Sunday 19 January 2014 04:28:33 Pacho Ramos wrote: El dom, 19-01-2014 a las 03:36 -0500, Mike Frysinger escribió: On Friday 17 January 2014 02:02:51 gro...@gentoo.org wrote: Maybe, a good solution is to introduce a special arch, noarch, for such packages (similar to what's done in the rpm world). Then, if a package is ~noarch, it is automatically considered ~arch for all arches. Similar for stable. The maintainer should be able to keyword ~noarch and to stabilize noarch. Comments? you mean * ? this already works today (at least with portage): KEYWORDS=~* KEYWORDS=* in fact, i was planning on converting Chromium OS over to use this instead of a list of arches. but that's because we run a simpler system of there really only being two sets of ebuilds in the tree -- stable for all and unstable for all. for the ebuilds that are truly arch-specific (or otherwise need restricting), then we'll do: KEYWORDS=-* ~arm I had no idea that existed :O, I guess something related with specification is missing? :/ specs are for chumps! although PMS documents -* already, so * and ~* is a logical extension. i suspect on the portage side the history is related to package.keywords support. but i'm just guessing. -mike signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: revisiting our stabilization policy
William Hubbs schrieb: When you say drop keywords do you mean: 1) revert the old version back to ~arch or 2) remove the old version. As a maintainer, I would rather do 2, because I do not want to backport fixes to the old version. William With 1) users would still be using newer versions with ~arch keyword except with explicit mask on newer versions, so keeping the old versions doesnt make much sense. With 2), there may be additional one-time cost for the maintainer (since he should check with reserve dependencies first to avoid broken dependency trees), but afterwards this solution should mean an adjusted amount of stable packages for each arch and no permanent additional work for the maintainer. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Thu, 16 Jan 2014 23:44:42 +0100 Tom Wijsman tom...@gentoo.org wrote: If I don’t, why do I care if the package is a year old? I lose none of my time to use the old version, since it does all I want; This is under the assumption that the old version has no further implications, which is a false assumption; because the older a stable ebuild get, the higher the chance is that it becomes incompatible with its libraries and/or causes blockers. Even further, a security bug for an old version of a library it depends on could cause its removal. Right, of course things can become incompatible—but the distro handles that by either leaving old enough version of e.g. libraries around that the latest stable versions of their reverse dependencies don’t break, or, in exceptional cases (e.g. security), by breaking things intentionally if necessary, thus telling me that there’s a problem. I lose a nonzero amount of time if I get a version which breaks things (even if the only time I lose is the time it takes to downgrade), Depends on whether the stable version is as perfect as one thinks it is; an upgrade can go two ways, it improves or regresses. (Well, three ways as it can stay the same, but that wouldn't demonstrate the point) Well, yes. I was considering the case of a stable version that does work well. If the stable version has a bug that affects me, I won’t be using it—I’ll pull in an unstable version that fixes the bug, and then get back to stable ASAP after that. so it’s in my best interest to use the stable versions of such packages, even if they’re a month, a year, or three years old. Based on what you know, what you need and that you can resist change; yes, but this doesn't take into account what you don't know, you don't know you need and the improvements that change can bring. While it doesn't happen often, some people will say if I knew this earlier, I would have already upgraded a long while ago; either because the new version brings something good, or the old version has a regression they were not aware of yet or came due to incompatibility... Sure, it was wrong to say it takes *no* time, but I think less time than sticking to the bleeding edge and having things break from time to time. My experience with stable has been that bugs (at least bugs that I encounter) are rare and, most importantly, bugs are *very* rare in the important packages that are hard to fix (glibc, openrc, gentoo-sources, openssh for servers, etc.). I understand they’re fairly rare in unstable as well, but I would expect a bit more common than in stable. If stable really is falling behind and the backlog is always growing, obviously something has to be done. I just don’t want “something” to mean “don’t have a stable tree”. The stable tree provides me with a benefit. If standards have to slip a bit to maintain timeliness, then I’d prefer a stable tree that’s as stable as practical, accepting reality—perhaps where users are able to submit reports of working packages, or where we let platform-agnostic packages be stabilized after one arch has tested, or various of the other suggestions in this thread. Just not no stable tree at all. -- Christopher Head signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Sun, 19 Jan 2014 14:31:57 -0800 Christopher Head ch...@chead.ca wrote: Right, of course things can become incompatible—but the distro handles that by either leaving old enough version of e.g. libraries around that the latest stable versions of their reverse dependencies don’t break, or, in exceptional cases (e.g. security), by breaking things intentionally if necessary, thus telling me that there’s a problem. True, note that upper limits on the dependencies (cat/pkg-ver) or similar blockers are not always in place; which can make this problematic if the maintainer doesn't catch the incompatible regression, especially since a lot of us run testing and don't look after older or stable packages as much as we would want. If stable really is falling behind and the backlog is always growing, obviously something has to be done. I just don’t want “something” to mean “don’t have a stable tree”. The stable tree provides me with a benefit. If standards have to slip a bit to maintain timeliness, then I’d prefer a stable tree that’s as stable as practical, accepting reality—perhaps where users are able to submit reports of working packages, or where we let platform-agnostic packages be stabilized after one arch has tested, or various of the other suggestions in this thread. Just not no stable tree at all. +1 as long as we can find effort and ways to keep it around. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Fri, Jan 17, 2014 at 2:58 AM, Matt Turner matts...@gentoo.org wrote: On Thu, Jan 16, 2014 at 11:02 PM, gro...@gentoo.org wrote: Maybe, a good solution is to introduce a special arch, noarch, for such packages (similar to what's done in the rpm world). Then, if a package is ~noarch, it is automatically considered ~arch for all arches. Similar for stable. The maintainer should be able to keyword ~noarch and to stabilize noarch. Comments? There's been opposition to this in the past, but I'm in favor of giving this a shot. I too think it is at least worth a try. We can learn from this either way. Maybe start out leaving it up to maintainer discretion, and if that becomes an issue we can try to formulate guidelines. Rich
Re: [gentoo-dev] rfc: revisiting our stabilization policy
Dnia 2014-01-17, o godz. 14:02:51 gro...@gentoo.org napisał(a): Maybe, a good solution is to introduce a special arch, noarch, for such packages (similar to what's done in the rpm world). Then, if a package is ~noarch, it is automatically considered ~arch for all arches. Similar for stable. The maintainer should be able to keyword ~noarch and to stabilize noarch. Comments? If you want to play with such a major change, you should start a new thread instead of starting it in the middle of this spam-art. Otherwise, many people will miss it and complain loudly afterwards. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Fri, 17 Jan 2014, grozin wrote: Maybe, a good solution is to introduce a special arch, noarch, for such packages (similar to what's done in the rpm world). Then, if a package is ~noarch, it is automatically considered ~arch for all arches. Similar for stable. The maintainer should be able to keyword ~noarch and to stabilize noarch. Comments? How would you handle dependencies in such a scenario? All dependencies must be keyworded or stable on all architectures, before the package can be keyworded or stabilised on noarch? Ulrich pgpF0dADhYThd.pgp Description: PGP signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Fri, 17 Jan 2014 16:31:54 +0100 Ulrich Mueller u...@gentoo.org wrote: On Fri, 17 Jan 2014, grozin wrote: Maybe, a good solution is to introduce a special arch, noarch, for such packages (similar to what's done in the rpm world). Then, if a package is ~noarch, it is automatically considered ~arch for all arches. Similar for stable. The maintainer should be able to keyword ~noarch and to stabilize noarch. Comments? How would you handle dependencies in such a scenario? All dependencies must be keyworded or stable on all architectures, before the package can be keyworded or stabilised on noarch? Maybe we can let the package managers only perceive it as keyworded or stable if all of its dependencies are keyworded or stable on the architecture that the user runs. Then we can have repoman just ignore checking dependencies' keywords when we keyword or stabilize them. Not sure how implementable this idea is though... -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Fri, 17 Jan 2014, Tom Wijsman wrote: On Fri, 17 Jan 2014 16:31:54 +0100 Ulrich Mueller u...@gentoo.org wrote: On Fri, 17 Jan 2014, grozin wrote: Maybe, a good solution is to introduce a special arch, noarch, for such packages (similar to what's done in the rpm world). Then, if a package is ~noarch, it is automatically considered ~arch for all arches. Similar for stable. The maintainer should be able to keyword ~noarch and to stabilize noarch. Comments? How would you handle dependencies in such a scenario? All dependencies must be keyworded or stable on all architectures, before the package can be keyworded or stabilised on noarch? Maybe we can let the package managers only perceive it as keyworded or stable if all of its dependencies are keyworded or stable on the architecture that the user runs. Then we can have repoman just ignore checking dependencies' keywords when we keyword or stabilize them. Very reasonable. Andrey
noarch packages, was Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Fri, 17 Jan 2014, Ulrich Mueller wrote: On Fri, 17 Jan 2014, grozin wrote: Maybe, a good solution is to introduce a special arch, noarch, for such packages (similar to what's done in the rpm world). Then, if a package is ~noarch, it is automatically considered ~arch for all arches. Similar for stable. The maintainer should be able to keyword ~noarch and to stabilize noarch. Comments? How would you handle dependencies in such a scenario? All dependencies must be keyworded or stable on all architectures, before the package can be keyworded or stabilised on noarch? Many pure data packages don't depend on anything. Pure TeX/LaTeX packages should be keyworded ~noarch only if a suitable binary TeX is keyworded for each arch. Hmm, this, probably, means that they can never be stabilized as noarch. Pure python scripts (without library dependencies) should become ~noarch if some suitable python binary is keyworded for each arch. Similarly for perl, ruby. Python is installed on each Gentoo box anyway, so, in this case it is less problematic. Andrey
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Fri, 17 Jan 2014 17:47:58 +0100 Tom Wijsman tom...@gentoo.org wrote: Maybe we can let the package managers only perceive it as keyworded or stable if all of its dependencies are keyworded or stable on the architecture that the user runs. Then we can have repoman just ignore checking dependencies' keywords when we keyword or stabilize them. Not sure how implementable this idea is though... It's going to hurt for four reasons that I can think of right now. Firstly, things you think are obviously portable sometimes aren't. Secondly, users already get confused by stable use masks. This is going to be even worse: users aren't going to understand why a noarch package isn't available for them. Thirdly, you have to decide how to deal with long chains and cycles in noarch dependencies. Fourthly, the interaction with || deps is an awful mess. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Friday 17 of January 2014 13:06:22 gro...@gentoo.org wrote: | dev-util/kdevelop-php-docs While of course it doesn't invalidate your entire idea, this particular example is a kdevelop plugin written in C++ that provides php API documentation integration. This tells however that decision to auto-keyword/stabilize remaining arches cannot be taken lightly and not by everyone. regards MM signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Fri, 17 Jan 2014 18:28:41 + Ciaran McCreesh ciaran.mccre...@googlemail.com wrote: On Fri, 17 Jan 2014 17:47:58 +0100 Tom Wijsman tom...@gentoo.org wrote: Maybe we can let the package managers only perceive it as keyworded or stable if all of its dependencies are keyworded or stable on the architecture that the user runs. Then we can have repoman just ignore checking dependencies' keywords when we keyword or stabilize them. Not sure how implementable this idea is though... It's going to hurt for four reasons that I can think of right now. Firstly, things you think are obviously portable sometimes aren't. We could write a search for architecture dependent / specific code. Secondly, users already get confused by stable use masks. This is going to be even worse: users aren't going to understand why a noarch package isn't available for them. We can improve the output of the package manager to make this easier to understand; one way is to clarify it, the other way is to just replace it by the actual archictecture the user runs. As a side note, I think we might want to name this anyarch... :) Thirdly, you have to decide how to deal with long chains and cycles in noarch dependencies. Fourthly, the interaction with || deps is an awful mess. Yes, these are though problems to resolve; my mind came up with that this idea needs recursion, hence the not sure how implementable. A cycle can be broken by stopping to continue to a certain dependency if that dependency is of the parent reverse dependencies, capture the set of packages as a cycle. Then check for each package in the cycle if their dependencies satisfy each package; if so, all the packages in the cycle are satisfied. Of course, this doesn't take into account more complex cycles were two cycles are connected to each other; but if we would have such thing, I'd rather see that get fixed in the Portage tree as that sounds like a needlessly complex set of ebuilds. Long chains might or might exist and might or might not be problematic, that's something we would need to test out when this is implemented. || deps can be done, just check them in the same order like before; what I'm more scared of is the amount of anyarch/noarch there would be added to the Portage tree, just a few can be easily done. If it is going to be a large share of the Portage tree we'll want to look for another design or just not change how this works at all. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/17/2014 06:08 PM, gro...@gentoo.org wrote: On Fri, 17 Jan 2014, Tom Wijsman wrote: On Fri, 17 Jan 2014 16:31:54 +0100 Ulrich Mueller u...@gentoo.org wrote: On Fri, 17 Jan 2014, grozin wrote: Maybe, a good solution is to introduce a special arch, noarch, for such packages (similar to what's done in the rpm world). Then, if a package is ~noarch, it is automatically considered ~arch for all arches. Similar for stable. The maintainer should be able to keyword ~noarch and to stabilize noarch. Comments? How would you handle dependencies in such a scenario? All dependencies must be keyworded or stable on all architectures, before the package can be keyworded or stabilised on noarch? Maybe we can let the package managers only perceive it as keyworded or stable if all of its dependencies are keyworded or stable on the architecture that the user runs. Then we can have repoman just ignore checking dependencies' keywords when we keyword or stabilize them. Very reasonable. Andrey I think the idea itself is good, but we should not add this to KEYWORDS directly, as it might cause some problems with older package managers(?). A new variable can be introduced, which will overwrite testing keywords to stable keywords, if the var is set to stable and keeps everything in KEYWORDS marked as testing otherwise. If this var exists in an ebuild and there is a new stabilization bug, the arch team can decide if they want to mark it stable for all architectures (via setting the var to stable) or only for the architecture they tested it for (if some dependencies are missing on other architectures). This practice ensures that at least one arch team member of any arch tested it. The use of the to-be-added variable could also be extended for vulnerability fixing. It's more important to users to deal with less vulnerabilities for a long time than a working stable dependency tree. Because the latter got easier with the autounmask feature in portage. If the var is set by the maintainer to security-fix-$bugid and the users add an option to their profile, it automatically sets the ebuild to stable and prompts an info with the bugid. Users who do not want to wait for stabilization or GLSA have a better possibility to secure their system earlier. The advantage in general is that quickly added fixes get a wider testing. So stable users will also profit. Cheers Manuel -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJS2cwvXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1 OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcpuwP/27np/ekt9AWHJz/OC7BpDz8 gxrE0iuocczV6m5/CejSY8GEdd26xQRdyloZ/7f74W1I5jRB/WPbHUKa0dnglZba AG/WRJRYOao6537t5p9n6knH3Bj0wIcZl90Jox80HOXsvk/eBwZaliE+jcA+6Mat Dcl0FVgl/b1WJZaa0aEt5st8nnW5TJ5ZTuWBG6e6shH94qAFcr8VWLOTtY1xqvHf U1GHlynM4h+nX7BnDlhPxPf2l9XPBZNQFOAvWfvE341uZcSUpkQYfYzpo2TKdYop oPL6hfMsHq5uggB0OvVaf4CiuCKhV3re7GVexKJE9Moigrb0v/nWCy5ApvR0Ww/N 7wozyGcWUKc/oHW3CHGAYr4wbFjjI9LjB5IVEjmEAGmJ5bq7/RViM+5slj/s9kBe Vioti6i2vYVs4awm/HrMvremVUJ03Deh8uwVnOaggyrggRnwbxEsRxdsMCmYNkKN 2xAVvnSi2YEMSwBWvClRJwFvvrZzzsWd+t2Y/e/VqAFNvZn0H0lqZAP1+z540nzU I7f2ym88jedwRJq41q6TgI9XaHlTFXLMcb9Hu19Xv/faUu5jHxg+ZvQtIwC/2YRy 6La1PGO9uk0wHOgixHe/bPXmZ2ArTHB6pAzgiLMpQxuahJhbGXiTmjM8qBc8IKD2 t0VP0WhLWZahQtQ21vrW =UumH -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Fri, Jan 17, 2014 at 04:02:27PM +0100, Michał Górny wrote: Dnia 2014-01-17, o godz. 14:02:51 gro...@gentoo.org napisał(a): Maybe, a good solution is to introduce a special arch, noarch, for such packages (similar to what's done in the rpm world). Then, if a package is ~noarch, it is automatically considered ~arch for all arches. Similar for stable. The maintainer should be able to keyword ~noarch and to stabilize noarch. Comments? If you want to play with such a major change, you should start a new thread instead of starting it in the middle of this spam-art. Otherwise, many people will miss it and complain loudly afterwards. I am going to agree with mgorny on this; highjacking this thread with this change is not appropriate; all we were doing in this thread is trying to figure out a way to improve our stabilization policy. Introducing a noarch keyword should be discussed in a completely separate thread. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
Sergey Popov wrote: As i said earlier, problem begins when we NEED to stabilize something to prevent breakages and arch teams are slow. Isn't that simply a matter of assigning and respecting priority on bugs properly? //Peter pgpNUTerDIRPI.pgp Description: PGP signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Thu, Jan 16, 2014 at 10:54 AM, Peter Stuge pe...@stuge.se wrote: Sergey Popov wrote: As i said earlier, problem begins when we NEED to stabilize something to prevent breakages and arch teams are slow. Isn't that simply a matter of assigning and respecting priority on bugs properly? Are you suggesting that we should forbid people from working on lower-priority bugs anytime a higher-priority bug exists? That would probably just reduce the amount of contribution. You can't force anybody to work on the higher-priority ones. Sure, in an ideal world people work on the high-priority stuff. However, often somebody either prefers to work on a lower-priority bug, or finds it easier to do so. Simply marking a bug as high-priority doesn't make the bug get resolved. Bottom line is that people work on what they work on. Unless you can find people to work on the stuff that you want done you need to make work go away. Rich
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On 16/01/2014 19:56, Rich Freeman wrote: On Thu, Jan 16, 2014 at 10:54 AM, Peter Stuge pe...@stuge.se wrote: Sergey Popov wrote: As i said earlier, problem begins when we NEED to stabilize something to prevent breakages and arch teams are slow. Isn't that simply a matter of assigning and respecting priority on bugs properly? Are you suggesting that we should forbid people from working on lower-priority bugs anytime a higher-priority bug exists? That would probably just reduce the amount of contribution. You can't force anybody to work on the higher-priority ones. Sure, in an ideal world people work on the high-priority stuff. However, often somebody either prefers to work on a lower-priority bug, or finds it easier to do so. Simply marking a bug as high-priority doesn't make the bug get resolved. Bottom line is that people work on what they work on. Unless you can find people to work on the stuff that you want done you need to make work go away. +1 Respecting bug priority feels like that corporate BS I have to put up with every day. Like every sysadmin team world-wide, we're understaffed so the only bugs that get any attention at all are ones where some fool of a manager thinks he can shout louder than anyone else. Gentoo is not like that. As you say, devs will work on what they feel like working on, heavily influenced by their own sense of responsibility. We have nothing to offer maintainers except fuzzy-feel-good and recognition; we have to trust them to do the right thing. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] rfc: revisiting our stabilization policy
Rich Freeman wrote: As i said earlier, problem begins when we NEED to stabilize something to prevent breakages and arch teams are slow. Isn't that simply a matter of assigning and respecting priority on bugs properly? Are you suggesting that we should forbid people from working on lower-priority bugs anytime a higher-priority bug exists? No, of course not forbid. I admit it's naïve but I can't believe that it would be neccessary. I expect anyone with the slightest sense of responsibility to solve problems in order of priority. Individuals may have different priorities than Gentoo as a whole and that is and must be fine, but in that case Gentoo's high priority problems stay unsolved, and I do not at all think that it's catastrophical to have unfixed high priority problems. You can't force anybody to work on the higher-priority ones. Yes, you can't force anybody to do anything unless you motivate them, usually with money. The state of Gentoo always did and always will equal the sum of contributors' work. Bottom line is that people work on what they work on. Unless you can find people to work on the stuff that you want done you need to make work go away. I certainly don't think the work needs to go away if the work is considered to be important. It's fine to have open bugs for years in the absence of a good solution. Things happen when they happen. If someone cares then they fix and ideally it is so easy for them to contribute the fix that they will. If noone cares then bugs stay unfixed and then the bugs don't matter. ;) //Peter
Re: [gentoo-dev] rfc: revisiting our stabilization policy
Alan McKinnon wrote: Respecting bug priority feels like that corporate BS I have to put up with every day. Gentoo is incorporated so maybe that fits. ;) On a more serious note, please try to understand what I meant rather than just what I wrote. I wrote both assigning and respecting; your gripe with corporate BS may be a result of how priority was assigned to your bugs, and likely amplified if you can't do much to influence that process. If you only get a priority shoved down your throat you of course can't really respect it. For priority to have any meaning on bugs.g.o there would need to be some buy-in among developers to actually want to work together to assign the proper priority to each bug. Bug trackers aren't management command and control tools, they are hive minds which just remember what workers agree on anyway. the only bugs that get any attention at all are ones where some fool of a manager thinks he can shout louder than anyone else. We have nothing to offer maintainers except fuzzy-feel-good and recognition; we have to trust them to do the right thing. Nobody will do the right thing if they don't know what it is. Recognition can certainly communicate that higher priority bugs are more important, but honestly, I wouldn't want someone who needs to be told that explicitly on my (the Gentoo) team in the first place.. Disclaimer for anyone who might find this upsetting: Of course people always have limited scope, and it is perfectly fine if high priority bugs can simply not be fixed by whoever has time to work on bugs at any given moment. IMO, closing bugs without having the right fix has negative value. I know that it can be depressing and demotivating to have too many bugs, just like it is to live in a too messy room, but I really do think that the best solution is simply to pick one thing up at a time. It may take a long time, but in the end the room is clean. :) //Peter
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Thu, Jan 16, 2014 at 1:11 PM, Peter Stuge pe...@stuge.se wrote: I certainly don't think the work needs to go away if the work is considered to be important. It's fine to have open bugs for years in the absence of a good solution. I get what you're saying, though there is still a cost to leaving the bug open to years. In this case it means an old package stays in the tree marked as stable. That either costs maintainers the effort to keep it work, or they don't bother to keep in working in which case users get saddled with issues. I am completely in support of making use of the priority field - if something is causing issues by all means call attention to it. I bet it would /help/ with the problem, but it won't make it go away. Rich
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Thu, Jan 16, 2014 at 01:42:41PM -0500, Rich Freeman wrote: On Thu, Jan 16, 2014 at 1:11 PM, Peter Stuge pe...@stuge.se wrote: I certainly don't think the work needs to go away if the work is considered to be important. It's fine to have open bugs for years in the absence of a good solution. I get what you're saying, though there is still a cost to leaving the bug open to years. In this case it means an old package stays in the tree marked as stable. That either costs maintainers the effort to keep it work, or they don't bother to keep in working in which case users get saddled with issues. Correct. I am completely in support of making use of the priority field - if something is causing issues by all means call attention to it. I bet it would /help/ with the problem, but it won't make it go away. It might help, but, no, it will not make the problem go away. The issue is that the arch team and maintainer may have different ideas of what is high priority. If a maintainer opens a high priority stable request or bumps a stable request to high priority, there is no guarantee that the arch team will feel it should be prioritized the same way, and when that happens, users are stuck with issues from the old versions of the software. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
Rich Freeman wrote: I get what you're saying, though there is still a cost to leaving the bug open to years. In this case it means an old package stays in the tree marked as stable. That either costs maintainers the effort to keep it work, or they don't bother to keep in working in which case users get saddled with issues. Since it's not possible to force anyone to keep old packages working when the rest of a system has been upgraded this is hard to solve. If reality is that a package is in the tree but there is no stable version which works in an otherwise updated system then I think it's accurate to have an open bug. If nobody makes the package work then there seem to be two options; either leave the bug open until someone makes things work again, or to remove the package from portage and close the bug as WONTFIX. But even if a given package is removed from portage the old stable version is still installed on the user's system. //Peter
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On 16/01/2014 20:26, Peter Stuge wrote: Alan McKinnon wrote: Respecting bug priority feels like that corporate BS I have to put up with every day. Gentoo is incorporated so maybe that fits. ;) On a more serious note, please try to understand what I meant rather than just what I wrote. I wrote both assigning and respecting; your gripe with corporate BS may be a result of how priority was assigned to your bugs, and likely amplified if you can't do much to influence that process. If you only get a priority shoved down your throat you of course can't really respect it. For priority to have any meaning on bugs.g.o there would need to be some buy-in among developers to actually want to work together to assign the proper priority to each bug. Bug trackers aren't management command and control tools, they are hive minds which just remember what workers agree on anyway. the only bugs that get any attention at all are ones where some fool of a manager thinks he can shout louder than anyone else. We have nothing to offer maintainers except fuzzy-feel-good and recognition; we have to trust them to do the right thing. Nobody will do the right thing if they don't know what it is. Recognition can certainly communicate that higher priority bugs are more important, but honestly, I wouldn't want someone who needs to be told that explicitly on my (the Gentoo) team in the first place.. Disclaimer for anyone who might find this upsetting: Of course people always have limited scope, and it is perfectly fine if high priority bugs can simply not be fixed by whoever has time to work on bugs at any given moment. IMO, closing bugs without having the right fix has negative value. I know that it can be depressing and demotivating to have too many bugs, just like it is to live in a too messy room, but I really do think that the best solution is simply to pick one thing up at a time. It may take a long time, but in the end the room is clean. :) When relying on folk's goodwill (like in the open source world), I find there are really only two priorities 1. the bug breaks stuff 2. everything else with possibly a #3 - stuff that doesn't matter, can be done whenever. Gentoo devs have shown time and again that they do take #1 seriously. After all, they are themselves Gentoo users. The team that is dealing with the bug may of course assign priority as they see fit as long as they mostly agree on what it is. I reckon the cardinal rule is avoid as much as possible having priority set by someone who is not solving the problem. I think that comes close in my words to what you are saying. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-dev] rfc: revisiting our stabilization policy
Alan McKinnon wrote: I wrote both assigning and respecting I reckon the cardinal rule is avoid as much as possible having priority set by someone who is not solving the problem. I think that comes close in my words to what you are saying. Yes that's exactly what I mean. Thanks for expressing it well. :) //Peter
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Wed, 15 Jan 2014 23:28:04 -0800 Christopher Head ch...@chead.ca wrote: If I need or want a feature or bugfix which isn’t in the newer version, I always have the choice to use ~. Yes. If I don’t, why do I care if the package is a year old? I lose none of my time to use the old version, since it does all I want; This is under the assumption that the old version has no further implications, which is a false assumption; because the older a stable ebuild get, the higher the chance is that it becomes incompatible with its libraries and/or causes blockers. Even further, a security bug for an old version of a library it depends on could cause its removal. Regardless, it'll work fine for some time; and you can even pull it further by attempting to keep things around and not upgrade, but at a certain point it'll come costly to hold on to. I'm not saying it is a lot of your time, but it's a bit more than none of your time. This point becomes much more clear if you imagine using software from in the early Linux years, most of them would be incompatible with today. I lose a nonzero amount of time if I get a version which breaks things (even if the only time I lose is the time it takes to downgrade), Depends on whether the stable version is as perfect as one thinks it is; an upgrade can go two ways, it improves or regresses. (Well, three ways as it can stay the same, but that wouldn't demonstrate the point) so it’s in my best interest to use the stable versions of such packages, even if they’re a month, a year, or three years old. Based on what you know, what you need and that you can resist change; yes, but this doesn't take into account what you don't know, you don't know you need and the improvements that change can bring. While it doesn't happen often, some people will say if I knew this earlier, I would have already upgraded a long while ago; either because the new version brings something good, or the old version has a regression they were not aware of yet or came due to incompatibility... -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Thu, 16 Jan 2014 10:20:37 +0400 Sergey Popov pinkb...@gentoo.org wrote: It can not go to no result, unless we have no breakages in stable, stable REMAINS stable. If it contains old, but working software - then it is stable. An ebuild promoted to stable is because an arch team (or a privileged maintainer to do it individually) has put a keyword in place. The person that puts that keyword in place, defines that the ebuild is stable at that specific point in time. However; this does not imply that as the ebuild gets older, that this doesn't come without problems; neither does it imply that the software is totally working. Software is rarely completely without bugs. As i said earlier, problem begins when we NEED to stabilize something to prevent breakages and arch teams are slow. Yes; there is a big correlation between breakages in old versions and stabilization, in both ways. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Thu, 16 Jan 2014, Sergey Popov wrote: 3. Also, another interesting question has come up in this thread, that of non-binary packages. Should we give maintainers the option of stabilizing them on all arch's themselves? 3. If code is interpreted rather then compiled, it does not matter that it is properly ported on minor arches. I knew dozens of examples with Perl and Python packages(not sure about Ruby, but Hans said that it happens with it too). So, i would not treat such packages differently. OK, let's be conservative. Python and Perl scripts may break on some arches (I'd say it's a rare exception, perhaps 1%, but still). But what about dev-java/java-sdk-docs dev-db/postgresql-docs sys-kernel/linux-docs dev-dotnet/gtk-sharp-docs app-xemacs/general-docs dev-util/kdevelop-php-docs dev-util/gnome-devel-docs app-vim/phpdocs gnome-extra/gnome-user-docs gnome-extra/gnome-getting-started-docs dev-php/smarty-docs dev-python/python-docs dev-python/cheetah-docs app-doc/php-docs app-doc/root-docs app-doc/geant-docs app-doc/blas-docs app-doc/lapack-docs app-doc/gnucash-docs app-office/abiword-docs dev-lisp/hyperspec sys-apps/man-pages[-*] and maybe others? They contain no scripts which can possibly break. I'd say they should be keyworded on all arches as soon as they are keyworded on the first arch; the same goes for stabilization. I'd include also packages containing only TeX/LaTeX code - TeX behaves identically on all arches, this was and is its main strength. Also, probably, python/perl/ruby interpreted scripts *which don't load extra libraries* work identically on all arches not in 99% of cases but in 99.99% (0.01% is for cases when the interpreter is broken on a given arch). Andrey
Re: [gentoo-dev] rfc: revisiting our stabilization policy
Sorry for following up myself, On Fri, 17 Jan 2014, gro...@gentoo.org wrote: OK, let's be conservative. Python and Perl scripts may break on some arches (I'd say it's a rare exception, perhaps 1%, but still). But what about dev-java/java-sdk-docs dev-db/postgresql-docs sys-kernel/linux-docs dev-dotnet/gtk-sharp-docs app-xemacs/general-docs dev-util/kdevelop-php-docs dev-util/gnome-devel-docs app-vim/phpdocs gnome-extra/gnome-user-docs gnome-extra/gnome-getting-started-docs dev-php/smarty-docs dev-python/python-docs dev-python/cheetah-docs app-doc/php-docs app-doc/root-docs app-doc/geant-docs app-doc/blas-docs app-doc/lapack-docs app-doc/gnucash-docs app-office/abiword-docs dev-lisp/hyperspec sys-apps/man-pages[-*] and maybe others? They contain no scripts which can possibly break. I'd say they should be keyworded on all arches as soon as they are keyworded on the first arch; the same goes for stabilization. I'd include also packages containing only TeX/LaTeX code - TeX behaves identically on all arches, this was and is its main strength. Also, probably, python/perl/ruby interpreted scripts *which don't load extra libraries* work identically on all arches not in 99% of cases but in 99.99% (0.01% is for cases when the interpreter is broken on a given arch). Maybe, a good solution is to introduce a special arch, noarch, for such packages (similar to what's done in the rpm world). Then, if a package is ~noarch, it is automatically considered ~arch for all arches. Similar for stable. The maintainer should be able to keyword ~noarch and to stabilize noarch. Comments? Andrey
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Thu, Jan 16, 2014 at 11:02 PM, gro...@gentoo.org wrote: Sorry for following up myself, On Fri, 17 Jan 2014, gro...@gentoo.org wrote: OK, let's be conservative. Python and Perl scripts may break on some arches (I'd say it's a rare exception, perhaps 1%, but still). But what about dev-java/java-sdk-docs dev-db/postgresql-docs sys-kernel/linux-docs dev-dotnet/gtk-sharp-docs app-xemacs/general-docs dev-util/kdevelop-php-docs dev-util/gnome-devel-docs app-vim/phpdocs gnome-extra/gnome-user-docs gnome-extra/gnome-getting-started-docs dev-php/smarty-docs dev-python/python-docs dev-python/cheetah-docs app-doc/php-docs app-doc/root-docs app-doc/geant-docs app-doc/blas-docs app-doc/lapack-docs app-doc/gnucash-docs app-office/abiword-docs dev-lisp/hyperspec sys-apps/man-pages[-*] and maybe others? They contain no scripts which can possibly break. I'd say they should be keyworded on all arches as soon as they are keyworded on the first arch; the same goes for stabilization. I'd include also packages containing only TeX/LaTeX code - TeX behaves identically on all arches, this was and is its main strength. Also, probably, python/perl/ruby interpreted scripts *which don't load extra libraries* work identically on all arches not in 99% of cases but in 99.99% (0.01% is for cases when the interpreter is broken on a given arch). Maybe, a good solution is to introduce a special arch, noarch, for such packages (similar to what's done in the rpm world). Then, if a package is ~noarch, it is automatically considered ~arch for all arches. Similar for stable. The maintainer should be able to keyword ~noarch and to stabilize noarch. Comments? Andrey There's been opposition to this in the past, but I'm in favor of giving this a shot.
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Wed, Jan 15, 2014 at 5:49 AM, William Hubbs willi...@gentoo.org wrote: Also, there is a substantial number of packages which contain only python code (or perl, ruby), or only LaTeX classes, or only documentation. It makes no sense to test them on each arch separately. I think maintainers should be allowed to stabilize such packages (with no compiled code) on all arches. There is a reason we don't do this, back in Gentoo history somewhere, but I don't remember what it was. If someone can tell us why this isn't allowed I am all ears. Otherwise, I could agree on this point as well. Yeah, as the python team lead, I feel we could definitely stick some policy bits in (almost) all python packages that says stable for one arch means stable for all arches. Sure, there'd be some fallout, but I suspect that would be very limited, and in return only one arch tester (or the maintainer!) can stabilize for all architectures. Cheers, Dirkjan
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Tue, 2014-01-14 at 22:49 -0600, William Hubbs wrote: Also, there is a substantial number of packages which contain only python code (or perl, ruby), or only LaTeX classes, or only documentation. It makes no sense to test them on each arch separately. I think maintainers should be allowed to stabilize such packages (with no compiled code) on all arches. There is a reason we don't do this, back in Gentoo history somewhere, but I don't remember what it was. If someone can tell us why this isn't allowed I am all ears. Otherwise, I could agree on this point as well. Speaking for ruby I have seen various arch-related bugs in pure ruby code. It doesn't happen a lot (maybe 1% of stable requests) but it is also not predictable. I also like the second set of eyes verifying what we've done as part of marking a package stable, so I probably would still file bugs rather than marking stuff stable myself. Hans
Re: [gentoo-dev] rfc: revisiting our stabilization policy
Dnia 2014-01-14, o godz. 15:37:19 William Hubbs willi...@gentoo.org napisał(a): I want comments wrt two ideas: 1. I think maintainers should be able to stabilize their packages on arch's they have access to. I think this is allowed by some arch teams, but I think it would be good to formalize it. I think we'd use more feedback from the 'other' arch teams before agreeing on this. Some arches may have a pretty tricky issues that could affect stabilization but which average developer may be not aware of. Maybe it'd be good if each arch team had a wiki page explaining the testing process for their arch. We should also make it clear that the developer is supposed to test the package on a pure stable system to avoid misunderstandings. 2. I would like to see the policy below applied to all arch's [2]. [2] http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt Honestly, this sounds like a very bad idea to me. Even on the minor architectures. TLDR: users will end up running unsupported mixed-arch systems and stabilizing the package again sometime wouldn't make much sense. Dropping the stable keyword on a package means that user either: 1) has to remove the package and either find an alternative or lose particular features completely. And unlike with regular package.mask, he won't get any tips from us. In fact, this policy makes it possible to kill, say, the last graphical word processor on the arch. 2) has to add package.accept_keywords entry for the package. Which means turning a pure stable system into an unsupported mixed-keyword system. Considering portage behavior, I think that 2) is much more likely. Now, the keyword may be added per-version or per-package. If it's added per-version, user simply ends up sticking to another single version until he thinks of upgrading the package manually. If it's added per-package, the keyword usually persists on the user's system. When we bring the stable keywords to the package again, user would have to notice that and remove his override. How likely is that going to happen? So, in the end once we remove stable keyword from a package, most users add ~arch keyword and future stable keyword on the package becomes meaningless. I'd rather go for removing stable keywords from all packages. This would at least make turning the architecture back stable easy for users. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
15.01.2014 01:37, William Hubbs пишет: I want comments wrt two ideas: 1. I think maintainers should be able to stabilize their packages on arch's they have access to. I think this is allowed by some arch teams, but I think it would be good to formalize it. 2. I would like to see the policy below applied to all arch's [2]. Thoughts? William [1] http://bugs.gentoo.org/487332 [2] http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt amd64 and x86 arch teams have agreement, that maintainers can stabilize their packages if they know how to properly test them. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
15.01.2014 03:11, William Hubbs пишет: The status quo is not good, because we are forced to keep old, and potentially buggy, versions of software around longer than necessary. arch team member opinion But both of suggested solutions will break the whole idea of stabling. Dropping packages to unstable on regular basis will annoy our users. If we have old stable package, it builds and works correctly in new environment(new gcc, glibc etc), then i do not see the point in rushing things up, unless there are some more critical things, that needs new version of this package. Stable should be reasonable. Each new version of package contains bugfixes, it is true. But we should note, that new versions(even so-called bugfix releases) can also bring new bugs. /arch team member -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
15.01.2014 01:37, William Hubbs пишет: All, It is becoming more and more obvious that we do not have enough manpower on the arch teams, even some of the ones we consider major arch's, to keep up with stabilization requests. For example, there is this bug [1], which is blocking the stabilization of several important packages. And by the way, the only arches left there are ppc and ppc64, which are NOT major ones. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
15.01.2014 06:42, Tom Wijsman пишет: And for that occasional mis-guess, *boohoo*, the user can just file a bug; which ironically even happens occasionally for stable packages. If we blindly approves increasing of such mis-guesses, then our QA level in arch teams will down below the apropriate level IMO. And this is not good first of all for our stable users. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Wed, Jan 15, 2014 at 4:54 AM, Michał Górny mgo...@gentoo.org wrote: 2) has to add package.accept_keywords entry for the package. Which means turning a pure stable system into an unsupported mixed-keyword system. As opposed to an unsupported pure stable system or an unsupported pure unstable system? I doubt anybody runs a pure stable system, and if they do I doubt their experience is much different from those who run mixed keywords. Of course, having random system packages drop stable keywords from time to time isn't going to help anything in that department. Obviously maintainers should keep stable system packages around as long as they can. However, there needs to be some way to deal with cases where their stabilization gets held up on a major arch. If we don't have the manpower to stabilize newer versions, what makes anybody think that maintainers have the manpower to support ancient versions? The have our cake and eat it too solution is to obtain more manpower. That should be done without question, but for whatever reason it never actually happens, so we need to think about what the alternative is. If talking about it scares more people into volunteering so that it isn't necessary all the better... Given constrained manpower the options basically are some variation on: 1. Status quo - for some packages stable gets REALLY old, and likely has problems that maintainers ignore. You can't force somebody to maintain something any more than you can force somebody to test something. 2. We become more liberal with stabilizing newer versions. Lots of variations on this, but the bottom line is that packages get stabilized that would otherwise not be. 3. We drop stable keywords on packages. Lots of variations on this as well, but the result is mixed-arch systems or dropping stable for the whole arch. I don't think #1 is really the answer - it just results in less-visible problems and a stable that is probably works worse than either #2 or #3 would yield. #2 has the advantage that it gives us more control over what gets installed on stable systems and you don't end up with mixed keywords. The downside to #2 is that the user doesn't have as much visibility into which packages are really stable. Maybe an in-between quality tier would help (if you're going to run a mixed keyword system, at least use this version). #3 has the advantage that it makes the problem directly visible to the user. However, the solution ends up being entirely user-discretion. Some users end up on ~arch for life, others do it version-by-version in which case they end up on various versions. Personally I run stable and when I need to run unstable on a package I tend to use cat/foo-major+1 syntax so that I'm tracking unstable until the next major version and then I get a chance to revisit the decision - usually stable catches up by then. The only nice solution is more manpower. I'd like a pony to go with that as well... Rich
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Wed, Jan 15, 2014 at 03:30:39PM +0400, Sergey Popov wrote: 15.01.2014 01:37, William Hubbs пишет: All, It is becoming more and more obvious that we do not have enough manpower on the arch teams, even some of the ones we consider major arch's, to keep up with stabilization requests. For example, there is this bug [1], which is blocking the stabilization of several important packages. And by the way, the only arches left there are ppc and ppc64, which are NOT major ones. Sparc is also still on that bug, and according to the council decision I sited, these arch's are still treated like major arch's. Wrt your comment about x86 and amd64 having agreements that maintainers can stabilize packages on those arch's, I thought amd64 did, but I didn't know about x86. Formal policy says that all stabilizations must be done by arch teams unless you have special arrangements with them [1], so my questions still stand. 1. Should we make it policy that maintainers can stabilize packages on arch's they have access to? 2. See Rich's message in this thread for my other concern; he spells it out pretty well -- what should we do about architectures the maintainer does not have access to? 3. Also, another interesting question has come up in this thread, that of non-binary packages. Should we give maintainers the option of stabilizing them on all arch's themselves? William [1] http://devmanual.gentoo.org/keywording/index.html signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Wed, 15 Jan 2014 15:33:28 +0400 Sergey Popov pinkb...@gentoo.org wrote: 15.01.2014 06:42, Tom Wijsman пишет: And for that occasional mis-guess, *boohoo*, the user can just file a bug; which ironically even happens occasionally for stable packages. If we blindly approves increasing of such mis-guesses, then our QA level in arch teams will down below the apropriate level IMO. And this is not good first of all for our stable users. What I'm saying is that even on arch team stabilized ebuilds bugs getting filed happens as well; so, it happening for a maintainer stabilized ebuild wouldn't be so problematic from that perspective. But, indeed, it depends on which arch team procedure efforts the maintainer actually applies; on an own arch it is quite possible for the maintainer to be near the QA level of the arch team, whereas not having access to a certain architecture can indeed become problematic. So, for the arches the maintainers do have, it depends on what the maintainers do as much as what the arch teams do; and to be realistic arch teams might not always do everything as intended, especially under time pressure. In my opinion, a maintainer would even spend more time. As for arches the maintainer does not have, the available machines might be usable; though the doubt is whether they have enough power. Most of this discussion is hypothetical assuming stabilization stays (or continues to grow to be more) problematic; who knows we might get to see the opposite effect that this thread yields some new arch team members, which could make what we've discussed here not necessary in the short term run. It is clear everyone wants to hold on to the arch teams. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Wed, 15 Jan 2014 15:40:20 +0400 Sergey Popov pinkb...@gentoo.org wrote: As i said earlier for similar proposals - the one option that i see here to make all things going better - to recruit more people in arch teams/arch testers. Other options lead us to nowhere, when stable will be eliminated or transformed into fake. If eventually our existing approach yields no or worsening results, it would leads us nowhere as well; we can pick that option a few times, but if it doesn't improve anything we'll need to start reconsidering. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On 01/15/2014 10:57 AM, Tom Wijsman wrote: On Wed, 15 Jan 2014 15:33:28 +0400 Sergey Popov pinkb...@gentoo.org wrote: 15.01.2014 06:42, Tom Wijsman пишет: And for that occasional mis-guess, *boohoo*, the user can just file a bug; which ironically even happens occasionally for stable packages. If we blindly approves increasing of such mis-guesses, then our QA level in arch teams will down below the apropriate level IMO. And this is not good first of all for our stable users. What I'm saying is that even on arch team stabilized ebuilds bugs getting filed happens as well; so, it happening for a maintainer stabilized ebuild wouldn't be so problematic from that perspective. But, indeed, it depends on which arch team procedure efforts the maintainer actually applies; on an own arch it is quite possible for the maintainer to be near the QA level of the arch team, whereas not having access to a certain architecture can indeed become problematic. So, for the arches the maintainers do have, it depends on what the maintainers do as much as what the arch teams do; and to be realistic arch teams might not always do everything as intended, especially under time pressure. In my opinion, a maintainer would even spend more time. As for arches the maintainer does not have, the available machines might be usable; though the doubt is whether they have enough power. Most of this discussion is hypothetical assuming stabilization stays (or continues to grow to be more) problematic; who knows we might get to see the opposite effect that this thread yields some new arch team members, which could make what we've discussed here not necessary in the short term run. It is clear everyone wants to hold on to the arch teams. I would like to see the ability for devs to become arch testers for the packages they own on the architectures they have access to. The hard part is enforcing the arch testing guidelines, so maybe this can be considered 'arch tester jr.'. -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
William Hubbs schrieb: Thoughts? William [1] http://bugs.gentoo.org/487332 [2] http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt I see 2 cases here: 1. specific or all arch teams allow maintainers to stabilize packages on their own, when they follow the arch team stabilization rules (e.g. having a system running with stable keywords for testing the package). This should not reduce the quality of the stable tree (or only to the small amount, that some arch testers do additional checks the maintainer does not do). Reading through this thread, it seems like amd64 and x86 arch teams already use this policy. This sounds like a reasonable agreement, so i am supporting this too. 2. for arches with no such agreement or where the maintainer does not have the needed hardware to test, no action for a certain amount of time usually means, that the arch team is overloaded with work so the only short- to mid-term solution is to reduce the amount of work resulting in smaller amount of stable packages. So i am voting for maintainers dropping stable keywords after a certain amount of time with no actions (maybe with some notice beforehand). This might result in a mixed arch user setup by default, but imho it is still better to have a smaller stable set of core packages and testing packages on top then having either everything on testing or broken/untested/unsupported packages, which are still claimed to be the opposite with the stable keyword. short summary: -in agreement with arch teams, following stabilization policy and having the needed hardware, maintainers should be able to add stable keywords themselves -if either agreement of arch team or needed hardware is missing, keywords should be dropped, so that after some time the workload matches the abilities of the arch team again. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Wed, Jan 15, 2014 at 07:33:45PM +0100, Thomas Sachau wrote: William Hubbs schrieb: Thoughts? William [1] http://bugs.gentoo.org/487332 [2] http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt I see 2 cases here: 1. specific or all arch teams allow maintainers to stabilize packages on their own, when they follow the arch team stabilization rules (e.g. having a system running with stable keywords for testing the package). This should not reduce the quality of the stable tree (or only to the small amount, that some arch testers do additional checks the maintainer does not do). Reading through this thread, it seems like amd64 and x86 arch teams already use this policy. This sounds like a reasonable agreement, so i am supporting this too. 2. for arches with no such agreement or where the maintainer does not have the needed hardware to test, no action for a certain amount of time usually means, that the arch team is overloaded with work so the only short- to mid-term solution is to reduce the amount of work resulting in smaller amount of stable packages. So i am voting for maintainers dropping stable keywords after a certain amount of time with no actions (maybe with some notice beforehand). This might result in a mixed arch user setup by default, but imho it is still better to have a smaller stable set of core packages and testing packages on top then having either everything on testing or broken/untested/unsupported packages, which are still claimed to be the opposite with the stable keyword. short summary: -in agreement with arch teams, following stabilization policy and having the needed hardware, maintainers should be able to add stable keywords themselves -if either agreement of arch team or needed hardware is missing, keywords should be dropped, so that after some time the workload matches the abilities of the arch team again. When you say drop keywords do you mean: 1) revert the old version back to ~arch or 2) remove the old version. As a maintainer, I would rather do 2, because I do not want to backport fixes to the old version. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Tuesday 14 January 2014 22:37:19 William Hubbs wrote: I think we need a global policy that either helps keep the stable tree up to date or reverts an architecture to ~ over time if the arch team can't keep up. As a compromise solution for minor archs, it would be nice if there were a portage feature allowing me to ACCEPT_KEYWORDS those packages that are keyworded both ~arch, and stable on some major arch. For example, on m68k, it would select packages that are keyworded ~m68k amd64, or ~m68k x86, etc. This would allow me to run m68k kinda stable. [Speculation as to applying a similar system more broadly witheld.] -- Ruud
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Wed, 2014-01-15 at 13:07 -0600, William Hubbs wrote: When you say drop keywords do you mean: 1) revert the old version back to ~arch or 2) remove the old version. As a maintainer, I would rather do 2, because I do not want to backport fixes to the old version. William I'm not sure what he meant by drop keywords either, however, something that I would like to see (with my ARM hat on here) - is, if something is taking a while to stable for a certain arch, remove the keywords except for that existing arch. We actually ran into something along this issue with git. Now, arm is an interesting keyword, because for arm, when something needs to be stabled, we have to test armv4, armv5, armv6, armv6 hardfloat, armv7, armv7 hardfloat, armv7 uclibc. In my testing, one known issue was that git on uclibc did (and still doesn't) work properly starting with git 1.8 - so I noted in the bug that this was the case, and to NOT stable it for arm. Unfortunately, someone else on the ARM team disregarded the note and stabled the new git, then the git maintainers dropped the old versions. Now on arm uclibc, git is entirely broken and unusable. And no, adding more people to the arch team doesn't particularly help, as people are buying more and more armv7 so they test that, but not the rest of the versions - and no one wants to buy the older hardware because it's so slow - we know it's slow, that's why it takes time. I'd have definitely preferred that for git, that the 1.7 version stuck around with just KEYWORDS=-* arm (and maybe even stabling 1.8 but leaving 1.7 in masked?) - I realize it was a bit of a special case because of the new git eclass. Unfortunately, debugging what's going on, is a bit above me, and the only other person I know who can/does work on it, is blueness, and he's quite busy.
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Wed, Jan 15, 2014 at 06:58:27PM -0600, Steev Klimaszewski wrote: We actually ran into something along this issue with git. Now, arm is an interesting keyword, because for arm, when something needs to be stabled, we have to test armv4, armv5, armv6, armv6 hardfloat, armv7, armv7 hardfloat, armv7 uclibc. In my testing, one known issue was that git on uclibc did (and still doesn't) work properly starting with git 1.8 - so I noted in the bug that this was the case, and to NOT stable it for arm. Unfortunately, someone else on the ARM team disregarded the note and stabled the new git, then the git maintainers dropped the old versions. Now on arm uclibc, git is entirely broken and unusable. Ugh, this does suck. Wasn't there a proposal years ago to include the libc in the keyword? -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Thu, 2014-01-16 at 02:32 +, Robin H. Johnson wrote: In my testing, one known issue was that git on uclibc did (and still doesn't) work properly starting with git 1.8 - so I noted in the bug that this was the case, and to NOT stable it for arm. Unfortunately, someone else on the ARM team disregarded the note and stabled the new git, then the git maintainers dropped the old versions. Now on arm uclibc, git is entirely broken and unusable. Ugh, this does suck. It does, though it's specific to arm uclibc, as it works fine on amd64/x86 uclibc. And unfortunately, it seems like this type of thing is what people are proposing we move towards. Instead of working but old, not having access to the software at all. I know it's not the norm, nor is it typical, but the chance of this happening does exist, and I can't see how anyone would say, well, that's just the chance that people should take, unless they've never been bitten by a bug like this. Wasn't there a proposal years ago to include the libc in the keyword? There may have been, I'm not sure that's really the right step either though.
Re: [gentoo-dev] rfc: revisiting our stabilization policy
15.01.2014 19:30, William Hubbs пишет: On Wed, Jan 15, 2014 at 03:30:39PM +0400, Sergey Popov wrote: 15.01.2014 01:37, William Hubbs пишет: All, It is becoming more and more obvious that we do not have enough manpower on the arch teams, even some of the ones we consider major arch's, to keep up with stabilization requests. For example, there is this bug [1], which is blocking the stabilization of several important packages. And by the way, the only arches left there are ppc and ppc64, which are NOT major ones. Sparc is also still on that bug, and according to the council decision I sited, these arch's are still treated like major arch's. Well, to be honest, personally i consider only amd64 and x86(and maybe arm) as major arches, other are minor in my eyes. Council decision is more about arches, that crucially lacks manpower. Wrt your comment about x86 and amd64 having agreements that maintainers can stabilize packages on those arch's, I thought amd64 did, but I didn't know about x86. It's not mentioned, yeah, i was not aware about it for some time. Probably it should be mentioned in Gentoo Development Guide. Formal policy says that all stabilizations must be done by arch teams unless you have special arrangements with them [1], so my questions still stand. 1. Should we make it policy that maintainers can stabilize packages on arch's they have access to? 2. See Rich's message in this thread for my other concern; he spells it out pretty well -- what should we do about architectures the maintainer does not have access to? 3. Also, another interesting question has come up in this thread, that of non-binary packages. Should we give maintainers the option of stabilizing them on all arch's themselves? 1. If you know how to test it properly, know arch-specific problems(aligning, endianness, ABI breakage) and how to fix it - then, probably yes. But usually maintainers are bored to do proper testing. 2. I think - no. You can not test it - you can not stabilize it, period. 3. If code is interpreted rather then compiled, it does not matter that it is properly ported on minor arches. I knew dozens of examples with Perl and Python packages(not sure about Ruby, but Hans said that it happens with it too). So, i would not treat such packages differently. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
15.01.2014 21:04, Tom Wijsman пишет: On Wed, 15 Jan 2014 15:40:20 +0400 Sergey Popov pinkb...@gentoo.org wrote: As i said earlier for similar proposals - the one option that i see here to make all things going better - to recruit more people in arch teams/arch testers. Other options lead us to nowhere, when stable will be eliminated or transformed into fake. If eventually our existing approach yields no or worsening results, it would leads us nowhere as well; we can pick that option a few times, but if it doesn't improve anything we'll need to start reconsidering. It can not go to no result, unless we have no breakages in stable, stable REMAINS stable. If it contains old, but working software - then it is stable. As i said earlier, problem begins when we NEED to stabilize something to prevent breakages and arch teams are slow. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
15.01.2014 22:33, Thomas Sachau пишет: William Hubbs schrieb: Thoughts? William [1] http://bugs.gentoo.org/487332 [2] http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt I see 2 cases here: 1. specific or all arch teams allow maintainers to stabilize packages on their own, when they follow the arch team stabilization rules (e.g. having a system running with stable keywords for testing the package). This should not reduce the quality of the stable tree (or only to the small amount, that some arch testers do additional checks the maintainer does not do). Reading through this thread, it seems like amd64 and x86 arch teams already use this policy. This sounds like a reasonable agreement, so i am supporting this too. 2. for arches with no such agreement or where the maintainer does not have the needed hardware to test, no action for a certain amount of time usually means, that the arch team is overloaded with work so the only short- to mid-term solution is to reduce the amount of work resulting in smaller amount of stable packages. So i am voting for maintainers dropping stable keywords after a certain amount of time with no actions (maybe with some notice beforehand). This might result in a mixed arch user setup by default, but imho it is still better to have a smaller stable set of core packages and testing packages on top then having either everything on testing or broken/untested/unsupported packages, which are still claimed to be the opposite with the stable keyword. short summary: -in agreement with arch teams, following stabilization policy and having the needed hardware, maintainers should be able to add stable keywords themselves -if either agreement of arch team or needed hardware is missing, keywords should be dropped, so that after some time the workload matches the abilities of the arch team again. Thanks, for the proposal. IIRC, there was similar backroom agreement in some minor arches, look at how armin76 stabilized packages earlier - sometimes he drops vast amount of keywords on ia64/sparc/m68k to unstable in stabilization requests. And i think we should continue this practice. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop Effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Tue, 14 Jan 2014 20:46:04 -0600 William Hubbs willi...@gentoo.org wrote: s/month/year/ Do you feel the same way then? I have heard of stabilizations taking this long before. I just had to try to pick something reasonable for the discussion. I suppose a compromise would be, instead of removing the old versions, move them back to ~arch for a month then remove them, but that still implies action on your part. William If I need or want a feature or bugfix which isn’t in the newer version, I always have the choice to use ~. If I don’t, why do I care if the package is a year old? I lose none of my time to use the old version, since it does all I want; I lose a nonzero amount of time if I get a version which breaks things (even if the only time I lose is the time it takes to downgrade), so it’s in my best interest to use the stable versions of such packages, even if they’re a month, a year, or three years old. -- Christopher Head signature.asc Description: PGP signature
[gentoo-dev] rfc: revisiting our stabilization policy
All, It is becoming more and more obvious that we do not have enough manpower on the arch teams, even some of the ones we consider major arch's, to keep up with stabilization requests. For example, there is this bug [1], which is blocking the stabilization of several important packages. I spoke to one of the team members on one of the affected arch teams on this bug a couple of weeks ago, and was told just that stabilization takes time. I pointed out that this was affecting important packages and I felt that the arch teams should step up their efforts when it comes to important packages. The arch team member disagreed unless the issue is a security bug. The council decision below [2] has made it possible to move on for some arch's by removing old stable versions of packages 90 days after the stable request is filed and the arch teams are added if there has been no action by the specific arch teams listed in the decision, and those arch teams are the only ones on the bug. I think we need a global policy that either helps keep the stable tree up to date or reverts an architecture to ~ over time if the arch team can't keep up. Keeping old software in the stable tree, I think we can agree, isn't good because newer software, besides having new features, will have bug fixes. Also, I think we can agree that allowing maintainers to stabilize new software on architectures they do not have access to wouldn't be good. I want comments wrt two ideas: 1. I think maintainers should be able to stabilize their packages on arch's they have access to. I think this is allowed by some arch teams, but I think it would be good to formalize it. 2. I would like to see the policy below applied to all arch's [2]. Thoughts? William [1] http://bugs.gentoo.org/487332 [2] http://www.gentoo.org/proj/en/council/meeting-logs/20130917-summary.txt signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On 01/14/2014 04:37 PM, William Hubbs wrote: 2. I would like to see the policy below applied to all arch's [2]. [ ] Yup [X] Nope
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Tue, Jan 14, 2014 at 04:57:30PM -0500, Michael Orlitzky wrote: On 01/14/2014 04:37 PM, William Hubbs wrote: 2. I would like to see the policy below applied to all arch's [2]. [ ] Yup [X] Nope The reverse of this would be to let maintainers stabilize on all arch's after 90 days, then they are allowed to remove all but the latest stable version. This isn't good though because maintainers would be stabilizing packages on arch's where they can't test. The stable tree is significantly behind because the arch teams are so short staffed, and this prooposal is an attempt to fix that. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On 01/14/2014 05:33 PM, William Hubbs wrote: On Tue, Jan 14, 2014 at 04:57:30PM -0500, Michael Orlitzky wrote: On 01/14/2014 04:37 PM, William Hubbs wrote: 2. I would like to see the policy below applied to all arch's [2]. [ ] Yup [X] Nope The reverse of this would be to let maintainers stabilize on all arch's after 90 days, then they are allowed to remove all but the latest stable version. This isn't good though because maintainers would be stabilizing packages on arch's where they can't test. The stable tree is significantly behind because the arch teams are so short staffed, and this prooposal is an attempt to fix that. It's attempting to fix a headache with a bullet. The arch teams are lagging behind, you're annoyed, I get it. Give 'em hell. But don't break stable to make a point. For users, both options are worse than the status quo.
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Tue, Jan 14, 2014 at 05:43:57PM -0500, Michael Orlitzky wrote: On 01/14/2014 05:33 PM, William Hubbs wrote: On Tue, Jan 14, 2014 at 04:57:30PM -0500, Michael Orlitzky wrote: On 01/14/2014 04:37 PM, William Hubbs wrote: 2. I would like to see the policy below applied to all arch's [2]. [ ] Yup [X] Nope The reverse of this would be to let maintainers stabilize on all arch's after 90 days, then they are allowed to remove all but the latest stable version. This isn't good though because maintainers would be stabilizing packages on arch's where they can't test. The stable tree is significantly behind because the arch teams are so short staffed, and this prooposal is an attempt to fix that. It's attempting to fix a headache with a bullet. The arch teams are lagging behind, you're annoyed, I get it. Give 'em hell. But don't break stable to make a point. For users, both options are worse than the status quo. The first option would start reverting things back to ~ and users would have to unmask them. The second option would introduce new things to stable which may not be stable due to not being tested on the arch. The second option is worse than the first imo, that's why I didn't propose it first. The status quo is not good, because we are forced to keep old, and potentially buggy, versions of software around longer than necessary. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On 14 January 2014 18:11, William Hubbs willi...@gentoo.org wrote: On Tue, Jan 14, 2014 at 05:43:57PM -0500, Michael Orlitzky wrote: On 01/14/2014 05:33 PM, William Hubbs wrote: On Tue, Jan 14, 2014 at 04:57:30PM -0500, Michael Orlitzky wrote: On 01/14/2014 04:37 PM, William Hubbs wrote: 2. I would like to see the policy below applied to all arch's [2]. [ ] Yup [X] Nope The reverse of this would be to let maintainers stabilize on all arch's after 90 days, then they are allowed to remove all but the latest stable version. This isn't good though because maintainers would be stabilizing packages on arch's where they can't test. The stable tree is significantly behind because the arch teams are so short staffed, and this prooposal is an attempt to fix that. It's attempting to fix a headache with a bullet. The arch teams are lagging behind, you're annoyed, I get it. Give 'em hell. But don't break stable to make a point. For users, both options are worse than the status quo. The first option would start reverting things back to ~ and users would have to unmask them. The second option would introduce new things to stable which may not be stable due to not being tested on the arch. The second option is worse than the first imo, that's why I didn't propose it first. The status quo is not good, because we are forced to keep old, and potentially buggy, versions of software around longer than necessary. William I think the simplest short-term solution might be to add teams that are looking for ArchTesters to the Staffing Needs page on the wiki and promote that page like crazy. I'd be more likely to do a lot more stabilizations if it wasn't just me going on my experience and running through the AT procedures myself (they're also a bit lengthy if you follow them properly, which I prefer to). I do feel some arches should be a bit deprecated. Not quite as severely other arches the council deprecated a few months back, but something. Also, to ease the burden on Arches, it'd be nice if the maintainer would do some of the archtesting work on all their available arches rather than making the AT's/arch teams do it...For example, almost everyone who has a amd64 system, can easily make a x86 chroot (or VM) to test in. Another option (and I don't mean to step on any toes or call anyone out here, these are just examples) may be to just deprecate stabilizing certain software. Packages such as the stuff in app-vim/ or app-emacs/ or some games or some scientific software. For the editor plugins, most people do not get them from the package manager I feel and a Vim plugin requires almost as much arch testing work as a new version of grep, for example...
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Tue, 14 Jan 2014 15:37:19 -0600 William Hubbs willi...@gentoo.org wrote: Thoughts? In this situation, I see three opposite ends of choices: 1. We do nothing; which means that as a side effect either less often a version would be picked for stabilization or stabilizations will just take longer due to a longer queue. The question here is whether the queue is actually growing; to get a quick idea, we could compare the amount of bugs we have now compared to those of last time. Advantage:We keep the same policy and quality of stabilization. Disadvantage: Stable runs further behind. Waiting time. Frustration. Resources:We need to find more people for the arch teams. 2. We crowd source it; which means we tackle the 'low manpower' problem itself, we invite at a larger scale feedback for packages in one or another way. This ranges from a simple reminder when merging a non-stable package to report back whether it is working, to a more large scale new website effort where this can be done much more organized; but that's a whole discussion on its own. Advantage:Power to the community. Need for arch teams decreases. Disadvantage: Stabilization quality could drop. Enough feedback? Resources:We need to patch up and/or write enough to pull attention from the user that there aid is needed. 3. We make stable mean less; which means that we accept the 'low manpower' problem, this would as a consequence thus mean that because we cannot put in enough effort to deem everything stable anymore. The word 'stable' would thus mean less, instead of 'thoroughly tested by a separate person' it becomes 'tested by the same maintainer'. Advantage:Gentoo becomes slightly more bleeding edge. Disadvantage: Problematic for important packages were stabilization is really needed; 'stability' of some user application has a much smaller meaning than on a library shared between multiple applications of the user. Resources:Less resources used, though it might yield more bugs. Of course this is not meant to limit other choices, there might be others and I hope people bring them forward; as a closing word it feels hard to decide here, especially since it can have quite an effect on the distribution. As put above neither option seems convincing, neither option seems like it is without risk; does anyone have a different view? Unless we only do a small version of those options, like changing a minor detail instead of pushing it through at once; which could be a more safe step forward. Which smaller options do we have here? If at all, maybe experiment something on one arch to start with? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
Am Mittwoch, 15. Januar 2014, 00:49:28 schrieb Tom Wijsman: On Tue, 14 Jan 2014 15:37:19 -0600 William Hubbs willi...@gentoo.org wrote: Thoughts? In this situation, I see three opposite ends of choices: Here's another idea: 4. Friendly ask the arch teams / make a policy that @system packages come first. (maybe these stable requests could be marked major in bugzilla then?) -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Tue, 14 Jan 2014 16:57:30 -0500 Michael Orlitzky m...@gentoo.org wrote: On 01/14/2014 04:37 PM, William Hubbs wrote: 2. I would like to see the policy below applied to all arch's [2]. [ ] Yup [X] Nope For which reason? I could do [✓] Yup [X] Nope 'cause a stable version that's no longer stable (due to found bugs) shouldn't remain, otherwise it is falsely shown to the users as being stable; whereas it could very well be old, insecure and buggy instead. Together with a news message, users could appreciate this. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Tue, 14 Jan 2014 17:43:57 -0500 Michael Orlitzky m...@gentoo.org wrote: It's attempting to fix a headache with a bullet. The arch teams are lagging behind, you're annoyed, I get it. Give 'em hell. But don't break stable to make a point. For users, both options are worse than the status quo. When you do nothing then things are bound to get worse, under the assumption that manpower doesn't change as well as the assumption that the queue fills faster than stabilization bugs get added to it. As a result of this, stable will eventually become broken. It is up to you as well as us whether to consider it to be broken right now. Will it be in a month from now? What about in a year? Will we wait for hell? Or try to prepare and/or fix it now? Maybe there are other options if these can be deemed as being worse. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On 01/14/2014 07:06 PM, Andreas K. Huettel wrote: Am Mittwoch, 15. Januar 2014, 00:49:28 schrieb Tom Wijsman: On Tue, 14 Jan 2014 15:37:19 -0600 William Hubbs willi...@gentoo.org wrote: Thoughts? In this situation, I see three opposite ends of choices: Here's another idea: 4. Friendly ask the arch teams / make a policy that @system packages come first. (maybe these stable requests could be marked major in bugzilla then?) Actually that's a very good idea. In fact, since those are the critical packages we can have the arch teams focus on them, and allow more relax policies of stabilization on less critical packages. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Tue, 14 Jan 2014 18:22:51 -0500 Jeff Horelick jdh...@gentoo.org wrote: I think the simplest short-term solution might be to add teams that are looking for ArchTesters to the Staffing Needs page on the wiki Adding a lot of them could make it noisy, I think we could just make one entry to link to a page that lists them in detail; alternatively we can work with some kind of categorization on the same page. You could determine the success of the current version by checking whether BSD and x86 arch teams (currently listed there) have seen enough new arch testers over the time the need was listed. and promote that page like crazy. It's linked to from the Gentoo homepage near the bottom of the left hand side list; I was thinking, maybe we could add something like a 200x250 sized banner advertisement somewhere advertising the ability to contribute and forward people to a relevant Wikipedia page. Besides it being linked there, hwoarang has very recently linked to this from the Google+ website; on IRC we have this URL near the end of the #gentoo-dev-help topic. Recently I revamped https://wiki.gentoo.org/wiki/Contributing_to_Gentoo where there are two lines that could invite people to the arch testing business, these two: - Become an arch tester; for instance, check out the arch teams x86 and amd64. - Become a Gentoo Developer and join one or more of the many herds to contribute to interesting project(s). But I feel like that page itself can use much more attention. Is anyone here good in advertising and promotion skills? :) I'd be more likely to do a lot more stabilizations if it wasn't just me going on my experience and running through the AT procedures myself (they're also a bit lengthy if you follow them properly, which I prefer to). We could optimize the AT pages to make them look less scary to people; especially if it's described as 'bit length' it doesn't sound like a neat workflow that I would be wanting to read through, maybe some things would be too wordy here or some things could be put in a tool? (Haven't actually looked, but reading length can matter a lot) I do feel some arches should be a bit deprecated. Not quite as severely other arches the council deprecated a few months back, but something. Yes, maybe; whatever we do, I hope it to be an arch-by-arch approach. Also, to ease the burden on Arches, it'd be nice if the maintainer would do some of the archtesting work on all their available arches rather than making the AT's/arch teams do it...For example, almost everyone who has a amd64 system, can easily make a x86 chroot (or VM) to test in. The problem (at least for overworked maintainers) is that this moves efforts from one place to another; and thus, while this could result in near the same quality stabilizations, it will remove (or delay) either work efforts or quality in other places due to the lack of time. Another option (and I don't mean to step on any toes or call anyone out here, these are just examples) may be to just deprecate stabilizing certain software. Packages such as the stuff in app-vim/ or app-emacs/ or some games or some scientific software. For the editor plugins, most people do not get them from the package manager I feel and a Vim plugin requires almost as much arch testing work as a new version of grep, for example... Sounds like a good idea, but how do we translate that to the user; always mark them stable, or always mark them unstable? Do we want users to explicitly accept keywords on these packages? -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Wed, 15 Jan 2014 01:06:07 +0100 Andreas K. Huettel dilfri...@gentoo.org wrote: Am Mittwoch, 15. Januar 2014, 00:49:28 schrieb Tom Wijsman: On Tue, 14 Jan 2014 15:37:19 -0600 William Hubbs willi...@gentoo.org wrote: Thoughts? In this situation, I see three opposite ends of choices: Here's another idea: 4. Friendly ask the arch teams / make a policy that @system packages come first. Hmm, I'm wondering if that has an actual use or whether that would just move the problem. The bug in question that WilliamH demonstrated is indeed part of @system; but shouldn't be, it is due to functions.sh. So, assuming OpenRC wouldn't have been part of it, as it should be; this suggestion wouldn't change WilliamH's problem. Then comes the question whether we expand on all options in the virtuals, dependencies that come in through certain USE flags of @system; as well as the important libraries that aren't necessarily part of @system. Though on the other hand, what would be the point of prioritizing stabilization of important libraries if the applications are way too long detailed? Maybe it could improve their workflow of picking bugs a bit, dunno; I guess arch teams can shed some light on this last part. (maybe these stable requests could be marked major in bugzilla then?) Given that I think that we want more than just @system in the future, but those other things wouldn't be as important as @system and thus need a different way of being marked; I think we should rather pick blocker for @system packages. Then it still leaves us critical and major available for packages that are in between being the most and least important. Though as said, I think this would make only certain people happy; the question is to whereas how unhappy the other people would be, I can't really comment on this because of completely using unstable here. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Tue, 14 Jan 2014 19:17:35 -0500 Anthony G. Basile bluen...@gentoo.org wrote: On 01/14/2014 07:06 PM, Andreas K. Huettel wrote: Am Mittwoch, 15. Januar 2014, 00:49:28 schrieb Tom Wijsman: On Tue, 14 Jan 2014 15:37:19 -0600 William Hubbs willi...@gentoo.org wrote: Thoughts? In this situation, I see three opposite ends of choices: Here's another idea: 4. Friendly ask the arch teams / make a policy that @system packages come first. (maybe these stable requests could be marked major in bugzilla then?) Actually that's a very good idea. In fact, since those are the critical packages we can have the arch teams focus on them, and allow more relax policies of stabilization on less critical packages. Besides allowing certain packages to be set a higher policy, we could also recommend that maintainers lower it if needed; for example: If I want to stabilize some plugin, it doesn't really have to be put Normal you know; I wouldn't bother it to be Enhancement. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Wed, Jan 15, 2014 at 01:38:08AM +0100, Tom Wijsman wrote: On Wed, 15 Jan 2014 01:06:07 +0100 Andreas K. Huettel dilfri...@gentoo.org wrote: Am Mittwoch, 15. Januar 2014, 00:49:28 schrieb Tom Wijsman: On Tue, 14 Jan 2014 15:37:19 -0600 William Hubbs willi...@gentoo.org wrote: Thoughts? In this situation, I see three opposite ends of choices: Here's another idea: 4. Friendly ask the arch teams / make a policy that @system packages come first. Hmm, I'm wondering if that has an actual use or whether that would just move the problem. The bug in question that WilliamH demonstrated is indeed part of @system; but shouldn't be, it is due to functions.sh. Correct; Openrc ultimately will not be part of @system; it is provided by a virtual that is. If you want to say @system, you have to include all rdepends of virtuals in @system and all packages that are dependencies of any packages in @system, at least. Keeping track of that will be difficult at best. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On 01/14/2014 06:11 PM, William Hubbs wrote: For users, both options are worse than the status quo. The first option would start reverting things back to ~ and users would have to unmask them. The second option would introduce new things to stable which may not be stable due to not being tested on the arch. The second option is worse than the first imo, that's why I didn't propose it first. The status quo is not good, because we are forced to keep old, and potentially buggy, versions of software around longer than necessary. So you're going to force stable users onto the unstable, untested version, which they could have done anyway if they wanted to. Strictly worse than the status quo (where it's optional).
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On 01/14/2014 07:13 PM, Tom Wijsman wrote: For users, both options are worse than the status quo. When you do nothing then things are bound to get worse, under the assumption that manpower doesn't change as well as the assumption that the queue fills faster than stabilization bugs get added to it. As a result of this, stable will eventually become broken. It is up to you as well as us whether to consider it to be broken right now. Will it be in a month from now? What about in a year? Will we wait for hell? Or try to prepare and/or fix it now? Maybe there are other options if these can be deemed as being worse. As I mentioned in a reply to William, right now I can decide when stuff is broken and keyword the newer versions. The proposal is to force me onto the new versions, which is strictly worse from my perspective. The whole issue of how much it sucks that stable is lagging is orthogonal.
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Tue, 14 Jan 2014 19:47:50 -0500 Michael Orlitzky m...@gentoo.org wrote: On 01/14/2014 06:11 PM, William Hubbs wrote: For users, both options are worse than the status quo. The first option would start reverting things back to ~ and users would have to unmask them. The second option would introduce new things to stable which may not be stable due to not being tested on the arch. The second option is worse than the first imo, that's why I didn't propose it first. The status quo is not good, because we are forced to keep old, and potentially buggy, versions of software around longer than necessary. So you're going to force stable users onto the unstable, untested version, which they could have done anyway if they wanted to. Strictly worse than the status quo (where it's optional). This is under the assumption that the user knows of the state of the stabilization worsening; if the user is unaware of that change, the could have done anyway might be less common and first something bad would need to happen before they realize the worsened stabilization. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On 01/14/2014 08:08 PM, Tom Wijsman wrote: This is under the assumption that the user knows of the state of the stabilization worsening; if the user is unaware of that change, the could have done anyway might be less common and first something bad would need to happen before they realize the worsened stabilization. If I don't realize it, it ain't broke.
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Tue, 14 Jan 2014 19:50:30 -0500 Michael Orlitzky m...@gentoo.org wrote: On 01/14/2014 07:13 PM, Tom Wijsman wrote: For users, both options are worse than the status quo. When you do nothing then things are bound to get worse, under the assumption that manpower doesn't change as well as the assumption that the queue fills faster than stabilization bugs get added to it. As a result of this, stable will eventually become broken. It is up to you as well as us whether to consider it to be broken right now. Will it be in a month from now? What about in a year? Will we wait for hell? Or try to prepare and/or fix it now? Maybe there are other options if these can be deemed as being worse. As I mentioned in a reply to William, right now I can decide when stuff is broken and keyword the newer versions. As in the mail I send seconds ago, I could complete this sentence with ... because I know stabilaziton has lagged / worsened; but how does the user know of that? If we keep things the same we might consider to bring out a news item to at least make them aware of this, that news item might even be useful to attract new arch testers at the same time. The proposal is to force me onto the new versions, which is strictly worse from my perspective. The whole issue of how much it sucks that stable is lagging is orthogonal. That's one of the proposals, there are others; and staying where we are is one of them, but we need to account for that (eg. recruit more, perhaps a news item, ...) to keep that option a good choice. Having stabilization eventually die due to the extra lag that collected over time is just another way of forcing you onto the new versions, which makes it less worse than you think it is; it might take a bit longer and yield a slow and painful death. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Tue, 14 Jan 2014 20:11:24 -0500 Michael Orlitzky m...@gentoo.org wrote: On 01/14/2014 08:08 PM, Tom Wijsman wrote: This is under the assumption that the user knows of the state of the stabilization worsening; if the user is unaware of that change, the could have done anyway might be less common and first something bad would need to happen before they realize the worsened stabilization. If I don't realize it, it ain't broke. So, you're going to wait for corruption, a security breach or something along those lines to happen first? Corruption is what stabilization of consistent dependencies can prevent, rather than relying on a =... dependency too much. Security is what prevents security bugs from remaining present. And so on... If you don't realize it, it ain't fixed. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Tue, 14 Jan 2014 18:46:06 -0600 William Hubbs willi...@gentoo.org wrote: If you want to say @system, you have to include all rdepends of virtuals in @system and all packages that are dependencies of any packages in @system, at least. Keeping track of that will be difficult at best. Trying to depclean it gives a warn, which is a simple form to check it; we could probably optimize this if it needs to run faster. Or we have some separate script generate an online list (like our rev deps) to quickly check it up with; could go a step further, one can set up a tool to ensure the bugs get set accordingly. For example; see security's GLSA bug bot, which is much more complex. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On 01/14/2014 08:23 PM, Tom Wijsman wrote: On Tue, 14 Jan 2014 20:11:24 -0500 Michael Orlitzky m...@gentoo.org wrote: On 01/14/2014 08:08 PM, Tom Wijsman wrote: This is under the assumption that the user knows of the state of the stabilization worsening; if the user is unaware of that change, the could have done anyway might be less common and first something bad would need to happen before they realize the worsened stabilization. If I don't realize it, it ain't broke. So, you're going to wait for corruption, a security breach or something along those lines to happen first? I will wait for them to be *known*. Security stabilizations are already treated special, so while they'd make a nice example here you don't get to invoke them =) It's highly unlikely that one day a stable piece of software is just going to start corrupting data randomly when some other stable package is updated. Why? Because arch testers have to test them before they go stable! It's even more unlikely that upgrading to untested stuff would be safer than staying put, which is really all I care about given a choice between the two. For really bad cases like data corruption we already have procedures that allow quick stabilization (reasonable amount of time...). All we're really talking about here is forcing me to upgrade to an unstable package for some features or bugfixes I don't care about.
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Tue, Jan 14, 2014 at 08:36:10PM -0500, Michael Orlitzky wrote: On 01/14/2014 08:23 PM, Tom Wijsman wrote: On Tue, 14 Jan 2014 20:11:24 -0500 Michael Orlitzky m...@gentoo.org wrote: On 01/14/2014 08:08 PM, Tom Wijsman wrote: This is under the assumption that the user knows of the state of the stabilization worsening; if the user is unaware of that change, the could have done anyway might be less common and first something bad would need to happen before they realize the worsened stabilization. If I don't realize it, it ain't broke. So, you're going to wait for corruption, a security breach or something along those lines to happen first? I will wait for them to be *known*. Security stabilizations are already treated special, so while they'd make a nice example here you don't get to invoke them =) It's highly unlikely that one day a stable piece of software is just going to start corrupting data randomly when some other stable package is updated. Why? Because arch testers have to test them before they go stable! It's even more unlikely that upgrading to untested stuff would be safer than staying put, which is really all I care about given a choice between the two. For really bad cases like data corruption we already have procedures that allow quick stabilization (reasonable amount of time...). All we're really talking about here is forcing me to upgrade to an unstable package for some features or bugfixes I don't care about. After the package has been sitting in ~arch for 90 days with an open stable request with no blockers that the arch team has not taken any action on. We are not talking about randomly yanking package versions, just doing something when arch teams are not responsive, and it seems that the cleanest thing to do would be to remove the old versions. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On 01/14/2014 09:09 PM, William Hubbs wrote: After the package has been sitting in ~arch for 90 days with an open stable request with no blockers that the arch team has not taken any action on. We are not talking about randomly yanking package versions, just doing something when arch teams are not responsive, and it seems that the cleanest thing to do would be to remove the old versions. People running stable value... stability. I would much rather wait for the arch teams to get un-busy than to be forced to upgrade to something untested. Why would I care if it takes another month? Strictly from a user's perspective. I don't, unless I do, in which case I know that I do, and I could just keyword the thing if I wanted to.
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Tue, 14 Jan 2014 20:36:10 -0500 Michael Orlitzky m...@gentoo.org wrote: On 01/14/2014 08:23 PM, Tom Wijsman wrote: On Tue, 14 Jan 2014 20:11:24 -0500 Michael Orlitzky m...@gentoo.org wrote: On 01/14/2014 08:08 PM, Tom Wijsman wrote: This is under the assumption that the user knows of the state of the stabilization worsening; if the user is unaware of that change, the could have done anyway might be less common and first something bad would need to happen before they realize the worsened stabilization. If I don't realize it, it ain't broke. So, you're going to wait for corruption, a security breach or something along those lines to happen first? I will wait for them to be *known*. The question is whether you or the user will want to wait whether it *happens* to you; of course you can restrict yourself to what's known, but you cannot keep track of *everything that's known* out there easily. And even if you were hundred security experts tracking everything; that wouldn't reflect the user, neither our security team. Just like stabilization, efforts are limited in security; so, you're going to have to rely on a problem similar to that of WilliamH. Besides that, *unknown* things could happen to you too; are you sure you definitely want to wait for that to happen? Or rather upgrade? Security stabilizations are already treated special, so while they'd make a nice example here you don't get to invoke them =) Assuming every security bug is known by the public. =) It's highly unlikely that one day a stable piece of software is just going to start corrupting data randomly when some other stable package is updated. That is exactly one of the popular ways to introduce incompatibilities; and thus, it can cause corruption or something less worse than that to happen. There are other things like data loss, like we see happen more often with hangs and crashes; corruption is just one example of many... Why? Because arch testers have to test them before they go stable! Testing all reverse dependencies of sys-libs/glibc or one of the other important libraries is rather impossible given the lack of resources, you're relying on the same problem WilliamH has here; well, you could select a sample set of them perhaps, but you cannot assure there to be no regression in a small set of the reverse dependencies. Arch testers have to test them before they go stable! Why? Because of the lack of upper bounds on deps, neither do they have proper slots, and not to forget that stabilizations are laggy; interesting! It's even more unlikely that upgrading to untested stuff would be safer than staying put, which is really all I care about given a choice between the two. untested (subjective) != unstable (objective), safer(subjective) != stable (objective), I care (subjective) != users care (objective). There's doubt in this paragraph, but no constructive reasoning. You are focusing on a single solution instead of focusing on the actual problem and the other solutions; while you may very well care for one solution not to happen, that doesn't ensure that we keep what we have. If you tell us what you want, we can do something about it. If you tell us what you don't want, but don't tell that to us based on what you want; it becomes a vote without any value instead than a discussion. For really bad cases like data corruption we already have procedures that allow quick stabilization (reasonable amount of time...). Turn this sentence around and you'll see how quick stabilization leads to less data corruption. All we're really talking about here is forcing me to upgrade to an unstable package for some features or bugfixes I don't care about. You are focusing on a single solutions instead of ... [see above]. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Tue, 14 Jan 2014 21:21:51 -0500 Michael Orlitzky m...@gentoo.org wrote: On 01/14/2014 09:09 PM, William Hubbs wrote: After the package has been sitting in ~arch for 90 days with an open stable request with no blockers that the arch team has not taken any action on. We are not talking about randomly yanking package versions, just doing something when arch teams are not responsive, and it seems that the cleanest thing to do would be to remove the old versions. People running stable value... stability. gentoo-sources-3.10.25 is stable on the most important arches; but, other arches are left in the dark with a stable 3.10.7(-r1). Now, what is well known is that kernel.org upstream backports mostly known fixes; as their goals is for this long term stable branch to increase the value of what you claim people running stable need... stability. But, as those people running stable on those arches are stuck on 3.10.7(-r1); heh, they're not running the more stable kernel at all. I would much rather wait for the arch teams to get un-busy than to be forced to upgrade to something untested. If they get stabilization requests faster than they can stabilize, then they will remain busy for as long as we don't get manpower to turn around the tide; and as mentioned in the mail of a few minutes ago, there are other options possible too. Forcing is just one of them. Why would I care if it takes another month? What about another year? Or ten years? Why would users care? Strictly from a user's perspective. I don't, unless I do, in which case I know that I do, and I could just keyword the thing if I wanted to. This is the exact same argument as in your other mail, which is your point of view; this is under the assumption that you know that stabilization is worsening over time, which users may not perceive. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On 01/14/2014 09:34 PM, Tom Wijsman wrote: Strictly from a user's perspective. I don't, unless I do, in which case I know that I do, and I could just keyword the thing if I wanted to. This is the exact same argument as in your other mail, which is your point of view; this is under the assumption that you know that stabilization is worsening over time, which users may not perceive. I've written too many emails today, I hereby give up =)
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Tue, 14 Jan 2014 20:09:34 -0600 William Hubbs willi...@gentoo.org wrote: After the package has been sitting in ~arch for 90 days with an open stable request with no blockers that the arch team has not taken any action on. We are not talking about randomly yanking package versions, just doing something when arch teams are not responsive, and it seems that the cleanest thing to do would be to remove the old versions. Exactly, the common case for stabilization bugs is that stabilization just happens; as far as I have seen, it is rather rare that another bug blocks the stabilization bug. At least this is the case for the common package; as for important bugs, which should be treated with more care, it is more common for these blocking bugs to get filed. If the arch hasn't responded for X months; then marking a version stable oneself on a non-important package should be acceptable, it doesn't yield any huge problem afaik and isn't that much different. And for that occasional mis-guess, *boohoo*, the user can just file a bug; which ironically even happens occasionally for stable packages. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Tue, Jan 14, 2014 at 09:21:51PM -0500, Michael Orlitzky wrote: On 01/14/2014 09:09 PM, William Hubbs wrote: After the package has been sitting in ~arch for 90 days with an open stable request with no blockers that the arch team has not taken any action on. We are not talking about randomly yanking package versions, just doing something when arch teams are not responsive, and it seems that the cleanest thing to do would be to remove the old versions. People running stable value... stability. I would much rather wait for the arch teams to get un-busy than to be forced to upgrade to something untested. Why would I care if it takes another month? Strictly from a user's perspective. I don't, unless I do, in which case I know that I do, and I could just keyword the thing if I wanted to. s/month/year/ Do you feel the same way then? I have heard of stabilizations taking this long before. I just had to try to pick something reasonable for the discussion. I suppose a compromise would be, instead of removing the old versions, move them back to ~arch for a month then remove them, but that still implies action on your part. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Tue, 14 Jan 2014 21:40:24 -0500 Michael Orlitzky m...@gentoo.org wrote: I've written too many emails today, I hereby give up =) At least you've let your voice be heard against this option. :) It sets the ground for discussion for people that agree with you. -- With kind regards, Tom Wijsman (TomWij) Gentoo Developer E-mail address : tom...@gentoo.org GPG Public Key : 6D34E57D GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D signature.asc Description: PGP signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Tue, 14 Jan 2014, William Hubbs wrote: 1. I think maintainers should be able to stabilize their packages on arch's they have access to. I think this is allowed by some arch teams, but I think it would be good to formalize it. +1 Also, there is a substantial number of packages which contain only python code (or perl, ruby), or only LaTeX classes, or only documentation. It makes no sense to test them on each arch separately. I think maintainers should be allowed to stabilize such packages (with no compiled code) on all arches. Andrey
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Wed, Jan 15, 2014 at 10:48:53AM +0700, gro...@gentoo.org wrote: On Tue, 14 Jan 2014, William Hubbs wrote: 1. I think maintainers should be able to stabilize their packages on arch's they have access to. I think this is allowed by some arch teams, but I think it would be good to formalize it. +1 Also, there is a substantial number of packages which contain only python code (or perl, ruby), or only LaTeX classes, or only documentation. It makes no sense to test them on each arch separately. I think maintainers should be allowed to stabilize such packages (with no compiled code) on all arches. There is a reason we don't do this, back in Gentoo history somewhere, but I don't remember what it was. If someone can tell us why this isn't allowed I am all ears. Otherwise, I could agree on this point as well. William signature.asc Description: Digital signature
Re: [gentoo-dev] rfc: revisiting our stabilization policy
On Tue, Jan 14, 2014 at 10:49:48PM -0600, William Hubbs wrote: Also, there is a substantial number of packages which contain only python code (or perl, ruby), or only LaTeX classes, or only documentation. It makes no sense to test them on each arch separately. I think maintainers should be allowed to stabilize such packages (with no compiled code) on all arches. There is a reason we don't do this, back in Gentoo history somewhere, but I don't remember what it was. If someone can tell us why this isn't allowed I am all ears. Otherwise, I could agree on this point as well. I vaguely recall an example of some non-compiled Perl code that wasn't portable over architectures. However I feel that should really be the exception, not the general case. -- Robin Hugh Johnson Gentoo Linux: Developer, Infrastructure Lead E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
