Re: [gentoo-dev] Requiring two sets of eyes for all eclass commits
Le 24/04/2010 19:40, Petteri Räty a écrit : What do you think about not allowing commits to eclasses without mentioning an another developer who has reviewed and approved the diff in the commit message? There's enough people on gentoo-dev for urgent stuff too. More bureaucracy and policies when we arguably have enough (or even too much...?) My vote is a clear and resounding *no*. If someone f*cks up, revert the commit if the issue isn't fixed quickly. If that someone f*cks up again, call devrel on his ass. If anything, we should be working on versionned eclasses rather than VCS hooks. My 2 euro cents. Cheers, Rémi
Re: [gentoo-dev] Requiring two sets of eyes for all eclass commits
On Sun, Apr 25, 2010 at 5:42 PM, Alistair Bush ali_b...@gentoo.org wrote: snip Use common sense here. ^^ Seems pretty clear to me.
Re: [gentoo-dev] Requiring two sets of eyes for all eclass commits
On 04/24/2010 09:14 PM, Alexis Ballier wrote: On Sat, 24 Apr 2010 20:40:54 +0300 Petteri Räty betelge...@gentoo.org wrote: 17:34 Betelgeuse robbat2|na: how easy to it to prevent commits to CVS if the commit message doesn't match a certain pattern? 17:36 @robbat2|na go and checkout the CVSROOT and there should be an example there 17:37 Betelgeuse robbat2|na: Ok so doable then. Thanks. What do you think about not allowing commits to eclasses without mentioning an another developer who has reviewed and approved the diff in the commit message? There's enough people on gentoo-dev for urgent stuff too. no thanks; we already have the policy to require that major changes to broad impact eclasses have gone through -dev, no need to add more bureaucracy. But the policy is not tested by the quizzes and we have had cases lately where large diffs have been committed without gentoo-dev review. With peer review it's likely that the reviewer is familiar with what should be sent to gentoo-dev as hesitant/new people won't give their approval that easily. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Requiring two sets of eyes for all eclass commits
On 04/24/2010 09:14 PM, Alexis Ballier wrote: On Sat, 24 Apr 2010 20:40:54 +0300 Petteri Räty betelge...@gentoo.org wrote: 17:34 Betelgeuse robbat2|na: how easy to it to prevent commits to CVS if the commit message doesn't match a certain pattern? 17:36 @robbat2|na go and checkout the CVSROOT and there should be an example there 17:37 Betelgeuse robbat2|na: Ok so doable then. Thanks. What do you think about not allowing commits to eclasses without mentioning an another developer who has reviewed and approved the diff in the commit message? There's enough people on gentoo-dev for urgent stuff too. no thanks; we already have the policy to require that major changes to broad impact eclasses have gone through -dev, no need to add more bureaucracy. But the policy is not tested by the quizzes and we have had cases lately where large diffs have been committed without gentoo-dev review. With peer review it's likely that the reviewer is familiar with what should be sent to gentoo-dev as hesitant/new people won't give their approval that easily. 1) Why is it of any relevance whether or not the quizzes test this policy? 2) Where is this policy recorded, and why does devmanual.g.o seem to (possibly) contradict it? [1] I'm not sure of the nature of the commits but were they non-general? - Alistair [1] It is not usually necessary to email the gentoo-dev list before making changes to a non-general eclass which you maintain. Use common sense here. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Requiring two sets of eyes for all eclass commits
On 2010.04.24 18:40, Petteri Räty wrote: 17:34 Betelgeuse robbat2|na: how easy to it to prevent commits to CVS if the commit message doesn't match a certain pattern? 17:36 @robbat2|na go and checkout the CVSROOT and there should be an example there 17:37 Betelgeuse robbat2|na: Ok so doable then. Thanks. What do you think about not allowing commits to eclasses without mentioning an another developer who has reviewed and approved the diff in the commit message? There's enough people on gentoo-dev for urgent stuff too. Regards, Petteri In industry, the practice is called peer review. Its generally thought to be a GoodThing as its part of the process of trapping errors as early as possible in the process, where they have lowest cost. We cannot easily attribute cost in terms of money, so think about it in developer and user hours wasted as errors 'escape'. Industry also recognises the need that any process needs to be tailored to the circumstance so the peer review process is not enforced. Project groups are permitted to assess the risk of screwing up against the cost of a fix. (That's overly simplistic). In short, following industry best practice, the peer review process should be strongly encouraged but we should stop short of using tools to enforce it. -- Regards, Roy Bamford (Neddyseagoon) a member of gentoo-ops forum-mods trustees pgprYCIfBGTiU.pgp Description: PGP signature
Re: [gentoo-dev] Requiring two sets of eyes for all eclass commits
On 04/26/2010 01:42 AM, Alistair Bush wrote: On 04/24/2010 09:14 PM, Alexis Ballier wrote: On Sat, 24 Apr 2010 20:40:54 +0300 Petteri Räty betelge...@gentoo.org wrote: 17:34 Betelgeuse robbat2|na: how easy to it to prevent commits to CVS if the commit message doesn't match a certain pattern? 17:36 @robbat2|na go and checkout the CVSROOT and there should be an example there 17:37 Betelgeuse robbat2|na: Ok so doable then. Thanks. What do you think about not allowing commits to eclasses without mentioning an another developer who has reviewed and approved the diff in the commit message? There's enough people on gentoo-dev for urgent stuff too. no thanks; we already have the policy to require that major changes to broad impact eclasses have gone through -dev, no need to add more bureaucracy. But the policy is not tested by the quizzes and we have had cases lately where large diffs have been committed without gentoo-dev review. With peer review it's likely that the reviewer is familiar with what should be sent to gentoo-dev as hesitant/new people won't give their approval that easily. 1) Why is it of any relevance whether or not the quizzes test this policy? I doubt recruits read all of our documentation while answering the quizzes. This would just enforce behavior. 2) Where is this policy recorded, and why does devmanual.g.o seem to (possibly) contradict it? [1] I'm not sure of the nature of the commits but were they non-general? http://devmanual.gentoo.org/eclass-writing/index.html Before updating eutils or a similar widely used eclass, it is best to email the gentoo-dev list. [1] It is not usually necessary to email the gentoo-dev list before making changes to a non-general eclass which you maintain. Use common sense here. Yeah it's not spelled that clearly there. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Requiring two sets of eyes for all eclass commits
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25-04-2010 13:10, Petteri Räty wrote: On 04/26/2010 01:42 AM, Alistair Bush wrote: On 04/24/2010 09:14 PM, Alexis Ballier wrote: On Sat, 24 Apr 2010 20:40:54 +0300 Petteri Räty betelge...@gentoo.org wrote: 17:34 Betelgeuse robbat2|na: how easy to it to prevent commits to CVS if the commit message doesn't match a certain pattern? 17:36 @robbat2|na go and checkout the CVSROOT and there should be an example there 17:37 Betelgeuse robbat2|na: Ok so doable then. Thanks. What do you think about not allowing commits to eclasses without mentioning an another developer who has reviewed and approved the diff in the commit message? There's enough people on gentoo-dev for urgent stuff too. no thanks; we already have the policy to require that major changes to broad impact eclasses have gone through -dev, no need to add more bureaucracy. But the policy is not tested by the quizzes and we have had cases lately where large diffs have been committed without gentoo-dev review. With peer review it's likely that the reviewer is familiar with what should be sent to gentoo-dev as hesitant/new people won't give their approval that easily. 2) Where is this policy recorded, and why does devmanual.g.o seem to (possibly) contradict it? [1] I'm not sure of the nature of the commits but were they non-general? http://devmanual.gentoo.org/eclass-writing/index.html Before updating eutils or a similar widely used eclass, it is best to email the gentoo-dev list. The important bit there is widely used eclass. I agree with having peer review, but as others argued I don't agree with the recent trend to make it increasingly harder to commit stuff to the tree. To expand on the above, by widely used eclass I interpret eutils, autotools, base and similar eclasses because even though some eclasses like the kde4 eclasses are used by many ebuilds, it's mostly a team's eclass and not a general eclass shared by everyone. - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / KDE / Elections -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJL1F5OAAoJEC8ZTXQF1qEPNf4QAIoyr8IELeixBJDHvv2ACaMw omUQj5nbjFB1Xc7Die4dT7TkUfJ2/QddMcG1I/CNTNEdRtJAR31UDS2Lbm7gOj11 wpd+g7mDQuJZdW3873YXkThoynqS3xzfpZocxb2s+adxyXF6Mh65+N+ZT515HMh8 DujqxGHxjA4Cqn/zGe6ClqfRwxfGZkYkA/eQfX9m7TSJHTwxK4sijhFNphSsA89E qyVW0Y18mrf0pVBpUaQ4kfCuwp0HWOIoubSCIo47KFINfL4TteaX1NTOP9JzEIDH saCUURHQw2nWTsPDNjvL6euvriyTZpm0lhHR86j87maDVeGFDn0PZ8Cs/ypCVhxJ 1MxdL7NvyUptHO6UGUvluqZzh4zTDEsotCRWzyshEPAy51q+rWbMLPVeDZfkVgl8 /0VlhNFgdoxuowOEK4AiTWifp5oa5RO03K5Hyfze2IfFXArva7Znb5oCGeHoEBqn Kr5trpgIqyW+v3XifurbuOSoU7BDTlzH3WrkCRJq0pP5Hogtod0wf1tAy/wQ+F+3 yUphi3tzMFMlFoqBE5pfjyTa22vi/RjNVgH3sie6HD8qZsmKJIILb2Y3NrloCzlB WYdCP0+dfFOafqFMpAFUuI3E7zrKacQK7mshLE9vTNa+dh6LVASn2WIaLdtse1GK sUN2ESxQteslTvu7v6r/ =GLm6 -END PGP SIGNATURE-
[gentoo-dev] Requiring two sets of eyes for all eclass commits
17:34 Betelgeuse robbat2|na: how easy to it to prevent commits to CVS if the commit message doesn't match a certain pattern? 17:36 @robbat2|na go and checkout the CVSROOT and there should be an example there 17:37 Betelgeuse robbat2|na: Ok so doable then. Thanks. What do you think about not allowing commits to eclasses without mentioning an another developer who has reviewed and approved the diff in the commit message? There's enough people on gentoo-dev for urgent stuff too. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Requiring two sets of eyes for all eclass commits
On 24 April 2010 23:10, Petteri Räty betelge...@gentoo.org wrote: 17:34 Betelgeuse robbat2|na: how easy to it to prevent commits to CVS if the commit message doesn't match a certain pattern? 17:36 @robbat2|na go and checkout the CVSROOT and there should be an example there 17:37 Betelgeuse robbat2|na: Ok so doable then. Thanks. What do you think about not allowing commits to eclasses without mentioning an another developer who has reviewed and approved the diff in the commit message? There's enough people on gentoo-dev for urgent stuff too. Were there recent breakages to make this necessary? Cheers, -- Arun Raghavan http://arunraghavan.net/ (Ford_Prefect | Gentoo) (arunsr | GNOME)
Re: [gentoo-dev] Requiring two sets of eyes for all eclass commits
On Sat, 24 Apr 2010 20:40:54 +0300 Petteri Räty betelge...@gentoo.org wrote: 17:34 Betelgeuse robbat2|na: how easy to it to prevent commits to CVS if the commit message doesn't match a certain pattern? 17:36 @robbat2|na go and checkout the CVSROOT and there should be an example there 17:37 Betelgeuse robbat2|na: Ok so doable then. Thanks. What do you think about not allowing commits to eclasses without mentioning an another developer who has reviewed and approved the diff in the commit message? There's enough people on gentoo-dev for urgent stuff too. no thanks; we already have the policy to require that major changes to broad impact eclasses have gone through -dev, no need to add more bureaucracy. Also, what will be the value of my opinion on changes on toolchain.eclass since I know nothing about it? Finally, find me someone able to review texlive-*.eclass changes. Alexis. signature.asc Description: PGP signature
