Hello, I like the idea of enforcing quality rules in the tree, but I have a few reservations regarding the current plan.
On Sun, Jul 29, 2018 at 04:47:47PM +0900, Alice Ferrazzi wrote: > 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 If you introduce penalties for breaking prefix as well, I'm afraid many people will be unnecessarily penalized. I think that such penalties are counter productive in most cases. If someone is really being careless it might make sense to get some warning and lose commit access temporarily. If someone made a simple mistake that can be easily fixed, like version bumping a package that starts to fail in some corner case, then punishment doesn't make much sense. I'd rather prefer to see improvements to our automated checks as the mean to improve the quality of the tree, and penalties for people that do not use repoman. Rather than a temporary ban, it would also make more sense to just require someone to go through the ebuild quiz again as penalty for breaking the tree many times. > > > > ( 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. I agree with Alice here. We already have the devmanual and repoman, as well as the CI system, which are all very good. Extending them is the best way to keep Gentoo in good shape. Also, if we have enough resources, we can try to reject broken pushes, rather than punishing devs after broken changes reach the main tree. Cheers, -Guilherme
