While I have not been paying quite as close attention as some, it seems to me this thread has sort of reached an impasse.
I can't quite figure out why, though. Please forgive me if I skitter past something handled (or vehemently disagreed on) already in the thread; I just want to throw out my impressions.
On the subject of
whether there need to be reviews: there are, loosely, two classes of changes. There are random drive-by patches, and there are larger, serious changes such as for a new feature. Let's avoid picking nits about whatever might be in between.
I have contributed a few drive-by patches (and even a new feature) to various open source projects. At no time, as a drive-by-patcher, did I expect the team to incorporate my change without reviewing it at least some. I don't think anyone reasonable would expect otherwise. So I'm going to guess an OU policy for reviewing changes is not really a meaningful obstacle for this class of changes.
The other class seems so far to be assumed to handled by a branch merging in. I, personally, don't care how code is managed on a branch, and aside from various technical points from rarified about how certain processes would make it easier or better in some way, I didn't get the sense anyone else here has much to say about others' process either. At the time of the branch merge... is it so painful for the contributors to expect someone to review it? The review could be anything from cursory (yep, no conflicts) to totally thorough, depending on what is known about the content, people, process, whatever... That's up to the person stuck with the review.
So, I don't understand why, even if OU adopted a 100% review rule, this is a serious problem. Unless the issue is that people want to be able to check into the "main" branch unfettered. I don't see why, though. Generally with a mostly-working product it's understood that keeping it working in the main branch is important. So why the urgency to put little changes there? Also, part of the reason for the choice of Mercurial is that it's designed to facilitate an individual or group doing the little pieces in a branch/repo/whatever you call it first, then pulling all the changes at once when done. In which case, that work falls into the same class as "branch merging in".
So what am I missing on this issue? Also, I saw nobody but my opining say that OU already has a non-negotiable 100% review rule. But truthfully, in light of my own understanding of the classes of changes, I have not seen anything that will change the opinion of those of us who have actually been doing this for a living for some time.
...
I did not see any actual disagreement on
branch development proposals. I saw rarified say it would really nice if they were done in a particular way, and explain how it is nice... but if you don't use the OU tools, I don't think OU is going to tell you to go away, your code is no good. That's ridiculous.
On
developer communication: I will reiterate that we cannot assume there is one group of developers. If you are assuming that, we have found a fundamental incompatibility here. There will always be drive-by patchers. Out there, I guarantee you, there are people who have or will pick it up for the first time. They could be quite productive. You may not agree with what I have done, but you can't argue I wasn't productive -- and I started out one of those random people. I joined the fray kind of late. I just started working on my own. Almlys took my contributions without comment (though perhaps a comment would have been nice
). He reviewed them, too, BTW, in the beginning at least.
Again, I think OU is concerned with providing tools, and a main repository for the whole developer community. We don't know yet who they all are. We can't assume they will all use your IRC. Even if they wanted to, we can't assume they can use it usefully. What if I am doing my real job when I need to be on IRC to plan anything? Organization needs to happen in some medium that sticks around so people anywhere anytime can participate. OU tries to provide ways to do that. People have to use it for it to work, though.
Personally, I am not a fan of super corporate behaviors. But I *am* willing to use the tools here in the interest of being open to others. If you want something in-between, I think it can happen. Ask if needed, otherwise, do. I did not see value in making a huge list of "bugs" in JIRA for MOSS so I tossed my to-do list up on the wiki. The wiki is filled with my development odds&ends for anyone to pick up. If someone wants to look there, good. If they want to look at the bug tracker, good. If they look at the forum, good. If they want to
add to the wiki, good. If others showed up with MOSS ideas and we found it best to work through some means other than the Atlassian ones, hey, whatever.
But I don't think a departure from the tools provided (or others that might be provided if requested) is in the best interest of the *entire* CWE developer community if the departure is to something not easily accessed by the *entire* community. OU is trying to provide as best as possible for the entire community.
It would be nice to agree on one bug tracking instance, though. Many bugs tend to apply across branches...
- a'moaca'
