Hello Manuel. I fully second you about asking Linux team about their processes.The Linux Kernel leverages on maintainers which is far from what we are proposing.And you become arch/release maintainers thanks to your skills (Meritocraty). https://www.kernel.org/doc/html/latest/process/2.Process .html?highlight=merge%20window#how-patches-get-into-the-kernel It's the opposite process of what we are defining here.And as far as I know, Linux doesn't have any problem to attrack developpers, and the best ones! Cédric
Le mardi 12 février 2019 à 23:00 +0100, Manuel Buil a écrit : > Hello, > > This is the last mail I got in this thread but perhaps it is not the > last one. For unknown reasons, this thread is being flagged as SPAM > and I am not sure if something got blocked in between (e.g. I never > got Alec's mail). > > Ok, now I get your points, thanks Alec and Cedric. Unfortunately, I > still think it is bad if this is not enforced (with temporary > exceptions) because of what I said in my previous mail. I'd suggest > to ask around people working in other communities about this (kernel, > openstack, CNCF...). Last week I was on a business trip and had the > opportunity to ask open source people. Everyone I asked was surprised > and I agreed with a couple of them who said that they would never > join a project that allows this. If a project does not attract > developers, allowing to self-merge patches is not going to help, > right the opposite. > > It seems to me, and correct me if I am wrong, that you guys are fine > if OPNFV becomes a community for multiple projects with only one/two > committers (as long as those are niche projects (@Alec: what about > installers? what about yardstick/functest/dovetail?) or projects with > an ideally perfect CI). That is a vision I don't share and I thought > OPNFV in general did not share but I can just talk for myself, let's > hear some other opinions ;). > > Regards, > Manuel > > On Mon, 2019-02-11 at 14:41 +0000, cedric.olliv...@orange.com wrote: > > Hello, > > > > New development process enforcement for which developers? > > The proposal could maybe make sense in a very active community with > > lots of developers without any automated verification jobs. > > Both assumptions are false: > > > > as bitergia statistics (https://opnfv.biterg.io) have been showing > > for several months, OPNFV is progressively becoming a community > > without developers. > > as a consequence we put in place lots of verification jobs which > > compensate the lack of reviews and which strongly improve the code > > quality. > > > > > > > > Some of them are being adopted by Yardstick (I voted +1). > > Imposing new process rules from the top will clearly discourage the > > remaining contributors and increase the risk of fork out of the > > community. > > It is at least an option I can clearly foresee for my project. > > > > Is adding process enforcements the top priority topic of OPNFV? > > Regarding the previous statement, is it really the top priority of > > OPNFV TSC to debate on new development processes which constraints > > the developers without any direct improvement regarding the project > > quality ? > > Is there no more critical decisions to take if we simply want to > > survive as a community? > > > > As service provider I am still fully convinced of the interest of > > OPNFV. > > The creation of the LF Networking should be a catalyst to work with > > the other projects and disseminate the best practices that are > > already in place and have been demonstrated by the code. > > It is already the case with the discussions on Xtesting with ONAP > > and Akraino. Docker production, Alpine adoption, CI/CD best > > practices which have been initiated in OPNFV. > > > > We certainly agree not to enable it in Functest. > > > > > > Cédric > > > > > > > > De : opnfv-tech-discuss@lists.opnfv.org [opnfv-tech-discuss@lists.o > > pnfv.org] de la part de Alec via Lists.Opnfv.Org [ahothan=cisco.com > > @lists.opnfv.org] > > > > Envoyé : samedi 9 février 2019 04:08 > > > > À : Manuel Buil; Cristina Pauna; opnfv-tech-discuss@lists.opnfv.org > > > > Cc : opnfv-tech-discuss@lists.opnfv.org > > > > Objet : Re: [opnfv-tech-discuss] Code and Release improvements > > > > > > > > > > > > > > > > > > > > I do not disagree on the general benefits of having multiple > > reviewers for every commit, no question about it. If you can afford > > it – go for it. > > However, I would like to point out that for most low-key or “niche” > > projects with few committers, a rule to enforce dual review and > > forbid self commit will quickly force any remaining participants to > > exit opnfv > > and head out direct to gihtub ot bitbucket. > > > > So I would vote to let the PTL decide on how to regulate the > > commits of his/her project. I think OPNFV PTL have generally been > > quite responsible in the past and I have not personally seen any of > > the behavior > > listed below. > > I think many PTL are in the same situation, with projects that are > > not sufficiently attractive to afford the luxury of requesting > > multiple reviews. Most PTL would welcome any “reasonable” review > > but in many > > cases, it just happens that the code that is being managed in not > > that easy to understand, not because it is spaghetti code, but > > because of the nature of the beast. In my case, people with good > > understanding of networking performance, traffic generation and > > TRex APIs are unfortunately very hard to come by. This is by no > > means and rarely the case that PTLs do not like multi-vendor > > participation or consider themselves as god > > 😉 > > > > > > I am PTL and I commit my own code and I am happy to add and > > encourage new committers and new reviewers (I do get some great > > “external” contributions only too occasionally). > > > > OPNFV has many great PTL for low key projects, I think we should > > not make their life more difficult and trust them to do what is > > best for their project. > > If OPNFV wants to attract more talents/contributors/projects I > > think adding more rules and process may not be the best approach. > > > > Thanks > > > > Alec > > > > > > > > > > > > > > > > From: > > <opnfv-tech-discuss@lists.opnfv.org> on behalf of Manuel Buil <mbui > > l...@suse.com> > > > > Date: Friday, February 8, 2019 at 12:48 PM > > > > To: Cristina Pauna <cristina.pa...@enea.com>, "opnfv-tech-discuss@l > > ists.opnfv.org" <opnfv-tech-discuss@lists.opnfv.org> > > > > Subject: Re: [opnfv-tech-discuss] Code and Release improvements > > > > > > > > > > > > Hi Cristina, > > > > > > > > > > > > SFC has been doing this from the beginning and I think it is a > > great idea which should be enforced. There are of course exceptions > > which should be handled with a workaround, especially at the > > beginning, but as > > you say, they should be limited on time. When a person merges his > > own patches, there are some dangerous potential consequences which > > jeopardize the values of community driven development, for example: > > > > > > > > > > > > 1 - Single Point of Failure. That person is the only one that knows > > about some piece of the code. If that person stops working in the > > project, can other people continue the development? > > > > > > 2 - Coding hero/god mentality which is very bad for the health of > > the community and will frighten potential new committers or > > consumers of that project > > > > > > 3 - Quality of code becomes worse. Several eyes on the code is > > better than just two. Jenkins tests will give +1 to spaghetti code > > > > > > 4 - Knowledge sharing is stopped. By code reviews, developers share > > knowledge and ideas or can enforce good documentation > > > > > > 5 - If I am PTL and I am able to merge my own patches. Why would I > > want to add new committers? > > > > > > 6 - Company driven projects instead of community driven projects > > > > > > > > > > > > Unfortunately, I was not able to join Tuesday's or Thursday's > > meeting because of a business trip. Did you reach any agreement? By > > reading your mail it seems there were people against it which > > suprises me because > > I see this as common sense in open source communities but perhaps > > I am missing the points of the people against it. > > > > > > > > > > > > Regards, > > > > > > Manuel > > > > > > > > > > > > On Wed, 2019-02-06 at 15:17 +0000, Cristina Pauna wrote: > > > > > Hi all, > > > > > > The first proposal from the > > > > > > Code and Release Quality (Improve project's info accuracy) has > > > been approved by the TSC on 5th Feb > > > (see TSC-14 > > > for details). > > > > > > The second proposal (Improve gerrit best practices), although > > > generally well received, has raised some concerns and I would > > > like to ask the community for more feedback on it. > > > The proposal is to discourage self-merging patches by adding this > > > into our wiki documentation and, in a reasonable timeline to > > > enforce it through gerrit (current recommendation is > > > Hunter 8.0 milestone) > > > > > > The background for this proposal is good practices done in other > > > open source communities, which value peer review. Some examples > > > are: > > > · > > > OpenStack requires 2 committers to give a +2 for any patch: > > > > > > https://docs.openstack.org/infra/manual/developers.html#code-revi > > > ew > > > · > > > Akraino requires contributor diversity (the project demonstrates > > > that it has a stable core team of contributors/committers which > > > are affiliated to a set of at least > > > three different companies): > > > https://wiki.akraino.org/display/AK/Akraino+Technical+Community+D > > > ocument#AkrainoTechnicalCommunityDocument-3.3.7.3CoreReview > > > · > > > Blog with gerrit best practices that promotes to not self-approve > > > changes and to have at least 2 other people review the change: > > > > > > https://blog.simplypatrick.com/html/gerrit-best-practices.html > > > · > > > Some OPNFV projects already follow this good practice although is > > > not enforced by gerrit > > > > > > > > > Peer reviews are important because they make other members to > > > better understand the changes that are happening in a project, > > > give opportunity to have architectural discussions, > > > make committers more involved and responsible, and improve the > > > overall quality of a project. > > > > > > > > > Understandably, there have been situations when a project had a > > > single active committer, and those can be excepted from the rule > > > for a limited period of time. On the long run this > > > type of projects have been proven to be unsustainable anyway > > > (most of them died on their own when the person sustaining the > > > project pursues other interests). Exceptions can always be > > > approved if there’s a good reason for them. > > > > > > These are some concerns I got over this proposal: > > > - > > > Code is automatically verified by Jenkins so a Verified +1 from > > > Jenkins assures the new code is not breaking anything > > > o > > > Peer review is just as important as automatic verification of the > > > patches, as it provides all the benefits listed above. One should > > > not exclude the other > > > - > > > Trivial patches don’t need peer review > > > o > > > What is trivial and not can be better decided by a second set of > > > eyes (one line change can have major impact). Also, it should not > > > matter if a change is trivial or not to have proper peer review > > > - > > > Low number of active developers in OPNFV > > > o > > > This is indeed a concern and a reason for which this practice has > > > become so common. But unless a project has just 1 active > > > committer, self-approved patches should not happen > > > > > > I would like to know if your projects already has this practice > > > informally, if you would like to have it as a hard requirement, > > > and if you have any concerns. You can either use this > > > thread or join us on the Technical Discuss meeting this Thursday > > > (https://wiki.opnfv.org/display/PROJ/Weekly+Technical+Discussion) > > > > > > Thanks, > > > Cristina > > > > > > > > > > > > > > > > ___________________________________________________________________ > > ______________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous > > avez recu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les > > messages electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, > > deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; > > they should not be distributed, used or copied without > > authorisation. > > If you have received this email in error, please notify the sender > > and delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that > > have been modified, changed or falsified. > > Thank you. > > > > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > > View/Reply Online (#22801): https://lists.opnfv.org/g/opnfv-tech-disc > uss/message/22801 > Mute This Topic: https://lists.opnfv.org/mt/29535315/1217365 > Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org > Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub [oll > ivier.ced...@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=-
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#22806): https://lists.opnfv.org/g/opnfv-tech-discuss/message/22806 Mute This Topic: https://lists.opnfv.org/mt/29535315/21656 Group Owner: opnfv-tech-discuss+ow...@lists.opnfv.org Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
