Sent from my phone. Please excuse my brevity. On Sun, 29 Jul 2018, 16:39 Fabian Groffen, <grob...@gentoo.org> wrote:
> Completely agreeing with Sergei, with some additional suggestions: > > On 28-07-2018 23:14:12 +0100, Sergei Trofimovich wrote: > > On Sun, 29 Jul 2018 00:40:18 +0300 > > Mikle Kolyada <zlog...@gentoo.org> wrote: > > > > > Hello, > > > > > > The Gentoo QA team would like to introduce the following policy that > > > would be applied to individuals breaking the state and quality of the > > > main gentoo.git tree > > > > > > ( as we do not have this strictly documented yet): > > > > > > <policy> > > > > > > If recommended > > > > It's not called "recommended" but "enforced". > > I agree. If you put penalties on these, they become hard rules. I > think that change should be discussed by the council perhaps? > > > > Gentoo workflow policies are not followed by an > > > individual developer > > > (e.g make major changes to the widely used eclasses without prior > > > discussion on the mailing list or > > > commit changes that lead to multiple CI checks failure) > > > > Here should go exhaustive list of links to the policies to be enforced. > > At least. And they should be clear and concise. No "common sense" or > anything involved for exceptions and the like. In addition, new checks > should be introduced to the community and possibly approved by council > as to whether being enforced or not. > > Fabian > > > > > > the standard QA > > > procedure is: > > > > > > 1.) Two warnings granted by QA team, after two independent breakages > > > 2.) Revoking the commit access for 14 days > > > > > > These violations will be evaluated individually by all QA team members. > > > Warnings can be revoked, if during 6 months period a developer makes at > > > least 20 non trivial changes not producing more breakages. > > > > > > </policy> > > > > -- > > > if you want to enforce rules, would be productive to also have extensive documentation on how to avoid to make such problems. Better would be to invest more time in something like the breckage checker script, similar at what mgorny is doing, than adding more ways to block developers contributions. thanks, Alice >
