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. > > 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. 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. 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. > > 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 For additional commands, e-mail: general-h...@incubator.apache.org
