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[2]: [gentoo-dev] [RFC] QA Team's role
1.3.2006, 11:29:47, Danny van Dyk wrote: | 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. Sure I did... that's not the breakage of a QA tool ciaranm has been talking about, though. If some tool stops to work b/c of spacing/indenting issues, then it's broken. Meanwhile, if you can't bear formating/whitespace issues, then either fix it yourself or file a bug and wait until someone gets to it or fixes it when next revbump/another bunch of more important fixes is due. Expecting that someone will fix a cosmetic issue within five minutes from the time when a bug is filed and ranting about it on #gentoo-qa and mailing lists isn't useful but rather plain annoying. -- jakub pgpR49V6Zhcqz.pgp Description: PGP signature
Re: [gentoo-dev] SLOTed MySQL or not?
Luca Longinotti wrote: As the title says, what would you prefer for the future of MySQL in Gentoo? Please take a moment to read https://forums.gentoo.org/viewtopic-t-438557.html and vote (and eventually comment on it). Thanks! I've asked to Luca to have one week poll but the results [1] show already that MySQL will be unslotted at the end. Thank you to spend the time to do that I should do it _before_ to try the slotting road (and may be speak with the other MySQL maintainer before :p). Luca (chtekk) Longinotti, will also take care of MySQL, on my request, in a near future, then I'll stay as a backup maintainer for the time coming, or leave if needed for whatever reason. Before to this to happen I'll try my best to close the greatest number of bugs still open (many already are but not committed) and manage to bring MySQL back to the unslotted version. [1] Yes. 12% [ 12 ] No. 75% [ 72 ] No preference. 11% [ 11 ] Best regards, Francesco Riosa -- 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[2]: [gentoo-dev] [RFC] QA Team's role
1.3.2006, 13:09:55, Paul de Vrieze wrote:
On Tuesday 28 February 2006 21:20, Ciaran McCreesh wrote:
| if [ ${IS_UPGRADE} = 1 ] ; then
| einfo Removing old version ${REMOVE_PKG}
|
| emerge -C ${REMOVE_PKG}
| fi
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.
Well yeah, but the problem here is that portage doesn't allow such stuff to
be used safely (locking issues, race conditions). And yeah, it's kinda
lacking sort of feature that would have its use in a couple of places.
--
jakub
pgpaEP0jPlTm4.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
[gentoo-dev] Re: [gentoo-core] Resignation
Donnie Berkholz posted [EMAIL PROTECTED], excerpted below, on Wed, 01 Mar 2006 01:51:03 -0800: Brian Harring wrote: Been an interesting two some years, but have decided it's time for me to turn in my resignation and wander on to things outside of gentoo. If you need to track me down, I'll be checking [EMAIL PROTECTED] . So... yeah, so long and thanks for all the fish :) Best of luck in your future endeavors. Don't think this gets you out of hanging out with me while you're in Oregon! Seeing this news makes me very sad, as ferringb was a name I had associated with trust and integrity of opinion and developer skills. It's certainly a loss for Gentoo, and as Gentoo is now a part of me, a loss I'll feel personally, as well, but unfortunately, those times do come. As with Donnie and the others, only user to dev, I wish you well. May our paths meet again! -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [gentoo-core] Resignation
On 3/1/06, Donnie Berkholz [EMAIL PROTECTED] wrote: Brian Harring wrote: Hola all. Been an interesting two some years, but have decided it's time for me to turn in my resignation and wander on to things outside of gentoo. If you need to track me down, I'll be checking [EMAIL PROTECTED] . So... yeah, so long and thanks for all the fish :) Damn shame to see you go. You were one of the people who made it a pleasure to work on Gentoo. Best regards, Stu -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Monthly Gentoo Council Reminder for March
This is your monthly friendly reminder ! Same bat time (typically the 2nd Thursday once a month), same bat channel (#gentoo-council @ irc.freenode.net) ! If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. Keep in mind that every *re*submission to the council for review must first be sent to the gentoo-dev mailing list 7 days (minimum) before being submitted as an agenda item which itself occurs 7 days before the meeting. Simply put, the gentoo-dev mailing list must be notified at least 14 days before the meeting itself. For more info on the Gentoo Council, feel free to browse our homepage: http://www.gentoo.org/proj/en/council/ -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] how to turn off hardened gcc flags reliably?
All, I'm hoping for some suggestions particularly from the toolchain and hardened profile folk. We have a compiler that goes via C and uses gcc as it's backend. This compiler does some pretty unpleasant things with the assembler output of gcc. For one thing it doesn't use the C stack. It strips off the prelude and epilogue of each function. Anyway, Suffice to say that it doesn't work with hardened gcc; that is both PIE and the stack protector. However turning these features off (by passing -nopie -fno-stack-protector to gcc) is not so easy when we consider that people can upgrade their gcc or change from a vanilla to a hardened profile *after* emerging ghc. gcc-3 supports both -nopie and -fno-stack-protector. So always using these would be ok if it were not for gcc-4 which doesn't grok -fno-stack-protector. If we don't use -fno-stack-protector then if someone changes from a vanilla gcc profile to a hardened one then the users will get breakage when they start using ghc again. We could have the ghc driver script work out dynamically which flags to pass to gcc to suppress the hardened stuff but I think we can all see the downside to that. We could say don't switch to a hardened gcc profile - it doesn't work. We could say don't use gcc 4 - it' not supported. However this will not last forever. We could ask the gcc-config people for some assistance. Perhaps by adding an extra env var GHC_CFLAGS that gives us the right flags. Or perhaps by hooking into gcc-config to have our flags updated whenever the user changes profile. Does anyone have any other suggestions? -- Duncan Coutts : Gentoo Developer (Haskell herd team lead) email : dcoutts at gentoo dot org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] how to turn off hardened gcc flags reliably?
On Wednesday 01 March 2006 10:35, Duncan Coutts wrote: gcc-3 supports both -nopie and -fno-stack-protector. So always using these would be ok if it were not for gcc-4 which doesn't grok -fno-stack-protector. yes it does every gcc in portage by default supports -fno-stack-protector -mike -- 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] how to turn off hardened gcc flags reliably?
On Wed, 2006-03-01 at 11:39 -0500, Mike Frysinger wrote: On Wednesday 01 March 2006 10:35, Duncan Coutts wrote: gcc-3 supports both -nopie and -fno-stack-protector. So always using these would be ok if it were not for gcc-4 which doesn't grok -fno-stack-protector. yes it does Oh. I had reports from ppc devs who said that gcc-4 didn't recognise that flag. I also heard that gcc-4 contains a re-written stack protector implementation with different semantics and that was why it didn't recognise the flag anymore. every gcc in portage by default supports -fno-stack-protector So that includes gcc 4 then. Well that makes life easier. :-) I presume it's a gentoo patch to gcc-4 to add back in -fno-stack-protector? -- Duncan Coutts : Gentoo Developer (Haskell herd team lead) email : dcoutts at gentoo dot org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] how to turn off hardened gcc flags reliably?
On Wed, 2006-03-01 at 17:17 +, Duncan Coutts wrote: On Wed, 2006-03-01 at 11:39 -0500, Mike Frysinger wrote: On Wednesday 01 March 2006 10:35, Duncan Coutts wrote: gcc-3 supports both -nopie and -fno-stack-protector. So always using these would be ok if it were not for gcc-4 which doesn't grok -fno-stack-protector. yes it does Oh. I had reports from ppc devs who said that gcc-4 didn't recognise that flag. I also heard that gcc-4 contains a re-written stack protector implementation with different semantics and that was why it didn't recognise the flag anymore. every gcc in portage by default supports -fno-stack-protector So that includes gcc 4 then. Well that makes life easier. :-) I presume it's a gentoo patch to gcc-4 to add back in -fno-stack-protector? For the 4.0.x it should be just a dummy call. For 4.1 it is included. What does change and is really uncool with 4.1 is that -fno-stack-protector-all is missing and wont be added back without several somebodies making a case for it upstream. -- solar [EMAIL PROTECTED] Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] how to turn off hardened gcc flags reliably?
On Wednesday 01 March 2006 12:17, Duncan Coutts wrote: On Wed, 2006-03-01 at 11:39 -0500, Mike Frysinger wrote: On Wednesday 01 March 2006 10:35, Duncan Coutts wrote: gcc-3 supports both -nopie and -fno-stack-protector. So always using these would be ok if it were not for gcc-4 which doesn't grok -fno-stack-protector. yes it does Oh. I had reports from ppc devs who said that gcc-4 didn't recognise that flag. it does and it doesnt ... official gcc-4.0.x lacks ssp support, but official gcc-4.1.x has it I presume it's a gentoo patch to gcc-4 to add back in -fno-stack-protector? yes -mike -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] glep 0042 (news) final draft
Attached is the final draft. No substantial changes since last time, just wording cleanups and a few clarifications. You'll be able to see it here in an hour or three (check the dates!): http://www.gentoo.org/proj/en/glep/glep-0042.html Or you can try to read the attached RST source, but no moaning that it looks weird if you do. Unless there are any huge flaws found, I'd like this to be voted on by the council -- looks like it'll have to wait until April's meeting to fit in with the two weeks rule. -- Ciaran McCreesh : Gentoo Developer (Wearer of the shiny hat) Mail: ciaranm at gentoo.org Web : http://dev.gentoo.org/~ciaranm GLEP: 42 Title: Critical News Reporting Version: $Revision: $ Author: Ciaran McCreesh [EMAIL PROTECTED] Last-Modified: $Date: $ Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 31-Oct-2005 Post-History: 1-Nov-2005, 5-Nov-2005, 7-Nov-2005, 11-Dec-2005, 13-Dec-2005, 18-Dec-2005, 5-Jan-2006, 2-Mar-2005 Abstract This GLEP proposes a new way of informing users about important updates and news related to the tree. Motivation == Although most package updates are clean and require little user action, occasionally an upgrade requires user intervention. Recent examples of the latter include the ``gcc-3.4`` stabilisation on ``x86`` and the ``mysql-4.1`` database format changes. There are currently several ways of delivering important news items to our users, none of them particularly effective: * Gentoo Weekly News * The ``gentoo-announce``, ``gentoo-user`` and ``gentoo-dev`` mailing lists * The Gentoo Forums * The main Gentoo website * RSS feeds of Gentoo news * ``einfo`` and ``ewarn`` messages in ``pkg_setup`` or ``pkg_postinst`` A more reliable way of getting news of critical updates out to users is required to avoid repeats of various prior upgrade debacles. This GLEP proposes a solution based around pushing news items out to the user via the ``rsync`` tree. .. Important:: This GLEP does not seek to replace or modify ``einfo`` messages which are displayed post-install. That is a separate issue which is handled by ``elog`` [#bug-11359]_. Requirements An adequate solution must meet all of the following requirements: Preemptive Users should be told of changes *before* they break a system, not after the damage has already been done. Ideally, the system administrator would be given ample warning to plan difficult upgrades and changes, rather than only being told just before action is necessary. No user subscription required It has already been demonstrated [#forums-apache2]_ that many users do not read the ``gentoo-announce`` mailing list or ``RSS`` feeds. A solution that requires subscription has no advantage over current methods. No user monitoring required It has already been demonstrated [#forums-apache2]_ that many users do not read news items posted to the Gentoo website, or do not read news items until it is too late. A solution that relies upon active monitoring of a particular source has no advantage over current methods. Relevant System administrators who do not use a particular package should not have to read news items which affect purely that package. Some news items may be of relevance to most or all users, but those that are not should not be forced upon users unnecessarily. Lightweight It is not reasonable to expect all users to have an MTA, web browser, email client, cron daemon or text processing suite available on their system. Users must not be forced to install unreasonable extra software to be able to read news items. No privacy violations Users of the solution should not be required to provide information about their systems (for example, IP addresses or installed packages). Multiple delivery method support Some users may wish to view news items via email, some via a terminal and some via a web browser. A solution should either support all of these methods or (better still) make it simple to write clients for displaying news items in different ways. The following characteristics would be desirable: Internationalisable Being able to provide messages in multiple languages may be beneficial. Quality control There should be some way to ensure that badly written or irrelevant messages are not sent out, for example by inexperienced developers or those whose English language skills are below par. Simple for developers Posting news items should be as simple as is reasonably possible. Simple for users Reading relevant news items should be as simple as is reasonably possible. Compatibility with existing and future news sources A news system would ideally be able to be integrated with existing news sources (for example, Forums, GWN, the main Gentoo website) without excessive difficulty. Similarly, easy interoperation with any future news
Re: [gentoo-dev] glep 0042 (news) final draft
On Wednesday 01 March 2006 19:19, Ciaran McCreesh wrote: Unless there are any huge flaws found, I'd like this to be voted on by the council -- looks like it'll have to wait until April's meeting to fit in with the two weeks rule. may push council meeting back to 3rd tuesday if people wish -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Monthly Gentoo Council Reminder for March
On Wednesday 01 March 2006 04:17, Mike Frysinger wrote: If you have something you'd wish for us to chat about, maybe even vote on, let us know ! Simply reply to this e-mail for the whole Gentoo dev list to see. so, GLEP44 is up right ? any last questions ? /me looks at solar genone: can you show up to the meeting to represent ? -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] how to turn off hardened gcc flags reliably?
On Wednesday 01 March 2006 17:41, solar wrote: On Wed, 2006-03-01 at 17:17 +, Duncan Coutts wrote: I presume it's a gentoo patch to gcc-4 to add back in -fno-stack-protector? For the 4.0.x it should be just a dummy call. For 4.1 it is included. What does change and is really uncool with 4.1 is that -fno-stack-protector-all is missing and wont be added back without several somebodies making a case for it upstream. For the non technically minded folks whats the difference between -fno-stack-protector and -fno-stack-protector-all? Thanks Roy -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] how to turn off hardened gcc flags reliably?
On Thu, 2006-03-02 at 00:41 +, Roy Marples wrote: On Wednesday 01 March 2006 17:41, solar wrote: On Wed, 2006-03-01 at 17:17 +, Duncan Coutts wrote: I presume it's a gentoo patch to gcc-4 to add back in -fno-stack-protector? For the 4.0.x it should be just a dummy call. For 4.1 it is included. What does change and is really uncool with 4.1 is that -fno-stack-protector-all is missing and wont be added back without several somebodies making a case for it upstream. For the non technically minded folks whats the difference between -fno-stack-protector and -fno-stack-protector-all? It was explained to me like this: -fno-stack-protector makes gcc use a heuristic to decide whether or not change a function to use stack-smashing protection. -fno-stack-protector-all makes gcc just do it for every function. there is also: -fno-stack-protector-to-all which if supplied makes -fno-stack-protector get promoted to -fno-stack-protector-all. Apparently -fno-stack-protector-to-all is on by default in all current gcc profiles so that means that at the moment if you specify -fno-stack-protector you really get -fno-stack-protector-all. Hope that's clear! :-) -- Duncan Coutts : Gentoo Developer (Haskell herd team lead) email : dcoutts at gentoo dot org -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] how to turn off hardened gcc flags reliably?
On Wednesday 01 March 2006 10:35, Duncan Coutts wrote:
Does anyone have any other suggestions?
i dont know exactly what you're trying to accomplish, but the way wine does it
is by faking out the ssp symbols
in their loader, they add (for gcc-4.1+):
void *__stack_chk_guard = 0;
void _stack_chk_fail(void) { return; }
older versions of ssp used diff symbols, so i patch in these for wine:
void *__guard = 0;
void __stack_smash_handler(void) { return; }
-mike
--
gentoo-dev@gentoo.org mailing list
[gentoo-dev] QA Roles v2
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 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, -- 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 pgpzsrf4P1Frz.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
Re: [gentoo-portage-dev] Questions regarding the new portage API (savior branch)
On Wed, 2006-01-03 at 17:39 -0800, Brian Harring wrote: On 2/28/06, Michael Schilling [EMAIL PROTECTED] wrote: - Is one of these svn-web-repository up to date? * http://sources.gentoo.org/viewcvs.py/portage/main/branches/savior/ * http://mzz.mine.nu/bzr/savior-svn/portage/ I switched over to bzr about 2 months back; svn doesn't allow for offline committing, nor does gentoo's vcs allow for anon*... bzr natively allows for those capabilities, so that's what I'm using. :) http://gentooexperimental.org/~ferringb/bzr/saviour Is where I'll be updating the code for at least the near future. emerge bzr bzr get http://gentooexperimental.org/~ferringb/bzr/saviour cd saviour bzr pull ...roughly. ;) Thanks, ~harring a little too rough :) [EMAIL PROTECTED] ~ $ bzr get http://gentooexperimental.org/~ferringb/bzr/saviour bzr: ERROR: Not a branch: http://gentooexperimental.org/~ferringb/bzr/saviour [EMAIL PROTECTED] ~ $ -- Brian [EMAIL PROTECTED] -- gentoo-portage-dev@gentoo.org mailing list
