Re: [gentoo-dev] rfc: stabilization policies
On 20/08/2013 22:25, Tom Wijsman wrote: On Tue, 20 Aug 2013 22:00:52 +0200 Alan McKinnon alan.mckin...@gmail.com wrote: As a long time user and citizen of -user I can tell you what the general feeling of arch vs ~arch there is: Thanks for jumping into the discussion. arch has plenty old stuff in it Yes, it keeps me from using it; I would have to unmask too much... ~arch is plenty good enough for everything except very mission critical stuff ~arch does not break every other day, and breakage is actually surprisingly rare. And, it's usually confined to openrc/udev/systemd/baselayout and other critical packages where one just knows upfront anyway that danger may lurk ahead. Some folks like me sync daily and accept that I deal with occasional breakage maybe once a month. Usually I just mask an offending package and move on. Others wait a few days and if no reported bugs, then emerge it. This really sounds like what would be the description of stable; I mean, for mission critical stuff someone would plan out a migration and test the upgrade prior to applying it to the server. For the rest, except for maybe that critical packages shouldn't break; an issue once a month is something that slips through, eg. see the stable bugs... I get the sense that hard masked and - is the new testing, Actually, hard masked is usually something that is really broken; while there are some things masked for some other reasons, you can't really regard it as testing. But yeah, as for -, it could be considered testing; although it is often broken, because of broken patches, ... I also get the sense that arch progresses too slowly for many people. +1 that's one of the points that came up on IRC; 30 days and more being too long, because not everyone follows up with that time schedule (we are people, not cronjobs), it even gets a bit longer... How long did we wait for MySQL-5.5 to reach arch? Folk wanted that one in stable reasonably early and mixing arch/~arch is very very bad in real life. Hence the recommendation to switch to ~arch, and it usually works out just fine. Yes, but we don't want to end up having everyone having mixed trees or be on ~arch; if we do, stabilization is going to become a wasted effort. Perhaps the area to be clarified is what is the intended risk profile for arch and ~arch? stable and unstable mean very different things to different people, they are quite overloaded terms, so a proper definition is in order. Then users can also accurately just what they are going to get in arch as well as the intended level of stability. We already have a good beginning with the usual description of ~arch as works pretty much OK most of the time but new ebuilds go in here first so expect some breakage sometimes. Let's express that in terms of risk. Something else we should also keep in mind - binary distros often recommend that autoupdates be enabled. If people do this it changes the game play as they really don't know what is coming down the wire at all. Gentoo is different - nothing changes until you sync and emerge world and this really does require that the sysadmin eyeballs the output. This removes a lot of the risk from the devs (you can't really know what my USE will do on my end so I must assume some responsibility for my choices). I do believe this gives the devs a lot of wiggle room to get things into arch quicker without having to test and verify every little thing. -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-dev] Re: rfc: stabilization policies
On 21/08/2013 05:31, Tom Wijsman wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 20 Aug 2013 14:28:15 -0400 Ian Stakenvicius a...@gentoo.org wrote: I see a few issues with ~arch - table migrations: #1 - things just sit in ~arch. The auto-stablereq script should help with this one I think; we should give it some time to see if it works out. That script has been running for long enough now. It doesn't work out... What do you mean when you say it doesn't work out?
Re: [gentoo-dev] rfc: stabilization policies
On Aug 20, 2013, at 11:19 AM, William Hubbs willi...@gentoo.org wrote: My question is, how can we improve our stabilization procedures/policies so we can convince people not to run production servers on ~arch and keep the stable tree more up to date? do the Arch Linux thing…keep just one version of a package in the tree, as a general rule.
Re: [gentoo-dev] rfc: stabilization policies
On 21/08/2013 03:54, Doug Goldstein wrote: Its also precisely that mix and match that might cause instability due to people not testing things. Case in point QEMU 1.6.0 just came out and it went through a number of release candidates but no one ever saw that it depends only on Python 2.4 but actually needs Python 2.6. That's kind of like Gentoo, a package says it depends on libfoo 1.0 or higher and the dev that tested stable baz 0.8 confirmed it worked with libfoo 1.0, but baz 0.9 in ~arch still depends on libfoo 1.0 but really needs libfoo 1.1 and libfoo 1.1 is ~arch as well. So the developer running ~arch believed that baz 0.9 works fine since he has ~arch libfoo. My point is what Gentoo calls stable is just something that usually 2 or more people have compiled and installed vs ~arch which 1 or more people have compiled and installed. +1 I think comparisons with the RHELs of this world to find what stable means are invalid. Gentoo does not play in RHELs space, and anyone who tries to deploy Gentoo where RHEL is a good fit is somewhat of a fool [Aside: I'm a huge Gentoo fan, all my personal machines are Gentoo or FreeBSD and yet I have banned Gentoo outright at work: juniors cause me too much headaches, and Centos fixed all of that] Gentoo simply cannot offer the same guarantees about stable that RHEL can, mostly for reasons of manpower. The best we can do is to state that we are confident stuff works pretty much mostly OK and doesn't break for everyone, so the user can now do their own tests and decide. Let's also keep in mind that Gentoo is a meta-distribution - it lets you build your own distro. So all the heavy QA lifting that RHEL does for you, you now have to do yourself (that role bumps one run down the ladder). The classic meaning of stable just doesn't quite fit in that scenario. And, a truly stable mission-critical system is one that has all the required features and emerge is never run again except for bug and security fixes. A rolling release will never be truly stable What I'm saying is let's not set the bar for stable too high. Our targeted userbase is somewhat unique in the world. -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-dev] Re: rfc: stabilization policies
On 21/08/2013 05:24, Tom Wijsman wrote: On Tue, 20 Aug 2013 13:19:10 -0500 William Hubbs willi...@gentoo.org wrote: All, I'm not really sure what the answer to this problem is, so I want to know what the group thinks about how we can handle it. During the last release of OpenRC, I learned that people *do* run production servers on ~arch. While I don't, and asked it just because of the large amount; it appears from some things lately, and not just OpenRC, that there is a certain group that regards ~arch as some kind of new stable. This isn't solely about versions entering ~arch, but also about versions leaving ~arch; as ~ is for testing, people should expect their version to break and they should also expect that they cannot rely on a version remaining in the Portage tree, that's just wrong... We would probably benefit from formalising a clearer definition of arch/~arch - it seems to mean a lot of different things to different people.
Re: [gentoo-dev] gtk2/gtk3 use flags
Le mercredi 21 août 2013 à 12:15 +0800, Ben de Groot a écrit : On 21 August 2013 07:36, Gilles Dartiguelongue e...@gentoo.org wrote: Le mardi 20 août 2013 à 17:31 +0400, Sergey Popov a écrit : 16.08.2013 21:15, hasufell пишет: https://bugs.gentoo.org/show_bug.cgi?id=420493 gtk2 and gtk3 useflags are discouraged and should only be used in special cases file a bug for those if there is not one already What's about maintainer wish to support both of toolkits? I have dropped GTK2 support in gtkdiskfree[1], but it seems that proxied maintainer will quit if i keep things that way :-/ The upstream maintainer is free to support both toolkits if he wishes to do so, but we strongly recommend to only select one slot for applications in gentoo tree, the one which works best for the application. -- Gilles Dartiguelongue e...@gentoo.org Gentoo When upstream supports both, and the maintainer wishes to do so as well, I would strongly recommend to support both, so that end-users can make their own choices. Some may wish to use the applications in a light-weight gtk2-only environment such as LXDE. As long as gtk+:2 is supported in the tree, I don't see why we should artificially restrict such choices for our users. The reasons are enumerated on the wiki and are just a summary of the older thread where this was discussed. Of course, since there is no body to impose such rules, you are free to go against gnome team self imposed policy and recommendation. -- Gilles Dartiguelongue e...@gentoo.org Gentoo
Re: [gentoo-dev] rfc: stabilization policies
20.08.2013 22:28, Ian Stakenvicius пишет: I see a few issues with ~arch - table migrations: #1 - things just sit in ~arch. The auto-stablereq script should help with this one I think; we should give it some time to see if it works out. My personal opinion on this - there is some package, that should not go into stable. Do not get me wrong, but i presumes that stable gives user ability to run well-working applications. If package can fail in some stupid untrivial ways and maintainer can reproduce this - then this version should not go into stable. And you know that some packages can be in such state, well, for years of active development. But it does not mean that some subset of users needs them. That's why - ~arch(or, if they are broken in some security-related things - hardmasked). -- 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: stabilization policies
20.08.2013 23:48, Tom Wijsman пишет: Yes, +1; last time this came up on chat, I asked whether it would be a nice idea to have something between stable and ~, what you propose sounds similar and might make sense. Though, on the other hand, doing it this way we don't get the advantages that filing bugs give; if we do it this way, I'd assume we need some other implementation to cover that (for things like the depends on, blocks, ... fields)... Why we should bring new half-stable, half-testing keyword for this? I think that this is no way to go. We should improve current situation with arches by some other ways(e.g., recruiting people). Maybe drop some damn-bad understaffed arches to unstable only(i do not point finger on anyone, they know, who they are... :-)) -- 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: stabilization policies
20.08.2013 23:42, Tom Wijsman пишет: On Tue, 20 Aug 2013 14:29:09 -0400 Wyatt Epp wyatt@gmail.com wrote: What manner of bitrot? They might ... 2. ... contain security bugs that later versions have fixed. There should be security bug on our bugzilla with quick stabilization on it and(probably) GLSA. -- 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
[gentoo-dev] Re: rfc: stabilization policies
On 21/08/2013 17:54, Sergey Popov wrote: Why we should bring new half-stable, half-testing keyword for this? I think that this is no way to go. We should improve current situation with arches by some other ways(e.g., recruiting people). Maybe drop some damn-bad understaffed arches to unstable only(i do not point finger on anyone, they know, who they are... :-)) I agree, I don't think adding a new keyword will help. I am also a big fan of dropping understaffed archs to unstable (or if that is too much, only keeping stable keywords for important system packages).
Re: [gentoo-dev] rfc: stabilization policies
21.08.2013 00:06, Tom Wijsman пишет: On Tue, 20 Aug 2013 15:41:42 -0400 Rich Freeman ri...@gentoo.org wrote: Let me dig up an example... Our last sys-kernel/gentoo-sources stabilization was 3 months ago: I don't really see a problem with stable package being all of 3 months old. Contrast that with youtube-dl which pull from ~arch and rebuild about 3x/week. For something that releases once to twice a week, it is a problem; we're not talking about a package that gets some slow commits here, no, let's run `git log --oneline v3.8.13..v3.10.7 | wc -l`: 28233 And you are dead sure that shiny new versions does not need testing in Gentoo for a reasonable amount of time(30 days)? If yes, then we have a problem in definitions here(thus, i am not talking about security stabilizations, they should be done as quickly, as bug reveals) That's a lot of commits; now you need to realize that every single commit in this means something, a lot of them are bug fixes (stability, security, reliability, anti corruption, ...) whereas of course a part of it also introduces parts of new features and refactoring. Desktop users might not care for all of these, but sysadmins will; actually, that's what this thread is about, they are switching to ~ because of things like this. Who are we stabilizing for then?! You should undestand that stabilizing new kernel should also imply that some important modules, presenting in tree will also work with them. I really do not like slow upstreams and situations like with nvidia-drivers, but i understand that this is not kernel team matter, it is upstream problem. And that fact, that you can successfully build and run kernel for a couple of hours, does not make it good, well tested stable candidate Bitrot due to a lack of resources. Such problem is exists, yeah, i agree. But do not overcomplicate things. We should fight with lack of resources, not with turning stable into just more old, but also breakable testing -- 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: stabilization policies
21.08.2013 00:00, Alan McKinnon пишет: Hey, maybe you guys are doing your job in ~arch *too well*, to your own detriment :-) Something to consider? ~arch should not break every day, yeah(we have hardmasked for that :-P), but it means that breakages are ALLOWED and it is NORMAL if they are not severe. -- 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] Re: rfc: stabilization policies
On Wed, 21 Aug 2013 16:51:37 +1000 Michael Palimaka kensing...@gentoo.org wrote: On 21/08/2013 05:31, Tom Wijsman wrote: On Tue, 20 Aug 2013 14:28:15 -0400 Ian Stakenvicius a...@gentoo.org wrote: That script has been running for long enough now. It doesn't work out... What do you mean when you say it doesn't work out? If it did, as we waited quite a while; we wouldn't have this thread. -- 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: stabilization policies
On Wed, 21 Aug 2013 11:54:48 +0400 Sergey Popov pinkb...@gentoo.org wrote: by some other ways(e.g., recruiting people). Recruiting shows to be a hard task; so, the suggestions I am doing are assuming that that doesn't work out. In which case, I wonder what by some other ways you would think of... -- 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: stabilization policies
On Wed, 21 Aug 2013 11:57:22 +0400 Sergey Popov pinkb...@gentoo.org wrote: 20.08.2013 23:42, Tom Wijsman пишет: On Tue, 20 Aug 2013 14:29:09 -0400 Wyatt Epp wyatt@gmail.com wrote: What manner of bitrot? They might ... 2. ... contain security bugs that later versions have fixed. There should be security bug on our bugzilla with quick stabilization on it and(probably) GLSA. Not all security bugs are visible; the older a piece of software, the higher the chance that some people know about one or another exploit that the rest of the world does not know about. -- 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] Re: rfc: stabilization policies
El mié, 21-08-2013 a las 18:08 +1000, Michael Palimaka escribió: On 21/08/2013 17:54, Sergey Popov wrote: Why we should bring new half-stable, half-testing keyword for this? I think that this is no way to go. We should improve current situation with arches by some other ways(e.g., recruiting people). Maybe drop some damn-bad understaffed arches to unstable only(i do not point finger on anyone, they know, who they are... :-)) I agree, I don't think adding a new keyword will help. I am also a big fan of dropping understaffed archs to unstable (or if that is too much, only keeping stable keywords for important system packages). I would also like to know concrete cases of packages lacking stable keywords on new enough versions. Maybe some of them comes from packages maintained by understaffed teams and, then, the solution would be different :/ Regarding the kernel... well, I don't think having a 3.8.x kernel as stable one is so old, what are current kernel versions in stable Fedora, OpenSuSE, Mageia... last time I checked we weren't so ahead on this (thanks to kernel team ;)) About Gnome, situation should improve soon, regarding KDE looks like we are OK. Also, with Phajdan Jr automated bug reports situation improved and, usually, the blocker is slow feedback from package maintainers in that bug reports. But once arches are CC, arch teams usually do the job really fast (specially thanks to Ago)
Re: [gentoo-dev] rfc: stabilization policies
21.08.2013 12:17, Tom Wijsman пишет: On Wed, 21 Aug 2013 11:57:22 +0400 Sergey Popov pinkb...@gentoo.org wrote: 20.08.2013 23:42, Tom Wijsman пишет: On Tue, 20 Aug 2013 14:29:09 -0400 Wyatt Epp wyatt@gmail.com wrote: What manner of bitrot? They might ... 2. ... contain security bugs that later versions have fixed. There should be security bug on our bugzilla with quick stabilization on it and(probably) GLSA. Not all security bugs are visible; the older a piece of software, the higher the chance that some people know about one or another exploit that the rest of the world does not know about. True. But blindly bringing new versions into stable(without testing) cause it POSSIBLY(without ChangeLog notes or CVES or whatever) contains LESS security problems is not an option. Stable should be reasonable -- 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
[gentoo-dev] Re: rfc: stabilization policies
On 21/08/2013 18:10, Tom Wijsman wrote: On Wed, 21 Aug 2013 16:51:37 +1000 Michael Palimaka kensing...@gentoo.org wrote: On 21/08/2013 05:31, Tom Wijsman wrote: On Tue, 20 Aug 2013 14:28:15 -0400 Ian Stakenvicius a...@gentoo.org wrote: That script has been running for long enough now. It doesn't work out... What do you mean when you say it doesn't work out? If it did, as we waited quite a while; we wouldn't have this thread. As per your other post, it would be interesting to see who/what the worst offenders are. At least in the areas I usually work, I have found a combination of the automatic stabilisation requests and imlate have definitely cut back on the bitrot.
Re: [gentoo-dev] rfc: stabilization policies
On Wed, 21 Aug 2013 12:07:16 +0400 Sergey Popov pinkb...@gentoo.org wrote: 21.08.2013 00:06, Tom Wijsman пишет: On Tue, 20 Aug 2013 15:41:42 -0400 Rich Freeman ri...@gentoo.org wrote: Let me dig up an example... Our last sys-kernel/gentoo-sources stabilization was 3 months ago: I don't really see a problem with stable package being all of 3 months old. Contrast that with youtube-dl which pull from ~arch and rebuild about 3x/week. For something that releases once to twice a week, it is a problem; we're not talking about a package that gets some slow commits here, no, let's run `git log --oneline v3.8.13..v3.10.7 | wc -l`: 28233 And you are dead sure that shiny new versions does not need testing in Gentoo for a reasonable amount of time(30 days)? If yes, then we have a problem in definitions here(thus, i am not talking about security stabilizations, they should be done as quickly, as bug reveals) 3.10 is not a shiny new version, it has been in the Portage tree for 7 weeks now (upstream release at 2013-06-30 22:13:42 (GMT)); so, that's almost double the time you are suggesting. That's a lot of commits; now you need to realize that every single commit in this means something, a lot of them are bug fixes (stability, security, reliability, anti corruption, ...) whereas of course a part of it also introduces parts of new features and refactoring. Desktop users might not care for all of these, but sysadmins will; actually, that's what this thread is about, they are switching to ~ because of things like this. Who are we stabilizing for then?! You should undestand that stabilizing new kernel should also imply that some important modules, presenting in tree will also work with them. I really do not like slow upstreams and situations like with nvidia-drivers, but i understand that this is not kernel team matter, it is upstream problem. Why should an external proprietary module that does not fix what is broken for 7 weeks now block stabilization; it has never blocked stabilization before, and I do not see a reason it should now... And that fact, that you can successfully build and run kernel for a couple of hours, does not make it good, well tested stable candidate Having people run it for 7 weeks is not a couple of hours. Bitrot due to a lack of resources. Such problem is exists, yeah, i agree. But do not overcomplicate things. We should fight with lack of resources, not with turning stable into just more old, but also breakable testing Well, my thoughts is that the way we are doing it now we aren't going to be able to deal with the lack of resources; so, a different approach is necessary and I don't see how it is old, but also breakable... -- 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] Re: rfc: stabilization policies
On Wed, 21 Aug 2013 17:04:45 +1000 Michael Palimaka kensing...@gentoo.org wrote: We would probably benefit from formalising a clearer definition of arch/~arch - it seems to mean a lot of different things to different people. http://devmanual.gentoo.org/keywording lists a definition; so, now I wonder what it could be misinterpreted as. It states ~ is believed to work, doesn't contain serious bugs but more testing is required... -- 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: stabilization policies
21.08.2013 12:13, Tom Wijsman пишет: Recruiting shows to be a hard task; so, the suggestions I am doing are assuming that that doesn't work out. In which case, I wonder what by some other ways you would think of... Dropping some keywords to unstable on minor arches. And about recruiting, it is the only way we can keep moving with getting distro, which makes bigger and bigger all the time. I would have joined recruiters unless i knew how difficult job they are doing. -- 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: stabilization policies
On Tue, 20 Aug 2013 20:42:57 -0400 Rich Freeman ri...@gentoo.org wrote: On Tue, Aug 20, 2013 at 5:03 PM, Andreas K. Huettel dilfri...@gentoo.org wrote: Stable implies not so often changing. If you really need newer packages on a system that has to be rock-solid, then keyword what you need and nothing else. ++ 30 days is too long? How can something new be stable? Stable doesn't mean I don't think this is broken. Stable means lots of others have already been using this and so far there aren't many reports of breakage. According to distrowatch RHEL is at 2.6.32. I'm sure it has a bazillion backports, but that is what I'd call stable. Running stable means starting to use the stuff everybody else is about ready to stop using. When an upstream releases a new stable release, that means that it is just now ready for testing, and chances are they'll have another stable release before their previous release really is stable. The latest distros seemed to be just a bunch of same old stuff. Nothing new -- nothing innovative. ~ Larry's frustration. :( Then Larry tried Gentoo Linux. He was just impressed. ... He discovered lots of up-to-date packages ... ~ Larry's happiness. :) http://www.gentoo.org/images/poster.jpg -- 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: stabilization policies
21.08.2013 12:25, Tom Wijsman пишет: 3.10 is not a shiny new version, it has been in the Portage tree for 7 weeks now (upstream release at 2013-06-30 22:13:42 (GMT)); so, that's almost double the time you are suggesting. Current stabilization target(3.10.7) was added to tree: *gentoo-sources-3.10.7 (15 Aug 2013) 15 Aug 2013; Tom Wijsman tom...@gentoo.org +gentoo-sources-3.0.91.ebuild, +gentoo-sources-3.10.7.ebuild, +gentoo-sources-3.4.58.ebuild, -gentoo-sources-3.0.87.ebuild, -gentoo-sources-3.10.4.ebuild, -gentoo-sources-3.10.5-r1.ebuild, -gentoo-sources-3.10.6.ebuild, -gentoo-sources-3.4.54.ebuild: Version bumps 3.0.91, 3.4.58 and 3.10.7. Removed old. (skip) So it is definitely NOT 7 weeks(30 days period counting from time when ordinary user can install it through portage, thus - after hitting portage tree). You know, that we can lighten stabilization requirements of 30 days sometimes, but let's be honest. Why should an external proprietary module that does not fix what is broken for 7 weeks now block stabilization; it has never blocked stabilization before, and I do not see a reason it should now... And that fact, that you can successfully build and run kernel for a couple of hours, does not make it good, well tested stable candidate Having people run it for 7 weeks is not a couple of hours. First of all, as i said early - it is NOT 7 weeks(thus - not a couple of hours either). And example with Nvidia drivers is not point of beginning a flamewar. We ARE a distro. Then, we should propose INTEGRATION of some kind. If some open-source modules with active upstreams, included in portage, do not support yet 3.10.* which will lead to unbootable system for some stable users - what you should say? Oops, sorry, guys? That's not how stable should work. We should either mark such modules as forever unstable(or even mask?), saying guys, shit happens, do not use this in Gentoo, unless you are dead sure, that you can handle problems with updates or slowing down stabilization(i am not talking about security stabilization right now). And as for security stabilization, if you say that version bump BRINGS security fixes, you KNOW what they are, and you do NOT file a security bug about old stable(and now - vulnerable!) kernel on Gentoo bugzilla, then current stabilization bug has no relation to security(as Gentoo Security team does not know about security problems), period. Well, my thoughts is that the way we are doing it now we aren't going to be able to deal with the lack of resources; so, a different approach is necessary and I don't see how it is old, but also breakable... I undestand your disturbance as Gentoo Kernel team member. But your proposal does not seem good to me. -- 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] Re: rfc: stabilization policies
On Wed, 21 Aug 2013 18:23:33 +1000 Michael Palimaka kensing...@gentoo.org wrote: On 21/08/2013 18:10, Tom Wijsman wrote: On Wed, 21 Aug 2013 16:51:37 +1000 Michael Palimaka kensing...@gentoo.org wrote: On 21/08/2013 05:31, Tom Wijsman wrote: On Tue, 20 Aug 2013 14:28:15 -0400 Ian Stakenvicius a...@gentoo.org wrote: That script has been running for long enough now. It doesn't work out... What do you mean when you say it doesn't work out? If it did, as we waited quite a while; we wouldn't have this thread. As per your other post, it would be interesting to see who/what the worst offenders are. Well, they are listed there; but it's quite some work to actually go through that list, that is, manually check the bugs of ~2000 packages as well as file a STABLEREQ bug, takes quite a while... At least in the areas I usually work, I have found a combination of the automatic stabilisation requests and imlate have definitely cut back on the bitrot. A single unimportant bug can prevent the automatic STABLEREQ bug from getting filed; as for imlate, not everyone seems to know that tool, not everyone seems to run it. Attention for some stabilizations is lost... -- 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: stabilization policies
21.08.2013 12:39, Tom Wijsman пишет: The latest distros seemed to be just a bunch of same old stuff. Nothing new -- nothing innovative. ~ Larry's frustration. :( Then Larry tried Gentoo Linux. He was just impressed. ... He discovered lots of up-to-date packages ... ~ Larry's happiness. :) http://www.gentoo.org/images/poster.jpg And how that regards about stable, huh? If you want to raise problem that ~arch has too less version bumps, well, that's other topic(but with same reason - lack of manpower :-(). -- 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] Re: rfc: stabilization policies
On Wed, 21 Aug 2013 10:22:39 +0200 Pacho Ramos pa...@gentoo.org wrote: Regarding the kernel... well, I don't think having a 3.8.x kernel as stable one is so old, what are current kernel versions in stable Fedora, OpenSuSE, Mageia... last time I checked we weren't so ahead on this (thanks to kernel team ;)) Don't compare apples and eggs. In other distros, heavy backporting of fixes and so on happens; but on Gentoo, we instead want to keep our genpatches minimal and therefore follow upstream stable more closely. If we have a kernel version stable that is stable on other distros, it is merely a sign that our stabilization currently is in a severe state... -- 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
[gentoo-dev] Re: rfc: stabilization policies
On 21/08/2013 18:30, Tom Wijsman wrote: On Wed, 21 Aug 2013 17:04:45 +1000 Michael Palimaka kensing...@gentoo.org wrote: We would probably benefit from formalising a clearer definition of arch/~arch - it seems to mean a lot of different things to different people. http://devmanual.gentoo.org/keywording lists a definition; so, now I wonder what it could be misinterpreted as. It states ~ is believed to work, doesn't contain serious bugs but more testing is required... To me, this means something like: after carefully writing or updating the ebuild, and testing of the ebuild and application, there were no serious bugs. That is, I have in general found it to be as good as, or an improvement (no serious bugs) on the previous version and it's suitable for wider consumption. Putting in the tree as ~arch will allow wider testing with configuration and usage that I didn't think of. To some people it means something like this: if it doesn't immediately rm -rf / for most users (if you have a funny configuration and this happens, too bad don't use ~arch), it's fine. I'm sure others have many different ideas, too.
Re: [gentoo-dev] rfc: stabilization policies
On Wed, 21 Aug 2013 12:32:35 +0400 Sergey Popov pinkb...@gentoo.org wrote: 21.08.2013 12:13, Tom Wijsman пишет: Recruiting shows to be a hard task; so, the suggestions I am doing are assuming that that doesn't work out. In which case, I wonder what by some other ways you would think of... Dropping some keywords to unstable on minor arches. If we grow (like you said below), then doing less seems like a decision that we shouldn't take; it is rather about doing it different to use our resources in a better way. Crowd sourcing users is an option here... And about recruiting, it is the only way we can keep moving with getting distro, which makes bigger and bigger all the time. Yes, but apart from recruiting you can make the resources used better; if the current way of using our resources isn't sufficient, we can improve that as well. Improving both is going to make the difference. I would have joined recruiters unless i knew how difficult job they are doing. Yes, I am interested in both mentoring and recruiting and I need to contact them again; but I do not really intend to point at recruiters here or how hard that is, what I intend to point at with recruiting is finding those users that are willing to learn to write better ebuilds and are willing to become a Gentoo Developer. They are hard to find; and in order for them to be found, a mentor has to find them somewhere. Came across three types of people already trying to find a mentee: 1. The first one doesn't want to go through the amount of time it takes; this depends a bit on the queue, but it can take months. 2. The second one's interest to become a Gentoo Developer depends from time to time; so, tries to start over and over to become one. 3. The third one writes a lot of ebuilds (and has an overlay that looks like a gold mine), but there is a language barrier that keeps the user from contributing; so, we take things slowly instead... 4. The fourth one leaves a message on IRC and quits before you return. 5. ... So, recruiting in the terms of finding recruits appears to be hard. -- 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: stabilization policies
On Wed, 21 Aug 2013 12:21:41 +0400 Sergey Popov pinkb...@gentoo.org wrote: 21.08.2013 12:17, Tom Wijsman пишет: On Wed, 21 Aug 2013 11:57:22 +0400 Sergey Popov pinkb...@gentoo.org wrote: 20.08.2013 23:42, Tom Wijsman пишет: On Tue, 20 Aug 2013 14:29:09 -0400 Wyatt Epp wyatt@gmail.com wrote: What manner of bitrot? They might ... 2. ... contain security bugs that later versions have fixed. There should be security bug on our bugzilla with quick stabilization on it and(probably) GLSA. Not all security bugs are visible; the older a piece of software, the higher the chance that some people know about one or another exploit that the rest of the world does not know about. True. But blindly bringing new versions into stable(without testing) cause it POSSIBLY(without ChangeLog notes or CVES or whatever) contains LESS security problems is not an option. Stable should be reasonable That's not what I am suggesting. It is not about bringing in new versions, but about getting rid of OLD versions which LIKELY contain MORE security problems than you imagine. Keeping them around for too long time isn't reasonable... -- 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: stabilization policies
Am Mittwoch, 21. August 2013, 10:39:23 schrieb Tom Wijsman: The latest distros seemed to be just a bunch of same old stuff. Nothing new -- nothing innovative. ~ Larry's frustration. :( Then Larry tried Gentoo Linux. He was just impressed. ... He discovered lots of up-to-date packages ... ~ Larry's happiness. :) http://www.gentoo.org/images/poster.jpg Yes. And most of the KDE team is acutally running live (master branch) ebuilds. Yay! Having something stable too is a service and advantage, not a burden. Remember, stable means stable, and Gentoo is about choice! -- Andreas K. Huettel Gentoo Linux developer (council, kde) dilfri...@gentoo.org http://www.akhuettel.de/
Re: [gentoo-dev] rfc: stabilization policies
On 08/21/2013 09:57 AM, Sergey Popov wrote: 20.08.2013 23:42, Tom Wijsman пишет: On Tue, 20 Aug 2013 14:29:09 -0400 Wyatt Epp wyatt@gmail.com wrote: What manner of bitrot? They might ... 2. ... contain security bugs that later versions have fixed. There should be security bug on our bugzilla with quick stabilization on it and(probably) GLSA. Security team could maintain its own p.accept_keywords in profiles/ and add testing keyworded ebuilds that fix security issues there. Users who are interested skipping the stabilization process could link it into their /etc/portage/p.accept_keywords directory. Kind regards Manuel signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] rfc: stabilization policies
On Wed, 21 Aug 2013 12:49:03 +0400 Sergey Popov pinkb...@gentoo.org wrote: 21.08.2013 12:39, Tom Wijsman пишет: The latest distros seemed to be just a bunch of same old stuff. Nothing new -- nothing innovative. ~ Larry's frustration. :( Then Larry tried Gentoo Linux. He was just impressed. ... He discovered lots of up-to-date packages ... ~ Larry's happiness. :) http://www.gentoo.org/images/poster.jpg And how that regards about stable, huh? Users that install Gentoo Linux will get their impression from stable. -- 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: stabilization policies
21.08.2013 13:28, Tom Wijsman пишет: That is 3.10.7, not 3.10; please look into how kernel releases work, minor releases are merely a small number of backported known fixes. What you propose, waiting 30 days for a minor; simply doesn't work when there are one to two minors a week, it puts us even more behind... We considered stabilizing package relying on it's version. Policy says that we should wait reasonable amount of time, no matter which version it is. And yes, minor release MAY bring breakages, do not tell me that they are not, i hit such breakages at least 4 times for kernel(no matter gentoo or vanilla, so problem is NOT genpatches) for past 5 years. And do you really want to stabilize EVERY minor release of some upstream stable branch? Maybe you want to bring some stable well tested version for some period and let unstable users choose another if they want to? And then - jump to next stable branch. Why should an external proprietary module that does not fix what is broken for 7 weeks now block stabilization; it has never blocked stabilization before, and I do not see a reason it should now... And that fact, that you can successfully build and run kernel for a couple of hours, does not make it good, well tested stable candidate Having people run it for 7 weeks is not a couple of hours. First of all, as i said early - it is NOT 7 weeks(thus - not a couple of hours either). It is 7 weeks. As i said early - it is not. Kernel team may have different policies on stabilization, that's OK IMO, but do not bend facts. This is release, and it should be considered as release, no matter minor or major. And stabilizations counts from it, not from 3.10.0. Following your logic i can say that KDE 4 is major release, and 4.1, 4.2 etc are minor. They are not. If some open-source modules with active upstreams, included in portage, do not support yet 3.10.* which will lead to unbootable system for some stable users - what you should say? Oops, sorry, guys? That's not how stable should work. That's how it has always worked, we do not see a need to change this. No it is not. We considered such things as serious flaws. At least - i consider. And as for security stabilization, if you say that version bump BRINGS security fixes, you KNOW what they are, and you do NOT file a security bug about old stable(and now - vulnerable!) kernel on Gentoo bugzilla, then current stabilization bug has no relation to security(as Gentoo Security team does not know about security problems), period. Actually, those are constantly filed by ago; please look at the picture first before you describe it, because you are drawing assumptions here. I do not see any dependant bugs in your current stable request, but you keep telling me about security, so i do not drawing any assumptions - it is not security stabilization in terms of Gentoo(probably it becomes so if you can find apropriate security flaws). -- 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: stabilization policies
21.08.2013 13:17, Manuel Rüger пишет: Security team could maintain its own p.accept_keywords in profiles/ and add testing keyworded ebuilds that fix security issues there. Users who are interested skipping the stabilization process could link it into their /etc/portage/p.accept_keywords directory. No, it is not an option. Masking current stable because it is broken was not successful also(i heard, that this was usual practice earlier). Please, let's not reinvent the wheel around evident problem: lack of manpower. Easing stabilization procedure makes stable more, well, unstable. Bringing some workarounds like this brokes consistency of keywording. Keywords are things, that chosen by user. Overlays maintains keywords lists, yeah, but that can be reasonable only on vast amount of packages(like KDE). As i said earlier, we should recruit more people - then problem will go away. Both for security(that have a VAST amount of work, that i am saying as a rookie security developer :-)) and arch teams. -- 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] Staging 'einstalldocs' for EAPI 6
Dnia 2013-08-20, o godz. 13:01:34
Michał Górny mgo...@gentoo.org napisał(a):
Hello,
Due to the widespread breakage in the tree noted in bug #480892 [1],
and mis-design of multilib-minimal.eclass, we'd like to put some more
work into getting einstalldocs() ready for EAPI 6.
When it's mostly defined, we'd like to backport it to eutils.eclass so
that we could use it to fix the existing breakages. But for that, we'd
really prefer if we had a final spec for it so that the EAPI switch
could be as simple as disabling the function in eutils.
Therefore, I'd like to open a final discussion for the features set
that is intended to be included in it, and it's name.
[1]:https://bugs.gentoo.org/show_bug.cgi?id=480892
Proposed implementation follows:
einstalldocs() {
if ! declare -p DOCS /dev/null ; then
local d
for d in README* ChangeLog AUTHORS NEWS TODO CHANGES \
THANKS BUGS FAQ CREDITS CHANGELOG ; do
[[ -s ${d} ]] dodoc ${d}
done
elif [[ $(declare -p DOCS) == declare -a * ]] ; then
[[ ${DOCS[@]} ]] dodoc -r ${DOCS[@]}
else
[[ ${DOCS} ]] dodoc -r ${DOCS}
fi
if [[ $(declare -p HTML_DOCS) == declare -a * ]] ; then
dohtml -r ${HTML_DOCS[@]}
elif [[ ${HTML_DOCS} ]]; then
dohtml -r ${HTML_DOCS}
fi
}
It's based on EAPI 4 src_install(). I've added support for DOCS=()
and DOCS='', HTML_DOCS, and made dodoc recursive per Pinkbyte's
request. In this form, it's suitable replacement for what's
in autotools-utils distutils-r1.
It should be noted that if we're to backport it to all old EAPIs,
'dodoc -r' needs te be conditional to EAPI 4+.
--
Best regards,
Michał Górny
signature.asc
Description: PGP signature
Re: [gentoo-dev] rfc: stabilization policies
21.08.2013 13:13, Tom Wijsman пишет: On Wed, 21 Aug 2013 12:32:35 +0400 Sergey Popov pinkb...@gentoo.org wrote: 21.08.2013 12:13, Tom Wijsman пишет: Recruiting shows to be a hard task; so, the suggestions I am doing are assuming that that doesn't work out. In which case, I wonder what by some other ways you would think of... Dropping some keywords to unstable on minor arches. If we grow (like you said below), then doing less seems like a decision that we shouldn't take; it is rather about doing it different to use our resources in a better way. Crowd sourcing users is an option here... What crowd sourcing do you talking about? We have Arch Tester for that. Do you see vast interest in this initiative? I think not(thus, for major arches we have some amount of testers, some of them are became developers lately). And if you want to move stabilization checks to unqualified users, then it is way to nowhere. Came across three types of people already trying to find a mentee: 1. The first one doesn't want to go through the amount of time it takes; this depends a bit on the queue, but it can take months. 2. The second one's interest to become a Gentoo Developer depends from time to time; so, tries to start over and over to become one. 3. The third one writes a lot of ebuilds (and has an overlay that looks like a gold mine), but there is a language barrier that keeps the user from contributing; so, we take things slowly instead... 4. The fourth one leaves a message on IRC and quits before you return. 5. ... So, recruiting in the terms of finding recruits appears to be hard. But, at my POV, it is only one way that we can improve current situation. -- 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
[gentoo-dev] Re: rfc: stabilization policies
On 21/08/2013 07:05, Tom Wijsman wrote: See `imlate --mtime=180 -s | less`. (From app-portage/gentoolkit-dev) I quote: == 4392 Stable candidates for 'gentoo' on 'amd64' == Let's double the number to a year ago (360 instead of 180), I quote: == 2728 Stable candidates for 'gentoo' on 'amd64' == And also get an impression of 3 months (90 instead of 180), I quote: == 6065 Stable candidates for 'gentoo' on 'amd64' == At least the numbers for the year sound like something we will want to deal with; from there, we could try to keep half a year low. And after a while, we might end up ensuring stabilization within 3 months. That's still three times more than our intended stabilization delay... For those not familiar with imlate, please note that these numbers include packages that have never been stabilised.
Re: [gentoo-dev] rfc: stabilization policies
On Wed, 21 Aug 2013 13:42:56 +0400 Sergey Popov pinkb...@gentoo.org wrote: So it is definitely NOT 7 weeks Let me clarify this again, our last stable kernel is from 7 weeks ago. 21.08.2013 13:28, Tom Wijsman пишет: That is 3.10.7, not 3.10; please look into how kernel releases work, minor releases are merely a small number of backported known fixes. What you propose, waiting 30 days for a minor; simply doesn't work when there are one to two minors a week, it puts us even more behind... We considered stabilizing package relying on it's version. We consider that as well, and for all the past releases it worked out. Policy says that we should wait reasonable amount of time, no matter which version it is. It does not state anything about versions in the policy, AFAIK; please refer me to it, and also note that on top of that we have the permission from the arch teams to auto stable minor releases when necessary. And yes, minor release MAY bring breakages, do not tell me that they are not, i hit such breakages at least 4 times for kernel(no matter gentoo or vanilla, so problem is NOT genpatches) for past 5 years. If you run ~, a breakage that you and some others experience less than once a year is to be expected; so, what you state here does not reflect our way of stabilization. In most of the cases, a later minor is better. And do you really want to stabilize EVERY minor release of some upstream stable branch? Maybe you want to bring some stable well tested version for some period and let unstable users choose another if they want to? And then - jump to next stable branch. No, what you propose is what we have been doing for a long while. As i said early - it is not. Kernel team may have different policies on stabilization, that's OK IMO, but do not bend facts. This is release, and it should be considered as release, no matter minor or major. And stabilizations counts from it, not from 3.10.0. Following your logic i can say that KDE 4 is major release, and 4.1, 4.2 etc are minor. They are not. Okay, then feel free to propose which versions we should pick for stabilization? At which times? As you will see, it doesn't work out... The kernel releases are not to be confused with that of another package; if I take a look at KDE's 4.1 announcement [1] I see that it is a feature release, which is not what a minor kernel release does. [1]: http://www.kde.org/announcements/4.1/ If some open-source modules with active upstreams, included in portage, do not support yet 3.10.* which will lead to unbootable system for some stable users - what you should say? Oops, sorry, guys? That's not how stable should work. That's how it has always worked, we do not see a need to change this. No it is not. We considered such things as serious flaws. At least - i consider. So do I, but why should it block stabilization? Why do the stability and security of other users have to suffer by that? There are other ways to deal with this: - Keep nvidia-drivers unstable, though they likely don't want to. - Clearly state that they don't work together, users should read that; but well, do we really want to account for the users that don't read? - Dep block the packages, *ugh*, let's not do this if we don't need to. - ... And as for security stabilization, if you say that version bump BRINGS security fixes, you KNOW what they are, and you do NOT file a security bug about old stable(and now - vulnerable!) kernel on Gentoo bugzilla, then current stabilization bug has no relation to security(as Gentoo Security team does not know about security problems), period. Actually, those are constantly filed by ago; please look at the picture first before you describe it, because you are drawing assumptions here. I do not see any dependant bugs in your current stable request, but you keep telling me about security, so i do not drawing any assumptions - it is not security stabilization in terms of Gentoo (probably it becomes so if you can find apropriate security flaws). You do draw assumptions, because you don't take a look; please do: https://bugs.gentoo.org/buglist.cgi?quicksearch=assignee%3Asecurity%40gentoo.org%20CC%3Akernel%40gentoo.org Sort by Changed such that the newest appear on top. -- 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] Re: rfc: stabilization policies
On Wed, 21 Aug 2013 20:13:00 +1000 Michael Palimaka kensing...@gentoo.org wrote: For those not familiar with imlate, please note that these numbers include packages that have never been stabilised. True, this brings up two questions: 1. How do we filter out those that were never stabilized? 2. How much of those actually don't need stabilization? How much do? -- 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] Staging 'einstalldocs' for EAPI 6
On Wed, 21 Aug 2013, Michał Górny wrote:
Proposed implementation follows:
einstalldocs() {
if ! declare -p DOCS /dev/null ; then
local d
for d in README* ChangeLog AUTHORS NEWS TODO CHANGES \
THANKS BUGS FAQ CREDITS CHANGELOG ; do
[[ -s ${d} ]] dodoc ${d}
The first pair of quotes is not needed.
done
elif [[ $(declare -p DOCS) == declare -a * ]] ; then
[[ ${DOCS[@]} ]] dodoc -r ${DOCS[@]}
I'd test for [[ ${#DOCS[@]} -gt 0 ]] here, but presumably that's a
matter of taste.
else
[[ ${DOCS} ]] dodoc -r ${DOCS}
fi
if [[ $(declare -p HTML_DOCS) == declare -a * ]] ; then
This will emit an error message if HTML_DOCS is unset. So:
if [[ $(declare -p HTML_DOCS 2/dev/null) == declare -a * ]] ; then
dohtml -r ${HTML_DOCS[@]}
No test for empty array here?
elif [[ ${HTML_DOCS} ]]; then
dohtml -r ${HTML_DOCS}
Make this the same as the DOCS logic, i.e.:
else
[[ ${HTML_DOCS} ]] dohtml -r ${HTML_DOCS}
fi
Maybe add a return 0 here?
}
Ulrich
Re: [gentoo-dev] rfc: stabilization policies
On Wed, 21 Aug 2013 13:54:51 +0400 Sergey Popov pinkb...@gentoo.org wrote: 21.08.2013 13:13, Tom Wijsman пишет: On Wed, 21 Aug 2013 12:32:35 +0400 Sergey Popov pinkb...@gentoo.org wrote: 21.08.2013 12:13, Tom Wijsman пишет: Recruiting shows to be a hard task; so, the suggestions I am doing are assuming that that doesn't work out. In which case, I wonder what by some other ways you would think of... Dropping some keywords to unstable on minor arches. If we grow (like you said below), then doing less seems like a decision that we shouldn't take; it is rather about doing it different to use our resources in a better way. Crowd sourcing users is an option here... What crowd sourcing do you talking about? We have Arch Tester for that. Do you see vast interest in this initiative? I think not(thus, for major arches we have some amount of testers, some of them are became developers lately). Yes, it is a large share of users that run ~, they want to test. And if you want to move stabilization checks to unqualified users, then it is way to nowhere. No, because there would be much more users giving feedback. So, recruiting in the terms of finding recruits appears to be hard. But, at my POV, it is only one way that we can improve current situation. Sorry, I do not understand (language barrier), do you mean that 1) that should be the way to improve it or do you mean that 2) this is just one approach and that we should look at different ones? -- 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] Staging 'einstalldocs' for EAPI 6
On 08/20/2013 01:01 PM, Michał Górny wrote: Hello, Due to the widespread breakage in the tree noted in bug #480892 [1], and mis-design of multilib-minimal.eclass, we'd like to put some more work into getting einstalldocs() ready for EAPI 6. What mis-design?
[gentoo-dev] Re: rfc: stabilization policies
On 21/08/2013 20:31, Tom Wijsman wrote: On Wed, 21 Aug 2013 20:13:00 +1000 Michael Palimaka kensing...@gentoo.org wrote: For those not familiar with imlate, please note that these numbers include packages that have never been stabilised. True, this brings up two questions: 1. How do we filter out those that were never stabilized? I don't see any option, perhaps imlate could use that improvement. 2. How much of those actually don't need stabilization? How much do? Someone said to me once everything in ~arch is a candidate for stabilisation. if it should never be stabilised, it shouldn't be in the tree. I'm not sure if I agree with that statement or not, but I suspect most things in the tree that have never been stabilised are that way simply because nobody every asked. There really is a large number of packages just rotting in ~arch though.
Re: [gentoo-dev] rfc: stabilization policies
On Wed, 21 Aug 2013 13:50:22 +0400 Sergey Popov pinkb...@gentoo.org wrote: Easing stabilization procedure makes stable more, well, unstable. It doesn't have to be easier; it just has to be done differently, in which way we can benefit from the users whom are actively testing it. Currently we use no bugs were filed lately as a measure; but not all bugs get filed downstream, so that's a problematic measurement. If we bring in another measure, that is, users that state if it is stable or broken; then we have another measure that help determine whether to stabilize, because then you wouldn't have cases where 1) a package ends up being stabilized although it doesn't work for 33% of the users because the GUI wasn't tested thoroughly and also not have cases where 2) a package works for almost anyone but not for the arch tester for some blocker that nobody else experiences at all. It clarifies that the arch tester's system is broken, which we then fix. Bringing some workarounds like this brokes consistency of keywording. It does not, when replacing the current way things are done we do not aim for it to be easier but rather for it to be different in that more users can contribute to the effort; the effort doesn't get easier, and should not result in a less consistent way of keywording. This should not be let's ask some users but rather let's set up a carefully designed framework to properly deal with this. As i said earlier, we should recruit more people - then problem will go away. There is no guarantee of that; years from now, we might have this discussion again. Yeah, maybe we might not; let's see what comes... -- 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] Staging 'einstalldocs' for EAPI 6
On Wed, 21 Aug 2013, Ulrich Mueller wrote: On Wed, 21 Aug 2013, Michał Górny wrote: Proposed implementation follows: elif [[ $(declare -p DOCS) == declare -a * ]] ; then I forgot about another issue pointed out by Arfrever some time ago. We may want to change the above to declare -a* (note the removed space) because of https://bugs.gentoo.org/show_bug.cgi?id=444740#c4. Ulrich
[gentoo-dev] Moving more arches to dev profiles
Hi, It's time of year again to consider moving a few arches to dev-only status. I propose the following arches to lose their stable keywords - s390 - sh - ia64 - alpha - m68k - sparc The manpower on these arches is below acceptable levels and they often block stabilizations for many months. This also causes troubles to developers trying to get rid of old versions of packages. I am CC'ing Mike and on this to draw his attention since he seems to be doing stabilizations and keywording on a few of them. Moreover, Agostino is also doing a lot of work on these arches. Consider what will happen if he ever goes MIA or decides to retire ;) We will probably end up with a pile of stabilization bugs like the good old days. In my opinion, having these arches be ~arch only, will improve the overall user experience since the arch teams will only have to test a single tree. It will also help developers get rid of old ebuilds and keep the portage tree healthy and reasonably updated. If I get enough positive feedback on this, I will propose this in the next Council's agenda. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Moving more arches to dev profiles
On Wed, Aug 21, 2013 at 1:04 PM, Markos Chandras hwoar...@gentoo.org wrote: I propose the following arches to lose their stable keywords - s390 - sh - ia64 - alpha - m68k - sparc +many. Cheers, Dirkjan
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
El mié, 21-08-2013 a las 11:52 +0200, Michał Górny escribió:
Dnia 2013-08-20, o godz. 13:01:34
Michał Górny mgo...@gentoo.org napisał(a):
Hello,
Due to the widespread breakage in the tree noted in bug #480892 [1],
and mis-design of multilib-minimal.eclass, we'd like to put some more
work into getting einstalldocs() ready for EAPI 6.
When it's mostly defined, we'd like to backport it to eutils.eclass so
that we could use it to fix the existing breakages. But for that, we'd
really prefer if we had a final spec for it so that the EAPI switch
could be as simple as disabling the function in eutils.
Therefore, I'd like to open a final discussion for the features set
that is intended to be included in it, and it's name.
[1]:https://bugs.gentoo.org/show_bug.cgi?id=480892
Proposed implementation follows:
einstalldocs() {
if ! declare -p DOCS /dev/null ; then
local d
for d in README* ChangeLog AUTHORS NEWS TODO CHANGES \
THANKS BUGS FAQ CREDITS CHANGELOG ; do
[[ -s ${d} ]] dodoc ${d}
done
elif [[ $(declare -p DOCS) == declare -a * ]] ; then
[[ ${DOCS[@]} ]] dodoc -r ${DOCS[@]}
else
[[ ${DOCS} ]] dodoc -r ${DOCS}
fi
if [[ $(declare -p HTML_DOCS) == declare -a * ]] ; then
dohtml -r ${HTML_DOCS[@]}
elif [[ ${HTML_DOCS} ]]; then
dohtml -r ${HTML_DOCS}
fi
}
It's based on EAPI 4 src_install(). I've added support for DOCS=()
and DOCS='', HTML_DOCS, and made dodoc recursive per Pinkbyte's
request. In this form, it's suitable replacement for what's
in autotools-utils distutils-r1.
It should be noted that if we're to backport it to all old EAPIs,
'dodoc -r' needs te be conditional to EAPI 4+.
Could appending to DOCS be allowed? I have seen a lot of time of me
needing to install all docs manually only to add a doc file over
default DOCS. Would be interesting to simply do:
DOCS+=( otherfile )
instead of needing to specify all files handled by the install function
Thanks a lot
Re: [gentoo-dev] rfc: stabilization policies
El mié, 21-08-2013 a las 11:16 +0200, Tom Wijsman escribió: [...] That's not what I am suggesting. It is not about bringing in new versions, but about getting rid of OLD versions which LIKELY contain MORE security problems than you imagine. Keeping them around for too long time isn't reasonable... I agree with seeing this problem, I guess it occurs because we (maintainers) usually forget about dropping old versions once last arch is done (probably because usually it takes long time to get all arches done). Maybe allowing all parties (maintainers, security and last arch team) cleanup old version could help :/ (I guess, there is no way to automatically notify maintainers about last arch doing the stabilization and, then, letting us drop it)
Re: [gentoo-dev] Re: rfc: stabilization policies
El mié, 21-08-2013 a las 10:57 +0200, Tom Wijsman escribió: On Wed, 21 Aug 2013 10:22:39 +0200 Pacho Ramos pa...@gentoo.org wrote: Regarding the kernel... well, I don't think having a 3.8.x kernel as stable one is so old, what are current kernel versions in stable Fedora, OpenSuSE, Mageia... last time I checked we weren't so ahead on this (thanks to kernel team ;)) Don't compare apples and eggs. In other distros, heavy backporting of fixes and so on happens; but on Gentoo, we instead want to keep our genpatches minimal and therefore follow upstream stable more closely. If we have a kernel version stable that is stable on other distros, it is merely a sign that our stabilization currently is in a severe state... In that case, probably the way to go would be to provide different versions tagged as stable: 1. The last one (would be 3.10.x now, I think) 2. The last one supporting that drivers used widely (nvidia comes to my mind now, no idea about ATI drivers status) But, does the kernel stabilization policy apply to the rest? Isn't it a bit special case? I mean, I would like to know what exact pieces are missing that people running testing in production servers. I doubt it's because of old toolchain. Isn't easier (and less risky) to report the bug and add the package to package.keywords instead of switching all to testing. Maybe the question is why that people don't report that bugs. I guess it's because, some times, stabilization bugs are ignored for a long time by maintainer. Maybe the situation could be improved if some of us could review that bugs periodically and directly CC arches if maintainer doesn't disagree (we usually need to do that manually... not sure if could be done in a more automatic way, I guess Phajdan will have something for that as he does it for his automated reports)
Re: [gentoo-dev] Moving more arches to dev profiles
On 08/21/2013 01:04 PM, Markos Chandras wrote: Hi, It's time of year again to consider moving a few arches to dev-only status. I propose the following arches to lose their stable keywords - s390 - sh - ia64 - alpha - m68k - sparc The manpower on these arches is below acceptable levels and they often block stabilizations for many months. This also causes troubles to developers trying to get rid of old versions of packages. I am CC'ing Mike and on this to draw his attention since he seems to be doing stabilizations and keywording on a few of them. Moreover, Agostino is also doing a lot of work on these arches. Consider what will happen if he ever goes MIA or decides to retire ;) We will probably end up with a pile of stabilization bugs like the good old days. In my opinion, having these arches be ~arch only, will improve the overall user experience since the arch teams will only have to test a single tree. It will also help developers get rid of old ebuilds and keep the portage tree healthy and reasonably updated. If I get enough positive feedback on this, I will propose this in the next Council's agenda. +1 Even if I'm not directly concerned by those arches, I agree with your point and can see its benefits for both devs and users. Cheers
Re: [gentoo-dev] Moving more arches to dev profiles
On Wed, 21 Aug 2013 13:09:55 +0200 Dirkjan Ochtman d...@gentoo.org wrote: On Wed, Aug 21, 2013 at 1:04 PM, Markos Chandras hwoar...@gentoo.org wrote: I propose the following arches to lose their stable keywords - s390 - sh - ia64 - alpha - m68k - sparc +many. ++many. If any of these arches considers themselves to be a major arch; they need to speak up and let us know if reasonable, but then we also need to ensure that we draw more manpower to such major arch. There's maybe one or so important in the server world; but as I don't have a good enough clue about that, I'm not going to name any names. -- 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: stabilization policies
On 08/21/2013 12:35 AM, Ben de Groot wrote: On 21 August 2013 04:12, Michael Orlitzky mich...@orlitzky.com wrote: [snip] Ok, this one is ridiculous. The stable version of Rails is 2.3.18, and 3.0 was released almost exactly three years ago. Every time rails-3.x gets bumped, I have to manually update the entire list above. I need to do it on an x86 server as well, so I get to do it twice; I can't even copy/paste the list. Yes you can. Just leave out the actual keyword. It will assume ~arch. (also in reply to Jonathan) I would rather not do this because I'd like to have as few lines as possible in package.accept_keywords, and things get stabled on x86 and amd64 at a different rate. So, for example, if I have, =dev-ruby/thor-0.15.2 ~amd64 in package.accept_keywords, and tomorrow it goes stable on amd64, I can remove it from the list. Running eix-test-obsolete will alert me to this fact if I have the version in the atom. If it's *not* stable on x86 yet, then I can't make the same change there. If I have instead, dev-ruby/thor It'll just pull in the latest ~amd64 version, and eix won't let me know that I can drop the keyword.
Re: [gentoo-dev] Moving more arches to dev profiles
El mié, 21-08-2013 a las 12:04 +0100, Markos Chandras escribió: [...] If I get enough positive feedback on this, I will propose this in the next Council's agenda. + :)
[gentoo-dev] Re: Moving more arches to dev profiles
On 21/08/2013 21:04, Markos Chandras wrote: I propose the following arches to lose their stable keywords - s390 - sh - ia64 - alpha - m68k - sparc +1
Re: [gentoo-dev] Moving more arches to dev profiles
21.08.2013 15:04, Markos Chandras пишет: Hi, It's time of year again to consider moving a few arches to dev-only status. I propose the following arches to lose their stable keywords - s390 - sh - ia64 - alpha - m68k - sparc +1 for that. Perl herd has *really* many work with stabilization, it's difficult because it's taking over a month in some cases.
Re: [gentoo-dev] Moving more arches to dev profiles
Markos Chandras hwoar...@gentoo.org writes: I propose the following arches to lose their stable keywords - s390 - sh - ia64 - alpha - m68k - sparc I support this proposal. I only have an old sparc box at hand. They are no longer major as time goes, IMHO.
Re: [gentoo-dev] Moving more arches to dev profiles
On 08/21/2013 07:04 AM, Markos Chandras wrote: Hi, It's time of year again to consider moving a few arches to dev-only status. I propose the following arches to lose their stable keywords - s390 - sh - ia64 - alpha - m68k - sparc Mips, as you know, has been ~arch for a while and we've been doing just fine with it. We can't pretend, however, that this doesn't shift some burden to the user. One example is perl where some modules need 5.12.4 (the current stable) and cannot use 5.16.x (~arch). On mips you might emerge 5.16.3 only to hit a module later that insists on 5.12.4, thus requiring downgrading. There are other examples where dependencies track stable but not unstable. This is in addition to the usual breakage on the bleeding edge. If I get enough positive feedback on this, I will propose this in the next Council's agenda. Or no serious negative feedback. I don't think you will. I can support this. -- 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] Staging 'einstalldocs' for EAPI 6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/20/2013 01:01 PM, Michał Górny wrote: Hello, Due to the widespread breakage in the tree noted in bug #480892 [1], and mis-design of multilib-minimal.eclass, we'd like to put some more work into getting einstalldocs() ready for EAPI 6. Ok, I'm too lazy to wait for a reply, so here you go Let's check what misdesign is: * creating eclasses with too many phases and those wrapped a thousand times, so no one really knows how it works anymore and ebuild writers are confused and often miss things; other devs have already complained about that obscurity * creating python eclasses that rely so heavily on useflags that it causes a lot of pain for users because of blockers (just read #gentoo) and adding/removing python version and then adding another bunch of python_single_foo* which cause even more useless rebuilds for users * creating a distutils eclass that fails for some packages, because it doesn't let you control how setup.py is called properly * updating vcs-snapshot eclass to drop support for an archive type, because the author is unable to make his code improvement work with it * creating multilib eclasses that are widely untested and dumping all the slow migration pain including multilib-specific bugs, countless blockers users have to deal with and all the emul-linux-x86-* updating stuff on everyone not really misdesign, but rather misbehavior: * refusing to slow down when told that your solutions may cause problems for other developers * refusing to work with other devs who demand an alternative implementation * trying to force other people to use a solution that they feel is not fit, because they want minimum reliance on eclasses which autotools-utils is NOT (and for the record, you do not follow PMS standard there) * requesting features for other peoples eclasses and then blaming them for misdesign, although YOU have even REVIEWED the changes If you keep on with this behavior, then I hope you know where that leads. I don't mind strong discussions and most points in the first chapter will not make me say it was the wrong choice (everyone knows that I am all pro migrating), but you are becoming someone people do not want to work with. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJSFKhuAAoJEFpvPKfnPDWzNX4H/AlQ+neoEUfnE4MCuyQKVifZ 1iMva9NjoO3xCQcSjyYmq0tOBeKbRbErdy0G2vca4JkX1fZnDiEQe+NCzMRIJBKl rTHYiDAaVg/ZTP+f1E0FXoPgS1t6NCjF/hKelniUGoYcxSKMJ5nA+z0/JuKQfzGF bsEkT44XXpliZAFOjuxSFMBl7NdCkt9XMBrX5tIdQj38XaVtnelvJII6TJ+hUsnj 8MVyui3d030X96Ezxe2k2kiqZRbqYCYQkU44zPeh/3Ns0O7mJ0/c0EidW1PcCvcZ ZS31GsPJV7zsl3HVlHuNmJDf3+WcNc8p06fRfG7iCS3nLGmsAEZBOc1y0oWvIVo= =PfTn -END PGP SIGNATURE-
Re: [gentoo-dev] Moving more arches to dev profiles
Mips, as you know, has been ~arch for a while and we've been doing just fine with it. We can't pretend, however, that this doesn't shift some burden to the user. One example is perl where some modules need 5.12.4 (the current stable) and cannot use 5.16.x (~arch). On mips you might emerge 5.16.3 only to hit a module later that insists on 5.12.4, thus requiring downgrading. There are other examples where dependencies track stable but not unstable. This is in addition to the usual breakage on the bleeding edge. There is a chance to be a bit off-topic here but I don't consider this being a problem for two reasons. First, mips profiles were marked 'experimental' so we missed a lot of repoman functionality :) Moreover, the problem you mentioned is a packaging issue which needs to be fixed. Having more people testing this as part of their regular testing can only improve the user experience in the end. For such arches, my personal opinion is that most people have been running ~arch all along because stable was lagging so far behind. Or no serious negative feedback. I don't think you will. I can support this. Thank you! -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
El mié, 21-08-2013 a las 13:45 +0200, hasufell escribió: On 08/20/2013 01:01 PM, Michał Górny wrote: Hello, Due to the widespread breakage in the tree noted in bug #480892 [1], and mis-design of multilib-minimal.eclass, we'd like to put some more work into getting einstalldocs() ready for EAPI 6. Ok, I'm too lazy to wait for a reply, so here you go Let's check what misdesign is: [...] I would really encourage people to keep talking about concrete technical issue. There is no need to blame on anybody and continuing this discussion in that terms won't help at all and won't resolve that conflict. To resolve that conflict (if possible), I would simply try to let things calm down again before replying too soon while involved parties are furious, as it will only cause more and more damage Thanks a lot :)
Re: [gentoo-dev] Moving more arches to dev profiles
On 21 August 2013 19:04, Markos Chandras hwoar...@gentoo.org wrote: Hi, It's time of year again to consider moving a few arches to dev-only status. I propose the following arches to lose their stable keywords - s390 - sh - ia64 - alpha - m68k - sparc ++ And consider adding ppc and ppc64 to that list. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] rfc: stabilization policies
On Wed, Aug 21, 2013 at 4:39 AM, Tom Wijsman tom...@gentoo.org wrote: The latest distros seemed to be just a bunch of same old stuff. Nothing new -- nothing innovative. ~ Larry's frustration. :( Then Larry tried Gentoo Linux. He was just impressed. ... He discovered lots of up-to-date packages ... ~ Larry's happiness. :) I'm not suggesting that we should be backporting bugfixes for two years. I'm just suggesting that it isn't a big deal if stable packages are ~90 days behind in general. Plus, Larry can always run the just-released KDE or whatever by accepting ~arch for that package and get a system where nothing other than KDE is likely to break. I have nothing against improvements that help us keep up though. If a package gets held up because of actual regressions (go read Ago's blog RE definition of a regression) that is one thing. If things get held up simply because nobody notices they're late, that is another. Plus, the innovation Larry was talking about doesn't mean having chrome-29 in the tree two days sooner than some other distro. What is innovative about Gentoo at its heart is letting the user have his cake and eat it too, like running a stable system but still getting chrome-29 near release day. I do firmly believe that Gentoo is a great distro for getting neat things done. Manpower will still always be an issue. I requested stable on mythtv on x86 a few weeks ago, but I can completely understand that client-server apps that typically involve hardware just aren't going to get turned around on a dime (FYI - if anybody wants to volunteer test that on x86 feel free to contact me and we can probably work something out with the x86 arch team together). Rich
Re: [gentoo-dev] rfc: stabilization policies
21.08.2013 14:36, Tom Wijsman пишет: On Wed, 21 Aug 2013 13:54:51 +0400 Sergey Popov pinkb...@gentoo.org wrote: 21.08.2013 13:13, Tom Wijsman пишет: On Wed, 21 Aug 2013 12:32:35 +0400 Sergey Popov pinkb...@gentoo.org wrote: 21.08.2013 12:13, Tom Wijsman пишет: Recruiting shows to be a hard task; so, the suggestions I am doing are assuming that that doesn't work out. In which case, I wonder what by some other ways you would think of... Dropping some keywords to unstable on minor arches. If we grow (like you said below), then doing less seems like a decision that we shouldn't take; it is rather about doing it different to use our resources in a better way. Crowd sourcing users is an option here... What crowd sourcing do you talking about? We have Arch Tester for that. Do you see vast interest in this initiative? I think not(thus, for major arches we have some amount of testers, some of them are became developers lately). Yes, it is a large share of users that run ~, they want to test. But it seems that they do not want to become Arch testers and bring things to stable, do not you think? And if you want to move stabilization checks to unqualified users, then it is way to nowhere. No, because there would be much more users giving feedback. Feedback is good. But if it simple works for me without tests on CFLAGS/LDFLAGS respect regression, cross-compile breakage regression or any other regressions, than it is pointless. I would suggest increase number of arch testers... Or, i repeat myself(in infinite time), recruit more people So, recruiting in the terms of finding recruits appears to be hard. But, at my POV, it is only one way that we can improve current situation. Sorry, I do not understand (language barrier), do you mean that 1) that should be the way to improve it or do you mean that 2) this is just one approach and that we should look at different ones? Yeah, my grammar sucks, i know. So, let's summarize what i mean. To deal with our current problems with arches we have only two ways: 1) drop some arches to unstable - lower the burden to arch teams; 2) recruit more arch testers/arch team members; -- 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: stabilization policies
21.08.2013 14:29, Tom Wijsman пишет: On Wed, 21 Aug 2013 13:42:56 +0400 You do draw assumptions, because you don't take a look; please do: https://bugs.gentoo.org/buglist.cgi?quicksearch=assignee%3Asecurity%40gentoo.org%20CC%3Akernel%40gentoo.org Sort by Changed such that the newest appear on top. And how should i must knew that these bugs related to particular versions if they do not contain affected versions(i know that ALL versions may be affected in particular time, but we are talking about new stable kernel which bring fixes) and no dependant bugs in stable request? How can i, not beeing member of Gentoo Kernel Team, discover that it is security stabilization and which security bugs, registered in our bugzilla, will gone when i will upgrad to it? Honestly, we should revive Kernel Security subproject somehow, cause this mess may confuse even ordinary developers. -- 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: stabilization policies
On Wed, 21 Aug 2013 16:16:53 +0400 Sergey Popov pinkb...@gentoo.org wrote: And if you want to move stabilization checks to unqualified users, then it is way to nowhere. No, because there would be much more users giving feedback. Feedback is good. But if it simple works for me without tests on CFLAGS/LDFLAGS respect regression, cross-compile breakage regression or any other regressions, than it is pointless. Sounds like Tinderbox covers those; so, it has a point for the rest. I would suggest increase number of arch testers... Or, i repeat myself(in infinite time), recruit more people That I agree with; but, will that be enough? So, recruiting in the terms of finding recruits appears to be hard. But, at my POV, it is only one way that we can improve current situation. Sorry, I do not understand (language barrier), do you mean that 1) that should be the way to improve it or do you mean that 2) this is just one approach and that we should look at different ones? Yeah, my grammar sucks, i know. So, let's summarize what i mean. To deal with our current problems with arches we have only two ways: 1) drop some arches to unstable - lower the burden to arch teams; This didn't come up until recently; so, yes, that might work! :) 2) recruit more arch testers/arch team members; Same point as before, let's see if that will be enough. -- 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] Staging 'einstalldocs' for EAPI 6
On Wed, 21 Aug 2013, Pacho Ramos wrote: Could appending to DOCS be allowed? I have seen a lot of time of me needing to install all docs manually only to add a doc file over default DOCS. Would be interesting to simply do: DOCS+=( otherfile ) instead of needing to specify all files handled by the install function We discussed this in bug 449806 already. Problems that need to be solved: - If we want to keep support for both array and whitespace-separated list then we can't preset a global variable. - How do we distinguish between DOCS being unset (i.e. install default docs) and DOCS being empty (i.e. don't install anything)? - We could introduce some special syntax like a __default__ marker, but do we want such in-band signalling? Ulrich
Re: [gentoo-dev] rfc: stabilization policies
On Wed, 21 Aug 2013 16:22:28 +0400 Sergey Popov pinkb...@gentoo.org wrote: 21.08.2013 14:29, Tom Wijsman пишет: On Wed, 21 Aug 2013 13:42:56 +0400 You do draw assumptions, because you don't take a look; please do: https://bugs.gentoo.org/buglist.cgi?quicksearch=assignee%3Asecurity%40gentoo.org%20CC%3Akernel%40gentoo.org Sort by Changed such that the newest appear on top. And how should i must knew that these bugs related to particular versions if they do not contain affected versions(i know that ALL versions may be affected in particular time, but we are talking about new stable kernel which bring fixes) and no dependant bugs in stable request? How can i, not beeing member of Gentoo Kernel Team, discover that it is security stabilization and which security bugs, registered in our bugzilla, will gone when i will upgrad to it? Our dev 'ago' is on top of all that, but we really shouldn't rely on a single person; the lack of manpower causes uncertainty here, and it is because of that that we have to regard any stabilization as security. Given the kernel volume, I think even CVE's don't cover everything... Honestly, we should revive Kernel Security subproject somehow, cause this mess may confuse even ordinary developers. +1 The latest kernel related discussion(s) also make it clear there is a need for more documentation on how things currently work; because people that are not aware what happens upstream are making assumptions that don't reflect reality, and this makes it harder to reach consensus. With the hope of one or two people wanting to help out on genpatches (although I haven't heard from them lately); I'll try to document upstream's release cycle as well as how our current maintenance is done as part of the move to Gentoo Wiki, together with the rest we could then also clarify some kernel team policies and guidelines... -- 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: stabilization policies
El mié, 21-08-2013 a las 14:25 +0200, Tom Wijsman escribió: [...] 2) recruit more arch testers/arch team members; Same point as before, let's see if that will be enough. Well, ago has being doing a great work getting more Arch Testers (at least for amd64), maybe some of them could give the step of becoming real devs with commit access to help him... probably Ago will know about them and their situation :)
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
El mié, 21-08-2013 a las 14:35 +0200, Ulrich Mueller escribió: On Wed, 21 Aug 2013, Pacho Ramos wrote: Could appending to DOCS be allowed? I have seen a lot of time of me needing to install all docs manually only to add a doc file over default DOCS. Would be interesting to simply do: DOCS+=( otherfile ) instead of needing to specify all files handled by the install function We discussed this in bug 449806 already. Problems that need to be solved: - If we want to keep support for both array and whitespace-separated list then we can't preset a global variable. - How do we distinguish between DOCS being unset (i.e. install default docs) and DOCS being empty (i.e. don't install anything)? - We could introduce some special syntax like a __default__ marker, but do we want such in-band signalling? Ulrich Well, the last comment by mgorny in bug report after some suggestions rised there made me think I should wait for the einstalldocs thing :/
Re: [gentoo-dev] rfc: stabilization policies
On Wed, Aug 21, 2013 at 5:50 AM, Sergey Popov pinkb...@gentoo.org wrote: As i said earlier, we should recruit more people - then problem will go away. This is a point most of the people in this thread seem to be dancing around that's sort of problematic. You can talk about recruiting until you're blue in the face, but the simple fact is Gentoo DOESN'T have adequate manpower. And has it ever, really? Can you honestly say we've ever had a solid surplus of devs with time [0]? We've gotten where we are, by and large, because Gentoo works smarter. Fundamentally, I see this as a problem of tooling. Let's turn the question around; try thinking about it like this: What tools have historically allowed relatively few active developers handle stablisation and integration of upstream patch flow IN SPITE of not having a lot of recruits? What tools could be added to assist with, if not outright _remove_ steps of the process? I'd like to point out something that jumped out to me as a red flag earlier (not to pick on you specifically, Tom; this is just the cleanest example I saw), and turn it into an example: On Wed, Aug 21, 2013 at 4:51 AM, Tom Wijsman tom...@gentoo.org wrote: Well, they are listed there; but it's quite some work to actually go through that list, that is, manually check the bugs of ~2000 packages as well as file a STABLEREQ bug, takes quite a while... This right here is a real problem. Any time you're talking about doing anything on this scale manually, you've already lost the battle. You need a tool to minimise the overhead of time and cognitive load. What would that tool look like? Think about the steps involved and how you can reduce them to only the parts that absolutely require decisions on your part. At least in the areas I usually work, I have found a combination of the automatic stabilisation requests and imlate have definitely cut back on the bitrot. A single unimportant bug can prevent the automatic STABLEREQ bug from getting filed; as for imlate, not everyone seems to know that tool, not everyone seems to run it. Attention for some stabilizations is lost... First off, why do developers not know about the tools? How can this be addressed? For a start, I'd suggest making sure the tools are at least mentioned in the docs. Somewhere other than the amd64 Arch Testing guide from 2006. [1] That's the only concrete (i.e. actually in the DOCS rather than the ML archives) documentation I've found so far, and it only references the file, rather than the tool. Maybe in the devmanual Tools Reference? [2] But, imlate is a good example of a tool that could ease the time cost of grindy crap. You showed before that it can get an ordinary count bounded on n days. That's handy, but only a little. Build out: - How many of those stablereq bugs reference versions no longer in the tree? Those can probably get closed. - How many have newer STABLE versions in the tree in the same slot? Probably fine to close those, too. - Of the remaining, how many have patches or ebuilds attached? Those may be solved problems waiting for closure; shortlist them. - How many are packages with newer versions that have been in the tree for 30 days? Consider changing the target version, then. - How many have open blockers, and what are those blockers (w/link and summary)? Scan for low-hanging fruit jumping out in that list. - Get views by category; are there categories where updates are more important? Things in @system, and things with security concerns (stuff in net-*) should probably get higher priority; games... probably less so. - Are there bugs with certain keywords in the body that should raise priority? Things like security or overflow might be good candidates. - Are there bugs with certain keywords in the body that indicate it'll be really easy to decide? e.g. trivial or minor might turn up some of those super-small version bumps that you pretty much know aren't going to affect stability. These are just examples off the top of my head, and by no means bulletproof, but these are in the class of improvements that have ROI because they reduce a task that previously took developer time to one that takes CPU time. CPU time is essentially free compared to the value of dev time. And I'm not saying more recruiting shouldn't happen, but relying on it is no better than hoping at $deity for bugs to close themselves. ;) Cheers, Wyatt [0] Okay, maybe in the glory days when we were higher up on Distrowatch and thing were really kicking. (I know, I know, DW isn't representative, but really? Sabayon is doing better than we are, now?) [1] http://www.gentoo.org/proj/en/base/amd64/tests/index.xml?part=1chap=2 [2] http://devmanual.gentoo.org/tools-reference/index.html
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
On Wed, 21 Aug 2013, Michał Górny wrote: elif [[ $(declare -p DOCS) == declare -a * ]] ; then Thinking about it again, the pattern matching (already present in default_src_install of EAPI 4) is brittle and relies on the output of declare -p whose exact format is undocumented. Maybe we could change the test for an array to the following? elif ! declare +a DOCS /dev/null; then This seems to work fine in bash versions 3.2 and 4.2. And behaviour is well documented in the bash reference manual [1]: | Using `+' instead of `-' turns off the attribute instead, with the | exceptions that `+a' may not be used to destroy an array variable | [...] | | The return status is zero unless [...] an attempt is made to turn | off array status for an array variable, [...] Ulrich [1] http://www.gnu.org/software/bash/manual/bashref.html#Bash-Builtins
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/08/13 07:45 AM, hasufell wrote: On 08/20/2013 01:01 PM, Michał Górny wrote: Hello, Due to the widespread breakage in the tree noted in bug #480892 [1], and mis-design of multilib-minimal.eclass, we'd like to put some more work into getting einstalldocs() ready for EAPI 6. what misdesign? The mis-design is that for some reason the default_src_install (and therefore the default EAPI4+ DOCS= handler) is being triggered regardless of whether multilib_src_install, or multilib_src_install_all are being overridden/customized. Possibly this is true for an override of src_install() too (or at least, the src_install that would still call the appropriate phase funcs from multilib-minimal), but I don't think I checked that so this would need to be confirmed. Probably what needs to be done is that the original default_src_install behaviour only occurs in multilib_src_install_all() and also only occurs when that phase func is not re-defined in an ebuild. But this is just a guess. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlIUyAEACgkQ2ugaI38ACPD/owD/ea8xL8zZKLtsWCZbjnym5TWf yZr3EXEtK6r0JdCvdUwBAIn2zXqAOp9jsoaVtD7IvKsXxHVs+24BTfFLet/HcRfk =hEKl -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: stabilization policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/08/13 08:36 AM, Tom Wijsman wrote: Given the kernel volume, I think even CVE's don't cover everything... Kernel is really a special case here, imo -- emerge doesn't install kernels, it just provides their sources. End-users still need to build the kernel to use them and I expect there are plenty that don't, at least, not as soon as the sources are installed. And really, portage is just providing kernel sources for convenience; anybody can download a kernel by hand, extract it to /usr/src, and build it with no ill effect on portage or the rest of their system. That's not to say that gentoo-sources shouldn't follow the regular overall stabilization policies, but focusing on the kernel as the impetus for adjusting the stabilization policy or pointing out what's wrong with the policy as a whole seems to be a bad use-case for this discussion. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) iF4EAREIAAYFAlIUzmcACgkQ2ugaI38ACPB07gD+Ps0gTO/gqgZQXMUCtcmXWw1/ Bv6n5HeDQD21qo59rxoA/21DZ8zUkpGSJIOldB8uL+zXTUhzbadvtdhrCJoelT4Q =69yu -END PGP SIGNATURE-
Re: [gentoo-dev] rfc: stabilization policies
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, 21 Aug 2013 10:27:51 -0400 Ian Stakenvicius a...@gentoo.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/08/13 08:36 AM, Tom Wijsman wrote: Given the kernel volume, I think even CVE's don't cover everything... Kernel is really a special case here, imo -- emerge doesn't install kernels, it just provides their sources. End-users still need to build the kernel to use them and I expect there are plenty that don't, at least, not as soon as the sources are installed. And really, portage is just providing kernel sources for convenience; anybody can download a kernel by hand, extract it to /usr/src, and build it with no ill effect on portage or the rest of their system. That doesn't make it a special case here, imo; especially not, since we are designing and implementing ebuilds that _build_ the kernel. Whether it provides the sources, or build it; what does that matter? We're talking here in terms of Gentoo QA and Stability; so, other people building the kernel on their own (which you could do with most packages in the tree, just install it to /usr/local or something), has nothing at all to do with this entire thread. I don't understand what you try to say with that paragraph. That's not to say that gentoo-sources shouldn't follow the regular overall stabilization policies, but focusing on the kernel as the impetus for adjusting the stabilization policy or pointing out what's wrong with the policy as a whole seems to be a bad use-case for this discussion. It's a good example to demonstrate bit rot due to lack of manpower, that's it sole intention; don't assume it as an example for change of policies, that's not what's being shown here. And for a change in policies proper statistics would be the least a person should base on. The sub thread, to clarify some matters, is indeed long enough as it is; and at some point we should have probably switched to gentoo-kernel ML. - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (GNU/Linux) iQEcBAEBAgAGBQJSFNU5AAoJEJWyH81tNOV93yQH/3vZZRfnbbrmtc9AuTq8cHLj q4fNQtsdhAcF5hT/VSLCODSlxt1+7g3j+jnIHTbKpxAwI/sALJO7ojNi5VYDK8zq LxgjEy91yVBVq2v974HyA4Snolo236cxZVwaT8g+GVrzDk2NAT8pAFV+QIubS/Gs nsmN5XPZPXIr027ZrH0k6eM+OjCBnKT4uqQIaRRHNSjkxAki611yIj9XsLn3yyiH Yc9kmKcGtjuc/daLyvFWmQIAaXxGhFug6YYpmb1fU3/i2Tn0fBqYnesN5DW85WYB cjd8eqGDIA/yS7MXX6Lx9V1Zd4gPvmZINHzhFUZ0i4dums+cyXM9b2bxvrRLM2g= =zVwU -END PGP SIGNATURE-
Re: [gentoo-dev] Sets in the tree
15.08.2013 12:12, Pacho Ramos пишет: El mié, 14-08-2013 a las 15:17 +0100, Ciaran McCreesh escribió: Ah, looks like I was too optimistic and we are (again) with the usual blocking (and blocker) issues -_- (PMS refusing to include something because of lack of documentation :S) And they are right at this point. How you can include something into standard, that is not documented? Documentation of how to use sets(for users) is not enough in this case, IMHO. -- 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: stabilization policies
On Wed, Aug 21, 2013 at 10:27 AM, Ian Stakenvicius a...@gentoo.org wrote: That's not to say that gentoo-sources shouldn't follow the regular overall stabilization policies, but focusing on the kernel as the impetus for adjusting the stabilization policy or pointing out what's wrong with the policy as a whole seems to be a bad use-case for this discussion. ++ I track ~arch on a few packages and few get anywhere near the kernel in terms of update frequency. The ones that do are usually little niche utilities that cause little issue if they break (calibre, youtube-dl, etc). The kernel also benefits from an unusually robust quality system outside of Gentoo. I'm not saying that this is the only project that has strong quality upstream, but few packages that update so often do. That said, kernel updates are not without issue either. There are certainly have been changes in behavior that impact other system deps in the past. So if for whatever reason we do stabilize kernels more often we'll have to make sure the kernel team is extra vigilant for these kinds of changes and that they coordinate accordingly (the fact that ~arch doesn't break often suggests that this is likely already happening). Rich
Re: [gentoo-dev] Moving more arches to dev profiles
21.08.2013 15:04, Markos Chandras пишет: Hi, It's time of year again to consider moving a few arches to dev-only status. I propose the following arches to lose their stable keywords - s390 - sh - ia64 - alpha - m68k - sparc The manpower on these arches is below acceptable levels and they often block stabilizations for many months. This also causes troubles to developers trying to get rid of old versions of packages. I am CC'ing Mike and on this to draw his attention since he seems to be doing stabilizations and keywording on a few of them. Moreover, Agostino is also doing a lot of work on these arches. Consider what will happen if he ever goes MIA or decides to retire ;) We will probably end up with a pile of stabilization bugs like the good old days. In my opinion, having these arches be ~arch only, will improve the overall user experience since the arch teams will only have to test a single tree. It will also help developers get rid of old ebuilds and keep the portage tree healthy and reasonably updated. If I get enough positive feedback on this, I will propose this in the next Council's agenda. +1 for that. Unless we have more manpower on them, their 'stable' state can bring false expectations to users. Do not get me wrong, i am all for choice, but if we can not bring quality stabilization on those arches(as we have no hardware, no manpower, etc.) - they should go to unstable. -- 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] Staging 'einstalldocs' for EAPI 6
20.08.2013 17:22, Sergey Popov пишет: 20.08.2013 17:02, Michał Górny пишет: Is there a future-eapi bug open for it? If not, please open one. I will, thanks Here it is: https://bugs.gentoo.org/show_bug.cgi?id=481980 -- 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] Moving more arches to dev profiles
On Wed, Aug 21, 2013 at 4:04 AM, Markos Chandras hwoar...@gentoo.org wrote: Hi, It's time of year again to consider moving a few arches to dev-only status. I propose the following arches to lose their stable keywords - s390 - sh - ia64 - alpha - m68k - sparc I want some level between stable and completely supported and loses all its stable keywords., at least for alpha. Is switching their profiles to dev the way to do that?
Re: [gentoo-dev] Moving more arches to dev profiles
On Wed, Aug 21, 2013 at 11:32 AM, Matt Turner matts...@gentoo.org wrote: On Wed, Aug 21, 2013 at 4:04 AM, Markos Chandras hwoar...@gentoo.org wrote: Hi, It's time of year again to consider moving a few arches to dev-only status. I propose the following arches to lose their stable keywords - s390 - sh - ia64 - alpha - m68k - sparc I want some level between stable and completely supported and loses all its stable keywords., at least for alpha. Is switching their profiles to dev the way to do that? The proposal is to drop stable keywords on arches that cannot keep up. Do you feel this is not the case on alpha?
Re: [gentoo-dev] Moving more arches to dev profiles
On 21 August 2013 16:32, Matt Turner matts...@gentoo.org wrote: On Wed, Aug 21, 2013 at 4:04 AM, Markos Chandras hwoar...@gentoo.org wrote: Hi, It's time of year again to consider moving a few arches to dev-only status. I propose the following arches to lose their stable keywords - s390 - sh - ia64 - alpha - m68k - sparc I want some level between stable and completely supported and loses all its stable keywords., at least for alpha. Is switching their profiles to dev the way to do that? Is there an alternative? afaik a profile can be either stable,dev or exp. I can't see how we can implement something between stable and dev. And what would that represent? It may or may not be stable? If this is the case, then I believe ~arch is more preferred. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Moving more arches to dev profiles
On 08/21/2013 01:04 PM, Markos Chandras wrote: The manpower on these arches is below acceptable levels and they often block stabilizations for many months. This also causes troubles to developers trying to get rid of old versions of packages. I am CC'ing Mike and on this to draw his attention since he seems to be doing stabilizations and keywording on a few of them. Moreover, Agostino is also doing a lot of work on these arches. Maybe we should fix this situation (find more stabilization guys) rather than the usual twice a year small arches bashing. Imho the situation is that agos intensive work displaced all the other ones, or they at least rely on ago doing the work and loose focus. -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org
Re: [gentoo-dev] rfc: stabilization policies
21.08.2013 17:38, Wyatt Epp пишет: Fundamentally, I see this as a problem of tooling. I think that no tool can cover all cases of checking that software WORKS. I mean - in generic, for all kinds of software. You can guarantee if it builds, if it follow some QA rules about CFLAGS/LDFLAGS/whatever, but there is only one 100% way to guarantee that software works - run and do something useful :-). Yeah, i know about testsuites, that can help in that case. Unfortunately: 1) they do not cover all cases, but that's not so important; 2) often they are badly broken; 3) not every program carries test suite. So, we stuck at automation in run-time checks right at the beginning :-). But yeah, we could automate build-time checks, surely. I'd like to point out something that jumped out to me as a red flag earlier (not to pick on you specifically, Tom; this is just the cleanest example I saw), and turn it into an example: On Wed, Aug 21, 2013 at 4:51 AM, Tom Wijsman tom...@gentoo.org wrote: Well, they are listed there; but it's quite some work to actually go through that list, that is, manually check the bugs of ~2000 packages as well as file a STABLEREQ bug, takes quite a while... This right here is a real problem. Any time you're talking about doing anything on this scale manually, you've already lost the battle. You need a tool to minimise the overhead of time and cognitive load. What would that tool look like? Think about the steps involved and how you can reduce them to only the parts that absolutely require decisions on your part. At least in the areas I usually work, I have found a combination of the automatic stabilisation requests and imlate have definitely cut back on the bitrot. A single unimportant bug can prevent the automatic STABLEREQ bug from getting filed; as for imlate, not everyone seems to know that tool, not everyone seems to run it. Attention for some stabilizations is lost... First off, why do developers not know about the tools? How can this be addressed? For a start, I'd suggest making sure the tools are at least mentioned in the docs. Somewhere other than the amd64 Arch Testing guide from 2006. [1] That's the only concrete (i.e. actually in the DOCS rather than the ML archives) documentation I've found so far, and it only references the file, rather than the tool. Maybe in the devmanual Tools Reference? [2] Good point, i agree. But, imlate is a good example of a tool that could ease the time cost of grindy crap. You showed before that it can get an ordinary count bounded on n days. That's handy, but only a little. Build out: - How many of those stablereq bugs reference versions no longer in the tree? Those can probably get closed. - How many have newer STABLE versions in the tree in the same slot? Probably fine to close those, too. - Of the remaining, how many have patches or ebuilds attached? Those may be solved problems waiting for closure; shortlist them. - How many are packages with newer versions that have been in the tree for 30 days? Consider changing the target version, then. - How many have open blockers, and what are those blockers (w/link and summary)? Scan for low-hanging fruit jumping out in that list. - Get views by category; are there categories where updates are more important? Things in @system, and things with security concerns (stuff in net-*) should probably get higher priority; games... probably less so. - Are there bugs with certain keywords in the body that should raise priority? Things like security or overflow might be good candidates. - Are there bugs with certain keywords in the body that indicate it'll be really easy to decide? e.g. trivial or minor might turn up some of those super-small version bumps that you pretty much know aren't going to affect stability. These are just examples off the top of my head, and by no means bulletproof, but these are in the class of improvements that have ROI because they reduce a task that previously took developer time to one that takes CPU time. CPU time is essentially free compared to the value of dev time. That's what i called constuctive criticism. Congratulations :-) And I'm not saying more recruiting shouldn't happen, but relying on it is no better than hoping at $deity for bugs to close themselves. ;) Cheers, Wyatt [0] Okay, maybe in the glory days when we were higher up on Distrowatch and thing were really kicking. (I know, I know, DW isn't representative, but really? Sabayon is doing better than we are, now?) [1] http://www.gentoo.org/proj/en/base/amd64/tests/index.xml?part=1chap=2 [2] http://devmanual.gentoo.org/tools-reference/index.html -- 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
[gentoo-dev] Re: Moving more arches to dev profiles
On 22/08/2013 01:56, Michael Weber wrote: On 08/21/2013 01:04 PM, Markos Chandras wrote: The manpower on these arches is below acceptable levels and they often block stabilizations for many months. This also causes troubles to developers trying to get rid of old versions of packages. I am CC'ing Mike and on this to draw his attention since he seems to be doing stabilizations and keywording on a few of them. Moreover, Agostino is also doing a lot of work on these arches. Maybe we should fix this situation (find more stabilization guys) rather than the usual twice a year small arches bashing. Imho the situation is that agos intensive work displaced all the other ones, or they at least rely on ago doing the work and loose focus. At one point before Ago came along, stabilisation of Qt was taking so long we had to start masking reverse dependencies for minor archs, so please don't blame Ago. (Please note I am not trying to point the finger at anyone, just trying to highlight the severity of the problem.) I have also been told that for some archs, new hardware is no longer available. That would make this not a question of if, but a question of when.
[gentoo-dev] Re: Moving more arches to dev profiles
On 22/08/2013 01:32, Matt Turner wrote: I want some level between stable and completely supported and loses all its stable keywords., at least for alpha. Is switching their profiles to dev the way to do that? What would you feel about instead of dropping stable completely, re-evaluating which packages are stable? I have seen in the past minor archs dropping stable (and sometimes even keywords completely) for less core packages.
Re: [gentoo-dev] Re: Moving more arches to dev profiles
On 21/08/13 12:23 PM, Michael Palimaka wrote: Imho the situation is that agos intensive work displaced all the other ones, or they at least rely on ago doing the work and loose focus. At one point before Ago came along, stabilisation of Qt was taking so long we had to start masking reverse dependencies for minor archs, so please don't blame Ago. I believe the point that xmw was trying to make was that ago is doing *too good* of a job, not too poor of a job. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Moving more arches to dev profiles
On Wed, Aug 21, 2013 at 8:40 AM, Mike Gilbert flop...@gentoo.org wrote: The proposal is to drop stable keywords on arches that cannot keep up. Do you feel this is not the case on alpha? I'm not sure if that's my claim. I'm worried because I think it might be a disaster for alpha (and perhaps other architectures).
Re: [gentoo-dev] Moving more arches to dev profiles
On Wed, Aug 21, 2013 at 8:50 AM, Markos Chandras hwoar...@gentoo.org wrote: Is there an alternative? afaik a profile can be either stable,dev or exp. I can't see how we can implement something between stable and dev. And what would that represent? It may or may not be stable? If this is the case, then I believe ~arch is more preferred. I haven't read much into it, but Fedora has a concept of Secondary Architectures. I think it would make sense if we could keep stable keywords for them, but not prevent maintainers from needing to wait on them to stabilize other packages. I've run into issues when I simply wanted to fix a mips-specific problem and wound up spending inordinate amounts of time dealing with general ~arch issues. I'm worried that dropping stable keywords, while it'll make it seem like the architectures are in better shape since there are fewer bugs, will actually make using or developing them significantly worse.
Re: [gentoo-dev] Moving more arches to dev profiles
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 08/21/2013 05:56 PM, Michael Weber wrote: On 08/21/2013 01:04 PM, Markos Chandras wrote: The manpower on these arches is below acceptable levels and they often block stabilizations for many months. This also causes troubles to developers trying to get rid of old versions of packages. I am CC'ing Mike and on this to draw his attention since he seems to be doing stabilizations and keywording on a few of them. Moreover, Agostino is also doing a lot of work on these arches. Maybe we should fix this situation (find more stabilization guys) rather than the usual twice a year small arches bashing. Imho the situation is that agos intensive work displaced all the other ones, or they at least rely on ago doing the work and loose focus. All in all, I'm in favor of dropping stable keywords for minor arches, if it is possible to keep up with the same quality. With regards to m68k armin76 blogged recently about an emulator[1]. Maybe if we don't want to drop stable keywords a keywording and stabilization timeout [2] would be sufficient (i.e. every dev can add a testing/stable keyword after testing it). Do we keep any statistics about the user base of each arch? There was a GSOC project called gentoostats [3], does anybody know anything about its current status? Kind regards Manuel [1] http://armin762.wordpress.com/2013/08/07/gentoom68k-in-the-aranym-emulator/ [2] https://bugs.gentoo.org/show_bug.cgi?id=455872#c15 [3] http://wiki.gentoo.org/wiki/Gentoostats -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJ8BAEBCgBmBQJSFPjSXxSAAC4AKGlzc3Vlci0uLi5Abm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4MDA1RERERkM0ODM2QkE4MEY3NzY0N0M1 OEZCQTM2QzhEOUQ2MzVDAAoJEFj7o2yNnWNcp/IP/2xMQmZHg6dggIm8YdxQUtAn OHsUjEMHPSsoYhpw1Un0oz06OHSlU0XF3OZSb1Xge8G4ZRbxu1tlBFG9tsf7aI01 zuZRCyZkEvSl4DLaZcRNw7x6mDPc5fgk29Wj2PLtSFmIQh7g0ad1JZrEPCqrulVS w2bpvm9FBrPWBhdWVY+cXsGSy3PCYLw/pGkZFXipmykXMmqb2f7bZsQurKkPMeEJ z5SgnbYKGKFTVbDQrlhILOJKT0RFxDsxe6+kNnBnoqFKoqxb4jC95CjGpGvlqYD8 Q7A1kqAcyjI99NTXH8nU1k0H2IP9pPi5JGs9w9HYd5aT2hJHfpWNm18h2WH9/fEa 1+MJUWG3ajipB6Lkixd99GszdPDybQQ159q8J7TTvj7aCDgDQWto1F/iJON5Fb+J rDDL9HxrxFZirJ2MV45e/TkYJyxQlw4XxnBwI6q2ubCqH4P2fe/wjg9BJnWLbDLc uc/LGr6BaYwq2s9sim4Mcgm7rM4Y0CgSQD7QLAQ6utUV+vsnK4rD+UTLI0bDI5ZR 7s+eYFxoo7CUHpq3qqpsVzM699G5JIQ/rBYEBCKwDKJUkZmO/pHuQnaF3YVdbeuV z2smnIx98p9SgW7h5kKDRYjDgQA6KTdS7byMjknFPVTU3wjZW0eB/jjYBdWm1R9d rCGwIxwK5VOOogjnssHF =Tumh -END PGP SIGNATURE-
Re: [gentoo-dev] Moving more arches to dev profiles
Instead of dropping them entirely to ~arch, maybe something in between could be done: Said arches could start moving to ~arch the leaf and less important packages. E.g. we have (had?) a lot of sparc keywords on sound packages or ppc keywords on ocaml ones because at some point (~10 years ago) some dev was interested in these on this architecture but I'm pretty sure nobody uses them. In short: Reduce stable coverage to reduce the workload. Also, from what I've seen in the thread, you are talking about keywords only, right ? Do these arches keep their stable mark in profiles.desc?
Re: [gentoo-dev] Staging 'einstalldocs' for EAPI 6
On Wed, 21 Aug 2013, I wrote: Maybe we could change the test for an array to the following? elif ! declare +a DOCS /dev/null; then I retract this suggestion. It doesn't work because of issues with local and global scope. Sorry for the noise. Ulrich
Re: [gentoo-dev] Moving more arches to dev profiles
On 21 August 2013 19:28, Alexis Ballier aball...@gentoo.org wrote: Instead of dropping them entirely to ~arch, maybe something in between could be done: Said arches could start moving to ~arch the leaf and less important packages. E.g. we have (had?) a lot of sparc keywords on sound packages or ppc keywords on ocaml ones because at some point (~10 years ago) some dev was interested in these on this architecture but I'm pretty sure nobody uses them. In short: Reduce stable coverage to reduce the workload. Also, from what I've seen in the thread, you are talking about keywords only, right ? Do these arches keep their stable mark in profiles.desc? I am not familiar with portage internals to understand what implications will an ~arch only architecture have if marked as stable. Is there a good reason for that? -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] Moving more arches to dev profiles
On Wed, 21 Aug 2013 20:03:30 +0100 Markos Chandras hwoar...@gentoo.org wrote: On 21 August 2013 19:28, Alexis Ballier aball...@gentoo.org wrote: Instead of dropping them entirely to ~arch, maybe something in between could be done: Said arches could start moving to ~arch the leaf and less important packages. E.g. we have (had?) a lot of sparc keywords on sound packages or ppc keywords on ocaml ones because at some point (~10 years ago) some dev was interested in these on this architecture but I'm pretty sure nobody uses them. In short: Reduce stable coverage to reduce the workload. Also, from what I've seen in the thread, you are talking about keywords only, right ? Do these arches keep their stable mark in profiles.desc? I am not familiar with portage internals to understand what implications will an ~arch only architecture have if marked as stable. Is there a good reason for that? Oh yes: Forbid broken deptree. x86-fbsd has always been dev profile + ~arch only. It is almost impossible to move it to stable profile since people (almost) never run 'repoman -d' and even less file bugs when they introduce broken deps. It is common to have portage bail out when updating your system because someone introduced a broken dep and didnt pay attention. amd64-fbsd is stable profile + ~arch only. People do it the correct way, which is: drop keywords, file a bug. Since we do not have a huge tree coverage here, I get about 5 such bugs a months, which are not hard to handle.
Re: [gentoo-dev] rfc: stabilization policies
On Wed, Aug 21, 2013 at 10:56 AM, Tom Wijsman tom...@gentoo.org wrote: That doesn't make it a special case here, imo; especially not, since we are designing and implementing ebuilds that _build_ the kernel. Whether it provides the sources, or build it; what does that matter? Yes and no. I don't think the kernel needs a separate QA/stabilization policy per-se. However, it probably isn't a good barometer of the state of the tree. On the one hand, it is probably one of the most popular and looked-after packages in the tree. On the other hand it has releases with both high frequency and impact. There really isn't a single FOSS project like the Linux kernel anywhere. So this isn't about making up different rules for the kernel. The issue is more that I wouldn't use the kernel as my main example of the state of the tree. I'm not sure it even makes sense to have single examples so much as categories. It might be interesting to see how up-to-date stable packages are when looking at system vs non-system (glibc vs mplayer), package popularity (firefox vs baobab), desktop vs server (vlc vs mysql), and so on. I suspect though that it has as much to do with maintainer philosophy as the package itself - some maintainers pay more attention to stable. Rich
Re: [gentoo-dev] Moving more arches to dev profiles
On 21 August 2013 20:10, Alexis Ballier aball...@gentoo.org wrote: On Wed, 21 Aug 2013 20:03:30 +0100 Markos Chandras hwoar...@gentoo.org wrote: On 21 August 2013 19:28, Alexis Ballier aball...@gentoo.org wrote: Instead of dropping them entirely to ~arch, maybe something in between could be done: Said arches could start moving to ~arch the leaf and less important packages. E.g. we have (had?) a lot of sparc keywords on sound packages or ppc keywords on ocaml ones because at some point (~10 years ago) some dev was interested in these on this architecture but I'm pretty sure nobody uses them. In short: Reduce stable coverage to reduce the workload. Also, from what I've seen in the thread, you are talking about keywords only, right ? Do these arches keep their stable mark in profiles.desc? I am not familiar with portage internals to understand what implications will an ~arch only architecture have if marked as stable. Is there a good reason for that? Oh yes: Forbid broken deptree. x86-fbsd has always been dev profile + ~arch only. It is almost impossible to move it to stable profile since people (almost) never run 'repoman -d' and even less file bugs when they introduce broken deps. It is common to have portage bail out when updating your system because someone introduced a broken dep and didnt pay attention. amd64-fbsd is stable profile + ~arch only. People do it the correct way, which is: drop keywords, file a bug. Since we do not have a huge tree coverage here, I get about 5 such bugs a months, which are not hard to handle. Ah, I have no strong preference then. -- Regards, Markos Chandras - Gentoo Linux Developer http://dev.gentoo.org/~hwoarang
Re: [gentoo-dev] New developer features in portage: cgroup, network-sandbox, ipc-sandbox
This sounds like cool stuff... I wonder if this could be a step towards unprivileged users being able to use portage for user-installed apps.
Re: [gentoo-dev] New developer features in portage: cgroup, network-sandbox, ipc-sandbox
On Wed, Aug 21, 2013 at 10:05 PM, Albert Hopkins mar...@letterboxes.org wrote: This sounds like cool stuff... I wonder if this could be a step towards unprivileged users being able to use portage for user-installed apps. Sounds like Prefix, lite? Rich
Re: [gentoo-dev] Sets in the tree
On 21 August 2013 23:03, Sergey Popov pinkb...@gentoo.org wrote: 15.08.2013 12:12, Pacho Ramos пишет: El mié, 14-08-2013 a las 15:17 +0100, Ciaran McCreesh escribió: Ah, looks like I was too optimistic and we are (again) with the usual blocking (and blocker) issues -_- (PMS refusing to include something because of lack of documentation :S) And they are right at this point. How you can include something into standard, that is not documented? Documentation of how to use sets(for users) is not enough in this case, IMHO. -- Best regards, Sergey Popov Gentoo developer Gentoo Desktop-effects project lead Gentoo Qt project lead Gentoo Proxy maintainers project lead So let's get a proper spec and documentation! Because sets can be very useful, as I'm sure everyone will agree. -- Cheers, Ben | yngwin Gentoo developer
Re: [gentoo-dev] Moving more arches to dev profiles
On 22 August 2013 01:19, Matt Turner matts...@gentoo.org wrote: On Wed, Aug 21, 2013 at 8:50 AM, Markos Chandras hwoar...@gentoo.org wrote: Is there an alternative? afaik a profile can be either stable,dev or exp. I can't see how we can implement something between stable and dev. And what would that represent? It may or may not be stable? If this is the case, then I believe ~arch is more preferred. I haven't read much into it, but Fedora has a concept of Secondary Architectures. I think it would make sense if we could keep stable keywords for them, but not prevent maintainers from needing to wait on them to stabilize other packages. I don't see how that would work. You can't remove older versions unless a newer one is stabilized, or you'd break the tree. One option I see is to limit the amount of packages with stable keywords to a select list, e.g. @system and closely related packages, and refuse stable keywords for GUI toolkits and their desktop reverse dependencies and the like. Ago is doing a fantastic job, but it would be good to lower his work-load and reduce the bus factor problem. -- Cheers, Ben | yngwin Gentoo developer
