Axel Dörfler wrote: > On 12/09/2012 01:40 PM, luroh wrote: >>> While that also results in less work for him, it may also result in a >>> poorer >>> release. >> >> I see no evidence for that. It borders on wishful thinking and >> preconceptions that a single person would do a better job in this >> respect than a team managed by a single person. > > > As a developer, I want my patch in the release - someone independent is > likely to make better decisions as to what should make it into the release, > and what should not. > Of course, that's not a guarantee either, and it might not work better in > the end, but it sure is a problem that should not be ignored. I think I understand what you are saying and I believe that I can point to some evidence supporting my position. If we take a look at how regular development goes on around here, we likely notice a few proven strong points such as peer review and self-policing. This is part of what has taken Haiku all the way from scratch to where we are now, which is certainly nothing to sneeze at. As a however pointless comparison, it took Wine 15 years to reach what they deemed 1.0 status, and that's with more developers implementing "merely" a shim of sorts. Now, pointless comparisons aside, I submit that we are clearly doing something right. Except when it comes to release branches - then we go ahead and do something completely different. For the release branch (and any other branch, really), I am proposing that we apply the same methods of peer reviewing and self-policing as we already do in trunk, just with an additional set of well-communicated policies set by the RM. >> Nope, no policy. We wouldn't care if a fix gets committed to trunk or >> branch first. > > > Okay, I misunderstand you there, then. I don't quite see how this would be a > good idea, though :-) Ok, no biggie, we can skip it for now, for the sake of keeping the length of this thread down. :) - luroh