Re: [gentoo-dev] [RFC] QA Team's role
Am Mittwoch, 1. März 2006 08:21 schrieb Jakub Moc: 28.2.2006, 16:31:26, Ciaran McCreesh wrote: On Tue, 28 Feb 2006 16:17:20 +0100 Paul de Vrieze [EMAIL PROTECTED] | On Tuesday 28 February 2006 15:52, Ciaran McCreesh wrote: | Yes, it's an utterly trivial problem, but it is a QA violation. | Getting a complete list is something that takes a heck of a lot | longer, and I have yet to be convinced that my time would not be | better spent elsewhere. | | Where is a coding style problem related to quality of code in general | and assurance in particular? It's more relevant than you might think. Screwing up layout like that breaks various QA checking tools that assume that things are in the standard format. A tool that chokes on coding style (like tabs and whitespaces) should be ifself fixed. Hmm, you never used repoman, right? repoman checks for whitespace and tab oddities and warns you, if you want to commit them. Danny -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tuesday 28 February 2006 21:20, Ciaran McCreesh wrote:
On Tue, 28 Feb 2006 20:09:02 +0100 Jakub Moc [EMAIL PROTECTED] wrote:
| 28.2.2006, 18:38:10, Ciaran McCreesh wrote:
| Sheesh, you'll probably claim that this isn't broken next too:
|
| if [ ${IS_UPGRADE} = 1 ] ; then
| einfo Removing old version ${REMOVE_PKG}
|
| emerge -C ${REMOVE_PKG}
| fi
|
| No, I won't claim that... I'd rather love to know why didn't you
| point out to an obvious eclass flaw about 30 emails and many hours
| ago, saving us from all the eclass formating, slotting and ewarn
| blurb.
Why didn't you look before accusing me of not having valid issues? I
mean, it's pretty frickin' hard to miss that one.
This code (or an equivalent kludge/hack) does however allow features that are
of great value to our users. While I agree that such hacks should be avoided
if possible, I think in this case it is not. As such the appropriate response
is to isolate the hack in a central place, where it is clear to be seen and
can easilly be fixed. This allows the quality of the hack to be ensured,
relieving many webapps from doing hacks themselves.
While this hack is being used, some effort should be put into constructively
creating a proper solution for the problems that were hacked around. Saying
this is not allowed because of X policy is not helpful as the costs of
disallowing it greatly outweigh the costs of overlooking it in a controlled
manner.
Paul
--
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net
pgpycg6fljZy3.pgp
Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Wednesday 01 March 2006 00:08, Mike Frysinger wrote: dont get me wrong, i wasnt implying that bugs shouldnt be filed ... i was addressing the incorrect idea that it isnt a valid QA issue unless a user experiences it and complains via bugzilla I agree with this. I would however also like to ask QA to allow exceptions to policy for well-discussed reasons. Sometimes ugly hacks are needed, and as long as they are understood to be ugly, they must not be banned outright. I don't think it is a problem if those issues have LATER bugs on them blocking on some feature request bug. I can even agree with it that a feature request bug must be written for such a hack to be allowed. With respect to webapp-config. I know it's ugly, I know it does perform jobs that should be performed by portage. Portage however doesn't, and webapp-config does provide valuable features for many users. As such, as long as portage does not offer the features that webapp-config provides, I am of the opinion that the webapp.eclass should be allowed to use minimal hacks to provide the webapp features. QA's role in this case is to ensure that no hacks are added, and to signal it when the hacks break. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpmUo9k4oCyD.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tuesday 28 February 2006 16:31, Ciaran McCreesh wrote: On Tue, 28 Feb 2006 16:17:20 +0100 Paul de Vrieze [EMAIL PROTECTED] wrote: | On Tuesday 28 February 2006 15:52, Ciaran McCreesh wrote: | Yes, it's an utterly trivial problem, but it is a QA violation. | Getting a complete list is something that takes a heck of a lot | longer, and I have yet to be convinced that my time would not be | better spent elsewhere. | | Where is a coding style problem related to quality of code in general | and assurance in particular? It's more relevant than you might think. Screwing up layout like that breaks various QA checking tools that assume that things are in the standard format. Then fix the damn tools. I've had runins with broken tools earlier. If you want the ebuild format to be stricter, well, make portage complain. Otherwise, fix up your parser. Proper coding style is part of being proper. Coding style issues exist in degrees. White space issues such as these are of very low priority. Broken QA tools should not be an excuse to give them higher priority. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpOKGomfGnJi.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
Ciaran McCreesh wrote:
On Tue, 28 Feb 2006 18:30:24 +0100 Jakub Moc [EMAIL PROTECTED] wrote:
| OK, so kernel-2.eclass is abusing the slot as well, go scream on
| kernel devs.
No. kernel-2 installs sources, not an actual package.
Not exactly. The webapp stuff gets installed to /usr/share/webapps/${PN}/${PVR},
which is about the equivalent of /usr/src/linux because you will never point
your webserver to that directory. If you do, you're just dumb and deserve a
security flaw. webapp-config installs the packages to /var/www (equivalent of
/boot), where the webserver should make it available. So the SLOT=${PVR} is
not an issue in this case.
--
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Wednesday 01 March 2006 02:37, Jakub Moc wrote: 28.2.2006, 16:29:10, Ciaran McCreesh wrote: The whole devrel handbook is policy, except where otherwise noted. See Mike's reply. Then any significant change there requires a sane procedure. which does not change the fact that the devrel handbook is policy unless otherwise noted as suggestion or guideline -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
Stephen P. Becker wrote: Grant Goodyear wrote: Ciaran McCreesh wrote: My point is that that's a nasty QA bug that's relying upon input from Stuart to be fixed. Whilst that one's still alive, I'm not going to go around filing more similar breaks non-interactively bugs because the discussion will just get repeated over and over. Huh? I just read through the bug, and it actually appears to be resolved pending Chris' testing w/ the needed USE flags added to the various profiles. I'll admit that the fix is inelegant, but I'm missing where it's waiting upon Stuart for additional info. Am I missing something? Yes, you are missing that the bug really isn't fixed. There are still USE combinations which would be otherwise perfectly valid, but which cause php to fail to emerge, thus reaking non-interactivity and forcing people to (ab)use /etc/portage/package.use to get things working properly. -Steve The bug is about *default* use flags breaking interactivity. There are donzens of packages that die in pkg_setup if incorrect USE flags are sepcified, because use-dependencies are not implemented. I don't believe anyone is trying to enforce interactivity in that case, because as far as I'm aware there is no workaround present. -Alec Warner signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] QA Team's role
On Monday 27 February 2006 16:12, Stuart Herbert wrote: On Mon, 2006-02-27 at 20:54 +, Ciaran McCreesh wrote: Whilst that one's still alive, I'm not going to go around filing more similar breaks non-interactively bugs because the discussion will just get repeated over and over. This point is another example of an attempt to enforce an undocumented QA policy the non-interactive rule has never been stated, just hinted at for example, the dev handbook mentions offhand: * Testing the package Please keep in mind the general requirements of an ebuild here. The src_test routine must not be interactive. if you like i can rectify this situation in the Ebuild policy guide -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, 27 Feb 2006 21:12:22 + Stuart Herbert [EMAIL PROTECTED] wrote: On Mon, 2006-02-27 at 20:54 +, Ciaran McCreesh wrote: My point is that that's a nasty QA bug that's relying upon input from Stuart to be fixed. I'm afraid you've been mis-informed. The PHP herd has provided a set of default USE flags to go into the profiles, and there's a comment at the bottom of the bug clearly stating that they're currently being tested. That's not a fix. That's a workaround. The PHP ebuilds are still broken; all that's changed is that the breakage isn't apparent on a default install. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, 27 Feb 2006 21:49:23 +0100 Jakub Moc [EMAIL PROTECTED] wrote: | rhetorical question | May I ask how is that related to webapp-config? | /rhetorical question It is related to Stuart, and hence utterly relevant to the conversation. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, Feb 27, 2006 at 05:30:27PM +, Stephen Bennett [EMAIL PROTECTED] wrote: (Yes, I'm taking that sentence out of context, but the fact that it comes up at all says something, to my mind.) Your mind is a dark and twisted place! -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgpcif7cymuGN.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
Stephen P. Becker wrote: Grant Goodyear wrote: Ciaran McCreesh wrote: My point is that that's a nasty QA bug that's relying upon input from Stuart to be fixed. Whilst that one's still alive, I'm not going to go around filing more similar breaks non-interactively bugs because the discussion will just get repeated over and over. Huh? I just read through the bug, and it actually appears to be resolved pending Chris' testing w/ the needed USE flags added to the various profiles. I'll admit that the fix is inelegant, but I'm missing where it's waiting upon Stuart for additional info. Am I missing something? Yes, you are missing that the bug really isn't fixed. There are still USE combinations which would be otherwise perfectly valid, but which cause php to fail to emerge, thus reaking non-interactivity and forcing people to (ab)use /etc/portage/package.use to get things working properly. Well, I did say that it was an inelegant fix In any event, I appreciate your response about php brokenness (I'll come back to this below), but does this php brokenness require additional info from Stuart to fix? Let me try breaking things down a bit to see if I can understand the various specific problems: 0. Stuart and Ciaranm (and Jakub and Ciaranm) don't like each other very much. *Shrug* That's not really a problem, it just means that one needs hip-waders to get through all of the muck. No big deal; that's part of being a dev with a really large project. 1. A fresh Gentoo install w/ default USE flags will fail to compile dev-lang/php. That one is being solved by adding some additional USE flags to the default profile. The claim from the php team is that the correct fix is a version of portage with USE-based dependencies. The QA folks would prefer to see the php ebuild implement a set of sane defaults to prevent breakages, instead, if I understand correctly, which in practice would mean that the ebuild would detect whether or not deps were built with the correct USE flags, and work around any broken deps in the ebuild. (I must be missing something, since the latter strikes me as notably _bad_, since it would mean that two people with identical USE flags would get different outcomes depending on how their dependencies are built.) 2. There are a variety of otherwise-valid USE-flag combinations that will cause php to fail to build (or be otherwise unusable). That's hardly surprising, since dev-lang/php has ~100 USE flags, which means ~2**100 (~10**30) possible USE-flag combinations. Let's see, there are roughly pi*10**7 seconds per year, so if we could test one build of php per second it would only take considerably longer than the lifetime of the universe to test all of the possible combinations. Clearly QA of the current ebuild has to be rather illusory. Do we have a bug open about this? Are there any reasonable suggestions on how to fix it? I do realize that the problem is complicated by the fact that people really do use fairly esoteric php builds on production machines. That said, the current situation really is a nightmare! 3. There are a number of people (not just ciaranm) who consider the webapp idea to be brilliant in concept, but horribly flawed in its execution. (I'm personally fairly agnostic, although the one time that I had to create a webapp-enabled ebuild I found the process to be incredibly confusing. I just assumed that with great flexibility comes great pain.) However, I've never known precisely why people feel that way, and I can't find any bugs about it, so perhaps we could have a real debate about this issue? I don't think that bug #120088 is it. -g2boojum- signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] QA Team's role
On Monday 27 February 2006 18:15, Ciaran McCreesh wrote: On Mon, 27 Feb 2006 10:47:58 -0600 Lance Albertson [EMAIL PROTECTED] wrote: | So if the maintainer sticks SANDBOX_DISABLE=1 rm -fr / in global | scope and refuses to move it, QA will have to get council approval | to fix it? | | Use some common sense when showing an example please. We all know | that something that stupid needs to be delt with quickly. If we all recognise that level of stupidity, please explain how the heck this got into the tree: http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/sys-apps/bootstrap _cmds/bootstrap_cmds-44.ebuild?rev=1.1content-type=text/plain Probably because although it isn't a good ebuild it still works and does not violate the sandbox. While it does things in the wrong way/place it does not do the wrong things. I do not think that anyone would argue against QA (or other developers) fixing urgent big tree breakages. (and rm -rf / would certainly qualify). What I see as the argument is that QA should show a degree of flexibility in it's policies, and not just enforce because of the policy. This especially in those cases where there is no way to provide the ebuild without breaking policy, or doing so would mean a greater inconvenience to the users. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpAaY4gCI1d4.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Monday 27 February 2006 21:37, Ciaran McCreesh wrote: | You know where bugzilla is. You know how to contact any of the | webapp-config maintainers via email, or via IRC. We're ready to | listen to your input, and to work with you (or anyone else) on fixing | any genuine problems that webapp-config has. The more feedback we | get, the better we can make this package for everyone's enjoyment. Then please start with bug 120088. Once that one's fixed we'll go from there. While that bug explains your issues with the webapp people in general and stuart in particular it is not related to webapp-config at all. Looking at that bug, and the issues discussed in this thread I do get to the point where I feel that instead of buggering people about packages, it would perhaps be better to get those features into portage whose absense causes the problems. The quality of the distribution would be better suited with a portage that supports USE-flag dependencies, dependencies between useflags in a package, sourcefile renaming / DIST_PREFIX, etc. Once that is supported, I'm also sure that those people involved will be more than happy to fix their ebuilds to use those features. I do agree with them though that the distribution should not be held back by missing features in portage. Especially since those features have been missing (recognized as such) for ages. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp7Sy1ZWbKjB.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Monday 27 February 2006 19:19, Ciaran McCreesh wrote: On Mon, 27 Feb 2006 12:05:58 -0600 Grant Goodyear [EMAIL PROTECTED] wrote: | Of course, that leaves the question of who decides on the severity of | a QA violation? All this talk of severity, and no talk of ease of detection or ease of fixing... Allow me to explain. There are certain not particularly high impact issues that can very easily be detected, and with 100% reliability, by The Thing About Which We Do Not Talk. Any individual one of these doesn't look like such a big deal, but when we're talking a couple of hundred instances, all of which can easily be fixed in less overall time than it would take to even detect one instance of a particular severe problem, it's most definitely worth concentrating on the 'easy' issue. I understand this point, but by your own admission, they are not particularly high impact. In the case at hand, the particular issue does however conflict with other goals. What I think would be reasonable is to expect that you are not going to be able to solve 100% of the easilly detectable issues. So, I think that while you continue to run the tests on these packages, you maintain a list of exceptions, including the reason for them being exceptions. Besides, work on finding solutions to the problems behind it. But do not choose the greater evil (removing or blocking a package) before the lesser evil (keeping a package with well-documented issues). In this respect I would like to propose that each package that has these issues related to missing portage features, ensures that a related bug is created for portage requesting that feature/a solution for the fundamental problem. This bug should be marked as blocker for the package related bugs in this respect. That way we can keep account of which features in portage are needed for which packages. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpunHQXZmc9Y.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
You still haven't posted posted a *single example* of webapp-config brokeness. You, I'd say you should either back up claims about all the ways in which webapp-config is broken or apologize to the concerned developers for false claims. Still waiting. OK, here is one. It seems that webapp-config silently assumes your webserver is apache by default. If a user uses lighttpd for example, this is totally incorrect. Now, this doesn't cause webapp-config to fail to emerge, but the first time you emerge any webapp, you get a big nasty error about no Apache group available, which further requires the end user to dig around the webapp-config manpage to figure out the correct file to edit *just* to get a silly php script to install in the correct location. And please, don't tell me this is a feature. It breaks noninteractivity for every webapp in the entire tree. -Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
webapp-config should be updated to handle such situation more gracefully, so why don't you file a bug about this? Is that all you have wrt all the ways in which webapp-config is broken? If so, that's not really much of a justification of the broad claim ciaranm has made as a QA project member. I only encountered the problem the day before yesterday, and hadn't gotten around to filing the bug yet. I assure you that I intend on doing so. And please, don't tell me this is a feature. It breaks noninteractivity for every webapp in the entire tree. What kind of non-interactivity? What's this universal non-interactivity blurb of yours and ciaranm's about? There's no such thing when it comes to configuration. If you want automated configuration, then please use Windows and stop moaning. If you don't want to read manpages or at least --help, then please use Windows as well. If you want to use non-default setup, then you need to change default values, that's what common sense dictates at least. And don't use the (non)-interactivity magical formular in a context where it has zero sense. No! You are completely missing the point. The non-interactivity of which we speak is the idea that when you emerge some package, it is perfectly reasonable (and in fact should be required) to expect that package to install to your userland with no further prodding. There should be no USE collisions which cause the emerge to die. There should be no default configuration which will break other packages in the tree by default. Note that in no way am I talking about auto-configuration, as that would be silly. The example problem with webapp-config which I have described here forces a user to intervene to get packages to install to the proper location. This is not desirable. Basically, I really don't see why webapp-config can't have some logic built in which makes it smart enough to figure out which webserver somebody is using. -Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On 2/28/06, Stephen P. Becker [EMAIL PROTECTED] wrote: OK, here is one. It seems that webapp-config silently assumes your webserver is apache by default. If a user uses lighttpd for example, this is totally incorrect. Now, this doesn't cause webapp-config to fail to emerge, but the first time you emerge any webapp, you get a big nasty error about no Apache group available, which further requires the end user to dig around the webapp-config manpage to figure out the correct file to edit *just* to get a silly php script to install in the correct location. There's no need to be rude about php scripts. Thank you for reporting this error. We've committed a fix for this problem upstream. We'll probably roll out w-c 1.5.11 at the weekend. That'll give us suitable time to test this, and to incorporate the QA issues from Ciaran that we're still waiting for. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tuesday 28 February 2006 04:49, Jakub Moc wrote: No, that's not a policy document, ebuild policy is documented here: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?style=printable; part=3chap=1 so what, you want us to duplicate everything in one document and place it in the other just because one has the title Policy ? that's retarded the dev handbook documents proper ebuild development regardless of the title on a particular page -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 10:49:13 +0100 Jakub Moc [EMAIL PROTECTED] wrote: | No, that's not a policy document, ebuild policy is documented here: | http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?style=printablepart=3chap=1 No, the whole thing is policy. | Moreover, the cited howto is wrong, since it will break built_with_use | checks No, that's a separate issue. | The howto also doesn't apply to cases like | recode vs. mysql, because that's a completely different | functionality, you can't exactly choose which one is better on behalf | of the user. No, it does apply. | So, to sum it up - you can't make up for portage's lack of features by | inventing a policy that doesn't work. Once again - until portage can | handle USE-based dependencies and until portage can handle | conflicting use flags, there's nothing that could be done here. Until Portage can handle conflicting USE flags, one should take the policy-mandated solution that has been sufficient for everyone else for four years or more. Sure, it's not perfect, but it's a hell of a lot better than repeatedly exploding in the user's face midway through an install. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 14:21:14 + Stuart Herbert [EMAIL PROTECTED] wrote: | We've committed a fix for this problem upstream. We'll probably roll | out w-c 1.5.11 at the weekend. That'll give us suitable time to test | this, and to incorporate the QA issues from Ciaran that we're still | waiting for. It's going to take longer than that for me to get you a full, properly explained list of every QA issue I can find. Now, I *could* give you the shorter list of stuff I noticed within half an hour of using it, but I'd rather get this done properly if I'm doing it at all. I'm still not convinced that it's worth my while, however, based upon your past attitude of claiming it's a feature. My time could better be spent helping out developers who will actually fix their breakages. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 11:34:49 +0100 Paul de Vrieze [EMAIL PROTECTED] wrote: | Once that is supported, I'm also sure that those people involved will | be more than happy to fix their ebuilds to use those features. I do | agree with them though that the distribution should not be held back | by missing features in portage. Especially since those features have | been missing (recognized as such) for ages. So until then, it's perfectly OK to screw over our users and fellow developers by committing any arbitrary mess to the tree and claiming that it's alright because Portage doesn't offer a perfect alternative? -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 11:21:23 +0100 Paul de Vrieze [EMAIL PROTECTED] wrote: | http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/sys-apps/bootstrap | _cmds/bootstrap_cmds-44.ebuild?rev=1.1content-type=text/plain | | Probably because although it isn't a good ebuild it still works and | does not violate the sandbox. While it does things in the wrong | way/place it does not do the wrong things. Huh? It violates the sandbox even if you do 'emerge sync' and never touch the ebuild. Look at the frickin' mkdir! -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 10:38:17 +0100 Jakub Moc [EMAIL PROTECTED] wrote:
| You still haven't posted posted a *single example* of webapp-config
| brokeness. You, I'd say you should either back up claims about all
| the ways in which webapp-config is broken or apologize to the
| concerned developers for false claims.
Fine. If posting a single way in which webapp-config is broken will
make you happy, here you go:
From webapp.eclass:
function webapp_read_config ()
{
This is a whitespace / coding style breakage. The correct format should
be:
webapp_read_config() {
Yes, it's an utterly trivial problem, but it is a QA violation. Getting
a complete list is something that takes a heck of a lot longer, and I
have yet to be convinced that my time would not be better spent
elsewhere.
--
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On 2/28/06, Ciaran McCreesh [EMAIL PROTECTED] wrote: I'm still not convinced that it's worth my while *You* chose to mention webapp-config in this thread. Stop making excuses. Make good on your claims. Put up, or shut up. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tuesday 28 February 2006 15:48, Ciaran McCreesh wrote: On Tue, 28 Feb 2006 11:21:23 +0100 Paul de Vrieze [EMAIL PROTECTED] Huh? It violates the sandbox even if you do 'emerge sync' and never touch the ebuild. Look at the frickin' mkdir! Hmm. Didn't realise that the sandbox is more restrictive in those cases (and that the ebuild is sourced then). The mkdir in toplevel is of course wrong. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpNV2fAU2YPC.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tuesday 28 February 2006 15:00, Stephen P. Becker wrote: Basically, I really don't see why webapp-config can't have some logic built in which makes it smart enough to figure out which webserver somebody is using. Please remember that the apache group is just another name for httpd group. And it is not linked to the apache webserver. Perhaps the group should be renamed, and webapp-config should require it's presence when it is installed. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpYDF9EeiOEr.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 2006-02-28 at 14:52 +, Ciaran McCreesh wrote:
On Tue, 28 Feb 2006 10:38:17 +0100 Jakub Moc [EMAIL PROTECTED] wrote:
| You still haven't posted posted a *single example* of webapp-config
| brokeness. You, I'd say you should either back up claims about all
| the ways in which webapp-config is broken or apologize to the
| concerned developers for false claims.
Fine. If posting a single way in which webapp-config is broken will
make you happy, here you go:
From webapp.eclass:
function webapp_read_config ()
{
This is a whitespace / coding style breakage. The correct format should
be:
webapp_read_config() {
Yes, it's an utterly trivial problem, but it is a QA violation. Getting
a complete list is something that takes a heck of a lot longer, and I
have yet to be convinced that my time would not be better spent
elsewhere.
Wow. That is ... impressive. After about two days of asking for any real
bugs you are able to show a trivial syntax issue?
Please stop yelling it si teh b0rk! if you can't even list any serious
issues, and stop being rude to other people.
Thanks,
Patrick
--
Stand still, and let the rest of the universe move
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, Feb 28, 2006 at 02:52:46PM +, Ciaran McCreesh wrote: Yes, it's an utterly trivial problem, but it is a QA violation. Getting a complete list is something that takes a heck of a lot longer, and I have yet to be convinced that my time would not be better spent elsewhere. So let me get this straight. You have been claiming that webapp-config is broken, to put it mildly, for quite some time (at least several months). Yet as of now, you are unable to tell us what exactly is wrong. When I asked you on IRC for feedback, you referred me to a private conversation with Stuart, which is just as useless as the rest of your comments. You have not filed a single bug or sent a single email to the maintainers. Your only relevant QA point is a trivial style issue. Your blathering is insulting to the people who actually spend time trying to improve webapp-config. No, it's not perfect. But we want to make it better, and we have asked you for feedback and got none. You, ciaranm, create measurable deadweight loss. Instead of doing productive work, I waste my time replying to your nonsense. I am fed up and will be taking the issue to devrel. -- Renat Lumpau all things web-apps C6A838DA 04AF B5EE 17CB 1000 DDA5 D3FC 1338 ADC2 C6A8 38DA America - land of the free* *Void where prohibited, restrictions apply. Cash value 1/100c. pgpmuYgynOwx3.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tuesday 28 February 2006 15:47, Ciaran McCreesh wrote: On Tue, 28 Feb 2006 11:34:49 +0100 Paul de Vrieze [EMAIL PROTECTED] wrote: | Once that is supported, I'm also sure that those people involved will | be more than happy to fix their ebuilds to use those features. I do | agree with them though that the distribution should not be held back | by missing features in portage. Especially since those features have | been missing (recognized as such) for ages. So until then, it's perfectly OK to screw over our users and fellow developers by committing any arbitrary mess to the tree and claiming that it's alright because Portage doesn't offer a perfect alternative? No, not in an arbitrary way. Those fixes should be discussed, and the path of least problems chosen. Waiting on portage to catch on however has shown to be a dead end. One of the reasons that webapp-config was developed is exactly because of the fact that portage does not offer certain features (although I don't know whether portage should offer these). What I mean is that if portage is a limiting factor, we should try to find a solution that allows incorporation of the package or feature instead of not having it. Doing so is only alright when it has been properly discussed. It is not alright to just introduce mess. There is indeed no strict line between the two. That's where QA comes in. To make the judgement. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpY0jenv87fX.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 16:17:20 +0100 Paul de Vrieze [EMAIL PROTECTED] wrote: | On Tuesday 28 February 2006 15:52, Ciaran McCreesh wrote: | Yes, it's an utterly trivial problem, but it is a QA violation. | Getting a complete list is something that takes a heck of a lot | longer, and I have yet to be convinced that my time would not be | better spent elsewhere. | | Where is a coding style problem related to quality of code in general | and assurance in particular? It's more relevant than you might think. Screwing up layout like that breaks various QA checking tools that assume that things are in the standard format. | QA is about things being proper, not looking proper. Proper coding style is part of being proper. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 16:26:37 +0100 Jakub Moc [EMAIL PROTECTED] wrote:
| If you can't do any better, then please apologize for your conduct
| and false claims and shut up... TIA.
Sure I can do better. But you didn't originally ask for better, you
asked for anything. If better's what you're after:
SLOT=${PVR}
Now, please apologise for insinuating that I don't have any real claims
to make. I find it extremely offensive that you're questioning my
technical ability.
--
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 16:08:05 +0100 Jakub Moc [EMAIL PROTECTED] wrote: | 28.2.2006, 15:39:40, Ciaran McCreesh wrote: | On Tue, 28 Feb 2006 10:49:13 +0100 Jakub Moc [EMAIL PROTECTED] | wrote: | | No, that's not a policy document, ebuild policy is documented | | here: | | | http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?style=printablepart=3chap=1 | | No, the whole thing is policy. | | No, it isn't. 'Fraid it is. Everything in the devrel handbook that isn't explicitly marked as a guideline is policy. | And silently sticking parts of unofficial gentoo | devmanual into official Gentoo docs, and then silently turning them | into a policy enforced under QA disguise is a bad very practice, | and pretending that this has been in the mentioned _howto_ (not | policy) for a long time as just plain silly. Since you haven't | answered the question in one of my previous emails at all, let me ask | again: | | When and where has been the following change discussed and who | approved that? | | http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?r1=1.25r2=1.26root=gentoo Wouldn't know. That was nothing to do with me. I just wrote the original text (or actually, that might not even have been me). It finding its way into the policy docs was devrel's doing. | | Moreover, the cited howto is wrong, since it will break | | built_with_use checks | | No, that's a separate issue. | | No, it isn't. If you want something to have as a policy, it needs to | be error-free, reasonably applicable and not doing more harm than if | it isn't applied at all. And implementing such stuff requires a | proper discussion, considering the consequences and some sort of | consent among affected developers. (Also, that howto example is less | than fortunate/clear, like some user noted in Bug 124401). built_with_use isn't a question of conflicting USE flags. It's a separate question of dependency resolution, and in this situation it *can't* be solved using the method that's been standard for four years or more. | | The howto also doesn't apply to cases like | | recode vs. mysql, because that's a completely different | | functionality, you can't exactly choose which one is better on | | behalf of the user. | | No, it does apply. | | No, it doesn't, you can't reasonably favour one of two completely | different functionalities based on some automagic | assumption/developer discretion. That doesn't benefit users in any | way and just produces unexpected results (hey, I explicitely enabled | recode use flag and php compiled without, the ebuild is broken, | fix0r it!) By all means warn the user. There's nothing in policy disallowing that. | No, noone should enforce a policy that | | - doesn't exist (see above) The whole devrel handbook is policy, except where otherwise noted. See Mike's reply. | - hasn't been discussed properly and approved (see above) Nothing in the devrel handbook was discussed properly or approved. | - it's consequences haven't been considered wrt whether its benefits | overweight the negatives and whether is useful at all. This one doesn't rule out the policy item in question. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Monday 27 February 2006 11:47, Lance Albertson wrote: Ciaran McCreesh wrote: On Sun, 26 Feb 2006 17:53:20 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | The maintainer should be the absolute authority over his/her packages, | and only the council should be able to overrule maintainer decisions | in the case of disagreement between the maintainer and anybody else. So if the maintainer sticks SANDBOX_DISABLE=1 rm -fr / in global scope and refuses to move it, QA will have to get council approval to fix it? Use some common sense when showing an example please. We all know that something that stupid needs to be delt with quickly. we've had at least one ebuild do stuff in /tmp in global scope ... of course that was a mistake the dev felt really bad about and it was fixed once noticed, so not sure this is an appropriate example ;) -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tuesday 28 February 2006 10:08, Jakub Moc wrote: 28.2.2006, 15:39:40, Ciaran McCreesh wrote: On Tue, 28 Feb 2006 10:49:13 +0100 Jakub Moc [EMAIL PROTECTED] wrote: | No, that's not a policy document, ebuild policy is documented here: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?style=printabl epart=3chap=1 No, the whole thing is policy. No, it isn't. yes, it is ... that's the point of the handbook -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 16:42:30 +0100 Jakub Moc [EMAIL PROTECTED] wrote: Punting every single piece of broken sh*t from the tree requires notifying everyone on -dev ml and allowing a period of time before it's actually done, so silently changing/stating policies is a very broken practice. This wasn't a silent change. It's been policy for as long as I can remember; it was just made explicit in the devrel documentation with that commit. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 2006-02-28 at 15:42 +, Ciaran McCreesh wrote:
On Tue, 28 Feb 2006 16:26:37 +0100 Jakub Moc [EMAIL PROTECTED] wrote:
| If you can't do any better, then please apologize for your conduct
| and false claims and shut up... TIA.
Sure I can do better. But you didn't originally ask for better, you
asked for anything. If better's what you're after:
SLOT=${PVR}
Now, please apologise for insinuating that I don't have any real claims
to make. I find it extremely offensive that you're questioning my
technical ability.
Ok, sorry for being dumb :-)
What exactly is the issue there? I don't see the issue in setting SLOT
depending on ... uhm ... some variable. Looks kinda logical at first
glance, but I'm not aware of the issues it causes.
Thanks for explaining,
Patrick
--
Stand still, and let the rest of the universe move
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 17:11:58 +0100 Patrick Lauer [EMAIL PROTECTED] wrote: | Ok, sorry for being dumb :-) | What exactly is the issue there? I don't see the issue in setting SLOT | depending on ... uhm ... some variable. Looks kinda logical at first | glance, but I'm not aware of the issues it causes. PVR includes the revision of an ebuild. This means that if a revbump is made on a webapp package to fix a critical flaw, users will still have the old broken package installed too. This is especially relevant for security issues, but also applies to other kinds of fix. Ebuilds can't override this either. Read on in the eclass and you'll notice that it checks that SLOT hasn't been changed to something sane. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 17:22:57 +0100 Jakub Moc [EMAIL PROTECTED] wrote:
| Eh? Seen kernel2.eclass? Going to file a bug about that as well? Seen
| gst/gstreamer eclasses? Going to file QA bugs about them as well? And
| - what's exactly the QA violation there, if you could enlighten us?
You're misunderstanding the issue. See my explanation to Patrick.
I don't see the same kind of mistake in gst-plugins.eclass, assuming
you're referring to SLOT=${PV_MAJ_MIN} . And kernel-2 is a special
case, since it's not installing an actual program -- this one's been
explained in depth in the past on various lists. If you can point out
any genuine SLOT screwups that I've missed then I'll work to get those
fixed.
| Maybe I could point you to
| http://dev.gentoo.org/~plasmaroo/devmanual//general-concepts/slotting/ ?
Uh... I know how slotting works. I wrote that page, remember?
--
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, Feb 28, 2006 at 05:11:58PM +0100, Patrick Lauer wrote: Ok, sorry for being dumb :-) What exactly is the issue there? I don't see the issue in setting SLOT depending on ... uhm ... some variable. Looks kinda logical at first glance, but I'm not aware of the issues it causes. One issue here is that security revbumps are no longer effective in that the vulnerable version remains installed and must be unmerged manually by the sysadmin. I started a discussion about this very same issue yesterday on -web-user and we hope to resolve it shortly. -- Renat Lumpau all things web-apps C6A838DA 04AF B5EE 17CB 1000 DDA5 D3FC 1338 ADC2 C6A8 38DA America - land of the free* *Void where prohibited, restrictions apply. Cash value 1/100c. pgpIiKs7bJd1b.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, Feb 28, 2006 at 04:35:32PM +, Ciaran McCreesh wrote: Ebuilds can't override this either. Read on in the eclass and you'll notice that it checks that SLOT hasn't been changed to something sane. Excepting that you can set WEBAPP_MANUAL_SLOT=yes and set SLOT to whatever the hell you want. But don't let my facts get in the way of your nonsense. -- Renat Lumpau all things web-apps C6A838DA 04AF B5EE 17CB 1000 DDA5 D3FC 1338 ADC2 C6A8 38DA America - land of the free* *Void where prohibited, restrictions apply. Cash value 1/100c. pgpWvP0y62A0D.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 18:00:03 +0100 Jakub Moc [EMAIL PROTECTED] wrote: | PVR includes the revision of an ebuild. This means that if a | revbump is made on a webapp package to fix a critical flaw, users | will still have the old broken package installed too. This is | especially relevant for security issues, but also applies to other | kinds of fix. | | Not including the revision into the SLOT can break the apps by | removing the needed files from a live site... I still can't see any | *QA* violation there. Again, that's a design flaw. It's an eclass that's abusing SLOT, thus it's a QA issue. | Yeah, it checks for that since that's the way the eclass is designed. | You can't declare a slot in a kernel ebuild either. One is a design flaw. The other is not. | Well, starts to be boring - so, either come with something valid from | QA standpoint or stop now. This is a valid issue from a QA standpoint. This is also why I'm not going to waste my time doing a proper list -- rather than addressing issues, they are being passed off as irrelevant or even features. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 17:02:11 + Renat Lumpau [EMAIL PROTECTED] wrote: | On Tue, Feb 28, 2006 at 04:35:32PM +, Ciaran McCreesh wrote: | Ebuilds can't override this either. Read on in the eclass and you'll | notice that it checks that SLOT hasn't been changed to something | sane. | | Excepting that you can set WEBAPP_MANUAL_SLOT=yes and set SLOT to | whatever the hell you want. But don't let my facts get in the way of | your nonsense. And it sticks out a nasty ewarn and says that the ebuild is probably broken. Again, you're dismissing QA issues as nonsense, and you wonder why I don't waste my time doing a full audit. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, Feb 28, 2006 at 05:11:57PM +, Ciaran McCreesh wrote: And it sticks out a nasty ewarn and says that the ebuild is probably broken. Which it _probably_ is. See, this is a numbers game. In most cases, if you use the webapp eclass, setting SLOT=0 is incorrect. There are some cases in which it's just fine. Until FEATURES=mindreader is implemented, how is the eclass to know what you're trying to do? So it prints a warning and doesn't die. Number of angry users storming bugs.g.o - 0. Again, you're dismissing QA issues as nonsense, and you wonder why I don't waste my time doing a full audit. No, what I was trying to do was call your distaste for fact-checking nonsensical, apologies if it wasn't crystal clear. Please keep the QA issues coming. -- Renat Lumpau all things web-apps C6A838DA 04AF B5EE 17CB 1000 DDA5 D3FC 1338 ADC2 C6A8 38DA America - land of the free* *Void where prohibited, restrictions apply. Cash value 1/100c. pgpiWUqXDtNG8.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 17:38:10 +
Ciaran McCreesh [EMAIL PROTECTED] wrote:
if [ ${IS_UPGRADE} = 1 ] ; then
einfo Removing old version ${REMOVE_PKG}
emerge -C ${REMOVE_PKG}
fi
Uh, what the fuck is that doing in an eclass ?
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 2006-02-28 at 17:38 +, Ciaran McCreesh wrote:
Sheesh, you'll probably claim that this isn't broken next too:
if [ ${IS_UPGRADE} = 1 ] ; then
einfo Removing old version ${REMOVE_PKG}
emerge -C ${REMOVE_PKG}
fi
Ciaran,
(and this is valid for all emails to technical lists,)
please save us some time and many emails by stating what is wrong when
you show a QA violation.
Many among us don't think in assembler and don't know enough about the
code to decide if/why something is wrong. This in turn causes someone
(like me) to send an email asking what is wrong, causing another reply
by you etc. etc.
It's a bit like me stating:
The bug is in line 14:
i+=2
If you don't know the code you won't understand why.
Now if I said line 14 increments by two, but then you won't ever get
out of the loop since the exit condition won't be met everyone could
understand it and evaluate my statement.
If you show a wrong code snippet please explain _why_ it is wrong in the
same email.
Thanks,
Patrick
--
Stand still, and let the rest of the universe move
signature.asc
Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, Feb 28, 2006 at 06:59:49PM +0100, Patrick Lauer wrote: If you show a wrong code snippet please explain _why_ it is wrong in the same email. Ehm you mean it is not obvious that calling emerge inside an eclass is utterly wrong ? -- Fernando J. Pereda Garcimartín Gentoo Developer (Alpha,net-mail,mutt,git) 20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4 pgpCBNysRgMmy.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 18:59:49 +0100 Patrick Lauer [EMAIL PROTECTED] wrote: (and this is valid for all emails to technical lists,) please save us some time and many emails by stating what is wrong when you show a QA violation. This is a technical discussion list, and as such it is fair to assume that anyone getting involved in a discussion on a particularly topic knows enough about said topic to understand what is going on. If you can't see what's wrong with the snippet he gave, then you shouldn't be in the discussion, and, frankly, probably shouldn't have commit rights to the tree either. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 18:59:49 +0100 Patrick Lauer [EMAIL PROTECTED] wrote: | (and this is valid for all emails to technical lists,) | please save us some time and many emails by stating what is wrong when | you show a QA violation. Oh come on. I'm not going to insult the intelligence of people reading this list by explaining something that frickin' obvious. When it's a subtle issue I explain why it's wrong. When it isn't, I try to avoid wasting everyone's time by making them read a huge explanation of something they all already know. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
Ciaran McCreesh wrote:
On Tue, 28 Feb 2006 18:30:24 +0100 Jakub Moc [EMAIL PROTECTED] wrote:
| OK, so kernel-2.eclass is abusing the slot as well, go scream on
| kernel devs.
No. kernel-2 installs sources, not an actual package.
| | Yeah, it checks for that since that's the way the eclass is
| | designed. You can't declare a slot in a kernel ebuild either.
|
| One is a design flaw. The other is not.
|
| Ah, tell me about the dual standards :P
Not dual standards at all. There's nothing wrong with saying don't do
x unless you're doing y, with appropriate justification.
| | Well, starts to be boring - so, either come with something valid
| | from QA standpoint or stop now.
|
| This is a valid issue from a QA standpoint. This is also why I'm not
| going to waste my time doing a proper list -- rather than addressing
| issues, they are being passed off as irrelevant or even features.
|
| Next time, rather think a couple of times up before claiming
| something very broken on a public mailing list where you have no
| proof for such claims. Will be immensely helpful for everyone
| involved.
No proof?
Sheesh, you'll probably claim that this isn't broken next too:
if [ ${IS_UPGRADE} = 1 ] ; then
einfo Removing old version ${REMOVE_PKG}
emerge -C ${REMOVE_PKG}
fi
Semantics of the logic aside, calling emerge from within an ebuild is a
BIG nono.
-Alec Warner
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 2006-02-28 at 18:19 +, Stephen Bennett wrote: On Tue, 28 Feb 2006 18:59:49 +0100 Patrick Lauer [EMAIL PROTECTED] wrote: (and this is valid for all emails to technical lists,) please save us some time and many emails by stating what is wrong when you show a QA violation. This is a technical discussion list, and as such it is fair to assume that anyone getting involved in a discussion on a particularly topic knows enough about said topic to understand what is going on. If you can't see what's wrong with the snippet he gave, then you shouldn't be in the discussion, and, frankly, probably shouldn't have commit rights to the tree either. Yeah, like it took me about two minutes of staring at the snippet to see why it's evil when reading a short explanation would have made me see that in 15 seconds. After all not everyone reading this list is a code ninja, please just stop this email pingpong and (like we do it with bugs) explain what is the issue instead of letting people guess. That might even teach those that are not yet super-gurus and is in general a nice thing to do. -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, Feb 28, 2006 at 06:12:57PM +, Ciaran McCreesh wrote: Oh come on. I'm not going to insult the intelligence of people reading this list by explaining something that frickin' obvious. When it's a subtle issue I explain why it's wrong. When it isn't, I try to avoid wasting everyone's time by making them read a huge explanation of something they all already know. Explaining stuff usually helps more than elitism. Those who already know it can simply skip it, those who don't may learn a bit and everyone wins. A lot of people are subscribed to this list and not everyone is an ebuild dev, but some may be tomorrow's devs. cheers, Wernfried -- Wernfried Haas (amne) - amne at gentoo dot org Gentoo Forums: http://forums.gentoo.org IRC: #gentoo-forums on freenode - email: forum-mods at gentoo dot org pgpaEgvuEtNEa.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 13:02:10 -0500,
Alec Warner [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
if [ ${IS_UPGRADE} = 1 ] ; then
einfo Removing old version ${REMOVE_PKG}
emerge -C ${REMOVE_PKG}
fi
Semantics of the logic aside, calling emerge from within an ebuild is
a BIG nono.
Reading the comments in the eclass, i can undestand the motivation.
# why do we do this? well ...
#
# normally, emerge -u installs a new version and then removes the
# old version. however, if the new version goes into a different
# slot to the old version, then the old version gets left behind
#
# if USE=-vhosts, then we want to remove the old version, because
# the user is relying on portage to do the magical thing for it
Two suggestions (don't really know what they are worth though):
* Short term, still evil, but less than calling emerge:
pkg_postinst() {
...
if ! use vhost ; then
echo 0 ${ROOT}var/db/pkg/${CATEGORY}/${PN}-${PVR}/SLOT
fi
}
This way, emerge's autoclean (the slow one, at the end) would
remove old version of USE=-vhost packages, since they would be
all slotted 0.
* Long term, don't know how difficult it would be: Do some kind of
USE-expansion of the SLOT variable, to allow something like
SLOT=vhost? ( ${PVR} ) !vhost? ( 0 )
This would only affect SLOT when read from porttree sure. In vartree,
and in the ebuild env in general, it should still be the reduced
version (${PVR} or 0) that is used.
--
TGL.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, Feb 28, 2006 at 08:11:26PM +0100, Thomas de Grenier de Latour wrote:
On Tue, 28 Feb 2006 13:02:10 -0500,
Alec Warner [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
if [ ${IS_UPGRADE} = 1 ] ; then
einfo Removing old version ${REMOVE_PKG}
emerge -C ${REMOVE_PKG}
fi
For those who are interested, ciaranm has kindly filed bug #124443, so please
comment there.
--
Renat Lumpau all things web-apps
C6A838DA 04AF B5EE 17CB 1000 DDA5 D3FC 1338 ADC2 C6A8 38DA
America - land of the free*
*Void where prohibited, restrictions apply. Cash value 1/100c.
pgpoiK0UtNaq9.pgp
Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, Feb 28, 2006 at 08:11:26PM +0100, Thomas de Grenier de Latour wrote:
On Tue, 28 Feb 2006 13:02:10 -0500,
Alec Warner [EMAIL PROTECTED] wrote:
Ciaran McCreesh wrote:
if [ ${IS_UPGRADE} = 1 ] ; then
einfo Removing old version ${REMOVE_PKG}
emerge -C ${REMOVE_PKG}
fi
That's #124440, not #124443 which is the SLOT issue.
--
Renat Lumpau all things web-apps
C6A838DA 04AF B5EE 17CB 1000 DDA5 D3FC 1338 ADC2 C6A8 38DA
America - land of the free*
*Void where prohibited, restrictions apply. Cash value 1/100c.
pgpsXqzpALYvB.pgp
Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 20:27:01 +0100 Jakub Moc [EMAIL PROTECTED] wrote: Once again, don't invent problems, please. Just because you don't see a problem doesn't mean it's not there. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jakub Moc schrieb: | 28.2.2006, 18:38:10, Ciaran McCreesh wrote: | No, I won't claim that... I'd rather love to know why didn't you point out | to an obvious eclass flaw about 30 emails and many hours ago, saving us from | all the eclass formating, slotting and ewarn blurb. The above needs to be | fixed, period. | | To return to the original topic - focus your QA efforts on real issues. Same | goes for that non-interactivity stuff. QA that serves no other purpose than interactivie stuff in the tree (outside of pkg_config() function) _is_ a QA problem. | inventing problems to enforce an inevitably hackish solution (there's no | good one because the needed tools are not available) is not useful at all. | Portage is a tool to install and manage packages, and serves no good purpose | on its own. Crippling installed packages and their available features for | the sole purpose of having nice ebuild tree with clean bash code is not what | QA is for. Improving the whole process is fine and welcome, as long as it Wrong. This is exactly what QA is for. There are additional duties for the QA team beside clean bash code. Danny - -- Danny van Dyk [EMAIL PROTECTED] Gentoo/AMD64 Project, Gentoo Scientific Project -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEBKe7aVNL8NrtU6IRAl75AKCT9h+9V4sM9YxRgIoaD+136dug9ACgkqoI chBYTGNn2hEChDAi/WfV1+k= =INNg -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
which part dont you understand ? the user sets a variable and then is told that the package probably contains a bug ... seems pretty confusing to me -mike rl03 already replied to that. I don't see any QA issues there, and if someone from QA team does, then he probably has too much time to ponder over the tree and invent issues where they don't exist. I don't see any point fixing this, at least until FEATURES=mindreader is implemented. Portage QA notices may be equally confusing to the users, with this kind of logic, yet they stay there - and number of people complaining about USE_EXPAND notices is much higher than the number of people who complained about confusing ewarn from webapps slot (exactly zero is far as I could find). Once again, don't invent problems, please. Nobody is inventing problems Jakub. Just because nobody has yet complained does not mean that there is not a problem. If you can't see the QA issues, then you really need to stop commenting in this thread, because there are a lot of people who know better. Furthermore, you are playing right into the hands of He Whom I Will Not Name, thus allowing yourself to be trolled into sounding like an idiot in public. You suffered from the same problem in the bbapm thread recently. -Steve -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tuesday 28 February 2006 12:51, Renat Lumpau wrote: On Tue, Feb 28, 2006 at 05:11:57PM +, Ciaran McCreesh wrote: And it sticks out a nasty ewarn and says that the ebuild is probably broken. Which it _probably_ is. See, this is a numbers game. In most cases, if you use the webapp eclass, setting SLOT=0 is incorrect. There are some cases in which it's just fine. Until FEATURES=mindreader is implemented, how is the eclass to know what you're trying to do? So it prints a warning and doesn't die. Number of angry users storming bugs.g.o - 0. why do you need to be a mindreader ? the user requested they control the package, thus it isnt a bug, so dont issue a warning -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 20:09:02 +0100 Jakub Moc [EMAIL PROTECTED] wrote:
| 28.2.2006, 18:38:10, Ciaran McCreesh wrote:
| Sheesh, you'll probably claim that this isn't broken next too:
|
| if [ ${IS_UPGRADE} = 1 ] ; then
| einfo Removing old version ${REMOVE_PKG}
|
| emerge -C ${REMOVE_PKG}
| fi
|
| No, I won't claim that... I'd rather love to know why didn't you
| point out to an obvious eclass flaw about 30 emails and many hours
| ago, saving us from all the eclass formating, slotting and ewarn
| blurb.
Why didn't you look before accusing me of not having valid issues? I
mean, it's pretty frickin' hard to miss that one.
--
Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tuesday 28 February 2006 15:10, Jakub Moc wrote: 28.2.2006, 20:59:42, Mike Frysinger wrote: On Tuesday 28 February 2006 12:51, Renat Lumpau wrote: On Tue, Feb 28, 2006 at 05:11:57PM +, Ciaran McCreesh wrote: And it sticks out a nasty ewarn and says that the ebuild is probably broken. Which it _probably_ is. See, this is a numbers game. In most cases, if you use the webapp eclass, setting SLOT=0 is incorrect. There are some cases in which it's just fine. Until FEATURES=mindreader is implemented, how is the eclass to know what you're trying to do? So it prints a warning and doesn't die. Number of angry users storming bugs.g.o - 0. why do you need to be a mindreader ? the user requested they control the package, thus it isnt a bug, so dont issue a warning Sure, and when *ebuild* requested it instead, then portage will be automagically informed. So yeah, we can implement yet another variable into the eclass, and we can do tons of other magic voodoo about three lines of eclass that noone has ever noticed until today, and the whole thing can be a lot more complex for sure. Sorry, I call this a complete waste of time. whats your point ? if an ebuild author wants to control the SLOT, then they should be able to without having an invalid warning issued on the subject considering the nature of the warning, it should be trivial to make it into a proper QA check by having the class see where files were installed and then warn/abort if certain conditions are met there's no reason for the user to see this crap -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tuesday 28 February 2006 16:02, Jakub Moc wrote: 28.2.2006, 21:39:43, Mike Frysinger wrote: whats your point ? if an ebuild author wants to control the SLOT, then they should be able to without having an invalid warning issued on the subject considering the nature of the warning, it should be trivial to make it into a proper QA check by having the class see where files were installed and then warn/abort if certain conditions are met there's no reason for the user to see this crap Yeah, and there's no reason for user to see USE_EXPAND QA notice crap, eclass inherited illegally crap and a couple of others - this isn't going anywhere. unrelated ... that is a portage limitation that has deeper work going on around it to resolve the issue properly ... this is an eclass limitation that can be resolved now You are trying to solve something that noone ever complained about. Why not rather solve stuff like ebuilds that depend unconditionally on arts, but because they inherit kde eclass they get bogus arts use flag from the eclass. This is an issue that's truly confusing and that people are filing bugs about. There's the difference between doing something useful and wasting time on an artificially invented issue. right, so from now on people shouldnt bother fixing issues until a bug is filed, that way we know someone actually cares enough to have the issue resolved today's lesson: proactive QA is frowned upon, it's only a bug when a user files a report at bugs.gentoo.org -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, Feb 28, 2006 at 04:31:37PM -0500, Mike Frysinger wrote: today's lesson: proactive QA is frowned upon, it's only a bug when a user files a report at bugs.gentoo.org I don't think that's the lesson. It oughtta be: we need a way to figure out which QA issues are important and which are less so. A QA team member's opinion (personal attacks, whatever) should be an important input but not the final say. -- Renat Lumpau all things web-apps C6A838DA 04AF B5EE 17CB 1000 DDA5 D3FC 1338 ADC2 C6A8 38DA America - land of the free* *Void where prohibited, restrictions apply. Cash value 1/100c. pgpVRryQIo0uR.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On 2/28/06, Renat Lumpau [EMAIL PROTECTED] wrote: On Tue, Feb 28, 2006 at 04:31:37PM -0500, Mike Frysinger wrote: today's lesson: proactive QA is frowned upon, it's only a bug when a user files a report at bugs.gentoo.org I don't think that's the lesson. It oughtta be: we need a way to figure out which QA issues are important and which are less so. A QA team member's opinion (personal attacks, whatever) should be an important input but not the final say. eh, see, from what I can tell you are just deciding to make it complicated. Do a quick bugzie search for bugs reported in the last week by ciaranm, I don't think he's singling you out. I think he's responding to your stubbornness. -- Renat Lumpau all things web-apps C6A838DA 04AF B5EE 17CB 1000 DDA5 D3FC 1338 ADC2 C6A8 38DA America - land of the free* *Void where prohibited, restrictions apply. Cash value 1/100c. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 21:50:40 + Renat Lumpau [EMAIL PROTECTED] wrote: | On Tue, Feb 28, 2006 at 04:31:37PM -0500, Mike Frysinger wrote: | today's lesson: proactive QA is frowned upon, it's only a bug when | a user files a report at bugs.gentoo.org | | I don't think that's the lesson. It oughtta be: we need a way to | figure out which QA issues are important and which are less so. A QA | team member's opinion (personal attacks, whatever) should be an | important input but not the final say. Important QA issues are, first and foremost, the ones that can be detected and fixed quickly. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
Mike Frysinger wrote: On Tuesday 28 February 2006 16:02, Jakub Moc wrote: 28.2.2006, 21:39:43, Mike Frysinger wrote: whats your point ? if an ebuild author wants to control the SLOT, then they should be able to without having an invalid warning issued on the subject considering the nature of the warning, it should be trivial to make it into a proper QA check by having the class see where files were installed and then warn/abort if certain conditions are met there's no reason for the user to see this crap Yeah, and there's no reason for user to see USE_EXPAND QA notice crap, eclass inherited illegally crap and a couple of others - this isn't going anywhere. unrelated ... that is a portage limitation that has deeper work going on around it to resolve the issue properly ... this is an eclass limitation that can be resolved now You are trying to solve something that noone ever complained about. Why not rather solve stuff like ebuilds that depend unconditionally on arts, but because they inherit kde eclass they get bogus arts use flag from the eclass. This is an issue that's truly confusing and that people are filing bugs about. There's the difference between doing something useful and wasting time on an artificially invented issue. right, so from now on people shouldnt bother fixing issues until a bug is filed, that way we know someone actually cares enough to have the issue resolved today's lesson: proactive QA is frowned upon, it's only a bug when a user files a report at bugs.gentoo.org -mike Actually as was mentioned on #gentoo-qa earlier today, I'd prefer to see bugs filed in almost all circumstances. If QA and the maintainer can fix stuff without bugs, thats cool, especially for trivial matters. If QA and the developer aren't getting along on a specific issue then there is no reason NOT to have a bug open. Otherwise you get circumstances that were also discussed, such as I told the maintainer in person over a year ago... which may in fact be true, but people forget things and make mistakes and now you have nothing to point at for proof of inactivity except a vague statement. Better to cover your rear and be able to point to a year old bug with a solution attached, and be like look there is a bug and a fix and no one did jack squat. Essentially you have a case for any sane developer to agree with. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, Feb 28, 2006 at 09:57:05PM +, Ciaran McCreesh wrote: On Tue, 28 Feb 2006 21:50:40 + Renat Lumpau [EMAIL PROTECTED] wrote: | On Tue, Feb 28, 2006 at 04:31:37PM -0500, Mike Frysinger wrote: | today's lesson: proactive QA is frowned upon, it's only a bug when | a user files a report at bugs.gentoo.org | | I don't think that's the lesson. It oughtta be: we need a way to | figure out which QA issues are important and which are less so. A QA | team member's opinion (personal attacks, whatever) should be an | important input but not the final say. Important QA issues are, first and foremost, the ones that can be detected and fixed quickly. You mean like whitespace and syntax that affects noone? -- Renat Lumpau all things web-apps C6A838DA 04AF B5EE 17CB 1000 DDA5 D3FC 1338 ADC2 C6A8 38DA America - land of the free* *Void where prohibited, restrictions apply. Cash value 1/100c. pgpMfKA23m3R2.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
Renat Lumpau wrote: On Tue, Feb 28, 2006 at 04:31:37PM -0500, Mike Frysinger wrote: today's lesson: proactive QA is frowned upon, it's only a bug when a user files a report at bugs.gentoo.org I don't think that's the lesson. It oughtta be: we need a way to figure out which QA issues are important and which are less so. A QA team member's opinion (personal attacks, whatever) should be an important input but not the final say. At the risk of trying to get this conversation back on track, here's what has been happening: Some members of the QA team are working on a new QA tool to identify QA problems in the portage tree. As they add new tests, they run their tool on the tree, and file bugs on any packages that are found to violate that particular QA test. I think it's fair to say that these QA checks will find problems ranging from not-awful-but-annoying to could-break-your-system, but they are all bugs that ought to be fixed eventually. Now, if you're currently working on fixing a big problem and thus too busy to fix the little one, that's perfectly reasonable, but to not fix a small bug because you know there are larger bugs that aren't fixed just seems lazy. So, back to the big issue, are there any real complaints about the QA team essentially formulating QA policy? Should new QA policies instead follow the same rules as new global USE flags or eclasses--an e-mail to -dev asking for comments first? Does QA trump, or does the maintainer trump when it comes to disputes? -g2boojum- signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, Feb 28, 2006 at 04:14:33PM -0600, Grant Goodyear wrote: I think it's fair to say that these QA checks will find problems ranging from not-awful-but-annoying to could-break-your-system, but they are all bugs that ought to be fixed eventually. Now, if you're currently working on fixing a big problem and thus too busy to fix the little one, that's perfectly reasonable, but to not fix a small bug because you know there are larger bugs that aren't fixed just seems lazy. I agree completely. However, ciaranm seems to think that if we don't fix a whitespace issue immediately, we'll ignore the rest of his QA comments and it's therefore not worth it to let us know about the bigger issues: in #gentoo-qa today: 18:39 @ciaranm pfff, if they won't fix whitespace, what're the chances of them fixing anything else? That's an odd position to take. So, back to the big issue, are there any real complaints about the QA team essentially formulating QA policy? Should new QA policies instead follow the same rules as new global USE flags or eclasses--an e-mail to -dev asking for comments first? Does QA trump, or does the maintainer trump when it comes to disputes? Yes. Here's a quote from Halcy0n (with his permission): Don't mistake me not getting involved for approval. I am just not going to get involved in every single dev-dev disagreement, and certainly not when I do not have all of the facts. I wasn't aware that every team leader was accountable for how devs on their team behaved. This is not meant as a comment on Halcy0n's abilities as a team leader, as I understand he has attempted to manage the issue but reasonable effort has failed. So, my concern is: if the QA team can't manage its members effectively, should they be entrusted with tree-wide powers? -- Renat Lumpau all things web-apps C6A838DA 04AF B5EE 17CB 1000 DDA5 D3FC 1338 ADC2 C6A8 38DA America - land of the free* *Void where prohibited, restrictions apply. Cash value 1/100c. pgpWy4qqKbVYZ.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 2006-02-28 at 16:14 -0600, Grant Goodyear wrote: So, back to the big issue, are there any real complaints about the QA team essentially formulating QA policy? Should new QA policies instead follow the same rules as new global USE flags or eclasses--an e-mail to -dev asking for comments first? Does QA trump, or does the maintainer trump when it comes to disputes? I think the QA team is free to classify QA bugs, but any changes should be pushed to the -dev ML just so that everyone is aware what is happening. It's a bit, well, annoying if QA decides that we have to use the Wrong Bracing Style in eclasses and files 50 bugs for cosmetic fixes while there are ebuilds doing evil things, but if there's a warning (We'll file bugs on Saturday if there are no objections to removal of mkdir in global scope) I can live with that. Also QA should not just decide on something without a documented explanation - it will erode their credibility as it is seen as a random process unless there is documentation. In case of dispute in general QA should be stronger than a single maintainer, but combined with the fact that QA also creates policy that would be a bit tricky. Disputes should be escalated along the normal devrel dispute lines I think, just think of QA as another herd/project and that mostly makes sense :-) QA is still new, so the communication channels might not be perfect- I hope everybody manages to cooperate so that Gentoo is the least buggy distro of them all when 2006.1 comes out ;-) Patrick -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 23:42:34 +0100 Patrick Lauer [EMAIL PROTECTED] wrote: | (We'll file bugs on Saturday if there are no objections to removal | of mkdir in global scope) Eek no. Have you any idea what happens when someone shoves an mkdir in global scope? That one is most definitely on the list of stuff that gets fixed in any way, up to and including immediate cvs rm even if it screws up deps for an arch list. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tuesday 28 February 2006 16:58, Alec Warner wrote: Mike Frysinger wrote: On Tuesday 28 February 2006 16:02, Jakub Moc wrote: 28.2.2006, 21:39:43, Mike Frysinger wrote: whats your point ? if an ebuild author wants to control the SLOT, then they should be able to without having an invalid warning issued on the subject considering the nature of the warning, it should be trivial to make it into a proper QA check by having the class see where files were installed and then warn/abort if certain conditions are met there's no reason for the user to see this crap Yeah, and there's no reason for user to see USE_EXPAND QA notice crap, eclass inherited illegally crap and a couple of others - this isn't going anywhere. unrelated ... that is a portage limitation that has deeper work going on around it to resolve the issue properly ... this is an eclass limitation that can be resolved now You are trying to solve something that noone ever complained about. Why not rather solve stuff like ebuilds that depend unconditionally on arts, but because they inherit kde eclass they get bogus arts use flag from the eclass. This is an issue that's truly confusing and that people are filing bugs about. There's the difference between doing something useful and wasting time on an artificially invented issue. right, so from now on people shouldnt bother fixing issues until a bug is filed, that way we know someone actually cares enough to have the issue resolved today's lesson: proactive QA is frowned upon, it's only a bug when a user files a report at bugs.gentoo.org Actually as was mentioned on #gentoo-qa earlier today, I'd prefer to see bugs filed in almost all circumstances. If QA and the maintainer can fix stuff without bugs, thats cool, especially for trivial matters. If QA and the developer aren't getting along on a specific issue then there is no reason NOT to have a bug open. Otherwise you get circumstances that were also discussed, such as I told the maintainer in person over a year ago... which may in fact be true, but people forget things and make mistakes and now you have nothing to point at for proof of inactivity except a vague statement. Better to cover your rear and be able to point to a year old bug with a solution attached, and be like look there is a bug and a fix and no one did jack squat. Essentially you have a case for any sane developer to agree with. dont get me wrong, i wasnt implying that bugs shouldnt be filed ... i was addressing the incorrect idea that it isnt a valid QA issue unless a user experiences it and complains via bugzilla -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 2006-02-28 at 22:50 +, Ciaran McCreesh wrote: On Tue, 28 Feb 2006 23:42:34 +0100 Patrick Lauer [EMAIL PROTECTED] wrote: | (We'll file bugs on Saturday if there are no objections to removal | of mkdir in global scope) Eek no. Have you any idea what happens when someone shoves an mkdir in global scope? That one is most definitely on the list of stuff that gets fixed in any way, up to and including immediate cvs rm even if it screws up deps for an arch list. It seems that your sense of humor has gone missing ... -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] QA Team's role
Renat Lumpau [EMAIL PROTECTED] said: Yes. Here's a quote from Halcy0n (with his permission): Don't mistake me not getting involved for approval. I am just not going to get involved in every single dev-dev disagreement, and certainly not when I do not have all of the facts. I wasn't aware that every team leader was accountable for how devs on their team behaved. This is not meant as a comment on Halcy0n's abilities as a team leader, as I understand he has attempted to manage the issue but reasonable effort has failed. So, my concern is: if the QA team can't manage its members effectively, should they be entrusted with tree-wide powers? Since one dev so far has stepped out of line, and this is by no means the only time it has happened, I don't see how this argument has any merit. If it becomes a pattern where all members of the QA team are causing problems, then I can see it as being valid. I don't think you will find one person that is going to say they are capable of changing how Ciaran interacts with people. This is an entirely different issue though, and I have talked to Ciaran about it. What I was saying above is that I am not going to go and get involved every single time someone has a disagreement. This situation has obviously grown to be ridiculous and I have had a talk with him about it, so he knows my feelings on the situation, and what I expect. -- Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpHicwMpXnag.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
Patrick Lauer [EMAIL PROTECTED] said: On Tue, 2006-02-28 at 16:14 -0600, Grant Goodyear wrote: So, back to the big issue, are there any real complaints about the QA team essentially formulating QA policy? Should new QA policies instead follow the same rules as new global USE flags or eclasses--an e-mail to -dev asking for comments first? Does QA trump, or does the maintainer trump when it comes to disputes? I think the QA team is free to classify QA bugs, but any changes should be pushed to the -dev ML just so that everyone is aware what is happening. It's a bit, well, annoying if QA decides that we have to use the Wrong Bracing Style in eclasses and files 50 bugs for cosmetic fixes while there are ebuilds doing evil things, but if there's a warning (We'll file bugs on Saturday if there are no objections to removal of mkdir in global scope) I can live with that. Also QA should not just decide on something without a documented explanation - it will erode their credibility as it is seen as a random process unless there is documentation. As I said, we plan on documenting everything as we find problems. I also don't expect us to be capable of creating completely new policies off in some corner and just surprise people with them. Communication with the rest of Gentoo is going to be needed, but I am not sure of the best possible way to get things approved. I think if something we find is highly questionable, that we should be able to fix it if possible, until such a time when a decision can be reached. (more on this below) In case of dispute in general QA should be stronger than a single maintainer, but combined with the fact that QA also creates policy that would be a bit tricky. Disputes should be escalated along the normal devrel dispute lines I think, just think of QA as another herd/project and that mostly makes sense :-) Devrel is really for non-technical issues, and for dev-dev problems. I would like to see enough trust in the QA team to be able to make these decisions on its own, instead of making one team responsible for everything (devrel). QA is still new, so the communication channels might not be perfect- I hope everybody manages to cooperate so that Gentoo is the least buggy distro of them all when 2006.1 comes out ;-) Thanks, hopefully enough people have faith in us to do the right thing so that we can get everything fixed up that we can. -- Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpIiQ6BfpkLK.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, Feb 28, 2006 at 06:34:32PM -0500, Mark Loeser wrote: Renat Lumpau [EMAIL PROTECTED] said: Yes. Here's a quote from Halcy0n (with his permission): Don't mistake me not getting involved for approval. I am just not going to get involved in every single dev-dev disagreement, and certainly not when I do not have all of the facts. I wasn't aware that every team leader was accountable for how devs on their team behaved. This is not meant as a comment on Halcy0n's abilities as a team leader, as I understand he has attempted to manage the issue but reasonable effort has failed. So, my concern is: if the QA team can't manage its members effectively, should they be entrusted with tree-wide powers? Since one dev so far has stepped out of line, and this is by no means the only time it has happened, I don't see how this argument has any merit. If it becomes a pattern where all members of the QA team are causing problems, then I can see it as being valid. I don't think you will find one person that is going to say they are capable of changing how Ciaran interacts with people. This is an entirely different issue though, and I have talked to Ciaran about it. What I was saying above is that I am not going to go and get involved every single time someone has a disagreement. This situation has obviously grown to be ridiculous and I have had a talk with him about it, so he knows my feelings on the situation, and what I expect. So you're saying it's ok to have one team member who steps out of line and cannot be managed? Are all teams allowed that exception? -- Renat Lumpau all things web-apps C6A838DA 04AF B5EE 17CB 1000 DDA5 D3FC 1338 ADC2 C6A8 38DA America - land of the free* *Void where prohibited, restrictions apply. Cash value 1/100c. pgpFDnKmcPDOU.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
Renat Lumpau [EMAIL PROTECTED] said: So you're saying it's ok to have one team member who steps out of line and cannot be managed? Are all teams allowed that exception? Did you read what I said? I talked to him and told him what I expect. I'm telling you to not expect him to change, not that I expect QA team members to behave that way. -- Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpuAjcZkQUWe.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
Mark Loeser wrote: I don't think you will find one person that is going to say they are capable of changing how Ciaran interacts with people. This is an entirely different issue though, and I have talked to Ciaran about it. What I was saying above is that I am not going to go and get involved every single time someone has a disagreement. This situation has obviously grown to be ridiculous and I have had a talk with him about it, so he knows my feelings on the situation, and what I expect. I should note that if are a Gentoo Developer and have problems/concerns/issues with Ciaran's attitude/actions, please comment on bug #114944. (this bug is only open to Gentoo developers). Its better if you say it yourself in this bug rather than letting other people quoting what you say. -- Lance Albertson [EMAIL PROTECTED] Gentoo Infrastructure | Operations Manager --- GPG Public Key: http://www.ramereth.net/lance.asc Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742 ramereth/irc.freenode.net signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tue, 28 Feb 2006 18:13:57 -0600 Lance Albertson [EMAIL PROTECTED] wrote: | I should note that if are a Gentoo Developer and have | problems/concerns/issues with Ciaran's attitude/actions, please | comment on bug #114944. (this bug is only open to Gentoo developers). | Its better if you say it yourself in this bug rather than letting | other people quoting what you say. I should note that if you are a Gentoo developer who has found my advice helpful, you should comment on bug #114944 since certain people are trying to turn Gentoo development into a popularity contest. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Tuesday 28 February 2006 19:28, Ciaran McCreesh wrote: On Tue, 28 Feb 2006 18:13:57 -0600 Lance Albertson [EMAIL PROTECTED] wrote: | I should note that if are a Gentoo Developer and have | problems/concerns/issues with Ciaran's attitude/actions, please | comment on bug #114944. (this bug is only open to Gentoo developers). | Its better if you say it yourself in this bug rather than letting | other people quoting what you say. I should note that if you are a Gentoo developer who has found my advice helpful, you should comment on bug #114944 since certain people are trying to turn Gentoo development into a popularity contest. there's a lot more to the issue, but it's sad if that's all you see in the bug -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
Lance Albertson wrote: I should note that if are a Gentoo Developer and have problems/concerns/issues with Ciaran's attitude/actions, please comment on bug #114944. (this bug is only open to Gentoo developers). Its better if you say it yourself in this bug rather than letting other people quoting what you say. Since some people may read this the wrong way, let me please clarify. If you have *anything* (good or bad) to add to the bug, please feel free to (If you're a developer). I'm not trying to single out one developer, rather I felt that informing developers about it (since there has been a lot of frustration shown on this list) was a good idea. Sorry if it seemed more biased one way or the other. It was not my intention at all. I assumed people would read that and realize that they could also add good comments if they wanted to. -- Lance Albertson [EMAIL PROTECTED] Gentoo Infrastructure | Operations Manager --- GPG Public Key: http://www.ramereth.net/lance.asc Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742 ramereth/irc.freenode.net signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] QA Team's role
On Sun, Feb 26, 2006 at 07:09:29PM -0500, Mark Loeser [EMAIL PROTECTED] wrote: The problem with that is, it usually ends up with too many pointless comments from people saying how things could be fixed in the distant future, or whining that it isn't explicitly forbidden by policy on situations where the screwup was too weird to be documented previously. This is very much a case-by-case thing. I still feel the debate should be better answered outside of conflicting qa members. Well, instead of putting the debate into an even larger crowd, this enables the QA team to act in the way it sees best first. If people believe we were wrong, then we give them the option to talk to the council about one of our changes. Also, we aren't unwilling to hear alternatives and we hope to work with the maintainer on these problems. I've yet to read the rest of this subthread this morning, but while its fresh in my mind I would also like to see less of a requirement from the council. They are there purely for technical direction and not for a teams beck and call. Regardless, I can see your point - although I would still prefer to see a little more public discussion when the QA team are unable to satisfactorily come to an answer between themselves and the maintainer in question. -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgpLXBkh7cAFg.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
Hi Mark, On 2/27/06, Mark Loeser [EMAIL PROTECTED] wrote: Your change seems to imply that the QA team must wait for the council's okay to go forth and fix the package, rather the QA team able to act on its own. If that is the case, I don't see how we would ever be able to get things done when someone disagrees with us. In the event of a disagreement, that's exactly what I'm asking for. Hopefully, disagreements will be rare. But, when they do arise, and it is not an emergency, I see no reason why the QA team needs the ability to force its point of view onto others. Again, then we are going to get into the argument of the definition of an emergency and never be able to get anything done. We really hope problems never come down to this, which is why we left it worded this way. Me too. But it will, sooner or later, and when something isn't an emergency, there's no reason why a change cannot wait until the dispute has been resolved. I have no desire to stop the QA team being able to act in an emergency. It's in all our interests for action to be taken in an emergency. The QA team has no monopoly on what is right or wrong in Gentoo, and neither do package maintainers. If there is a disagreement that leads to an appeal, the onus should be on the QA team to have to present their case to the council, as they are the ones pushing for change. Again, this is taking away any power that the QA team might have I find that an interesting statement. The only power my proposals remove is to stop you bullying people by insisting you are always right before a peer review has happened. If there is a genuine QA problem, and you can't convince the developer in question of that, there's still a fair process that allows you to enforce when concensus has failed. Without these safeguards, my feeling is that the QA team is free to enforce without concensus at all times. I don't believe that is in the best interests of Gentoo, and is a significant shift in the way we govern ourselves. I don't see any compelling reason for the QA team to be judge, jury and executioner, with the council acting as a post-execution appeals panel. Wasn't devrel broken up into separate investigation and enforcement teams over these very same concerns, raised by a member of the QA team? This is not quantifiable at all and will just get us into arguments with people that disagree with us that there is a problem present. If you mean that it creates grey areas where the output of automated tools cannot always be right, I agree. If you're saying that it's beyond your capacity as human beings to weigh up the merits of an argument on more than just narrowly-defined technical facts, then are you best placed to be making the decision in the first place? If a policy is to be supportable and implementable, it has to be reasonable, and it has to be managed by reasonable people. I feel that what you're asking for, on this point, is more dogmatic than reasonable. Case in point. I've presented to you that, after two and a half years, the situation that has sparked this debate off hasn't affected users. I've explained that it is a third scenario, and that it is different to the two (legitimate) scenarios that you've been busy getting fixed. From where I'm sat, it would seem reasonable to accept that, although this is a problem when looked at purely from a technical point of view, this scenario isn't causing problems at this time, and we could all move on to dealing with more important matters. If there was a real problem, there would be enough evidence after two and a half years for you to show me, and that would convince me (and any other reasonable person) that I was wrong, and that action was worth taking. You haven't presented that evidence, or if you have, I haven't seen it since getting up this morning. Instead, we have a proposed QA policy that says we're always right, and when we're not, we still get our way until you convince the council to let you back out the changes we demand. I think that's unreasonable. That's why I oppose this point. To me, it smacks of wanting to have your own way whether you're right or not. I can't support that. Again, this bogs us down in useless process if someone wants to argue a change that clearly breaks things, but isn't documented. It is impossible to document every single thing that is a problem, and we are asking for some freedom to be able to work on issues that fall under QA. As already mentioned, if it's not documented, how on earth do you expect to raise the general quality of the QA done by each and every developer? How do you expect to be able to consistently enforce your own QA standards? If it's not documented, then you're left with making it up as you go along. That's in no-one's interest. This comes back to my point about the QA team needing to be an educational role first and foremost. So the Portage team will have to agree with us on every single
Re: [gentoo-dev] [RFC] QA Team's role
On Sun, Feb 26, 2006 at 07:12:52PM -0500, Mark Loeser [EMAIL PROTECTED] wrote: Alec Warner [EMAIL PROTECTED] said: This is meant to prevent the case where the QA team ( or a subset; the established QA members ) decides to make unilateral changes to the tree ( or large subset thereof ) without even necessarily talking to the affected developers. While you may not think that soliciting comments is useful ( and in some limited cases I would agree with you ) giving people the opportunity to comment also means you just covered your ass, in terms of people going where the hell did that come from? We don't plan on going around and making changes without discussing issues with the maintainers. We put this in so that if the maintainer is unwilling to work with us for some reason, that we are able to come up with what we believe to be the best fix. As I said earlier in the document, we plan to work as much with maintainers as possible, but sometimes that may prove to be impossible. In this specific instance, impossible is effectively a point of view. For me the question comes down to this.. If QA trump maintainer, then who picks the QA staff? If anyone can become QA staff, then this is questionable in itself. is QA becoming another council with a sole purpose? If so I'd like to see an election again. At the end of the day the pack have to have faith in the team doing the work, and disagreements are obviously contrary to that. -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgpgTcm5SZaCd.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Sun, 26 Feb 2006 17:53:20 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | The maintainer should be the absolute authority over his/her packages, | and only the council should be able to overrule maintainer decisions | in the case of disagreement between the maintainer and anybody else. So if the maintainer sticks SANDBOX_DISABLE=1 rm -fr / in global scope and refuses to move it, QA will have to get council approval to fix it? -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, 27 Feb 2006 00:09:28 -0500 Ned Ludd [EMAIL PROTECTED] wrote: | I think I agree with the part that security@ having near final say. Security have (admittedly not very often) screwed up in the past. Fixing a security issue at the expense of utterly h0rking an arch, for example, is not an acceptable solution... -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, 27 Feb 2006 09:09:01 + John Mylchreest [EMAIL PROTECTED] wrote: | In this specific instance, impossible is effectively a point of view. | For me the question comes down to this.. If QA trump maintainer, then | who picks the QA staff? If anyone can become QA staff, then this is | questionable in itself. is QA becoming another council with a sole | purpose? If so I'd like to see an election again. At the end of the | day the pack have to have faith in the team doing the work, and | disagreements are obviously contrary to that. QA consists of whoever is on the QA project page. To be added, you must convince the existing QA team that you know what you're doing. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, Feb 27, 2006 at 04:37:52PM +, Ciaran McCreesh [EMAIL PROTECTED] wrote: On Mon, 27 Feb 2006 09:09:01 + John Mylchreest [EMAIL PROTECTED] wrote: | In this specific instance, impossible is effectively a point of view. | For me the question comes down to this.. If QA trump maintainer, then | who picks the QA staff? If anyone can become QA staff, then this is | questionable in itself. is QA becoming another council with a sole | purpose? If so I'd like to see an election again. At the end of the | day the pack have to have faith in the team doing the work, and | disagreements are obviously contrary to that. QA consists of whoever is on the QA project page. To be added, you must convince the existing QA team that you know what you're doing. My point was the more along the lines that the existing QA team need to convince the rest of the development community that they know what they're doing first. Whats stopping the existing QA team disregarding all new applicants because they enjoy having authority? Especially when its mis-placed authority. -- Role:Gentoo Linux Kernel Lead Gentoo Linux:http://www.gentoo.org Public Key: gpg --recv-keys 9C745515 Key fingerprint: A0AF F3C8 D699 A05A EC5C 24F7 95AA 241D 9C74 5515 pgpe2CwZZJnYv.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, 27 Feb 2006 10:47:58 -0600 Lance Albertson [EMAIL PROTECTED] wrote: | So if the maintainer sticks SANDBOX_DISABLE=1 rm -fr / in global | scope and refuses to move it, QA will have to get council approval | to fix it? | | Use some common sense when showing an example please. We all know that | something that stupid needs to be delt with quickly. If we all recognise that level of stupidity, please explain how the heck this got into the tree: http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/sys-apps/bootstrap_cmds/bootstrap_cmds-44.ebuild?rev=1.1content-type=text/plain -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, 27 Feb 2006 17:09:42 + John Mylchreest [EMAIL PROTECTED] wrote: | My point was the more along the lines that the existing QA team need | to convince the rest of the development community that they know what | they're doing first. Whats stopping the existing QA team disregarding | all new applicants because they enjoy having authority? Especially | when its mis-placed authority. Oh, that one's easy. We're all lazy and would never turn down someone decent who is going to reduce our workload :P -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Monday 27 February 2006 12:08, Ciaran McCreesh wrote: On Mon, 27 Feb 2006 09:00:15 + Stuart Herbert [EMAIL PROTECTED] wrote: | Again, then we are going to get into the argument of the definition | of an emergency and never be able to get anything done. We really | hope problems never come down to this, which is why we left it | worded this way. | | Me too. But it will, sooner or later, and when something isn't an | emergency, there's no reason why a change cannot wait until the | dispute has been resolved. And, when such a case occurs, there's nothing *requiring* QA to commit before the dispute is resolved. It's extremely likely that QA will work hard to ensure that everyone is happy before something gets changed. However, there are situations where waiting for a month would lead to considerable damage, and in those situations QA must be free to act. if something is going to lead to considerable damage and the maintainer is unwilling to resolve the issue, then i'm pretty sure there's more to be resolved here than fixing a package not sure leaving this power open ended is really needed -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, 27 Feb 2006 10:47:58 -0600 Lance Albertson [EMAIL PROTECTED] wrote: We all know that something that stupid needs to be delt with quickly. So you're agreeing that someone needs to be able to act should a package maintainer screw up sufficiently badly, and the obvious candidate for that role is the QA team. The ability to overrule package maintainers doesn't, and shouldn't, mean that they'll go around doing so willy-nilly, but it should be there as a last resort should it be necessary. (Yes, I'm taking that sentence out of context, but the fact that it comes up at all says something, to my mind.) -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, Feb 27, 2006 at 05:08:34PM +, Ciaran McCreesh wrote: Abuse from people like you whenever someone finally gets brave enough to document all the ways in which webapp-config is broken. wrobel and I would be very interested to see such a document. In the meantime, we shall continue to look forward to more whining and moaning from you et al. -- Renat Lumpau all things web-apps C6A838DA 04AF B5EE 17CB 1000 DDA5 D3FC 1338 ADC2 C6A8 38DA America - land of the free* *Void where prohibited, restrictions apply. Cash value 1/100c. pgp8koU359mKC.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
Mark Loeser wrote: * In case of emergency, or if package maintainers refuse to cooperate, the QA team may take action themselves to fix the problem. My suspicion is that the more common problem is going to be inaccessible developers, rather than uncooperative ones. Certainly, if a maintainer cannot be contacted, then I would prefer that QA fix the problem rather than let it languish. So, yes, I do believe that QA needs the ability to go in and change any package that is broken. (It's worth noting, though, that every dev w/ tree access already has that ability, and the only real issue is the amount of pain that will be inflicted on a dev who changes packages both without permission and without skill. Very few devs will complain about somebody improving packages even without permission as long as the improvement is done well.) * In the event that a developer still insists that a package does not break QA standards, an appeal can be made at the next council meeting. The package should be dealt with per QA's request until such a time that a decision is made by the council. I'm somewhat ambivalent on this one on a couple of points, and the nxserver case (bug #123926) hits both of them. The first is that it seems to me that in a case like this one, where the package involved is a minor one that (I think) is not a dependency of any other packages, the most that QA should do is hard mask the package w/ a clear note pointing to the bug report, until some sort of resolution is achieved. Removing the package would seem to be a bit much. The second is the fact that I don't really like seeing policy bounced to the council unless absolutely necessary. Just as was seen here, a discussion on -dev might well lead to a reasonable compromise. If it doesn't, then the council can get involved. Of course, that leaves the question of who decides on the severity of a QA violation? Well, I would suggest that the QA team does, at the risk of getting publicly smacked down if they choose poorly. -g2boojum- signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, 27 Feb 2006 12:21:29 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: | if something is going to lead to considerable damage and the | maintainer is unwilling to resolve the issue, then i'm pretty sure | there's more to be resolved here than fixing a package Sure. There're other parts of the document that address that. Getting the issue fixed, however, has higher priority than any disciplinary action. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, 27 Feb 2006 12:05:58 -0600 Grant Goodyear [EMAIL PROTECTED] wrote: | Of course, that leaves the question of who decides on the severity of | a QA violation? All this talk of severity, and no talk of ease of detection or ease of fixing... Allow me to explain. There are certain not particularly high impact issues that can very easily be detected, and with 100% reliability, by The Thing About Which We Do Not Talk. Any individual one of these doesn't look like such a big deal, but when we're talking a couple of hundred instances, all of which can easily be fixed in less overall time than it would take to even detect one instance of a particular severe problem, it's most definitely worth concentrating on the 'easy' issue. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
Grant Goodyear [EMAIL PROTECTED] said: Mark Loeser wrote: * In case of emergency, or if package maintainers refuse to cooperate, the QA team may take action themselves to fix the problem. My suspicion is that the more common problem is going to be inaccessible developers, rather than uncooperative ones. Certainly, if a maintainer cannot be contacted, then I would prefer that QA fix the problem rather than let it languish. So, yes, I do believe that QA needs the ability to go in and change any package that is broken. We hope that it is never the case when someone refuses to cooperate, but it is a possible situation we may likely have to deal with at some point. * In the event that a developer still insists that a package does not break QA standards, an appeal can be made at the next council meeting. The package should be dealt with per QA's request until such a time that a decision is made by the council. I'm somewhat ambivalent on this one on a couple of points, and the nxserver case (bug #123926) hits both of them. The first is that it seems to me that in a case like this one, where the package involved is a minor one that (I think) is not a dependency of any other packages, the most that QA should do is hard mask the package w/ a clear note pointing to the bug report, until some sort of resolution is achieved. Removing the package would seem to be a bit much. The second is the fact that I don't really like seeing policy bounced to the council unless absolutely necessary. Just as was seen here, a discussion on -dev might well lead to a reasonable compromise. If it doesn't, then the council can get involved. I agree. With regards to the nxserver case, we said the package should be removed if we could not come to a resolution. We never said that we were going to outright remove the package immediately. It is not our goal, nor our intent, to go around and remove people's packages from the tree. This entire bullet point is really a worst case scenario when all else breaks down. The same with if there is a disagreement within the majority of the QA team. I don't foresee this occuring often, if at all, but I felt it was important enough to address. -- Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpBVWM0NwbfO.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] QA Team's role
Ciaran McCreesh wrote: On Sun, 26 Feb 2006 17:53:20 -0800 Donnie Berkholz [EMAIL PROTECTED] wrote: | The maintainer should be the absolute authority over his/her packages, | and only the council should be able to overrule maintainer decisions | in the case of disagreement between the maintainer and anybody else. So if the maintainer sticks SANDBOX_DISABLE=1 rm -fr / in global scope and refuses to move it, QA will have to get council approval to fix it? I already addressed that in the next email in the thread. That assumes lack of extenuating circumstances such as security vulnerabilities or major tree breakage. Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, 2006-02-27 at 17:08 +, Ciaran McCreesh wrote: Abuse from people like you whenever someone finally gets brave enough to document all the ways in which webapp-config is broken. This isn't the first time we've heard this tune from you, and alas I fear it won't be the last. You know where bugzilla is. You know how to contact any of the webapp-config maintainers via email, or via IRC. We're ready to listen to your input, and to work with you (or anyone else) on fixing any genuine problems that webapp-config has. The more feedback we get, the better we can make this package for everyone's enjoyment. Please make sure you test your issues against webapp-config v1.5.10 or later, as that is the latest testing version of the package. But - if you're not going to take up any of those means of contacting us with your issues, and instead prefer to behave like this, making general statements about quality that you're not willing to substantiate and share with the package maintainers in question, then kindly step down from the QA team. There can be no place for someone who prefers to abuse the mantle of QA work to attack other people's reputations, exactly like you've just done, if the Gentoo QA team is to have credibility. Put up, or shut up, once and for all. Best regards, Stu -- Stuart Herbert [EMAIL PROTECTED] Gentoo Developer http://www.gentoo.org/ http://blog.stuartherbert.com/ GnuGP key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint = 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C -- signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] QA Team's role
On Mon, 27 Feb 2006 20:26:10 + Stuart Herbert [EMAIL PROTECTED] wrote: | On Mon, 2006-02-27 at 17:08 +, Ciaran McCreesh wrote: | Abuse from people like you whenever someone finally gets brave | enough to document all the ways in which webapp-config is broken. | | This isn't the first time we've heard this tune from you, and alas I | fear it won't be the last. | | You know where bugzilla is. You know how to contact any of the | webapp-config maintainers via email, or via IRC. We're ready to | listen to your input, and to work with you (or anyone else) on fixing | any genuine problems that webapp-config has. The more feedback we | get, the better we can make this package for everyone's enjoyment. Then please start with bug 120088. Once that one's fixed we'll go from there. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm signature.asc Description: PGP signature
