On Wednesday 18 November 2015, Emmanuel Lécharny <elecha...@gmail.com> wrote:
> Le 18/11/15 11:31, Stephen Connolly a écrit : > > I believe the issue here is that with CTR it is very easy to miss the 72h > > lazy consensus voting (with an assumed +1 absence any votes cast) that > most > > CTR projects operate under... and thus it can also be very easy to miss > the > > fact that there are reviews going on (and I am being generous here, I > > suspect that a lot of CTR commits are only reviewed within the 72h by a > > blind man on a galloping horse) > > I'm not sure why you are correlating commit reviews and a 72h vote... > They are two really different things. When I last read up my understanding is that CTR operates as if there is a vote for each commit. It's a really lazy vote though as the vote passes if nobody comments on the commit after 72h... And personally I do not see much value in post-hoc votes... What are we going to do, rewrite history? But as I understand the "vote" is so that the code in source control can be covered by the legal umbrella despite it being outside of a formal source release. > > > > If the PMC is doing its duty, then when release time comes around, if > they > > have not been tracking the commits, then they should not be providing a > > binding +1 for the release until they have reviewed the commit delta from > > the last release *at least from the point of view of ASL compliance*. > No. There is nothing that says such a thing. > http://www.apache.org/dev/release-publishing.html All the source code of the project must be covered by the Apache License, version 2.0. The license must be included in each source file. For the license to be valid, the code must have been contributed by an individual covered by an appropriate contributor license agreement, or have otherwise been licensed to the Foundation and passed through IP clearance. S Now I will agree that the above is not a very high bar: 1. Check all commits are authored by a committer (as committer has an ICLA) 2. For commits authored by non committers (git makes these easier to find) check that the author provides clear intent to submit the code to the ASF (a patch submitted to JIRA/project mailing list or a PR against Apache GitHub repo seems clear intent) and that the patch is not "too big" (a somewhat nebulous concept but as all the ones I have had to check were under the 50-60 LOC metric I haven't had to probe that concept too hard) 3. If all else fails as the author to sign an ICLA It would be very good if > every PMC member casting a vote were reviewing all the commits since the > last release, but this is unlikely to happen, and it's not even > required. > This is correct, as long as I review as we go for the above (minimal) provenance checks then I am good to go and provide 1/3rd of the legal umbrella. And unless you point us to the so called ASL compliance, I > think this is your own interpretation of the PMC member that you are > pulling here. See the link. It's not a strenuous compliance check like the paper exercise that the interrupted view of planetary objects foundation performs... Thank goodness do that... But it is a requirement of you read up on the PMC roles. > > > > So if we look at a well established CTR project such as Maven, you do not > > see many comments on individual commits... from this you might be > forgiven > > if you concluded that there is no review going on... and thus infer that > > CTR is really C. I cannot speak for the entire Maven PMC but I can assure > > you that I reviewed each and every commit in the delta between the 3.3.3 > > release and the 3.3.9 release from both a technical perspective and the > > legal umbrella perspective (does that mean I spotted every bug, nope... > no > > code review can catch every bug... and it took us 6 goes to get the > release > > out... but there was review) > That's good for Maven. But that does not mean any other project should > do so. > > Look, this is where we *trust* other committers - and this is the reason > we voted them in, btw - : they *know* they should not break the ASF > rules (IP, etc) plus they *know* they should not break the trust the > community has put in them. > > In 10 years, I have very rarely seen such things happening - and most of > the time it was a mistake -. I saw someone pushing some revamped Sun > code (and signaled so to the project), vote -1 on one commit (not sure I > should be proud of that veto, btw) and asked for some better code to be > pushed a few times, but more as a discussion than as a formal request. > Otherwise, did I saw some commits that needed some fixe because they > were breaking the build ? You bet ! (and I plaid guilty as charged too). > Bottom line, trusting my co-workers was easy : they are all my pairs, > and I don't feel like I'm any superior in any way, so I was expecting > their code to be at least as good as mine. Who would I be if I was to > check their daily commits and not asking them to review mine otherwise ? > > And the best of it : it simply works. With flying colors. We have a > bunch of tests that avoid many errors to be introduced into the code, > and we can release fast enough so that our users can actually be real > users, and provide us with feedbacks. There is nothing better than users > feedbacks : not only they see what's wrong in our products, but they > also use it ways we haven't thought about, discovering new problems we > totally missed. That's the key : release often means get quick feedbacks. > > But there is more : asking people who are volunteers to review what > others are pushing would introduce a latency that would certainly kill > the project. > > Now I can see how people being paid by a company might *want* such > reviews to be done (regardless of the mode, CTR or RTC), and I feel that > as a bias toward a control by a few companies, excluding de facto those > who don't have time to work on the project but what they squeeze out of > a day job, familly, and sleep... And I saw that frequently in *many* > projects ! Sounds like a hidden agenda, isn't it ? That would may be > pushing the thing a bit too far, but I suspect that in some case, yes, > that was exactly that. This is *NOT* The Apache Way... > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > <javascript:;> > For additional commands, e-mail: general-h...@incubator.apache.org > <javascript:;> > > -- Sent from my phone
