Hi Manuel, I don’t think it is valid to compare large open source projects that have a lots of contributors with smaller ones that are just what they are, niche projects. If you ask a contributor of these high visibility projects if they want to contribute to a small niche OPNFV project, I don’t think there will much interest and it will not be because of loose commit requirements.
In the past few years I’ve noticed pretty large resource shift from openstack related projetcs to orchestration (ONAP), edge cloud and containers/k8s, not because there is no more work to do in the traditional openstack/NFVi space but because of vendors shift of strategy and priority. I don’t think having looser commit rules has any bearing in the defection of developers (even openstack has been losing a lot of developers and interest compared to a few years ago). BR, Alec From: Manuel Buil <[email protected]> Date: Tuesday, February 12, 2019 at 1:57 PM To: "[email protected]" <[email protected]>, "Alec Hothan (ahothan)" <[email protected]>, Cristina Pauna <[email protected]>, "[email protected]" <[email protected]> Subject: Re: [opnfv-tech-discuss] Code and Release improvements 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, [email protected] 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 : [email protected] [[email protected]] de la part de Alec via Lists.Opnfv.Org [[email protected]] Envoyé : samedi 9 février 2019 04:08 À : Manuel Buil; Cristina Pauna; [email protected] Cc : [email protected] 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: <[email protected]> on behalf of Manuel Buil <[email protected]> Date: Friday, February 8, 2019 at 12:48 PM To: Cristina Pauna <[email protected]>, "[email protected]" <[email protected]> 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<https://etherpad.opnfv.org/p/Code_and_Release_Quality> (Improve project's info accuracy) has been approved by the TSC on 5th Feb (see TSC-14<https://jira.opnfv.org/browse/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-review • 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+Document#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 (#22802): https://lists.opnfv.org/g/opnfv-tech-discuss/message/22802 Mute This Topic: https://lists.opnfv.org/mt/29535315/21656 Group Owner: [email protected] Unsubscribe: https://lists.opnfv.org/g/opnfv-tech-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
