i know that such things drains a lot of energy. I'm working for a very small company and we changed our commit / review system entirely.
currently I think you are right at your four points, but one of your four points is somehow really bad > We have only one person reviewing patches regularly in his free time, so requiring as few as two reviews for a patch to be merged is already unrealistic I know that everybody is working here. I mean some people are working for django quite hard or working for their company and doing a lot of work for django, too. But still reviewing PR's is really important for a community project. I know lots of things already changed and this change is great as well. Still I think there are parts where some upstream work could be done way better by the community than by a few (with few i mean core) and thats the review process, thats why I came up with gerrit. I actually don't think that gerrit actually suites everybody's projects ( and I came to the same four conclusions in my company ;)) But maybe we are finding something that is as good as gerrit but suites the djangos project size a little bit better. i mean i still think commits needs control, else there would be a lot of circlejerk as the master/replica thing. but still it looks that pr's take way too long for django. and thats the last thing that django could do better. especially since there are a lots of ideas how to solve such problems in the real world.. i mean maybe we should really look at a review tool and maybe say if two people of the community reviewed it gets pipelined to the "core" which can do a final review. so it would be more community oriented and fewer "bad patches" will get to the commit pipeline. still it takes a lot of time to teach people and setup everything. but it will put the project further ahead. (also I'm not a core member but if we had such a review system i would definitely do more of these reviews since thats the thing i do at my company, too) 2014-08-01 19:02 GMT+02:00 Aymeric Augustin < aymeric.augus...@polytechnique.org>: > On 1 août 2014, at 18:31, Christian Schmitt <c.schm...@briefdomain.de> > wrote: > > Since you've introduced these changes, wouldn't it be suitable to change > Django's commit / review system entirely? > > > “Hey, you climbed this hill just fine, why don’t you climb the Everest > while you’re at it?” ;-) Even though the final vote looks like everything > went fine, preparing it took three months and drained a lot of energy. > > Like introduce gerrit, where very commit / ticket needs to be reviewed by > X people and then it would be marked as merge ready and a "core" or whoever > member could merge that. > There are a lot of projects which uses this kind of workflow. > > > I’ve discussed that idea with other core devs several times. Generally > speaking, we’re interested in shifting from a commit-oriented culture to a > review-oriented culture. We haven’t done it (yet) for four main reasons: > > - Someone has to organize this process, set up the tools, and teach > everyone. No one has volunteered. > - The drawbacks of adding bureaucracy may exceed the advantages of reviews > for a vast majority of patches, which are small fixes or improvements. > - We have only one person reviewing patches regularly in his free time, so > requiring as few as two reviews for a patch to be merged is already > unrealistic. Contrast this with the number of full-time paid developers on > OpenStack. > - Overall e’re not convinced this process would be appropriate for Django > and we don’t know what would happen if it turns out to be impractical. > > Also there are like 120 Pull Requests which are over an year old > sometimes.Which scary's off a lot of people. We should do something against > it to have a "cleaner" queue. > > > Unfortunately, GitHub’s issues and PRs management tools are somewhere > between primitive and non-existent. The only option GitHub gives us to move > a PR that requires discussion out of the review queue is to close it. Often > that triggers a heated argument with its author. That has killed all > attempts to clean the queue. Thus we’ve been beaten into the path of least > resistance and now we're letting PRs that cannot be merged as-is rot. > > Overall, I don’t think that change is impossible, but I think we’re going > to see how the dust settles before considering further (r)evolutions. > > -- > Aymeric. > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/428911F3-292F-4F97-AB3C-B2AC5AC76798%40polytechnique.org > <https://groups.google.com/d/msgid/django-developers/428911F3-292F-4F97-AB3C-B2AC5AC76798%40polytechnique.org?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAPDLAU4riUVrxvAwL_%3Diy2uRm3FY1g%3DXJnDcqAAwp%3DPj1N5T9g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
