Re: [gentoo-dev] QA Roles v2
On Saturday 04 March 2006 15:45, Danny van Dyk wrote:
Just to throw in my 2 cents into this discussion: I'm all against
die-ing during the update process. However, i think that stopping
before the update process would be the best solution at hand. I'd like
to propose the addition of a dedicated USE conflict detection to
ebuilds which need it.
Perhaps it would be possible to tell portage to have a
build-what-you-can mode, where it tries to build as much as possible
after a compilation failure. At the end it then can report on the
packages that were not compiled.
This detection function (for example pkg_prepare()) must be executed
for every package in the depgraph right after the depgraph has been
built and has only the possibility to either mark the package as 'go'
or 'no-go'. In case that any package has been marked as 'no-go', the
whole process stops.
And this indeed.
A possible implementation from the build side could look like this:
# the next two functions would be candidates for eutils.eclass
emutexuse() {
eerror The following USE flags are mutually exclusive:
eerror [EMAIL PROTECTED]
eerror Please choose only one of the above and disable the remaining
eerror USE flags. For additional information about this problem, see
eerror http://www.gentoo.org/some place to store add. info about
this echo
}
Add some reference to the package for which they are mutually exclusive.
Paul
--
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net
pgpZHjLsEpQYe.pgp
Description: PGP signature
Re: [gentoo-dev] QA Roles v2
Paul de Vrieze wrote: On Saturday 04 March 2006 15:45, Danny van Dyk wrote: Just to throw in my 2 cents into this discussion: I'm all against die-ing during the update process. However, i think that stopping before the update process would be the best solution at hand. I'd like to propose the addition of a dedicated USE conflict detection to ebuilds which need it. Perhaps it would be possible to tell portage to have a build-what-you-can mode, where it tries to build as much as possible after a compilation failure. At the end it then can report on the packages that were not compiled. We've had a bug for this for years, no one has implemented it. Most of the Portage developers would prefer USE-deps to anything else, as this is what that is really trying to cover. The only alternative I'm willing to support at this time is moving the death ( per Kugelfang's suggestion ) to right after depgraph building. Thus a user will find out right away that their USE flags conflict and need to be changed. Even with USE deps, there cases that just aren't resolvable, they are unsolveable and I think coming up with some sort of structure to inform the user of this is a good idea. However we have talked about this and the DEPEND syntax doesn't seem to cut it for showing USE conflicts and dependencies. Certainly right now the resolver has no metadata whatsoever to work with, so it can't even tell if a specific set of USE flags conflict or not, if we provide it with that information it can at least die during depgraph creation stating what the problem is with the depgraph ( getting closer to having actaul buildplans... ). -Alec Warner -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
Mike Frysinger wrote: On Wednesday 01 March 2006 21:53, Mark Loeser wrote: Here is my updated version after some feedback from people: * In case of emergency, or if package maintainers refuse to cooperate, the QA team may take action themselves to fix the problem. * The QA team may also offer to fix obvious typos and similar minor issues, and silence from the package maintainers can be taken as agreement in such situations. * 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. one thing i dont think we give enough emphasis to is that our tools arent perfect ... sometimes we utilize QA violations to work around portage limitations ... if you want to see some really sweet hacks, review any of the toolchain related ebuilds and the hacks ive had to add to get cross-compiling to the usuable state that it is today. a handful of them would fall under the 'severe' category i'm sure. and if we want to use the lovely php example, personally i think that given portage's current limitations, the latest dev-lang/php ebuild is probably one of the best solutions that could have been developed, thanks Stuart for all the flak you've had to take over this. also, many games ebuilds break the 'non-interactive' policy by displaying licensing and making the user hit Y because portage lacks checks where the user explicitly states what licenses they accept. -mike I installed dev-lang/php on a server in my house to test torrents.gentoo.org and ramereth also installed it on the torrents.g.o server. I have to say that it was a painless and normal operation with no errors. Thanks for the hard work on this ebuild, it's appreciated. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] QA Roles v2
On Fri, 3 Mar 2006 22:44:22 +, Stuart Herbert [EMAIL PROTECTED] wrote: Unless a user looks inside the ebuild, they're not going to understand why the USE flags they've selected has resulted in a package that doesn't actually have those features. ... This is going to *create* more support, not reduce it. The problem here, from a user point of view, is the USE flag usage not matching its description (that's what makes unexpected the ebuild behavior). For instance, description says foo - Enable libfoo, whereas actually the ebuild will only use libfoo if some other bar is unset. One point of view on this issues is that the ebuilds are wrong, because they are abusing the said USE flags, and they should rather die. Imho, it makes sense, but if such a strict policy was applied to every ebuilds which atm are abusing flags this way, it would become really hard to put anything in the make.conf USE variable without breaking emerge -uD world. Just take the default flags from x86 profile for instance: both motif (Adds motif support) and gtk (Adds support for x11-libs/gtk+) are enabled, whereas the logic in several packages supporting both is to build the GTK interface when gtk is on, and to build a Motif one otherwise, if motif is on. Do you think such ebuilds should rather die at compile time, asking the user to make an unconflicting choice? I don't. My package.use is already ~200 lines long for various other reasons, and i really don't want to double its size again just to make my emerge -uD world successfully terminating. Now, an alternative point of view is that what is wrong is rather the USE flag descriptions. That's exactly what the package specific USE flag descriptions proposal, which popups on this list from time to time, is about (sorry, no URL because GMane seems down, but i can post some later if you're interested). The idea (or at least my pov on this idea, but others had different views iirc) is that emerge could display some package-specific flags descriptions in such cases. Using the emerge patch from bug #84884, and with a use.local.desc entry for app-editors/gvim:motif, the user would be warned about what the motif flag actualy does (or does not) on this package: --- % emerge -pv --use-desc-special gvim ... [ebuild R ] app-editors/gvim-6.4 USE=-acl bash-completion cscope gnome gpm gtk motif nls -perl python ruby 0kB ... The following USE flags have package-specific descriptions: app-editors/gvim motif - Include support for the Motif GUI, but if gtk or gnome flags are turned on too, in which case they are prefered. --- This way, nothing unexpected for users, and no complain for devs. -- TGL. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
On Friday 03 March 2006 23:32, Grant Goodyear wrote: Stuart Herbert wrote: I agree. Adopting a policy like this is a low quality solution for servers. I've no opinion on how this affects desktops, but packages for servers need to be precise.A policy that says if two USE flags deliver the same benefits, but conflict, pick one is fine. But saying flip a coin ... how on earth is that quality? See my previous post. And how the heck is it going to work w/ USE-based defaults? This creates a situation where package (b) cannot trust that a feature is enabled in package (a), even if package (a) was built with the required USE flags. Yep. Having a USE flag enabled turns out not to be a guarantee. That said, package builds do become deterministic, so (for example) if one needs to know if msmtp was built with openssl or gnutls it is easy enough to pull the logic from the msmtp ebuild. I'm sure that there is a more elegant solution, but I'm not convinced that having the user randomly throw USE flags at a package until some combination works is necessarily it. I could be wrong, however. *Shrug* You mean the logic should be replicated between msmtp and all packages that need to know how it was built. I see this as a bigger source of bugs (msmtp changes, some of the dependants forget to change too) than verifying at setup time that the package has sane use flags. I'd prefer that a stage were introduced that runs at pretend time exactly for these things. I would say it is a bug if a useflag was specified for a package, including dependencies, and the package does not actually depend on it because the useflag was not actually applied. But even if the dependencies are proper, it is a bug from a HCI point of view. A package should deliver what it promisses. If it can't it should fail, not silently ignore the request. Until Portage supports resolving conflicting USE flags when the deptree is built, the practical thing to do is for ebuilds w/ conflicting USE flags to bail. I, quite respectfully, disagree. As explained above, when an ebuild can not deliver, it should fail, not silently downgrade its features. Especially when other packages may depend on those features being present. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpgvlRFCHTSr.pgp Description: PGP signature
Re: [gentoo-dev] QA Roles v2
On Saturday 04 March 2006 00:29, Ciaran McCreesh wrote: On Fri, 3 Mar 2006 23:14:41 + Stuart Herbert [EMAIL PROTECTED] wrote: | If we're going to do this, then at least we should be implementing a | consistent standard across all ebuilds. F.ex, when SSL and TLS | conflict, we should have a standard saying that all ebuilds will | consistenly favour one over the other. That's much more deterministic | than having some ebuilds prefer SSL, and others prefer TLS (for | example). And what of gtk vs qt, where for many packages one is clearly the preferred choice, but which one this is varies between packages? Do *you* know which GUI is the best option for gvim and why? Than say in the policy For the choice TLS vs SSL choose SSL. For the choice GTK vs QT choose the upstream preferred; if there is none, choose QT (Don't pin me on the choices in this example) Heck, it's hard enough figuring out a usable set of USE flags for PHP. If we started dieing for the three zillion or so mutually independent GUI options in gvim7 users would never actually be able to figure out how to install the thing... The problem is that these flags are dependent. Bailing out on independent useflags is not needed. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpBYCzBkJJo0.pgp Description: PGP signature
Re: [gentoo-dev] QA Roles v2
Hi Thomas,
Am Samstag, 4. März 2006 14:24 schrieb Thomas de Grenier de Latour:
One point of view on this issues is that the ebuilds are wrong, because
they are abusing the said USE flags, and they should rather die. Imho,
it makes sense, but if such a strict policy was applied to every
ebuilds which atm are abusing flags this way, it would become really
hard to put anything in the make.conf USE variable without breaking
emerge -uD world.
Just to throw in my 2 cents into this discussion: I'm all against die-ing
during the update process. However, i think that stopping before the update
process would be the best solution at hand. I'd like to propose the addition
of a dedicated USE conflict detection to ebuilds which need it.
This detection function (for example pkg_prepare()) must be executed for every
package in the depgraph right after the depgraph has been built and has only
the possibility to either mark the package as 'go' or 'no-go'. In case that
any package has been marked as 'no-go', the whole process stops.
A possible implementation from the build side could look like this:
# the next two functions would be candidates for eutils.eclass
emutexuse() {
eerror The following USE flags are mutually exclusive:
eerror [EMAIL PROTECTED]
eerror Please choose only one of the above and disable the remaining
eerror USE flags. For additional information about this problem, see
eerror http://www.gentoo.org/some place to store add. info about
this
echo
}
emissinguse() {
eerror In order to enable the ${2} USE flag you need also to enable
eerror the ${1} USE flag. For additional information
echo
}
pkg_prepare() {
local ret=0
if use foo use bar ; then
emutexuse foo bar
ret=1
fi
if use fnord2 ! use fnord ; then
emissinguse fnord fnord2
ret=1
fi
return ${ret}
}
Comments?
Danny
--
Danny van Dyk [EMAIL PROTECTED]
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
Hi Ciaran, On 3/3/06, Ciaran McCreesh [EMAIL PROTECTED] wrote: And what of gtk vs qt, where for many packages one is clearly the preferred choice, but which one this is varies between packages? Do *you* know which GUI is the best option for gvim and why? No, I don't. But that doesn't mean the user shouldn't make the choice. Even if it is the wrong one from your point of view with your additional knowledge. We're a metadistribution, not a distribution. We're supposed to be all about allowing the user to tailor each and every package to his/her exact specification. I think the policy of 'never die' would be understandable for a distribution, but I don't feel it's appropriate for a metadistribution. Heck, it's hard enough figuring out a usable set of USE flags for PHP. How so? We've worked very hard to ensure that's not the case. What have we missed? Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
Hi Mike, On 3/4/06, Mike Frysinger [EMAIL PROTECTED] wrote: bad idea ... Yes it is a bad idea; policy belongs with users. It shouldn't be hardcoded into ebuilds, whether across the whole tree or per package. But ... I realise I'm flogging a dead horse here. We'll come up with a new revision of the PHP packages which builds *something* no matter how broken the combination of USE flags are. We'll test it first in our overlay, and then when we're happy we'll add them to the tree for testing and eventual stabilisation. We'll also provide a replacement for 'built_with_use', which works with what the package was actually compiled with, rather than what USE flags the user originally specified. This will be needed for all the web-based apps that are written in PHP. That might take a bit longer, and might have to follow in a later revision. As already pointed out, all this will have to be revisited when Portage supports USE-based deps. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
Hi Danny, On 3/4/06, Danny van Dyk [EMAIL PROTECTED] wrote: Just to throw in my 2 cents into this discussion: I'm all against die-ing during the update process. However, i think that stopping before the update process would be the best solution at hand. I'd like to propose the addition of a dedicated USE conflict detection to ebuilds which need it. This is the sort of thing we're asking for in bug #75936. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
Danny van Dyk [EMAIL PROTECTED] said: Just to throw in my 2 cents into this discussion: I'm all against die-ing during the update process. However, i think that stopping before the update process would be the best solution at hand. I'd like to propose the addition of a dedicated USE conflict detection to ebuilds which need it. This detection function (for example pkg_prepare()) must be executed for every package in the depgraph right after the depgraph has been built and has only the possibility to either mark the package as 'go' or 'no-go'. In case that any package has been marked as 'no-go', the whole process stops. I'd rather see the ebuild marked with some flag to show there are conflicting use flags that have been resolved, and by adding --verbose or some other flag, you can see what flags are overridden so the user knows exactly what is going on, and can decide if they like the defaults the ebuild developer has chosen. I think we should give users the choice/information to make an informed decision, but I don't think we should shove a failure into their lap when we can make choices for them which we believe to be sane. I'd like less errors/dies during the build/deptree phase and more warnings/information to be presented so the user could look at it and make changes, or just accept what we have done for them. -- 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 pgpuYYiCyv87J.pgp Description: PGP signature
Re: [gentoo-dev] QA Roles v2
Stuart Herbert wrote: [...] Mark, in the discussions about the QA policy, your fallback justification always seems to be Trust us. I think this week's events have put a big dent in the credibility of that argument, if not holed it below the water line. If the QA team followed processes similar to what I've described above, I believe that this week's events wouldn't have happened. What started off as a worthy piece of QA work, which I'm sure has fixed many real problems for users, degenerated into something altogether unpleasant and unnecessary for all involved. We've all gotten a week older and a week greyer out of this. Have we fixed any real problems that stop our users installing and running Gentoo? No, we haven't. I hope we can all (and I include myself in that) learn something from this to prevent a repeat. I call for Mark's proposed policy to be rejected as it stands. Trust us sounds like a good justification to me. If the council grants the QA team the right to preempt maintainers for major QA violations, they will indeed have power and may abuse it. But if their use of this power is obviously abusive, the council can revert its decision and cut the balls from that QA team. So I'm for trusting them and see. We need more QA and they can't do their job properly the way it's working now. -- Thierry Carrez (Koon) Gentoo Linux Security Council Member -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
On Friday 03 March 2006 15:47, Jakub Moc wrote: Please, until something is clarified/some consent reached, avoid changing the docs w/ funny stuff like just flip a coin... please, get a sense of humor, kthxbye -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
Sending this from the right address this time -g2boojum- Grant Goodyear wrote: Jakub Moc wrote: Please, until something is clarified/some consent reached, avoid changing the docs w/ funny stuff like just flip a coin... I don't believe the text is meant to be funny. It's meant (I think) to suggest that if all else is equal, meaning that there is no obvious best choice, then just choose a flag, by whatever means, to support as the default. Even if it is not what the user might have chosen, at least the build will complete. Moreover, the results will then be deterministic. http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/devrel/handbook/hb-guide-ebuild.xml?root=gentoor1=1.31r2=1.32 What's the above again? QA policy? How does user benefit from flipping a coin wrt choosing a functionality? Sigh... :/ It prevents emerge from crashing out in the middle of what could be a quite extensive build. Personally, I would rather rebuild one package to get desired functionality _after_ the emerge completes than have to fix the flags for that one package to be able to build everything else. -g2boojum- signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] QA Roles v2
On Fri, 3 Mar 2006 22:27:45 +0100 Jakub Moc [EMAIL PROTECTED] wrote: What kind of point does it get across, exactly? That you must choose one flag, or set of flags, to take precedence in such situations, but that how you choose is quite immaterial. If there is an obvious choice then use it, else pick one some other way. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
Jakub Moc wrote: Erm, how exactly will you find out that you need to recompile that package after such extensive build? You'll spend a couple of hours debugging when your server app stops working? Yay! :P I had assumed that in such a case the ebuild would output a scary-looking ewarn that notified the user of such a problem. Oh please, stop making up artificial policies doing no good to users just to hack around lacking features in portage. Was I so impolite that you felt the need to be rude in turn? If so, I certainly apologize, as it was not my intention. I don't believe that I made up this policy, although it's been around as an unofficial policy for so long that I couldn't really say one way or the other. In any event, I certainly agree that fixing portage would be preferable to policies that work around portage's warts. On the other hand, until those warts get fixed it seems useful to have a set of best practices in the meantime. I'm arguing that sudden, difficult to predict package build breakages are a bigger sin than having a package build deterministic functionality that may be unexpected by the user. You (I think) believe the opposite. Fair enough. -g2boojum- signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] QA Roles v2
Stuart Herbert wrote: I agree. Adopting a policy like this is a low quality solution for servers. I've no opinion on how this affects desktops, but packages for servers need to be precise.A policy that says if two USE flags deliver the same benefits, but conflict, pick one is fine. But saying flip a coin ... how on earth is that quality? See my previous post. And how the heck is it going to work w/ USE-based defaults? This creates a situation where package (b) cannot trust that a feature is enabled in package (a), even if package (a) was built with the required USE flags. Yep. Having a USE flag enabled turns out not to be a guarantee. That said, package builds do become deterministic, so (for example) if one needs to know if msmtp was built with openssl or gnutls it is easy enough to pull the logic from the msmtp ebuild. I'm sure that there is a more elegant solution, but I'm not convinced that having the user randomly throw USE flags at a package until some combination works is necessarily it. I could be wrong, however. *Shrug* I'll go as far as saying that right now I'm embarrased that it looks like this is going to become a Gentoo policy in its current form. With an apology for singling you out (when yours is certainly not the only, or even the most appropriate, example), that sort of emotional response is how these threads begin to degenerate. There appears to be an implicit assumption there that your view is clearly correct, and any other is embarrassingly silly. Instead, I suggest that perhaps people on both (all?) sides of the issue are rational, intelligent people who simply differ on what happens to be the greatest evil. You're absolutely *not* creating a better user experience. You're brushing a problem under the carpet ... and making it the users' problem when they wonder why the built a package with a USE flag and the package still doesn't work as they expect. I would argue that the user tends to get unexpected results in either case, it's just a matter of whether the build crashes, or the resulting package is somewhat unexpected. Given that fact, I'm arguing that having a potentially-lengthy emerge crash out is the bigger evil. Until Portage supports resolving conflicting USE flags when the deptree is built, the practical thing to do is for ebuilds w/ conflicting USE flags to bail. I, quite respectfully, disagree. -g2boojum- signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] QA Roles v2
On Fri, 3 Mar 2006 23:31:49 +0100 Jakub Moc [EMAIL PROTECTED] wrote: Yeah, that's a wonderful message. Let users choose, they are not idiots and such policy does more harm than good. Period. You're completely missing the point here. The user has a choice, but if his set of choices doesn't make sense for whatever reason, you have to decide on some sane way to configure the package. How you come to that decision is irrelevant, hence the 'flip a coin'. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
It prevents emerge from crashing out in the middle of what could be a quite extensive build. Personally, I would rather rebuild one package to get desired functionality _after_ the emerge completes than have to fix the flags for that one package to be able to build everything else. This is why Ciaran and I opened a bug for the Portage team to get this handled up-front. Alas, I can't find the bug any more to reference it here :( You're assuming that a user can figure out how to fix the one package when they realise it's broken. Unless a user looks inside the ebuild, they're not going to understand why the USE flags they've selected has resulted in a package that doesn't actually have those features. Chances are, the user will never look. This is going to *create* more support, not reduce it. That's hardly a worthy outcome. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
Stuart Herbert wrote: It prevents emerge from crashing out in the middle of what could be a quite extensive build. Personally, I would rather rebuild one package to get desired functionality _after_ the emerge completes than have to fix the flags for that one package to be able to build everything else. This is why Ciaran and I opened a bug for the Portage team to get this handled up-front. Alas, I can't find the bug any more to reference it here :( bug 75936 -- Kind Regards, Simon Stelling Gentoo/AMD64 Member -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
Hi Grant, On 3/3/06, Grant Goodyear [EMAIL PROTECTED] wrote: Yep. Having a USE flag enabled turns out not to be a guarantee. That said, package builds do become deterministic, so (for example) if one needs to know if msmtp was built with openssl or gnutls it is easy enough to pull the logic from the msmtp ebuild. If a build process has errors, it should stop. That's still deterministic. I'd respectfully argue that it's far more deterministic than having each single package implement separate policy for handling conflicting USE flags. Policy belongs with the user, not in Portage. It's exactly the same as the kernel pushing policy into userspace. I believe that it's bad engineering to force (using your example) packages that depend on msmtp to have to copy the logic from the msmtp ebuild to understand how to correctly depend on that package. It violates the principle of Don't Repeat Yourself. If we're going to do this, then at least we should be implementing a consistent standard across all ebuilds. F.ex, when SSL and TLS conflict, we should have a standard saying that all ebuilds will consistenly favour one over the other. That's much more deterministic than having some ebuilds prefer SSL, and others prefer TLS (for example). I'm sure that there is a more elegant solution, but I'm not convinced that having the user randomly throw USE flags at a package until some combination works is necessarily it. I could be wrong, however. *Shrug* Why would the user be randomly throwing USE flags at a package? With the PHP ebuilds and the confutils eclass, we've already proved that you can tell the user exactly why the ebuild has bailed, and what they can do to fix it. With an apology for singling you out (when yours is certainly not the only, or even the most appropriate, example), that sort of emotional response is how these threads begin to degenerate. There appears to be an implicit assumption there that your view is clearly correct, and any other is embarrassingly silly. Instead, I suggest that perhaps people on both (all?) sides of the issue are rational, intelligent people who simply differ on what happens to be the greatest evil. I accept the point, but, well, I *am* embarrassed. I guess I'm just willing to admit it when others would rather not be open and honest about how this makes them feel. I think it's fair to raise that as part of the debate. I don't think we talk enough about how we feel about what's happening to Gentoo these days. I think it's reasonable that issues like this are delt with both on an emotional intelligence level as well as an intellectual one. I would argue that the user tends to get unexpected results in either case, it's just a matter of whether the build crashes, or the resulting package is somewhat unexpected. Given that fact, I'm arguing that having a potentially-lengthy emerge crash out is the bigger evil. I can understand how that matters to first-time installs, or users running old hardware. My environment and concern are servers, where dual-Xeon or dual-Opterons are the norm. The time it takes to install a package is trivial against the time it takes to diagnose why it isn't working the way you would expect. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
On Fri, 3 Mar 2006 23:14:41 + Stuart Herbert [EMAIL PROTECTED] wrote: | If we're going to do this, then at least we should be implementing a | consistent standard across all ebuilds. F.ex, when SSL and TLS | conflict, we should have a standard saying that all ebuilds will | consistenly favour one over the other. That's much more deterministic | than having some ebuilds prefer SSL, and others prefer TLS (for | example). And what of gtk vs qt, where for many packages one is clearly the preferred choice, but which one this is varies between packages? Do *you* know which GUI is the best option for gvim and why? Heck, it's hard enough figuring out a usable set of USE flags for PHP. If we started dieing for the three zillion or so mutually independent GUI options in gvim7 users would never actually be able to figure out how to install the thing... -- 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] QA Roles v2
The whole argument here is that bailing out with conflicting use flags breaks some extensive compiles. So you suppose users will be sitting in front of their monitor and stare on the screen waiting for a scary warning? No, they won't. And even if they were, how exactly is that warning better No they won't, but elog in portage-2.1 will gladly send them a message via whatever configuration they have about the warning that the ebuild produced. -Alec Warner -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
On Friday 03 March 2006 18:14, Stuart Herbert wrote: If we're going to do this, then at least we should be implementing a consistent standard across all ebuilds. F.ex, when SSL and TLS conflict, we should have a standard saying that all ebuilds will consistenly favour one over the other. That's much more deterministic than having some ebuilds prefer SSL, and others prefer TLS (for example). bad idea ... choosing a default is a per-package issue. say we take this path and we declare that if a package supports both tls and ssl, you must utilize tls over ssl regardless. then you come to a package has really shitty tls support but it has wonderful ssl support. you're saying that defaulting to tls is a better idea than ssl ? a global decision like this just wont cut it. -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
Alec Warner wrote: The whole argument here is that bailing out with conflicting use flags breaks some extensive compiles. So you suppose users will be sitting in front of their monitor and stare on the screen waiting for a scary warning? No, they won't. And even if they were, how exactly is that warning better No they won't, but elog in portage-2.1 will gladly send them a message via whatever configuration they have about the warning that the ebuild produced. -Alec Warner Greetings dear Gentoo developers. I would like to give you my humble point of view on this subject as a simple gentoo user. A few days after an emerge that took 7 hours to complete I used the portlog-info script to extract the warnings from the portage log (I'm using portage 2.0.54 on that computer so no elog there). While reading these warnings I came to this one: === 2006-02-12 01:01 === php-4.4.0-r4 === = /var/log/portage/2729-php-4.4.0-r4.log (4.0K) = ... * If you have both freetds and mssql in your USE flags, parts of PHP * may not behave correctly, or may give strange warnings. You have * been warned! It's recommended that you pick ONE of them. For sybase * support, chose 'freetds'. For mssql support choose 'mssql'. * If you have additional third party PHP extensions (such as * dev-php/eaccelerator) you may need to recompile them now. ... So now, even if I have no knowledge about PHP, I know that if something is going wrong with it I will have to check these use flags. And if I was not so lazy I would have a look at them right now to be sure nothing bad will happen. I feel more comfortable with this behavior than with a long emerge that would have stopped in the middle because of potentially conflicting use flags. (sorry for my bad English and thank you all for your good work. I just love Gentoo) Fabrice Bellamy ___ Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les tarifs exceptionnels pour appeler la France et l'international. Téléchargez sur http://fr.messenger.yahoo.com -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
Hi Mark, This draft seems to be effectively the same as the last one. On 3/2/06, Mark Loeser [EMAIL PROTECTED] wrote: * The QA team's purpose is to provide cross-team assistance in keeping the tree in a good state. This is done primarily by finding and pointing out issues to maintainers and, where necessary, taking direct action. Same as original version. * In case of emergency, or if package maintainers refuse to cooperate, the QA team may take action themselves to fix the problem. Same as original version. * The QA team may also offer to fix obvious typos and similar minor issues, and silence from the package maintainers can be taken as agreement in such situations. Same as original version. * 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. Same as original version. * In the case of disagreement on policy among QA members, the majority of established QA members must agree with the action. Same as original version. * Just because a particular QA violation has yet to cause an issue does not change the fact that it is still a QA violation. Same as original version. * If a particular developer persistently causes breakage, the QA team may request that devrel re-evaluates that developer's commit rights. Evidence of past breakages will be presented with this request to devrel. Same as original version. * The QA team will maintain a list of current QA Standards with explanations as to why they are problems, and how to fix the problem. The list is not meant by any means to be a comprehensive document, but rather a dynamic document that will be updated as new problems are discovered. The QA team will also do their best to ensure all developer tools are in line with the current QA standards. The bit about explanations as to why they are prblems, and how to fix the problem is new, as is the statement to ensure that all developer tools are in line with the current QA standards, but otherwise this is also the same. I'm sorry, but personally I don't see how this draft is substantially different from the one posted originally. It looks like you've decided not to address the points I raised about your original draft: * There's nothing in this policy about end users. If this QA team is not *focused* on delivering benefit to end users, then (as has happened this week) it becomes a self-serving team, focused instead on what can only be described as a destructive path. No-one benefits from that, no-one at all. * The QA team is asking for more than it needs to perform its role. The UNIX principle is that of least privilege. Donnie's already pointed out that FreeBSD is able to conduct effective QA without the extra power that the QA team is continuing to ask for. * There is no proposal for a process to formulate, and gain wide approval for new QA standards. This week, there's been an example of the QA team documenting a QA standard *after* a bug was raised about a QA violation ... and then that document being used as if that particular QA standard had always been in the document. Mistakes will always be made by all developers, and good QA is essential to Gentoo's future. We need a good QA team for Gentoo. Not having a QA team is, in my eyes, not an option at all. But, as this week has shown, QA members are also developers (and human), and are just as capable of making mistakes as anyone else. We need a quality assurance team that conducts all its activities in a quality manner. I'm not just talking about personal behaviour, or of any one individual. The way *everything* is done must be in a quality manner. That should mean a high quality process for creating QA standards, having them approved, and making sure developers know what changes are coming and when. That should mean high quality automated tools that cope with the real world, not some ivory tower that has no real pay-off for users. It should mean an interpretation and application of QA standards that is focused on how it improves matters for real users - and not a tick in a box QA approach. It should mean a team of educators, not a team out to bully with the mandate to do so. In twelve years of being a professional software engineer, I've never seen a successful QA team that didn't match that description above. Mark, in the discussions about the QA policy, your fallback justification always seems to be Trust us. I think this week's events have put a big dent in the credibility of that argument, if not holed it below the water line. If the QA team followed processes similar to what I've described above, I believe that this week's events wouldn't have happened. What started off as a worthy piece of QA work, which I'm sure has fixed many real problems for users, degenerated into
Re: [gentoo-dev] QA Roles v2
On Thursday 02 March 2006 03:53, Mark Loeser wrote: Here is my updated version after some feedback from people: * The QA team's purpose is to provide cross-team assistance in keeping the tree in a good state. This is done primarily by finding and pointing out issues to maintainers and, where necessary, taking direct action. * In case of emergency, or if package maintainers refuse to cooperate, the QA team may take action themselves to fix the problem. * The QA team may also offer to fix obvious typos and similar minor issues, and silence from the package maintainers can be taken as agreement in such situations. * 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. * In the case of disagreement on policy among QA members, the majority of established QA members must agree with the action. * Just because a particular QA violation has yet to cause an issue does not change the fact that it is still a QA violation. * If a particular developer persistently causes breakage, the QA team may request that devrel re-evaluates that developer's commit rights. Evidence of past breakages will be presented with this request to devrel. * The QA team will maintain a list of current QA Standards with explanations as to why they are problems, and how to fix the problem. The list is not meant by any means to be a comprehensive document, but rather a dynamic document that will be updated as new problems are discovered. The QA team will also do their best to ensure all developer tools are in line with the current QA standards. I'd like to add the following two points: * Just because breaking policy breaks a QA tool, but is guaranteed to never break itself (formatting policy, like space vs. tab etc.) does not increase the severity of the breakage. * Before any enforcement is possible, QA must establish a well supported (debated on dev-) exception policy. While it were nice if exceptions are not needed, reality is that they can not be avoided. Therefore there must be an exception policy. An exception does not mean there is no violation (so appeal is pointless). An exception means that the violation is needed because it offers important features for the user, and the benefits outweigh the costs. At the same time that an exception is allowed, steps should be undertaken to get a structural solution to the problem. QA is responsible for ensuring that the maintainer(s) of the package in question keep on doing so. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgprXCemTv9v5.pgp Description: PGP signature
Re: [gentoo-dev] QA Roles v2
On Thu, 2006-03-02 at 09:01 +, Stuart Herbert wrote: [snip] * There's nothing in this policy about end users. If this QA team is not *focused* on delivering benefit to end users, then (as has happened this week) it becomes a self-serving team, focused instead on what can only be described as a destructive path. No-one benefits from that, no-one at all. * The QA team is asking for more than it needs to perform its role. The UNIX principle is that of least privilege. Donnie's already pointed out that FreeBSD is able to conduct effective QA without the extra power that the QA team is continuing to ask for. So I see two scenarios for that: - A QA team with a purely advisory function, helping with communication. pro: no big policy changes etc. con: teethless QA may get ignored - A QA team with limited executive power, fixing bugs as they are found pro: fast turnaround times on bugs con: resistance from developers The second approach needs to be carefully implemented, people need to have trust in the QA team to empower them. * There is no proposal for a process to formulate, and gain wide approval for new QA standards. This week, there's been an example of the QA team documenting a QA standard *after* a bug was raised about a QA violation ... and then that document being used as if that particular QA standard had always been in the document. Communications issue. This thread should help fix the policies for that I hope. Mistakes will always be made by all developers, and good QA is essential to Gentoo's future. We need a good QA team for Gentoo. Not having a QA team is, in my eyes, not an option at all. Fully agreed. But, as this week has shown, QA members are also developers (and human), and are just as capable of making mistakes as anyone else. Obviously :-) We need a quality assurance team that conducts all its activities in a quality manner. I'm not just talking about personal behaviour, or of any one individual. The way *everything* is done must be in a quality manner. That should mean a high quality process for creating QA standards, having them approved, and making sure developers know what changes are coming and when. That should mean high quality automated tools that cope with the real world, not some ivory tower that has no real pay-off for users. It should mean an interpretation and application of QA standards that is focused on how it improves matters for real users - and not a tick in a box QA approach. It should mean a team of educators, not a team out to bully with the mandate to do so. That sounds like a mission statement and should be part of QA policy In twelve years of being a professional software engineer, I've never seen a successful QA team that didn't match that description above. Mark, in the discussions about the QA policy, your fallback justification always seems to be Trust us. I think this week's events have put a big dent in the credibility of that argument, if not holed it below the water line. If the QA team followed processes similar to what I've described above, I believe that this week's events wouldn't have happened. What started off as a worthy piece of QA work, which I'm sure has fixed many real problems for users, degenerated into something altogether unpleasant and unnecessary for all involved. We've all gotten a week older and a week greyer out of this. Have we fixed any real problems that stop our users installing and running Gentoo? No, we haven't. I hope we can all (and I include myself in that) learn something from this to prevent a repeat. I call for Mark's proposed policy to be rejected as it stands. I'd like to see it extended with the ideas shown in this thread. Also the QA team should consider ways of getting higher acceptance - I suggest that a general vote should be done, that's about as democratic as we can get and noone can weasel put after that (although I'm open for other processes to give the QA team support) Patrick -- Stand still, and let the rest of the universe move signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] QA Roles v2
Paul de Vrieze [EMAIL PROTECTED] said: * Just because breaking policy breaks a QA tool, but is guaranteed to never break itself (formatting policy, like space vs. tab etc.) does not increase the severity of the breakage. I had hoped something like this would have just been understood to not be too severe, since it doesn't really break anything but coding standards. * Before any enforcement is possible, QA must establish a well supported (debated on dev-) exception policy. While it were nice if exceptions are not needed, reality is that they can not be avoided. Therefore there must be an exception policy. I'm not sure what you mean here. You mean for each instance? In general? In general can be difficult since it leaves a lot of things up for interpretation. For each instance, 99% of the time an acceptable interim solution should be able to be achieved between the QA team and the maintainer. In situations where we can't figure out how to best address the situation, opening the discussion up to -dev may help, but in the end it should come down to an agreement between the maintainer and the team. -- 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 pgpa7xQtkRfX0.pgp Description: PGP signature
Re: [gentoo-dev] QA Roles v2
On Thursday 02 March 2006 14:09, Mark Loeser wrote: Paul de Vrieze [EMAIL PROTECTED] said: * Just because breaking policy breaks a QA tool, but is guaranteed to never break itself (formatting policy, like space vs. tab etc.) does not increase the severity of the breakage. I had hoped something like this would have just been understood to not be too severe, since it doesn't really break anything but coding standards. * Before any enforcement is possible, QA must establish a well supported (debated on dev-) exception policy. While it were nice if exceptions are not needed, reality is that they can not be avoided. Therefore there must be an exception policy. I'm not sure what you mean here. You mean for each instance? In general? In general can be difficult since it leaves a lot of things up for interpretation. For each instance, 99% of the time an acceptable interim solution should be able to be achieved between the QA team and the maintainer. In situations where we can't figure out how to best address the situation, opening the discussion up to -dev may help, but in the end it should come down to an agreement between the maintainer and the team. The policy should be general. It could be something like Developer and QA discuss the exception and the solution to be used. If they do not agree the council . In any case when an exception is made, appropriate bugs are created, including a bug to request a feature that makes the exception unneeded. When the requested feature is available and stable, the exception becomes invalid and the feature must be used instead. My idea is that QA can not enforce controversial things before such a policy exists. Otherwise exceptions stay only a theoretical possibility, and arguments continue. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgp5PvPaEwYUz.pgp Description: PGP signature
Re: [gentoo-dev] QA Roles v2
On Thu, 2 Mar 2006 11:35:12 +0100 Paul de Vrieze [EMAIL PROTECTED] wrote: | * Just because breaking policy breaks a QA tool, but is guaranteed to | never break itself (formatting policy, like space vs. tab etc.) | does not increase the severity of the breakage. I'd argue against this one. See, it's possible to deliberately circumvent some of repoman's checks by doing weird whitespace and syntax trickery. There's also no way to fix repoman short of writing a fully functional bash parsing tool -- which is complicated enough that even bash doesn't have one that works in some releases... -- 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] QA Roles v2
Lance Albertson [EMAIL PROTECTED] said: Ciaran McCreesh wrote: I'd argue against this one. See, it's possible to deliberately circumvent some of repoman's checks by doing weird whitespace and syntax trickery. There's also no way to fix repoman short of writing a fully functional bash parsing tool -- which is complicated enough that even bash doesn't have one that works in some releases... QA shouldn't have to depend on the tools you use. The final say should be the human interaction. If doing weird white spaces breaks the tool, but really isn't a QA issue outside of neatness, it shouldn't be waving red flags. Yes, its probably something that should be fixed, but it shouldn't be a critical one just because the tool is broken and can't handle the weirdness. I agree. Coding standards, while they may qualify as violations, are not as severe, but are definitely things we would like to see fixed. They are there to make readability across ebuilds easier since everything will be formatted the same way for a developer to see. -- 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 pgplmu4fjgdQn.pgp Description: PGP signature
Re: [gentoo-dev] QA Roles v2
On Thu, 02 Mar 2006 11:35:34 -0600 Lance Albertson [EMAIL PROTECTED] wrote: | QA shouldn't have to depend on the tools you use. Sure. However, the tree is far too large to check manually for many things. If we were to do the Sekrit Tool's IUSE check manually, for example, we'd still be in app-something, and would have missed many of the screwups. | The final say should | be the human interaction. If doing weird white spaces breaks the tool, | but really isn't a QA issue outside of neatness, it shouldn't be | waving red flags. The problem is, without fixing the syntax weirdness it's not possible to tell whether red flags should be being waved for something else. | Yes, its probably something that should be fixed, | but it shouldn't be a critical one just because the tool is broken | and can't handle the weirdness. That's the thing... Doing static analysis on bash code is ludicrously difficult. If you don't believe me, try writing a tool that will figure out all ebuilds that have a redundant src_compile. It's a heck of a lot easier to do if you assume that developers will use sane syntax. Where developers don't use sane syntax, the only way to deal with it is to check it by hand. We don't have enough developers to do that. -- 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] QA Roles v2
Ciaran McCreesh wrote: On Thu, 02 Mar 2006 11:35:34 -0600 Lance Albertson [EMAIL PROTECTED] wrote: | QA shouldn't have to depend on the tools you use. Sure. However, the tree is far too large to check manually for many things. If we were to do the Sekrit Tool's IUSE check manually, for example, we'd still be in app-something, and would have missed many of the screwups. Then fix the tool. I find it somehow ironic that a member of the QA team is trying to force a 'work-around' just to avoid fixing the source of the problem. -- Kind Regards, Simon Stelling Gentoo/AMD64 Member -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
On Thu, 02 Mar 2006 19:09:28 +0100 Simon Stelling [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | On Thu, 02 Mar 2006 11:35:34 -0600 Lance Albertson | [EMAIL PROTECTED] wrote: | | QA shouldn't have to depend on the tools you use. | | Sure. However, the tree is far too large to check manually for many | things. If we were to do the Sekrit Tool's IUSE check manually, for | example, we'd still be in app-something, and would have missed many | of the screwups. | | Then fix the tool. I find it somehow ironic that a member of the QA | team is trying to force a 'work-around' just to avoid fixing the | source of the problem. How? Writing a full bash parser is extremely difficult and would be a complete waste of time. It's far saner to assume sane syntax, and just bail out when crazy stuff is encountered. Sane syntax is not a work around -- it's a basic thing that should be expected from any source file that has to be worked on by more than one person, or even one person over a long period of time. Syntax is already, at least to a certain extent, mandated by policy. The question at hand is whether violations of this policy should be effectively ignored, or whether they should be treated as potentially severe simply because they mask other problems. -- 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] QA Roles v2
Ciaran McCreesh [EMAIL PROTECTED] said: It's a heck of a lot easier to do if you assume that developers will use sane syntax. Where developers don't use sane syntax, the only way to deal with it is to check it by hand. We don't have enough developers to do that. I don't see where anyone is saying that we shouldn't fix things to adhere to coding standards. We are just saying it is not a, OMG you broke it! problem. It is about appropriate responses to the problems we encounter. -- 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 pgpLZFPLlfZyj.pgp Description: PGP signature
Re: [gentoo-dev] QA Roles v2
Ciaran McCreesh wrote: On Thu, 02 Mar 2006 19:09:28 +0100 Simon Stelling [EMAIL PROTECTED] wrote: | Ciaran McCreesh wrote: | On Thu, 02 Mar 2006 11:35:34 -0600 Lance Albertson | [EMAIL PROTECTED] wrote: | | QA shouldn't have to depend on the tools you use. | | Sure. However, the tree is far too large to check manually for many | things. If we were to do the Sekrit Tool's IUSE check manually, for | example, we'd still be in app-something, and would have missed many | of the screwups. | | Then fix the tool. I find it somehow ironic that a member of the QA | team is trying to force a 'work-around' just to avoid fixing the | source of the problem. How? Writing a full bash parser is extremely difficult and would be a complete waste of time. It's far saner to assume sane syntax, and just bail out when crazy stuff is encountered. Sane syntax is not a work around -- it's a basic thing that should be expected from any source file that has to be worked on by more than one person, or even one person over a long period of time. It should be a basic thing to expect the QA tool knows how to bail out correctly and resume looking for more important critical issues. QA should not revolve around the tools you use. Technical difficulties in the QA tool dealing with weird syntax's should not provoke a red flag on a particular package. Yes, those weirdness issues should be fixed, but the tool should not hinder the overall outcome of the QA process. So what if it takes too much time to fix it, then just have it ignore that package (and mark it to be viewed later by hand) and move on to the next package. -- 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] QA Roles v2
On Thu, 02 Mar 2006 13:15:48 -0600 Lance Albertson [EMAIL PROTECTED] wrote: | It should be a basic thing to expect the QA tool knows how to bail out | correctly and resume looking for more important critical issues. Sure. But what if more important critical issues are being masked by weird syntax? | QA should not revolve around the tools you use. There are not enough people to check the entire tree by hand. Even if there were, manual checks are extremely tricky to do properly. Humans are extremely bad at picking out errors like transposed letters or a missed captial in a package name. The tools are extremely important. Without them most QA mistakes will go unnoticed until they cause breakage. | Technical difficulties in the QA tool dealing with weird syntax's | should not provoke a red flag on a particular package. Not flagging a weird package can lead to breakage being missed. | So what if it takes too much time to fix it, then just have it ignore | that package (and mark it to be viewed later by hand) and move on to | the next package. Doable, but not reliably, only for so long as it's a very small number of affected packages. Here's why manual checks don't scale. Some of the following *DEPEND specifications are broken. Some are not. Without using a tool, pick out which ones are broken. Then say how long it took you to do it. For comparison, at least one QA tool can do these in well under a hundredth of a second. RDEPEND=|| ( ( x11-libs/libXext x11-libs/libX11 x11-libs/libXau x11-libs/libXdmcp x11-libs/libXkbui ) virtual/x11 ) DEPEND=~app-editors/vim-core-7.0_alpha20060228 || ( x11-libs/libXext virtual/x11 ) !aqua? ( gtk? ( =x11-libs/gtk+-2.6 virtual/xft gnome? ( =gnome-base/libgnomeui-2.6* ) ) !gtk? ( motif? ( x11-libs/openmotif ) !motif? ( nextaw? ( x11-libs/neXtaw ) !nextaw? ( || ( x11-libs/libXaw virtual/x11 ) ) ) ) ) !bootstrap? ( sys-devel/patch ) cscope? ( dev-util/cscope ) gpm? ( =sys-libs/gpm-1.19.3 ) perl? ( dev-lang/perl ) python? ( dev-lang/python ) acl? ( sys-apps/acl ) ruby? ( virtual/ruby ) mzscheme? ( dev-lisp/mzscheme ) netbeans? ( dev-util/netbeans ) =sys-apps/sed-4 sys-devel/autoconf dev-util/ctags =sys-libs/ncurses-5.2-r2 RDEPEND= ( !gnome-base/gnome-core =dev-libs/glib-2.8.6 =x11-libs/gtk+-2.8.11 =dev-libs/atk-1.10.3 =x11-libs/pango-1.10.3 =dev-libs/libxml2-2.6.23 =dev-libs/libxslt-1.1.15 =media-libs/audiofile-0.2.6-r1 =media-sound/esound-0.2.36 =x11-libs/libxklavier-2 =media-libs/libart_lgpl-2.3.17 =dev-libs/libIDL-0.8.6 =gnome-base/orbit-2.12.5 =x11-libs/libwnck-2.12.3 =x11-wm/metacity-2.12.3 =gnome-base/gnome-keyring-0.4.6 =gnome-extra/gnome-keyring-manager-2.12 =gnome-base/gnome-vfs-2.12.2 =gnome-base/gnome-mime-data-2.4.2 =gnome-base/gconf-2.12.1 =net-libs/libsoup-2.2.7 =gnome-base/libbonobo-2.10.1 =gnome-base/libbonoboui-2.10.1 =gnome-base/libgnome-2.12.0.1 =gnome-base/libgnomeui-2.12 =gnome-base/libgnomecanvas-2.12 =gnome-base/libglade-2.5.1 =gnome-extra/bug-buddy-2.12.1 =gnome-base/control-center-2.12.3 =gnome-base/eel-2.12.2 =gnome-base/nautilus-2.12.2 =media-libs/gstreamer-0.8* =media-libs/gst-plugins-0.8* =gnome-extra/gnome-media-2.12 =media-sound/sound-juicer-2.12.3 =media-video/totem-1.2.1 =media-gfx/eog-2.12.3 =www-client/epiphany-1.8.4.1 =app-arch/file-roller-2.12.3 =gnome-extra/gcalctool-5.6.31 =gnome-extra/gconf-editor-2.12.1 =gnome-base/gdm-2.8.0.7 =x11-libs/gtksourceview-1.4.2 =app-editors/gedit-2.12.1 =app-text/evince-0.4.0 =gnome-base/gnome-desktop-2.12.3 =gnome-base/gnome-session-2.12.0 =gnome-base/gnome-applets-2.12.3 =gnome-base/gnome-panel-2.12.3 =gnome-base/gnome-menus-2.12.0 =x11-themes/gnome-icon-theme-2.12.1 =x11-themes/gnome-themes-2.12.3 =x11-themes/gtk-engines-2.6.7 =x11-themes/gnome-backgrounds-2.12.3.1 =x11-libs/vte-0.11.17 =x11-terms/gnome-terminal-2.12.0 =gnome-extra/gucharmap-1.4.4 =gnome-base/libgnomeprint-2.12.1 =gnome-base/libgnomeprintui-2.12.1 =gnome-extra/gnome-utils-2.12.2 =gnome-extra/gnome-games-2.12.3 =gnome-base/librsvg-2.12.7 =gnome-extra/gnome-system-monitor-2.12.2 =gnome-base/libgtop-2.12.2 =x11-libs/startup-notification-0.8 =gnome-extra/gnome2-user-docs-2.8.1 =gnome-extra/yelp-2.12.2 =gnome-extra/zenity-2.12.1 =net-analyzer/gnome-netstatus-2.12.0 =net-analyzer/gnome-nettool-1.4.1 cdr? ( =gnome-extra/nautilus-cd-burner-2.12.3 ) dvdr? ( =gnome-extra/nautilus-cd-burner-2.12.3 ) hal? ( =gnome-base/gnome-volume-manager-1.5.4 ) =gnome-extra/gtkhtml-3.8.2 =mail-client/evolution-2.4.2.1 =gnome-extra/evolution-data-server-1.4.2.1 =gnome-extra/evolution-webcal-2.4.1 =net-misc/vino-2.12.0 =app-admin/gnome-system-tools-1.4.1 =app-admin/system-tools-backends-1.4.2 accessibility? ( =gnome-extra/libgail-gnome-1.1.3 =gnome-base/gail-1.8.8 =gnome-extra/at-spi-1.6.6 =app-accessibility/dasher-3.2.18 =app-accessibility/gnome-mag-0.12.3 =app-accessibility/gnome-speech-0.3.9 =app-accessibility/gok-1.0.5 =app-accessibility/gnopernicus-0.11.8 ) ) -- Ciaran McCreesh : Gentoo Developer (Wearer of the
Re: [gentoo-dev] QA Roles v2
On Thursday 02 March 2006 17:45, Ciaran McCreesh wrote: On Thu, 2 Mar 2006 11:35:12 +0100 Paul de Vrieze [EMAIL PROTECTED] wrote: | * Just because breaking policy breaks a QA tool, but is guaranteed to | never break itself (formatting policy, like space vs. tab etc.) | does not increase the severity of the breakage. I'd argue against this one. See, it's possible to deliberately circumvent some of repoman's checks by doing weird whitespace and syntax trickery. There's also no way to fix repoman short of writing a fully functional bash parsing tool -- which is complicated enough that even bash doesn't have one that works in some releases... I'm also convinced that deliberate circumvention is easy to detect. QA should be able to fix these issues on itself anyway. If people deliberately subvert QA in these kinds of way, In my opinion, they are in need of a serious talk with devrel. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpHUMOGgR5Vl.pgp Description: PGP signature
Re: [gentoo-dev] QA Roles v2
On Thu, 2 Mar 2006 21:10:02 +0100 Paul de Vrieze [EMAIL PROTECTED] wrote: | I'm also convinced that deliberate circumvention is easy to detect. In that case, please provide a list of cases where !arch? flags are being used to circumvent repoman warnings, where the correct solution would be to use use.mask. My reasonably educated guess is that this is the most common kind of deliberate circumvention to avoid a repoman error. Unfortunately, detecting foo? ( !arch? ( somepackage ) ) gets a whole load of false positives. I already tried that one without success... -- 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] QA Roles v2
On Thursday 02 March 2006 19:28, Mark Loeser wrote: Ciaran McCreesh [EMAIL PROTECTED] said: It's a heck of a lot easier to do if you assume that developers will use sane syntax. Where developers don't use sane syntax, the only way to deal with it is to check it by hand. We don't have enough developers to do that. I don't see where anyone is saying that we shouldn't fix things to adhere to coding standards. We are just saying it is not a, OMG you broke it! problem. It is about appropriate responses to the problems we encounter. That is my point exactly. I do encourage QA though to make available a list of those syntax issues that break their tools. Take it for a positive spin, developers will then be prepared to accomodate QA. We all want quality. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgptQ7HUvX6fU.pgp Description: PGP signature
Re: [gentoo-dev] QA Roles v2
On 02-03-2006 20:19:19 +, Ciaran McCreesh wrote: On Thu, 2 Mar 2006 21:10:02 +0100 Paul de Vrieze [EMAIL PROTECTED] wrote: | I'm also convinced that deliberate circumvention is easy to detect. In that case, please provide a list of cases where !arch? flags are being used to circumvent repoman warnings, where the correct solution Circumvent? Can you elaborate on that? repoman does have a problem with this, while portage does not. -- Fabian Groffen -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
On Thursday 02 March 2006 21:19, Ciaran McCreesh wrote: On Thu, 2 Mar 2006 21:10:02 +0100 Paul de Vrieze [EMAIL PROTECTED] wrote: | I'm also convinced that deliberate circumvention is easy to detect. In that case, please provide a list of cases where !arch? flags are being used to circumvent repoman warnings, where the correct solution would be to use use.mask. My reasonably educated guess is that this is the most common kind of deliberate circumvention to avoid a repoman error. Then explain people that doing this is not the way. I would suspect that people think that this is the actual solution. It's also not really like people would do this to hide the fact that they have hidden a global rm -rf somewhere around.And is it really a quality issue? In all cases? There must be cases where the problem is package + arch + useflag specific, and this solution solves it. What I mean with deliberate, is circumventing when knowing it is wrong. If people know it's wrong, and still do it, they are clearly malvolent. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpDiTiKMvNES.pgp Description: PGP signature
Re: [gentoo-dev] QA Roles v2
On Thu, 2 Mar 2006 21:29:30 +0100 Grobian [EMAIL PROTECTED] wrote: | On 02-03-2006 20:19:19 +, Ciaran McCreesh wrote: | On Thu, 2 Mar 2006 21:10:02 +0100 Paul de Vrieze [EMAIL PROTECTED] | wrote: | | I'm also convinced that deliberate circumvention is easy to | | detect. | | In that case, please provide a list of cases where !arch? flags are | being used to circumvent repoman warnings, where the correct | solution | | Circumvent? Can you elaborate on that? repoman does have a problem | with this, while portage does not. Okay. This is a rather hypothetical example, since alsa is masked on relevant profiles, but it's a nice, easy to understand case that's on a worryingly common theme. Say you create a new package, which we'll call mysoundthing. You add mysoundthing 1.1 to the tree, and it picks up a ~sparc keyword. Along comes mysoundthing 1.2, complete with optional ALSA support. You add in a dep of alsa? ( whatever the alsa libraries are these days ), and try to commit it. Repoman complains that the alsa libraries are unkeyworded on sparc. Now, you've heard that dropping keywords is bad. But you have a clever idea, and make the dep alsa? ( !sparc? ( alsa libraries ) ). This gets past repoman just fine. Along comes 2006 (or late 2005), and some sparc profiles get working ALSA support. So, the ALSA libraries are keyworded / profile masked as appropriate. Along comes joeuser, who installs mysoundthing. He wants ALSA support, so he turns on the alsa USE flag. Sure enough, emerge -pv indicates that ALSA will be enabled. However... Because of the nasty !arch? hack, he won't get alsa support until the arch team goes through and fixes this ebuild (and probably several others too...). The correct solution is to get the alsa USE flag use.masked on various profiles (as, in the alsa case, it is). However, there are a whooole load of ebuilds in the tree that don't do this properly. Scary sidenote: a similar hack has lead to some forums users suggesting that the way to avoid getting mozilla as part of gnome was to use USE=mips. This issue has been a major pain in the ass for some of the arch teams, and it will very likely be another major pain in the ass in the future, again and again. -- 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] QA Roles v2
On Thu, 2 Mar 2006 21:38:33 +0100 Paul de Vrieze [EMAIL PROTECTED] wrote: | Then explain people that doing this is not the way. Have done, repeatedly, as have many others. | And is it really a qualityissue? In all cases? There must be cases | where the problem is package + arch + useflag specific, and this | solution solves it. This is most definitely a quality issue in cases where it is misused. See my reply to Grobian for why it's a huge problem. And yes, there are legit cases of using !arch? inside DEPEND, which is what makes it even harder to detect deliberate repoman circumvention. -- 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] QA Roles v2
Stuart Herbert [EMAIL PROTECTED] said: Hi Mark, This draft seems to be effectively the same as the last one. I'm sorry, but personally I don't see how this draft is substantially different from the one posted originally. It looks like you've decided not to address the points I raised about your original draft: I never said it was different. I said I added some things based on feedback I got. As I said in the last thread, I disagree with many of the things you have come up with. You are free to try and convince me otherwise. -- 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 pgpsVcWsbNh6w.pgp Description: PGP signature
Re: [gentoo-dev] QA Roles v2
On Thursday 02 March 2006 21:51, Ciaran McCreesh wrote: On Thu, 2 Mar 2006 21:38:33 +0100 Paul de Vrieze [EMAIL PROTECTED] wrote: | Then explain people that doing this is not the way. Have done, repeatedly, as have many others. | And is it really a qualityissue? In all cases? There must be cases | where the problem is package + arch + useflag specific, and this | solution solves it. This is most definitely a quality issue in cases where it is misused. See my reply to Grobian for why it's a huge problem. And yes, there are legit cases of using !arch? inside DEPEND, which is what makes it even harder to detect deliberate repoman circumvention. I've read your explanation in the other reply. I agree with you that it is indeed an issue. Paul ps. The explanation was clear to me. -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpyjB4SoEQ9o.pgp Description: PGP signature
Re: [gentoo-dev] QA Roles v2
On Thu, 2006-03-02 at 20:49 +, Ciaran McCreesh wrote: Now, you've heard that dropping keywords is bad. But you have a clever idea, and make the dep alsa? ( !sparc? ( alsa libraries ) ). This gets past repoman just fine. STOP As any arch can tell you, that's never stopped me - *IF* you do it correctly, ie comment out the existing keywords, add the keywords that the package can support, and file a bug against the arch's that you had to drop explaining the need for re-keywording because of a new dep that they don't yet support. AFAIK that's the correct way to do it - and I believe that pretty strongly since at this point there isn't a single arch that wouldn't have filed a grievance against me otherwise. Sure, those bugs may stay open for months and months and months because ia64 doesn't have the resources to devote (which is understood), but at that point you have 2 references for users, the ebuild with the commented out line, the ChangeLog, and the bug. Is this not how its supposed to be done? Because if it is, maybe those insistant on the !arch method should be pointed to that and leave it up to the arch's to make the decision of whether to keyword or disable specific support. Devs acting on behalf of a herd shouldn't be making these kind of arch decisions, but instead leaving it up to devs acting with their arch hats on. Maybe the two meet under the same roof sometimes, but more times than not they don't. Yep, that's a lot more work and effort and pain - but afaik it follows good qa methods. And despite the length of this message, I haven't spoken on one side of the fence or the other I think...sweet :) ~mcummings signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] QA Roles v2
On Thu, 02 Mar 2006 16:19:58 -0500 Michael Cummings [EMAIL PROTECTED] wrote: | On Thu, 2006-03-02 at 20:49 +, Ciaran McCreesh wrote: | Now, you've heard that dropping keywords is bad. But you have a | clever idea, and make the dep alsa? ( !sparc? ( alsa libraries ) ). | This gets past repoman just fine. | | STOP As any arch can tell you, that's never stopped me - *IF* you do | it correctly, ie comment out the existing keywords, add the keywords | that the package can support, and file a bug against the arch's that | you had to drop explaining the need for re-keywording because of a | new dep that they don't yet support. AFAIK that's the correct way to | do it Yup. I probably should've mentioned that as part of the explanation... The correct way to proceed, in the general case, is to contact the arch team and ask them to use.mask or keyword deps as appropriate. Keywords can be dropped if and only if a bug is filed. -- 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] QA Roles v2
On Thursday 02 March 2006 16:19, Michael Cummings wrote: On Thu, 2006-03-02 at 20:49 +, Ciaran McCreesh wrote: Now, you've heard that dropping keywords is bad. But you have a clever idea, and make the dep alsa? ( !sparc? ( alsa libraries ) ). This gets past repoman just fine. STOP As any arch can tell you, that's never stopped me yes, but you do not represent every single dev :) we still have occurrences in the tree where people wrongly utilize the aforementioned syntax ... -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
On Thursday 02 March 2006 04:01, Stuart Herbert wrote: * There is no proposal for a process to formulate, and gain wide approval for new QA standards. This week, there's been an example of the QA team documenting a QA standard *after* a bug was raised about a QA violation ... and then that document being used as if that particular QA standard had always been in the document. i chatted on irc with a few peeps about this and here's what has been rolling around in my noggin ... we're going to have two documents of sorts ... the balls-to-the-wall happy-to-be-hardcore nothing-more-official-than-this devrel document ... and then we're going to have the stop-cant-stop-my-feet QA guidelines which is quite dynamic and meant to outline what the QA team is looking for at any particular point in time to get into the QA guidelines, you go through the QA team ... to get into the devrel document, you go through the devrel doc maintainers. to increase visibility here, i think that all significant changes to policy that are Incorporated into the devrel handbook should have a notice sent to the gentoo dev mailing list first. thus if people strongly object, we can resolve those differences without having people upset when something they disagree with and have never heard of is thrown in their FACE. as for the QA document, there is a QA list where notifications/changes can be sent. then over time we can move relevant pieces of the QA document into the devrel document. -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
On Wednesday 01 March 2006 21:53, Mark Loeser wrote: Here is my updated version after some feedback from people: * In case of emergency, or if package maintainers refuse to cooperate, the QA team may take action themselves to fix the problem. * The QA team may also offer to fix obvious typos and similar minor issues, and silence from the package maintainers can be taken as agreement in such situations. * 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. one thing i dont think we give enough emphasis to is that our tools arent perfect ... sometimes we utilize QA violations to work around portage limitations ... if you want to see some really sweet hacks, review any of the toolchain related ebuilds and the hacks ive had to add to get cross-compiling to the usuable state that it is today. a handful of them would fall under the 'severe' category i'm sure. and if we want to use the lovely php example, personally i think that given portage's current limitations, the latest dev-lang/php ebuild is probably one of the best solutions that could have been developed, thanks Stuart for all the flak you've had to take over this. also, many games ebuilds break the 'non-interactive' policy by displaying licensing and making the user hit Y because portage lacks checks where the user explicitly states what licenses they accept. -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] QA Roles v2
Mike Frysinger [EMAIL PROTECTED] said: one thing i dont think we give enough emphasis to is that our tools arent perfect ... sometimes we utilize QA violations to work around portage limitations ... if you want to see some really sweet hacks, review any of the toolchain related ebuilds and the hacks ive had to add to get cross-compiling to the usuable state that it is today. a handful of them would fall under the 'severe' category i'm sure. and if we want to use the lovely php example, personally i think that given portage's current limitations, the latest dev-lang/php ebuild is probably one of the best solutions that could have been developed, thanks Stuart for all the flak you've had to take over this. also, many games ebuilds break the 'non-interactive' policy by displaying licensing and making the user hit Y because portage lacks checks where the user explicitly states what licenses they accept. This somewhat touchs on what pauldv mentioned earlier, that we will acknowledge when no better possible solution is available, and some workaround is needed. As he also suggested, we should keep a list of these in the form of open bugs so that we can get a better solution somewhere in the long-term. -- 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 pgpZANo2PW7H2.pgp Description: PGP signature
Re: [gentoo-dev] QA Roles v2
Mark Loeser wrote: Here is my updated version after some feedback from people: * In the case of disagreement on policy among QA members, the majority of established QA members must agree with the action. What is an Established QA member? I guess this won't be reviewed by the council for another month, but I'd like to get all of the debate out of the way now. Please lets keep the discussion on topic and constructive. Thanks, signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] QA Roles v2
Alec Warner [EMAIL PROTECTED] said: Mark Loeser wrote: Here is my updated version after some feedback from people: * In the case of disagreement on policy among QA members, the majority of established QA members must agree with the action. What is an Established QA member? Listed on the QA website and approved by the current QA lead. -- 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 pgpoG5RBk9TZX.pgp Description: PGP signature
Re: [gentoo-dev] QA Roles v2
Mark Loeser [EMAIL PROTECTED] said: Here is my updated version after some feedback from people: * The QA team's purpose is to provide cross-team assistance in keeping the tree in a good state. This is done primarily by finding and pointing out issues to maintainers and, where necessary, taking direct action. * In case of emergency, or if package maintainers refuse to cooperate, the QA team may take action themselves to fix the problem. * The QA team may also offer to fix obvious typos and similar minor issues, and silence from the package maintainers can be taken as agreement in such situations. * 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. * In the case of disagreement on policy among QA members, the majority of established QA members must agree with the action. * Just because a particular QA violation has yet to cause an issue does not change the fact that it is still a QA violation. * If a particular developer persistently causes breakage, the QA team may request that devrel re-evaluates that developer's commit rights. Evidence of past breakages will be presented with this request to devrel. * The QA team will maintain a list of current QA Standards with explanations as to why they are problems, and how to fix the problem. The list is not meant by any means to be a comprehensive document, but rather a dynamic document that will be updated as new problems are discovered. The QA team will also do their best to ensure all developer tools are in line with the current QA standards. I'm happy enough to send the above to the Council. I think the only issue will be with bullet point 4. I know that the QA team as a whole like the wording this way leaving the onus on the package maintainer to prove the merrits of their package rather then having the onus on the QA team to prove fault. Personally I also like the wording this way (in most cases). In the cases where a clear technical solution presents itself to the problems the package presents that does not change the intended behavior (unless said behavior is what is broken) and the maintainer still refuses to apply the neceesary changes I think that the QA team should be cleared to make them. This is all under the understanding that the maintainer has the right to appeal in order to revert said changes. The tougher call comes when the severity of a QA violation comes into question. If the QA team presents a problem to a maintainer that they believe is severe enough to warrant a package's removal and no technical solution has presented itself to either the QA team or the maintainer to work around the issue I think that the QA team should have the right to hard mask the package pending an appeal. In such cases I'd almost say that an appeal should be automatically triggered so that a decision about the true severity of the QA issue can be ironed out. I certainly hope that there will be few enough of these that the council will not end up bogged down in policy decisions and QA conflict mediation. The above also has to be done on a case by case basis, if hardmasking a package would cause wide tree breakage itself then another choice has to be made. Concurrent with the above what I'd like to see is the QA team showing a willingness to help maintainers find workarounds to particualarly sticky violations. I'm not saying that they should have to learn the packages inside out or that they should not be allowed to act until a solution is found just that they should put a certain level of effort into helping find (or concoct) a solution. This is not to say that they are not doing this now, however, as has been said in the prior incarnation of this thread I also believe that the stickier problems are likely to arise because the maintainer in question did not see a better solution, so part of QA's roll should be to help educate the developer community. All in all the one thing I'd like to aviod is QA bugs getting closed as invalid (one of the events that lead up to this thread). I know there is a sense of territory with the ebuilds one maintains, but I'd really like to see an effort made to allow the QA team to explain themselves. If a bug gets opened up on one of your pacakges and it is unclear to you why something is a QA issue either comment on the bug asking th QA team to explain (and I consider pointing someone to existing offial documentation so long as it contains an explanation of what is wrong and how to generally fix such issues to be a valid explanation) or ping them online. I really hope that noone thinks the QA team is out to get them. They are here to make the experiance better for all of us as a whole (even if that sometimes means that the experiance for a particular package or
Re: [gentoo-dev] QA Roles v2
Daniel Ostrow [EMAIL PROTECTED] said: The above also has to be done on a case by case basis, if hardmasking a package would cause wide tree breakage itself then another choice has to be made. I agree. We aren't here to make a situation even worse, and we acknowledge that we won't always get the perfect solution right away and that flexibility is required. -- 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 pgpavwNoVjNzV.pgp Description: PGP signature
Re: [gentoo-dev] QA Roles v2
[deleted] All seems fair enough, but please fix portage qa issues before this policy is applied (see bug http://bugs.gentoo.org/show_bug.cgi?id=123733). signature.asc Description: OpenPGP digital signature
