Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
On Thu, 23 May 2013 05:30:25 + (UTC)
Duncan <1i5t5.dun...@cox.net> wrote:
> That's the point. It *IS* possible to use INSTALL_MASK sanely,
> without something breaking.
Nobody said it isn't, I agree hacks can be used without breaking
things; the point is that that doesn't make it a good idea in general.
> Applying your exact phrasing to the topic at hand: "If you really
> think[1] you can't use INSTALL_MASK without something breaking, you
> should carefully consider who is doing the screwing up."
If you really think[1] you need INSTALL_MASK for a few small files when
there are much larger consumers around, you should carefully consider
whether what you are doing is the right thing. ("OMG systemd units!")
> [1] Think: Or for that matter, demonstrate to yourself and others.
--
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: Making systemd more accessible to "normal" users
On Wed, 22 May 2013 16:39:25 -0500 Daniel Campbell wrote: > I'm curious as to why you consider users who want to save disk space > (openrc or systemd, or other packages, it doesn't matter) as > fundamentalists. I'd call them using other words but I didn't want to be that inpolite. Seriously, there are bigger problems in the world than a few text files. And much bigger useless space consumers which you don't even notice because they don't have the 'systemd' name on them. If you care about disk space, then find the biggest consumers and try to work on them. Otherwise, you're just picking. And that's close to fundamentalism. -- Best regards, Michał Górny signature.asc Description: PGP signature
Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
On Wed, 22 May 2013 17:21:40 +0200 Luca Barbato wrote: > On 05/21/2013 09:03 AM, Alan McKinnon wrote: > > On 21/05/2013 05:03, Daniel Campbell wrote: > >> That's missing the point. If you don't run systemd, having unit files is > >> pointless. Thankfully there's INSTALL_MASK and whatnot, but that seems > >> like a hack instead of something more robust. Why include systemd unit > >> files (by default, with no systemd USE flag, thanks to the council...) > >> on a system that's not using it? 154 files isn't negligible unless > >> you're flippant with your system and don't care about bloat. Unused > >> software sitting around *is* a waste of disk-space. > >> > >> Some people (like myself) came to Gentoo to avoid putting systemd on > >> their systems and to make use of the great choice that Gentoo allows. > >> This push to make systemd a "first level citizen" or whatever reeks of > >> marketing. If there is desire among users for unit files, they can > >> contact upstream or maintain their own set of unit files. It's not like > >> they're hard to write. > >> > > > > > > > > This is such a weak argument it's quite laughable. > > > > I don't like gnu info files. Neither me nor anyone I know can figure out > > how to drive info. So, let's rip all the info files out of every > > package; leaving the 3 users who do know info free to grab their copies > > from upstream. I mean it's not like it's hard or anything, and info > > files are easy to write. > > check the FEATURES variable and be surprise =) (from man make.conf) > > nodoc Do not install doc files (/usr/share/doc). > > noinfo Do not install info pages. > > noman Do not install manpages. > > Adding a nounits norunscript and such might work and had been proposed. Yet it's just redundant and a more specific form of INSTALL_MASK. Without the ability to e.g. rebuild packages which were installing given files. -- Best regards, Michał Górny signature.asc Description: PGP signature
[gentoo-dev] Re: robo-stable bugs
Jeroen Roovers posted on Wed, 22 May 2013 17:21:46 +0200 as excerpted: > On Tue, 21 May 2013 00:46:22 + (UTC) > Duncan <1i5t5.dun...@cox.net> wrote: >> As a user, I've understood: >> >> * Severity is something the user/filer can use. > > So when Chromium doesn't compile on your machine, you set it as a > Blocker, and then it gets reverted to Normal because it works fine for > the other 99,9%. Well, I chose to put the big bullet-points at the top and the caveats (with which you agreed) below. The caveat in this case being that even still a normal user shouldn't be setting it, and I even proposed making that the first level of "gentoo bugzilla privilege" people could get, thus restricting it for the general user. > Individual users are probably not best suited to > discover the scope of a bug report, let alone the actual bug, if there > is one. If the Severity does not get reverted to Normal, then we can > safely assume it's being completely ignored. I'd not agree that it's safe to assume, but it certainly could be the case. > The interpretation of Severity is highly dependent on the type of bug > report. It's already diverting strongly between stabilisation requests, > security vulnerabilities and changes to documentation. The meaning of > the field thusly changes according to the Product/Component and other > fields. True. >> Even so, if there's no known-approved reason to set severity, a user >> should just leave it alone. That means users unfamiliar with gentoo's >> bugzilla should just leave it alone. > > Agreed. =:^) >> * If it's an enhancement I mark it as such, and expect maintainer bug >> priority ranked less urgent as a result. The *.desktop file example >> someone mentioned goes here, > > What if a bad/missing .desktop file stops you from running an app > through your DM/another app trying to find an appropriate program to > open a file in? It's still an enhancement. If it were /that/ important to the app in general, it'd be shipped by upstream. It not being shipped by upstream means (at minimum) they don't care enough to have made it a priority, and that existing general functionality isn't affected, which means the generally lower priority of "enhancement" fits, because that's what it /is/, an "enhancement, an /added/ feature in this case for better desktop integration. It's certainly more an enhancement than a bug with an existing feature, the default case, thus the name "bugzilla". >> * If the bug has system-wide or arch-class-wide (all ~arch, for >> instance) implications, I'll sometimes up severity accordingly, with a >> note in the text explaining my reasoning. Toolchain or base-system >> bugs that prevent normal boot or system upgrade arguably fit here, >> especially if they're on a recently (say a day) unmasked or announced >> to be unmasked package with arch-class-wide implications, where an >> immediate remask might be appropriate until the situation can be >> resolved. > > What if your initial analysis completely misses the mark? Then you end > up with an INVALID Blocker with one or more devs investigating hours in > a user error. How did setting Severity help here? In the "first privilege" scenario I suggested, ordinary users wouldn't have that ability, and if those who /do/ have that ability abuse it consistently, well, it's a privilege not a right, and it gets revoked as such. Which would tend to make users with the privilege /very/ cautious about setting it, since it could cause a privilege revoke. > In conclusion, setting Severity can only be properly done after an > actual bug has been appreciated, not at the time you file the bug > report. With the bugs I file where I change it, I've confident enough in the leg- work I've already done to know the _severity_ of the bug -- basically, a rough percentage of package users that would face the bug were they to emerge that version of the package right now, and the effect it would have on their system. If anything, I tend to under-rank the severity. An example of a "blocker" bug would be the one a few years ago where portage was screwing up glibc symlinks, pretty much killing the entire system for anyone that tried that (freshly unmasked IIRC) version! (In that case it was a portage symlinking bug... that happened to occur at exactly the worst time possible, at almost exactly the same time a new glibc came out, triggering the bug in the worst possible way.) Similarly, the IIRC twice in nearing a decade on gentoo I've seen a bash bug (in ~arch, admittedly, where they're to expected from time to time and people running ~arch should be prepared to deal with it) that effectively killed the default system shell... for anyone happening to update to it on ~arch since that's where it was unmasked. > As explained above, the security team has its own rules. Basically what I was saying, they're handled separately (my words) and have their own rules (yours). -- Duncan - List replie
Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
On 22/05/2013 23:39, Daniel Campbell wrote: > I do not consider Gentoo to be only about my own choices, but as a user, > who else's choices am I going to consider when I administer my system? > I'm happy for any new choices as long as they don't step on mine. I > think that's fair. Your choices are necessarily constrained by the fact that other people also have choices, and those people use a copy of the same machinery you use to implement their choices. You do not operate in a vacuum, and you cannot consider just your own choices and get a sane result - Godel proved that this cannot happen in this universe, in much the same way you cannot multiple two and three and get nine. Now, you cannot know what choices I've made here on my systems, but you do know that I have choices and you must consider that fact when making your choices. This has many side-effects, but the most common is that often you have to give a little to get a lot. In the case of systemd - people like Canek have the choice to use it, and to give him that choice you pretty much have to tolerate that all our machines are going to get unit files. That's the bit where you give a little. It works in reverse too. If you want KDE you get .desktop files and so does everyone else, and they too must give a little. If the generic machinery (aka package managers) that deals with this stuff doesn't quite cut the mustard as you would like, you still retain the ultimate choice: rm or it's expedient cousin INSTALL_MASK -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-dev] Re: Making systemd more accessible to "normal" users
Ciaran McCreesh posted on Wed, 22 May 2013 16:24:05 +0100 as excerpted: > On Tue, 21 May 2013 21:37:25 + (UTC) > Duncan <1i5t5.dun...@cox.net> wrote: >> Ciaran McCreesh posted on Tue, 21 May 2013 14:50:04 +0100 as >> excerpted: >> > On Tue, 21 May 2013 04:45:12 + (UTC) >> > Duncan <1i5t5.dun...@cox.net> wrote: >> >> But the point you're missing is that INSTALL_MASK is NOT a hack. >> > >> > Sure it is. It's a hack and remains a hack until there's a way of >> > using it without risk of breakage. >> >> LOL. Better turn off that computer then. By your definition it's a >> hack. Or at least remove anything gentoo related from it. That's a >> hack too. Oh, and that stove and microwave, better throw them away >> too, because leave something cooking too long and... FIRE! So >> they're hacks too. > > That's nonsense, and you know it. There is a big difference between a > carefully designed feature that only breaks if someone screws up, and > something which breaks arbitrarily with no warning. One of the things > about working with computers is that, if something breaks, it's because > someone screwed up. If you really think you can't use your computer > without something breaking, you should carefully consider who is doing > the screwing up. That's the point. It *IS* possible to use INSTALL_MASK sanely, without something breaking. Applying your exact phrasing to the topic at hand: "If you really think[1] you can't use INSTALL_MASK without something breaking, you should carefully consider who is doing the screwing up." [1] Think: Or for that matter, demonstrate to yourself and others. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
On Wed, May 22, 2013 at 11:42:08AM -0700, Zac Medico wrote > It will require portage to be able to predict where the units are > installed, and also be able to avoid accidentally wiping out anything > else that may be installed nearby. The prediction issue also comes up in > this bug which requests a 'dounit' ebuild helper: > >https://bugs.gentoo.org/show_bug.cgi?id=469086 > > Maybe the package manager should query the unit location from pkg-config? I think this is the wrong algorithm... i.e. asking where files of type "X" are installed, and wreaking havoc in in that location. I think that it would be more robust for the installer to decide which files are of type "X", and not install them in the first place. This approach does not risk wiping files from another program in the same directory. And preventative action is generally better than cleaning up after the fact. -- Walter Dnes I don't run "desktop environments"; I run useful applications
Re: [gentoo-dev] robo-stable bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/22/2013 09:11 AM, Ian Stakenvicius wrote: > On 21/05/13 11:46 PM, Rick "Zero_Chaos" Farina wrote: > >> I do, however, completely agree that there should be some way to >> leave the bug open and state that it will be stabled later. Would >> a comment trigger this in the script? That seems semi-sane. If >> the maintainer wanted to stabilize things they would cc arches, any >> other comment could likely be understood to mean "don't auto-stable >> this". > > > It does make a lot of sense that there be a way to flag whether the > bug has been touched or not, and *only* auto-process it if it hasn't > been touched. Of course there are some cases where changes would be > OK (CC's added, for instance; also end-user comments but possibly dev > comments)... > > Maybe we can do something with bug status? Something along the lines > maybe of filing as 'unconfirmed' and a dev setting it to 'confirmed' > (or anything else) would make it be ignored by the auto-stabilizer ? > Or maybe 'confirmed' is the initial status and a dev can set it to > 'unconfirmed' or w/e... ? > > Changing Confirmed->Unconfirmed seems like a good policy. Also if we are going to start establishing such policies they should be posted somewhere and linked to from the autostabilization script's comment. - -Zero -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRnU6yAAoJEKXdFCfdEflKe4oQAK9ObsiJ2ZXUVM5K8n4Vnl+W 8vLzqTjPtWJbhFSIdAVA2RzzxXWSAl7Gza+TlMX764DCJQQcEXRnulQXAEyqKAaL OPlhc9SlhnXa2WA3D0f/koY8NSOPu2vxqe+TXlgwgrysWruBPugTqtTrdjd1fmfy fLlX3ANekbKa06Rc16Q8am9OxVvU/GlRJ7FbUh1c16wxsX0edjBEbg2Ze0kDyeMU ajK4sC+ocZSNM79TjMgWhAzOKCH1XCgHW61dh0h8nJ/SEGJLW5V+yKbH3/oIlSAN nLiBVEtprBeySbMRKDafMvgjW2Zk90blckPBYhtAJQ70oYtZsIXdqRb3WEdyuQGX I55JAaHsRnOdppwiOGZRKnHi34ExTACx5XjKOZs0c9C5z1yELfFhFT9iyVoIB7z/ 3X1KM55UvLK1R9RCwdwSo5JxlI3ezUUdnVIZnGMS9mzf/mHijZVGpt11pTHXyxQi fsppqDAAzhomuaudYnRfFRqyJy+ZikeQGTlG2dWIBPdXaS3gxF+0j2ipUqyZASMx 7krVlL0IDDQQfdyug2zl8b9R/gInkei4oovnz89DepcbmVsIDF2Ndd2sB1LTvHvv 9VYDvVrcd7JZL+hsXIpCfZpXOfsmhPrOaPn3nau2ZSq6j9WCPj9o7kGFT6L3+luX vOM9X+tAxHdjNW7CJrNm =aze5 -END PGP SIGNATURE-
Re: Re: Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
On Wed, May 22, 2013 at 9:39 PM, Daniel Campbell wrote: > On 05/20/2013 10:34 PM, Canek Peláez Valdés wrote: >> On Tue, May 21, 2013 at 3:03 AM, Daniel Campbell wrote: >>> On 05/19/2013 01:05 PM, Canek Peláez Valdés wrote: On Sun, May 19, 2013 at 9:34 AM, Peter Stuge wrote: > J. Roeleveld wrote: >> I don't see how this will avoid the issue of a limited amount of >> inodes. >> That is what I usually run out of before the disk is full when >> storing lots of smaller files. > > I guess the number of unit files is on the order of hundreds (Sorry, sent email before it was ready). Laptop running full GNOME: # find /usr/lib/systemd/system -type f | wc 154 1547012 Server running Apache+MySQL+Mailman+Squid+Other services: # find /usr/lib/systemd/system -type f | wc 121 1215560 And as you said, you can always use INSTALL_MASK. If 154 files are going to deplete your inodes, I think your problem lies somewhere else. Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México >>> >>> That's missing the point. If you don't run systemd, having unit files is >>> pointless. Thankfully there's INSTALL_MASK and whatnot, but that seems >>> like a hack instead of something more robust. Why include systemd unit >>> files (by default, with no systemd USE flag, thanks to the council...) >>> on a system that's not using it? 154 files isn't negligible unless >>> you're flippant with your system and don't care about bloat. Unused >>> software sitting around *is* a waste of disk-space. >> >> Unit files are not software; they are data. >> >> And I believe you are the one missing the point. I don't run OpenRC; I >> don't need no files in /etc/init.d. But you don't see me (nor any >> other systemd user) complaining about pointless scripts in >> /etc/init.d. I just put /etc/init.d in INSTALL_MASK and go on with my >> life. >> >> Non-systemd users should do the same for files under /usr/lib/systemd, >> if they really are that worried about systemd "infecting" their >> systems. Complaining about a council-decided policy (and, I believe, >> backed up by the developers that matter, including the OpenRC >> maintainers) is just beating on a dead horse. >> >> Get over it. >> >>> Some people (like myself) came to Gentoo to avoid putting systemd on >>> their systems and to make use of the great choice that Gentoo allows. >>> This push to make systemd a "first level citizen" or whatever reeks of >>> marketing. >> >> If Gentoo is about choice, then systemd is one of those choices. And >> systemd will become a first class citizen inside Gentoo, like it or >> not. Support for it has been getting better and better, and more and >> more Gentoo users are running with systemd. >> >> If some fundamentalists users don't want even one file in their >> systems with "systemd" on their paths, they can install eudev/mdev, >> put the necessary directories in INSTALL_MASK, and do the extra work. >> If some other fundamentalists users (like myself) don't want even one >> OpenRC related file on our systems, we can create an overlay to remove >> the dependency of baselayout on OpenRC, put /etc/init.d in >> INSTALL_MASK, and do the extra work. >> >> Neither case covers the average systemd/OpenRC user, who doesn't care >> about a few scattered files in /etc/init.d nor /usr/lib/systemd, and >> just want to run her machine with the init system of her choice. If >> Gentoo is really about choice. >> >>> If there is desire among users for unit files, they can >>> contact upstream or maintain their own set of unit files. It's not like >>> they're hard to write. >> >> So, Gentoo is about choice, but only for the choices you agree with. Great. >> >> Regards. >> -- >> Canek Peláez Valdés >> Posgrado en Ciencia e Ingeniería de la Computación >> Universidad Nacional Autónoma de México >> > > It seems that I've stepped on a few toes in calling INSTALL_MASK a hack. > Hacks aren't necessarily bad; if anything it shows that there's interest > in supporting something but perhaps not enough time or manpower to > implement a more robust solution. If adding one or two directories to > that variable will nuke any unit files, consider me happy. As I was, when I used to put /etc/init.d in INSTALL_MASK. > systemd is certainly a choice, but it is no more deserving of > consideration than any other init system. I don't see anyone calling for > runit to be a 'first level citizen'. I wonder why that is. Probably because is used by a really small number of users, contrary to systemd > Again, if > INSTALL_MASKing openrc dirs will get rid of init scripts for systemd > users, then perhaps INSTALL_MASK is the best we have for now and should > make use of it. I never said that it wasn't suitable to use. Then we agree. > As for "complaining" about policy, what
Re: Re: Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
On 05/20/2013 10:34 PM, Canek Peláez Valdés wrote: > On Tue, May 21, 2013 at 3:03 AM, Daniel Campbell wrote: >> On 05/19/2013 01:05 PM, Canek Peláez Valdés wrote: >>> On Sun, May 19, 2013 at 9:34 AM, Peter Stuge wrote: J. Roeleveld wrote: > I don't see how this will avoid the issue of a limited amount of > inodes. > That is what I usually run out of before the disk is full when > storing lots of smaller files. I guess the number of unit files is on the order of hundreds >>> >>> (Sorry, sent email before it was ready). >>> >>> Laptop running full GNOME: >>> >>> # find /usr/lib/systemd/system -type f | wc >>> 154 1547012 >>> >>> Server running Apache+MySQL+Mailman+Squid+Other services: >>> >>> # find /usr/lib/systemd/system -type f | wc >>> 121 1215560 >>> >>> And as you said, you can always use INSTALL_MASK. If 154 files are >>> going to deplete your inodes, I think your problem lies somewhere >>> else. >>> >>> Regards. >>> -- >>> Canek Peláez Valdés >>> Posgrado en Ciencia e Ingeniería de la Computación >>> Universidad Nacional Autónoma de México >>> >> >> That's missing the point. If you don't run systemd, having unit files is >> pointless. Thankfully there's INSTALL_MASK and whatnot, but that seems >> like a hack instead of something more robust. Why include systemd unit >> files (by default, with no systemd USE flag, thanks to the council...) >> on a system that's not using it? 154 files isn't negligible unless >> you're flippant with your system and don't care about bloat. Unused >> software sitting around *is* a waste of disk-space. > > Unit files are not software; they are data. > > And I believe you are the one missing the point. I don't run OpenRC; I > don't need no files in /etc/init.d. But you don't see me (nor any > other systemd user) complaining about pointless scripts in > /etc/init.d. I just put /etc/init.d in INSTALL_MASK and go on with my > life. > > Non-systemd users should do the same for files under /usr/lib/systemd, > if they really are that worried about systemd "infecting" their > systems. Complaining about a council-decided policy (and, I believe, > backed up by the developers that matter, including the OpenRC > maintainers) is just beating on a dead horse. > > Get over it. > >> Some people (like myself) came to Gentoo to avoid putting systemd on >> their systems and to make use of the great choice that Gentoo allows. >> This push to make systemd a "first level citizen" or whatever reeks of >> marketing. > > If Gentoo is about choice, then systemd is one of those choices. And > systemd will become a first class citizen inside Gentoo, like it or > not. Support for it has been getting better and better, and more and > more Gentoo users are running with systemd. > > If some fundamentalists users don't want even one file in their > systems with "systemd" on their paths, they can install eudev/mdev, > put the necessary directories in INSTALL_MASK, and do the extra work. > If some other fundamentalists users (like myself) don't want even one > OpenRC related file on our systems, we can create an overlay to remove > the dependency of baselayout on OpenRC, put /etc/init.d in > INSTALL_MASK, and do the extra work. > > Neither case covers the average systemd/OpenRC user, who doesn't care > about a few scattered files in /etc/init.d nor /usr/lib/systemd, and > just want to run her machine with the init system of her choice. If > Gentoo is really about choice. > >> If there is desire among users for unit files, they can >> contact upstream or maintain their own set of unit files. It's not like >> they're hard to write. > > So, Gentoo is about choice, but only for the choices you agree with. Great. > > Regards. > -- > Canek Peláez Valdés > Posgrado en Ciencia e Ingeniería de la Computación > Universidad Nacional Autónoma de México > It seems that I've stepped on a few toes in calling INSTALL_MASK a hack. Hacks aren't necessarily bad; if anything it shows that there's interest in supporting something but perhaps not enough time or manpower to implement a more robust solution. If adding one or two directories to that variable will nuke any unit files, consider me happy. systemd is certainly a choice, but it is no more deserving of consideration than any other init system. I don't see anyone calling for runit to be a 'first level citizen'. I wonder why that is. Again, if INSTALL_MASKing openrc dirs will get rid of init scripts for systemd users, then perhaps INSTALL_MASK is the best we have for now and should make use of it. I never said that it wasn't suitable to use. As for "complaining" about policy, what is the proper thing to do in a situation where someone questions the reasoning behind a decision? Are there links somewhere on Gentoo's website that outline the process for each important decision that the council's made? I think it'd be valuable information for people and keep individuals like you from telling others to "
Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
On Wed, May 22, 2013 at 2:42 PM, Zac Medico wrote: > On 05/22/2013 08:21 AM, Luca Barbato wrote: >> >> check the FEATURES variable and be surprise =) (from man make.conf) >> >>nodoc Do not install doc files (/usr/share/doc). >> >>noinfo Do not install info pages. >> >>noman Do not install manpages. >> >> Adding a nounits norunscript and such might work and had been proposed. > > > It will require portage to be able to predict where the units are installed, > and also be able to avoid accidentally wiping out anything else that may be > installed nearby. The prediction issue also comes up in this bug which > requests a 'dounit' ebuild helper: > > https://bugs.gentoo.org/show_bug.cgi?id=469086 > > Maybe the package manager should query the unit location from pkg-config? That sounds reasonable to me.
Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
On 05/22/2013 08:21 AM, Luca Barbato wrote: check the FEATURES variable and be surprise =) (from man make.conf) nodoc Do not install doc files (/usr/share/doc). noinfo Do not install info pages. noman Do not install manpages. Adding a nounits norunscript and such might work and had been proposed. It will require portage to be able to predict where the units are installed, and also be able to avoid accidentally wiping out anything else that may be installed nearby. The prediction issue also comes up in this bug which requests a 'dounit' ebuild helper: https://bugs.gentoo.org/show_bug.cgi?id=469086 Maybe the package manager should query the unit location from pkg-config? -- Thanks, Zac
Re: [gentoo-dev] robo-stable bugs
On Wed, 22 May 2013 17:03:21 +0200 Jeroen Roovers wrote: > On Mon, 20 May 2013 17:29:43 +0200 > Tom Wijsman wrote: > > > Also, your script does not set the STABLEREQ keyword. People are > > > having to hunt down your robo-stabilisation requests and add it > > > themselves. You should just do it yourself or turn your script > > > off. > > > > Maintainer(s) and arch team member(s) blamed me for setting this. :( > > I have frankly never heard that one before. Setting STABLEREQ *and* > CC'ing is probably what went wrong there? Nope, effectively just adding the STABLEREQ keyword and not CC-ing anyone had someone ping me on IRC. Similarly I've had people ping me about KEYWORDREQ as well (but that was according to policy and agreed). -- 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: robo-stable bugs
On Wed, 22 May 2013 19:18:41 +1000 Michael Palimaka wrote: > A newer version of a package is usually considered to be better in > some way, hence it is an enhancement. Unless it's a Blocker, of course. :) > According to the bug-wrangler's own docs[1]: "A stabilisation request > should be handled by the package's maintainer, so you should not CC > arch teams in your role as bug wrangler, nor set the STABLEREQ > keyword in the Keywords field.". There should at least be some > consistency there before telling people what to do. I am trying to find consensus based on reasonable argument here. > [1]: http://www.gentoo.org/proj/en/qa/bug-wranglers/ Documentation/policy should change after discussion. I set up the b-w project to get something of a standard going, not to "[tell] people what to do". I have been adding STABLEREQ recently because it's turning out to be more practical (mainly because developers keep forgetting to add it, despite the helpful suggestion from the robo-script). I will change the default in the b-w doc if I find there is reasonable consensus on the matter. jer
Re: [gentoo-dev] Re: robo-stable bugs
On Tue, 21 May 2013 18:57:20 -0600 Ryan Hill wrote: > Huh? The severity of the bug is it's an enhancement. The point I was making is we could improve things by a fair margin. If all stabilisation bugs had a Severity that actually reflected the severity, then I'd pay attention to it. Right now only the security team gets it right, it seems. > Yes stabilizations are enhancements. Always have been. Looking through more than eight and a half years of stabilisation bug mail, I can definitively confirm that you are wrong. It wasn't always this way and it changed very recently. Again, the status quo is no reason to not improve the status quo. > > Also, your script does not set the STABLEREQ keyword. People are > > having to hunt down your robo-stabilisation requests and add it > > themselves. You should just do it yourself or turn your script off. > > Did you read the message? The point is you're supposed to add that > yourself. It's not a STABLEREQ until you add arches. Yes, I've read its nearly useless contents way too many times. It is awful. It could probably be improved and refreshed in even more ways than I and others have suggested so far. It could include actual information, for starters, instead of things that should probably be in some policy document or guide. Adding STABLEREQ can't be done through the bugzilla API until after the bug is filed, which was the technical reason it isn't done, I've been told. That's a technical problem we can solve. jer
Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
On Tue, 21 May 2013 21:37:25 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > Ciaran McCreesh posted on Tue, 21 May 2013 14:50:04 +0100 as > excerpted: > > On Tue, 21 May 2013 04:45:12 + (UTC) > > Duncan <1i5t5.dun...@cox.net> wrote: > >> But the point you're missing is that INSTALL_MASK is NOT a hack. > > > > Sure it is. It's a hack and remains a hack until there's a way of > > using it without risk of breakage. > > LOL. Better turn off that computer then. By your definition it's a > hack. Or at least remove anything gentoo related from it. That's a > hack too. Oh, and that stove and microwave, better throw them away > too, because leave something cooking too long and... FIRE! So > they're hacks too. That's nonsense, and you know it. There is a big difference between a carefully designed feature that only breaks if someone screws up, and something which breaks arbitrarily with no warning. One of the things about working with computers is that, if something breaks, it's because someone screwed up. If you really think you can't use your computer without something breaking, you should carefully consider who is doing the screwing up. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] robo-stable bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22/05/13 11:14 AM, Michael Mol wrote: > On 05/22/2013 11:00 AM, Jeroen Roovers wrote: >> On Wed, 22 May 2013 08:53:06 -0400 Ian Stakenvicius >> wrote: >> >>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 >>> >>> On 21/05/13 07:43 PM, Thomas Sachau wrote: [ Snip reasons for why opt-out is bad ] >>> So why don't we add something to package metadata, to indicate >>> that a package is OK to be considered for auto-stabilization? >> Package or ebuild or SLOT or what? Please explain what these >> metadata.xml entries should look like. Also, since we're working >> per ebuild, and not per package, why couldn't we include this in >> each individual ebuild? What happens when you've set the >> variable, tag or whatever, and then an obscure bug pops up (and >> you're not CC'd because the bug appears in a dependent package >> three branches removed) and then your robo-call comes in for that >> ebuild? >> >> It's a neat idea, but the red tape would stretch to Alpha >> Centauri and back. IOW, it's hardly maintainable unless you can >> afford the espresso machine and all of your spare time. Common >> sense and proper research usually cuts that short. Automating >> CC'ing arch teams would probably only catch this in a very late >> stage, if at all in time before an ebuild is deemed "stable". >> >> >> jer >> > > My expectation is that something in metadata.xml would operate > *per-package* to allow the maintainer of that package to say "hey, > let me do my own thing here." Trying to set those values per-ebuild > sounds like a bug farm as those values are accidentally set wrong > from time to time. Then you try writing something to automate the > maintainer side of things, and you've got more lines of > (theoretically possibly buggy) code to worry about. > > "let me do my own thing here" would start off as "don't touch my > packages". Trying to plan more granularity than that at the outset > seems a lot like trying to tell the future. > I agree - the metadata addition I would propose would be for metadata.xml, and would be per-package. It would also be specifically for the auto-stablereq script(s) (or for people, if this changes in the future to something a team works on) to read. Handling individual package versions -could- be done via metadata.xml, but that would ..well, jer described what that'd be like. :) Plus metadata.xml probably shouldn't change with every version bump. I think it'd be best to just handle individual package versions by opening a bug (as then the stabilizer script would just skip that $PV anyhow). All in all, this isn't much different from the idea i mentioned a while ago, about dev's putting in an "others feel free to touch my stuffs" / "touch these ebuilds and i kill your first born" entry in metadata.xml -- it's just stabilization specific. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGc4q0ACgkQ2ugaI38ACPApeQEAjs5IZ6KVXWLJQJ+NNbekvyub nidlgWEVs2YXJiOLHWMA/0iArPM7T4a2hJruNw5MVmbEfYvwu66HrOFhue9LSPRA =5T7z -END PGP SIGNATURE-
Re: [gentoo-dev] Re: robo-stable bugs
On Tue, 21 May 2013 00:46:22 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > As a user, I've understood: > > * Severity is something the user/filer can use. So when Chromium doesn't compile on your machine, you set it as a Blocker, and then it gets reverted to Normal because it works fine for the other 99,9%. Individual users are probably not best suited to discover the scope of a bug report, let alone the actual bug, if there is one. If the Severity does not get reverted to Normal, then we can safely assume it's being completely ignored. The interpretation of Severity is highly dependent on the type of bug report. It's already diverting strongly between stabilisation requests, security vulnerabilities and changes to documentation. The meaning of the field thusly changes according to the Product/Component and other fields. > * Priority is strictly for maintainers/teams if they want to use it, > NOT the user/filer (unless it's a maintainer filed bug). There is no policy here except where herds/teams specifically set them out. > Even so, if there's no known-approved reason to set severity, a user > should just leave it alone. That means users unfamiliar with > gentoo's bugzilla should just leave it alone. Agreed. > * If it's an enhancement I mark it as such, and expect maintainer bug > priority ranked less urgent as a result. The *.desktop file example > someone mentioned goes here, What if a bad/missing .desktop file stops you from running an app through your DM/another app trying to find an appropriate program to open a file in? > * If the bug has system-wide or arch-class-wide (all ~arch, for > instance) implications, I'll sometimes up severity accordingly, with > a note in the text explaining my reasoning. Toolchain or base-system > bugs that prevent normal boot or system upgrade arguably fit here, > especially if they're on a recently (say a day) unmasked or announced > to be unmasked package with arch-class-wide implications, where an > immediate remask might be appropriate until the situation can be > resolved. What if your initial analysis completely misses the mark? Then you end up with an INVALID Blocker with one or more devs investigating hours in a user error. How did setting Severity help here? In conclusion, setting Severity can only be properly done after an actual bug has been appreciated, not at the time you file the bug report. > * Also, arugably many security bugs could get severity-upgraded, > altho with security handled separately on gentoo, I'd discourage that > unless again it's something like toolchain or base-system, thus > fitting the above system-wide condition. As explained above, the security team has its own rules. jer
Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
On 05/21/2013 09:03 AM, Alan McKinnon wrote: > On 21/05/2013 05:03, Daniel Campbell wrote: >> That's missing the point. If you don't run systemd, having unit files is >> pointless. Thankfully there's INSTALL_MASK and whatnot, but that seems >> like a hack instead of something more robust. Why include systemd unit >> files (by default, with no systemd USE flag, thanks to the council...) >> on a system that's not using it? 154 files isn't negligible unless >> you're flippant with your system and don't care about bloat. Unused >> software sitting around *is* a waste of disk-space. >> >> Some people (like myself) came to Gentoo to avoid putting systemd on >> their systems and to make use of the great choice that Gentoo allows. >> This push to make systemd a "first level citizen" or whatever reeks of >> marketing. If there is desire among users for unit files, they can >> contact upstream or maintain their own set of unit files. It's not like >> they're hard to write. >> > > > > This is such a weak argument it's quite laughable. > > I don't like gnu info files. Neither me nor anyone I know can figure out > how to drive info. So, let's rip all the info files out of every > package; leaving the 3 users who do know info free to grab their copies > from upstream. I mean it's not like it's hard or anything, and info > files are easy to write. check the FEATURES variable and be surprise =) (from man make.conf) nodoc Do not install doc files (/usr/share/doc). noinfo Do not install info pages. noman Do not install manpages. Adding a nounits norunscript and such might work and had been proposed. lu
Re: [gentoo-dev] Re: Making systemd more accessible to "normal" users
On Wed, May 22, 2013 at 4:46 AM, Tom Wijsman wrote: > The amount of users misusing a knife or hammer is much lower than the > amount of users misusing INSTALL_MASK. Agreed. A typical user would almost never need to use INSTALL_MASK. If they're using it, they're probably doing something wrong. If you want to not install unit files, I'd say you're probably doing something wrong, but if you want to do that anyway, INSTALL_MASK is in fact the most appropriate tool for the job. Ditto if you don't want to install init.d scripts. > > Let's not sacrifice part of our user base by taking a wrong decision; > developing a distro goes much further than "let's just use this hack", > until multiple people agree a hack to be the best short term solution. Few people NEED to INSTALL_MASK systemd units. For those who don't care about a few hundred inodes, just use the system and don't worry about this. For those who go nuts over it, use the feature. You get to keep the pieces if you use it wrong. If you don't want to break your system, just set the desktop profile, don't touch your flags, and just emerge what you want. Your system will work just fine. Rich
Re: [gentoo-dev] robo-stable bugs
On 05/22/2013 11:00 AM, Jeroen Roovers wrote: > On Wed, 22 May 2013 08:53:06 -0400 > Ian Stakenvicius wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> On 21/05/13 07:43 PM, Thomas Sachau wrote: >>> [ Snip reasons for why opt-out is bad ] >> So why don't we add something to package metadata, to indicate that a >> package is OK to be considered for auto-stabilization? > Package or ebuild or SLOT or what? Please explain what these > metadata.xml entries should look like. Also, since we're working per > ebuild, and not per package, why couldn't we include this in each > individual ebuild? What happens when you've set the variable, tag or > whatever, and then an obscure bug pops up (and you're not CC'd because > the bug appears in a dependent package three branches removed) and > then your robo-call comes in for that ebuild? > > It's a neat idea, but the red tape would stretch to Alpha Centauri and > back. IOW, it's hardly maintainable unless you can afford the espresso > machine and all of your spare time. Common sense and proper research > usually cuts that short. Automating CC'ing arch teams would probably > only catch this in a very late stage, if at all in time before an > ebuild is deemed "stable". > > > jer > My expectation is that something in metadata.xml would operate *per-package* to allow the maintainer of that package to say "hey, let me do my own thing here." Trying to set those values per-ebuild sounds like a bug farm as those values are accidentally set wrong from time to time. Then you try writing something to automate the maintainer side of things, and you've got more lines of (theoretically possibly buggy) code to worry about. "let me do my own thing here" would start off as "don't touch my packages". Trying to plan more granularity than that at the outset seems a lot like trying to tell the future. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Re: robo-stable bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22/05/13 10:51 AM, Jeroen Roovers wrote: > On Wed, 22 May 2013 09:03:43 -0400 Ian Stakenvicius > wrote: > >>> And the circle is closed since we started with the correlation >>> "no answer to stable bug in 30 days" => "package unmantained" >>> ;-) >>> >> >> This could actually work > > Then we'd get the Ubuntu/Launchpad situation, where several bugs > that I filed more than 4 years ago are still being actively flipped > from on to off and back, invalid to confirmed to wontfix to cantfix > and so on for various reasons, including that the actual > maintainers of the bugs' targets didn't respond in time. It > definitely put me off filing any new bug reports against Ubuntu > packages. Possibly forever. > > > jer > (reading this, I have a fully feeling this was actually in response to the other email I wrote, relating to status changes; however in case it wasn't...) ... just trying to wrap my head around how this would play out: 1- stabilization bug filed 2- no response for 30 days 3- timeout script marks package for maintainer-needed (say, by adding a keyword and a comment) .. script should check devaway first on the maintainers, if devaway then stop at #2. 4- say, another 30 days timeout (longer? how about 90?) 5- a team (treecleaners? or other?) actually marks package maintainer-needed (removing keyword from the bug), assuming the maintainer(s) are not devaway. 6- announcement that package is up for grabs (maybe just in the 'weekly summary'?) The "stabilization request" bug would still be valid and open even if the package moves to maintainer-needed; probably that indication would occur via a KEYWORD rather than a reassignment of the summary. Any dev that chose to get involved and cause deviation at any point in the above list, would stop the process in its tracks, afaict. I don't see how things would flip back again to repeat the whole process Note, on #3, it would really aid this process if the particular maintainer(s) of a package within a herd was listed in the metadata -- iirc for say, x11 herd, certain packages are only touched by one member of the herd even though it just has a tag. I think this could make things smoother for many interactions and not just the above. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGc34QACgkQ2ugaI38ACPAYlQEAjVv44o1Ry3jpfAnFePYJEyBn FNZotaz/D71deOjsbT4A/2pvdMRE+BcmRhQmBj14zXlycwYARcPw8ayoP2kNi8Vh =27YH -END PGP SIGNATURE-
Re: [gentoo-dev] robo-stable bugs
On Mon, 20 May 2013 17:29:43 +0200 Tom Wijsman wrote: > > Also, your script does not set the STABLEREQ keyword. People are > > having to hunt down your robo-stabilisation requests and add it > > themselves. You should just do it yourself or turn your script off. > > Maintainer(s) and arch team member(s) blamed me for setting this. :( I have frankly never heard that one before. Setting STABLEREQ *and* CC'ing is probably what went wrong there? jer
Re: [gentoo-dev] robo-stable bugs
On Wed, 22 May 2013 08:53:06 -0400 Ian Stakenvicius wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On 21/05/13 07:43 PM, Thomas Sachau wrote: > > [ Snip reasons for why opt-out is bad ] > > So why don't we add something to package metadata, to indicate that a > package is OK to be considered for auto-stabilization? Package or ebuild or SLOT or what? Please explain what these metadata.xml entries should look like. Also, since we're working per ebuild, and not per package, why couldn't we include this in each individual ebuild? What happens when you've set the variable, tag or whatever, and then an obscure bug pops up (and you're not CC'd because the bug appears in a dependent package three branches removed) and then your robo-call comes in for that ebuild? It's a neat idea, but the red tape would stretch to Alpha Centauri and back. IOW, it's hardly maintainable unless you can afford the espresso machine and all of your spare time. Common sense and proper research usually cuts that short. Automating CC'ing arch teams would probably only catch this in a very late stage, if at all in time before an ebuild is deemed "stable". jer
Re: [gentoo-dev] Re: robo-stable bugs
On Wed, 22 May 2013 19:18:41 +1000 Michael Palimaka wrote: > > Yet the base system lead went and apply it to any stabilization > > bug; as both him and Jer (the bug wrangling lead) do it this way, > > I'll be doing it as well. Let's not be inconsistent with our leads > > unless there is a wide decision to do so; I expect none will come, > > unless you really think this should become Council material. > > > According to the bug-wrangler's own docs[1]: "A stabilisation request > should be handled by the package's maintainer, so you should not CC > arch teams in your role as bug wrangler, nor set the STABLEREQ > keyword in the Keywords field.". There should at least be some > consistency there before telling people what to do. Just asked the bug wranglers lead to fix that up. > As for base system, I don't really see what bearing their actions has > to do with anything to on bugzilla. The keywords are theirs afaik, how their keywords are used is relevant. > Let's not forget that the current lead has a history of doing > whatever he wants, so I don't think the actions that come out of that > are a good example to follow. Sub project members behaving differently is annoying, that's why I've asked before that the lead(s) attempt to bring some consistency in the way that bugs are dealt with and what is expected from bug wranglers. -- 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: robo-stable bugs
On Wed, 22 May 2013 09:03:43 -0400 Ian Stakenvicius wrote: > > And the circle is closed since we started with the correlation "no > > answer to stable bug in 30 days" => "package unmantained" ;-) > > > > This could actually work Then we'd get the Ubuntu/Launchpad situation, where several bugs that I filed more than 4 years ago are still being actively flipped from on to off and back, invalid to confirmed to wontfix to cantfix and so on for various reasons, including that the actual maintainers of the bugs' targets didn't respond in time. It definitely put me off filing any new bug reports against Ubuntu packages. Possibly forever. jer
Re: [gentoo-dev] robo-stable bugs
On Tue, 21 May 2013 15:32:25 +0200 Thomas Sachau wrote: > Automagic stabilization is a bad idea. I agree. "Maintainer timeout" is not a valid reason to go ahead with stabilisation. If you really want to push forward, you should be required to do more research as bug reporter. > And just because a maintainer can opt-out per bug, it does not change > the automagic behaviour nor does it make this thing any better. In > this case, there are enough possible cases, where a maintainer does > miss the bug, so again a package may become stable, also it should > never have been a stable candidate. So again: If a specific ebuild should never go stable but is, by default, a stable target, then you can do several things: 1) Remove it from the tree If it should never go stable, then ask yourself why it's in the tree. 2) Put it in package.mask Add some reasons, like bug reports that explain what needs to be done to once again make it a stabilisation target. 3) File a bug report detailing while it shouldn't go stable Ebuilds with open bugs should never go stable. This is detailed in the (correct answers to the) quizzes and so on, IIRC, and in [1]. This makes robo-stable requests difficult, though, since the bug report in question could be summarised as " with has issue foo" and then phajdan.jr's robo-script should be able to recognise it.[2] jer [1] http://devmanual.gentoo.org/keywording/index.html [2] Or wait, some human interaction is again called for to fix the bureaucratic mess the script created! Since we still cannot pinpoint a specific cat/pkg/ver-rev in a bug report, it's down to scraping and regexen again.
Re: [gentoo-dev] robo-stable bugs
On Wed, May 22, 2013 at 5:22 AM, viv...@gmail.com wrote: > On 05/21/13 23:38, Andreas K. Huettel wrote: >> Am Dienstag, 21. Mai 2013, 15:38:44 schrieb Thomas Sachau: >>> And if a maintainer is not responding within 30 days, you can ping him >>> or, without a response, try to get a different maintainer. Just assuming >>> that a stable request is ok without a maintainer response is really not >>> a good idea. >> If none of the listed maintainers responds to a bug in 30 days in any way, >> the >> package is effectively unmaintained. >> > And thus its risky to mark it stable. While I can see the logic here, I'd suggest that if we're going to refuse to stabilize because we don't think there is a maintainer, then we should mark the package as maintainer-needed while we're at it. Packages listed with maintainers who don't actually stabilize the package have several problems: 1. It diminishes the experience for stable users, which really should be the best experience we offer (and yes, I know that this is often not the case, hence the need to improve things). 2. The fact that a maintainer is already listed means that nobody else steps up to maintain it either. If a package is maintained, it should be stabilized (unless this is inappropriate due to the nature of the package itself, and that just requires asking for whitelisting). If a package isn't maintained, then it should be marked as such. Rich
Re: [gentoo-dev] robo-stable bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/05/13 11:46 PM, Rick "Zero_Chaos" Farina wrote: > > I do, however, completely agree that there should be some way to > leave the bug open and state that it will be stabled later. Would > a comment trigger this in the script? That seems semi-sane. If > the maintainer wanted to stabilize things they would cc arches, any > other comment could likely be understood to mean "don't auto-stable > this". > It does make a lot of sense that there be a way to flag whether the bug has been touched or not, and *only* auto-process it if it hasn't been touched. Of course there are some cases where changes would be OK (CC's added, for instance; also end-user comments but possibly dev comments)... Maybe we can do something with bug status? Something along the lines maybe of filing as 'unconfirmed' and a dev setting it to 'confirmed' (or anything else) would make it be ignored by the auto-stabilizer ? Or maybe 'confirmed' is the initial status and a dev can set it to 'unconfirmed' or w/e... ? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGcxAoACgkQ2ugaI38ACPA4/AEAp7ezuWH8GjdkrM/1wsidA5Gw iK0+RvCt3xXQBWK+9yYBAI7R/77W154YZ40W28dRDvMHavR1RazzmSffE9FRiTCT =Bclk -END PGP SIGNATURE-
Re: [gentoo-dev] Re: robo-stable bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22/05/13 07:16 AM, viv...@gmail.com wrote: > On 05/22/13 13:06, Michael Palimaka wrote: >> On 22/05/2013 20:41, Thomas Sachau wrote: >>> Michael Palimaka schrieb: On 22/05/2013 20:07, viv...@gmail.com wrote: > On 05/22/13 11:43, Michael Palimaka wrote: >> On 22/05/2013 19:22, viv...@gmail.com wrote: >>> On 05/21/13 23:38, Andreas K. Huettel wrote: Am Dienstag, 21. Mai 2013, 15:38:44 schrieb Thomas Sachau: > And if a maintainer is not responding within 30 > days, you can ping him or, without a response, try > to get a different maintainer. Just assuming that a > stable request is ok without a maintainer response > is really not a good idea. If none of the listed maintainers responds to a bug in 30 days in any way, the package is effectively unmaintained. >>> And thus its risky to mark it stable. >>> >>> >> That's why we have arch teams in the first place, to test >> beforehand. >> >> > The risky part is about the after, not the before, to avoid > the risks arch teams should keep the package working > *after* it has stabilized. Seem to be a good case for those > things that need to be evaluated case by case and could not > be written in stone. > > I am confused as to what you are proposing. Do you want arch teams to continually test packages that are already in stable to make sure they haven't broken somehow? >>> The point is probably, that when you stable a package with >>> inactive maintainer, there will be noone following the opened >>> bugs against this new version. >>> >>> So this looks like a case, where one should ask for a new >>> maintainer, who then decides about the stable versions instead >>> of doing auto-stabilization. >>> >> If the maintainer is inactive, presumably nobody is looking at >> bugs for the old version either. >> >> > And the circle is closed since we started with the correlation "no > answer to stable bug in 30 days" => "package unmantained" ;-) > This could actually work -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGcwi8ACgkQ2ugaI38ACPDVLQEAkWpd//XIy8Newa+TCdHbltKr eeRByNJDLKTwowwoTzMA/iGM9q2vvnCeSYr0J3I60qiTgVBxAGIcOQTXmYbdsUW8 =4KjF -END PGP SIGNATURE-
Re: [gentoo-dev] Re: robo-stable bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22/05/13 06:07 AM, viv...@gmail.com wrote: > On 05/22/13 11:43, Michael Palimaka wrote: >> On 22/05/2013 19:22, viv...@gmail.com wrote: >>> On 05/21/13 23:38, Andreas K. Huettel wrote: Am Dienstag, 21. Mai 2013, 15:38:44 schrieb Thomas Sachau: > And if a maintainer is not responding within 30 days, you > can ping him or, without a response, try to get a different > maintainer. Just assuming that a stable request is ok > without a maintainer response is really not a good idea. If none of the listed maintainers responds to a bug in 30 days in any way, the package is effectively unmaintained. >>> And thus its risky to mark it stable. >>> >>> >> That's why we have arch teams in the first place, to test >> beforehand. >> >> > The risky part is about the after, not the before, to avoid the > risks arch teams should keep the package working *after* it has > stabilized. Seem to be a good case for those things that need to be > evaluated case by case and could not be written in stone. > Unless it's officially maintainer-needed, a package shouldn't be in ~arch when it's unmaintained, either. If an AT passes a package from ~arch to stable, it's no more likely to break things there than it is in ~arch. Plus, it's important to consider the zero-bugs case here -- if all bugs in the ~arch package are fixed, AND the ATs give it a go, then the likliness of harm in stable is pretty minimal. I'd say less so than the end-users keywording the package. Now, one big thing I do worry about with this whole process, is that it's going to significantly increase the workload on ATs. And if it does that, what's the likliness of things getting a 'pass' when they shouldn't? *that* part I worry about more, when the maintainer hasn't manually cleared a package for stabilization. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGcweYACgkQ2ugaI38ACPDGmAD/QtIKe/J5Xg3TjthITn1eTLA4 NfSMrrF6cyXfOdjtmoABAKauw9JDDX5JjUERL2K8At88VjWfeeST45qZ9HifDanv =qB7D -END PGP SIGNATURE-
Re: [gentoo-dev] robo-stable bugs
On 05/22/2013 08:53 AM, Ian Stakenvicius wrote: > On 21/05/13 07:43 PM, Thomas Sachau wrote: > > [ Snip reasons for why opt-out is bad ] > > So why don't we add something to package metadata, to indicate that a > package is OK to be considered for auto-stabilization?? It lets > everyone opt-in, and we still have the opportunity to opt-out if we > want to at stable-bug-request time (or better, the dev can file their > own bug to indicate stabilization will not occur or will occur later > once XYZ are met or w/e).. > > We include it in the default metadata.xml template going forward, and > request all dev's add it to their packages if they want to contribute. > > Thoughts? > > (Note: I also recall there being some sort of blacklist mentioned, > where is the info for that stored? IE, how could I put a package in > that blacklist?) > > I was thinking something similar yesterday, except I'd rather it be seen as opt-out rather than opt-in. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] robo-stable bugs
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21/05/13 07:43 PM, Thomas Sachau wrote: > [ Snip reasons for why opt-out is bad ] So why don't we add something to package metadata, to indicate that a package is OK to be considered for auto-stabilization?? It lets everyone opt-in, and we still have the opportunity to opt-out if we want to at stable-bug-request time (or better, the dev can file their own bug to indicate stabilization will not occur or will occur later once XYZ are met or w/e).. We include it in the default metadata.xml template going forward, and request all dev's add it to their packages if they want to contribute. Thoughts? (Note: I also recall there being some sort of blacklist mentioned, where is the info for that stored? IE, how could I put a package in that blacklist?) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlGcv7IACgkQ2ugaI38ACPA9ewEAp5IwDre3O8iz+UurnAhDsCF5 fIWcearEExwknl14U48A/0IW0sI0Yxs+qnQnJaE1kUut/kQT6PxanFGqz3mV+oiI =zqJh -END PGP SIGNATURE-
Re: [gentoo-dev] Re: robo-stable bugs
On Wed, 22 May 2013 21:07:45 +1000 Michael Palimaka wrote: > Is a stabilisation an enhancement per se? If all stabilisations > are enhancements, then why isn't Severity set to Normal instead? > (What is an enhanced severity to begin with, Mozilla?) > >> > >>> Why are they enhancements? Them having been this way is not a > >>> reason not to change the priority and severity fields to make > >>> more sense. > >> > >> Do you agree that a version bump, i.e. an ebuild entering ~arch is > >> an enhancement? Then why would it be different if the same ebuild > >> gets promoted from ~arch to arch? > > > > Is a version bump an enhancement per se? If all version bumps are > > enhancements, then why isn't Severity set to Normal instead? (What > > is an enhanced version bump to begin with, Mozilla?) > > > What does this statement even mean? It means the same as it meant the first time. Let me ask you the same: What does enhancement even mean? Isn't any bug an enhancement? What is enhancement in the meaning of severity? Who makes up this meaning? Why? How does enhancement instead of normal as a severity help us? Just setting things because we can set them is silly and a time waste... -- 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: robo-stable bugs
On 05/22/13 13:06, Michael Palimaka wrote: > On 22/05/2013 20:41, Thomas Sachau wrote: >> Michael Palimaka schrieb: >>> On 22/05/2013 20:07, viv...@gmail.com wrote: On 05/22/13 11:43, Michael Palimaka wrote: > On 22/05/2013 19:22, viv...@gmail.com wrote: >> On 05/21/13 23:38, Andreas K. Huettel wrote: >>> Am Dienstag, 21. Mai 2013, 15:38:44 schrieb Thomas Sachau: And if a maintainer is not responding within 30 days, you can ping him or, without a response, try to get a different maintainer. Just assuming that a stable request is ok without a maintainer response is really not a good idea. >>> If none of the listed maintainers responds to a bug in 30 days in >>> any way, the >>> package is effectively unmaintained. >>> >> And thus its risky to mark it stable. >> >> > That's why we have arch teams in the first place, to test beforehand. > > The risky part is about the after, not the before, to avoid the risks arch teams should keep the package working *after* it has stabilized. Seem to be a good case for those things that need to be evaluated case by case and could not be written in stone. >>> I am confused as to what you are proposing. Do you want arch teams to >>> continually test packages that are already in stable to make sure they >>> haven't broken somehow? >>> >>> >>> >> The point is probably, that when you stable a package with inactive >> maintainer, there will be noone following the opened bugs against this >> new version. >> >> So this looks like a case, where one should ask for a new maintainer, >> who then decides about the stable versions instead of doing >> auto-stabilization. >> > If the maintainer is inactive, presumably nobody is looking at bugs > for the old version either. > > And the circle is closed since we started with the correlation "no answer to stable bug in 30 days" => "package unmantained" ;-)
[gentoo-dev] Re: robo-stable bugs
On 22/05/2013 21:00, Tom Wijsman wrote: On Wed, 22 May 2013 11:07:26 +0200 Ulrich Mueller wrote: Is a stabilisation an enhancement per se? If all stabilisations are enhancements, then why isn't Severity set to Normal instead? (What is an enhanced severity to begin with, Mozilla?) Why are they enhancements? Them having been this way is not a reason not to change the priority and severity fields to make more sense. Do you agree that a version bump, i.e. an ebuild entering ~arch is an enhancement? Then why would it be different if the same ebuild gets promoted from ~arch to arch? Is a version bump an enhancement per se? If all version bumps are enhancements, then why isn't Severity set to Normal instead? (What is an enhanced version bump to begin with, Mozilla?) What does this statement even mean?
[gentoo-dev] Re: robo-stable bugs
On 22/05/2013 20:41, Thomas Sachau wrote: Michael Palimaka schrieb: On 22/05/2013 20:07, viv...@gmail.com wrote: On 05/22/13 11:43, Michael Palimaka wrote: On 22/05/2013 19:22, viv...@gmail.com wrote: On 05/21/13 23:38, Andreas K. Huettel wrote: Am Dienstag, 21. Mai 2013, 15:38:44 schrieb Thomas Sachau: And if a maintainer is not responding within 30 days, you can ping him or, without a response, try to get a different maintainer. Just assuming that a stable request is ok without a maintainer response is really not a good idea. If none of the listed maintainers responds to a bug in 30 days in any way, the package is effectively unmaintained. And thus its risky to mark it stable. That's why we have arch teams in the first place, to test beforehand. The risky part is about the after, not the before, to avoid the risks arch teams should keep the package working *after* it has stabilized. Seem to be a good case for those things that need to be evaluated case by case and could not be written in stone. I am confused as to what you are proposing. Do you want arch teams to continually test packages that are already in stable to make sure they haven't broken somehow? The point is probably, that when you stable a package with inactive maintainer, there will be noone following the opened bugs against this new version. So this looks like a case, where one should ask for a new maintainer, who then decides about the stable versions instead of doing auto-stabilization. If the maintainer is inactive, presumably nobody is looking at bugs for the old version either.
Re: [gentoo-dev] Re: robo-stable bugs
On Wed, 22 May 2013 11:07:26 +0200 Ulrich Mueller wrote: > > > Is a stabilisation an enhancement per se? If all stabilisations > > > are enhancements, then why isn't Severity set to Normal instead? > > > (What is an enhanced severity to begin with, Mozilla?) > > > Why are they enhancements? Them having been this way is not a reason > > not to change the priority and severity fields to make more sense. > > Do you agree that a version bump, i.e. an ebuild entering ~arch is > an enhancement? Then why would it be different if the same ebuild gets > promoted from ~arch to arch? Is a version bump an enhancement per se? If all version bumps are enhancements, then why isn't Severity set to Normal instead? (What is an enhanced version bump to begin with, Mozilla?) -- 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: robo-stable bugs
Michael Palimaka schrieb: > On 22/05/2013 20:07, viv...@gmail.com wrote: >> On 05/22/13 11:43, Michael Palimaka wrote: >>> On 22/05/2013 19:22, viv...@gmail.com wrote: On 05/21/13 23:38, Andreas K. Huettel wrote: > Am Dienstag, 21. Mai 2013, 15:38:44 schrieb Thomas Sachau: >> And if a maintainer is not responding within 30 days, you can ping >> him >> or, without a response, try to get a different maintainer. Just >> assuming >> that a stable request is ok without a maintainer response is really >> not >> a good idea. > If none of the listed maintainers responds to a bug in 30 days in > any way, the > package is effectively unmaintained. > And thus its risky to mark it stable. >>> That's why we have arch teams in the first place, to test beforehand. >>> >>> >> The risky part is about the after, not the before, to avoid the risks >> arch teams should keep the package working *after* it has stabilized. >> Seem to be a good case for those things that need to be evaluated case >> by case and could not be written in stone. >> >> > I am confused as to what you are proposing. Do you want arch teams to > continually test packages that are already in stable to make sure they > haven't broken somehow? > > > The point is probably, that when you stable a package with inactive maintainer, there will be noone following the opened bugs against this new version. So this looks like a case, where one should ask for a new maintainer, who then decides about the stable versions instead of doing auto-stabilization. -- Thomas Sachau Gentoo Linux Developer signature.asc Description: OpenPGP digital signature
[gentoo-dev] Re: robo-stable bugs
On 22/05/2013 20:07, viv...@gmail.com wrote: On 05/22/13 11:43, Michael Palimaka wrote: On 22/05/2013 19:22, viv...@gmail.com wrote: On 05/21/13 23:38, Andreas K. Huettel wrote: Am Dienstag, 21. Mai 2013, 15:38:44 schrieb Thomas Sachau: And if a maintainer is not responding within 30 days, you can ping him or, without a response, try to get a different maintainer. Just assuming that a stable request is ok without a maintainer response is really not a good idea. If none of the listed maintainers responds to a bug in 30 days in any way, the package is effectively unmaintained. And thus its risky to mark it stable. That's why we have arch teams in the first place, to test beforehand. The risky part is about the after, not the before, to avoid the risks arch teams should keep the package working *after* it has stabilized. Seem to be a good case for those things that need to be evaluated case by case and could not be written in stone. I am confused as to what you are proposing. Do you want arch teams to continually test packages that are already in stable to make sure they haven't broken somehow?
Re: [gentoo-dev] Re: robo-stable bugs
On 05/22/13 11:43, Michael Palimaka wrote: > On 22/05/2013 19:22, viv...@gmail.com wrote: >> On 05/21/13 23:38, Andreas K. Huettel wrote: >>> Am Dienstag, 21. Mai 2013, 15:38:44 schrieb Thomas Sachau: And if a maintainer is not responding within 30 days, you can ping him or, without a response, try to get a different maintainer. Just assuming that a stable request is ok without a maintainer response is really not a good idea. >>> If none of the listed maintainers responds to a bug in 30 days in >>> any way, the >>> package is effectively unmaintained. >>> >> And thus its risky to mark it stable. >> >> > That's why we have arch teams in the first place, to test beforehand. > > The risky part is about the after, not the before, to avoid the risks arch teams should keep the package working *after* it has stabilized. Seem to be a good case for those things that need to be evaluated case by case and could not be written in stone.
[gentoo-dev] Re: robo-stable bugs
On 22/05/2013 19:22, viv...@gmail.com wrote: On 05/21/13 23:38, Andreas K. Huettel wrote: Am Dienstag, 21. Mai 2013, 15:38:44 schrieb Thomas Sachau: And if a maintainer is not responding within 30 days, you can ping him or, without a response, try to get a different maintainer. Just assuming that a stable request is ok without a maintainer response is really not a good idea. If none of the listed maintainers responds to a bug in 30 days in any way, the package is effectively unmaintained. And thus its risky to mark it stable. That's why we have arch teams in the first place, to test beforehand.
Re: [gentoo-dev] robo-stable bugs
On 05/21/13 23:38, Andreas K. Huettel wrote: > Am Dienstag, 21. Mai 2013, 15:38:44 schrieb Thomas Sachau: >> And if a maintainer is not responding within 30 days, you can ping him >> or, without a response, try to get a different maintainer. Just assuming >> that a stable request is ok without a maintainer response is really not >> a good idea. > If none of the listed maintainers responds to a bug in 30 days in any way, > the > package is effectively unmaintained. > And thus its risky to mark it stable.
[gentoo-dev] Re: robo-stable bugs
On 22/05/2013 18:58, Tom Wijsman wrote: On Tue, 21 May 2013 18:57:20 -0600 Ryan Hill wrote: Huh? The severity of the bug is it's an enhancement. Yes stabilizations are enhancements. Always have been. Why are they enhancements? Them having been this way is not a reason not to change the priority and severity fields to make more sense. A newer version of a package is usually considered to be better in some way, hence it is an enhancement. Also, your script does not set the STABLEREQ keyword. People are having to hunt down your robo-stabilisation requests and add it themselves. You should just do it yourself or turn your script off. Did you read the message? The point is you're supposed to add that yourself. It's not a STABLEREQ until you add arches. Yet the base system lead went and apply it to any stabilization bug; as both him and Jer (the bug wrangling lead) do it this way, I'll be doing it as well. Let's not be inconsistent with our leads unless there is a wide decision to do so; I expect none will come, unless you really think this should become Council material. According to the bug-wrangler's own docs[1]: "A stabilisation request should be handled by the package's maintainer, so you should not CC arch teams in your role as bug wrangler, nor set the STABLEREQ keyword in the Keywords field.". There should at least be some consistency there before telling people what to do. As for base system, I don't really see what bearing their actions has to do with anything to on bugzilla. (And let's not forget that the current lead has a history of doing whatever he wants, so I don't think the actions that come out of that are a good example to follow). [1]: http://www.gentoo.org/proj/en/qa/bug-wranglers/
Re: [gentoo-dev] Re: robo-stable bugs
> On Wed, 22 May 2013, Tom Wijsman wrote: > On Tue, 21 May 2013 18:57:20 -0600 > Ryan Hill wrote: >> Huh? The severity of the bug is it's an enhancement. >> >> Yes stabilizations are enhancements. Always have been. > Why are they enhancements? Them having been this way is not a reason > not to change the priority and severity fields to make more sense. Do you agree that a version bump, i.e. an ebuild entering ~arch is an enhancement? Then why would it be different if the same ebuild gets promoted from ~arch to arch? Ulrich
Re: [gentoo-dev] Re: robo-stable bugs
On Tue, 21 May 2013 18:57:20 -0600 Ryan Hill wrote: > Huh? The severity of the bug is it's an enhancement. > > Yes stabilizations are enhancements. Always have been. Why are they enhancements? Them having been this way is not a reason not to change the priority and severity fields to make more sense. > > Also, your script does not set the STABLEREQ keyword. People are > > having to hunt down your robo-stabilisation requests and add it > > themselves. You should just do it yourself or turn your script off. > > Did you read the message? The point is you're supposed to add that > yourself. It's not a STABLEREQ until you add arches. Yet the base system lead went and apply it to any stabilization bug; as both him and Jer (the bug wrangling lead) do it this way, I'll be doing it as well. Let's not be inconsistent with our leads unless there is a wide decision to do so; I expect none will come, unless you really think this should become Council material. -- 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: Making systemd more accessible to "normal" users
On Wed, 22 May 2013 03:06:05 + (UTC) Duncan <1i5t5.dun...@cox.net> wrote: > And a knife or hammer can be used to murder or commit suicide as > well; that doesn't mean they're bad tools, it means the user is > misusing them. The amount of users misusing a knife or hammer is much lower than the amount of users misusing INSTALL_MASK. And even if you want to use it as an example, murdering is only bad when you consider it to be bad. Anyhow, the knife and hammer aren't the best tools around to do it as your target will have a high chance of surviving. Unless you target people that don't defend themselves, all you make is a few scratches. > There's more advanced knives and hammers too, but you don't have to > procure the most expensive one to do the job. You do, because better tools cost more effort. > In some cases, even a heavy screwdriver can be used as a hammer, if > that's what you have in your hand and the hammer's down the ladder in > the toolbox. It's this kind of lazyness that ends up breaking things. > > In other Package managers, I assume this madness isn't supported. > > That might be part of why I don't use other PMs... But other users do, because Portage isn't perfect. > > In its current state, it certainly has its use cases; though it is > > often misused by unaware users that don't know what removal of > > certain files has as a consequence, that means it can do more bad > > than good... > > > > [1]: http://forums.gentoo.org/viewtopic-t-670094.html > > First INSTALL_MASK I came across searching for it online, > > particularly masking *.h, *.pc and Makefile* are very bad > > ideas. > > Did you read the use case? He is (was, that was 2008) doing the > builds for his 2GB drive netbook on different build system, then > doing binpkg installs on the netbook. In that case, INSTALL_MASKING > those filetypes for installation to the netbook, where he has no > intention of doing any building anyway, makes quite a lot of sense. A good lesson is that people don't actually read all that stuff, those that are looking for values for INSTALL_MASK will often just try it for themselves only to see these dangerous values fail and start bothering them. Or they may not know it's because of their INSTALL_MASK that they need to reinstall their system some time later. Historically, ricing other settings like the CFLAGS in make.conf is a quite good example of why this file is a red herring; it took quite some time for the concept of SAFE CFLAGS to get some attention. That's why SAFE INSTALL MASKS is amongst one of the suggestions I made in the earlier reply; people on an embedded profile could mask these files, other people cannot unless they _explicitly_ unmask the ability to mask. > In fact, I have a netbook (tho it has a much larger 100+ gig drive) > and could use the idea myself (altho currently I don't run a PM at > all on the netbook, instead rsyncing from the build image on the main > machine, so I'd have to modify his use case... or mine... somewhat). Not running a PM makes this paragraph irrelevant to this discussion. > As for people misusing the available tools, gentoo has always taken > the position that we make the tools available and document how to use > them, but we aren't a babysitting or handholding distro, and if > handholding is what people want/need, they better look elsewhere as > gentoo's simply not in that market, and doesn't pretend to be. We do babysitting / handholding where we can, the _right_ amount of it. Not bringing out news or supporting people with the udev upgrade, that would've cost us people; not working on options that make systemd work, that would've cost us people. Not pointing to solutions for the recent automake errors / genkernel blocker, that would've cost us people. Let's not sacrifice part of our user base by taking a wrong decision; developing a distro goes much further than "let's just use this hack", until multiple people agree a hack to be the best short term solution. Go consistently make the worst tools available, we'll talk again then. -- 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
