Christopher Blizzard wrote:
> For the trunk, post 0.9.2 branch until 0.9.3:
>
> After 0.9.2 has been cut we will return to the model we used before
> the 0.9.2 cycle. When the trunk is open for regular checkins you will
> not be required to ask for approval from drivers to check in your
> code. You will only need the usual review, module owner approval and
> super-review. ( I can hear the cheers now. )
WOO HOO!!!! ;-)
Truthfully, I have mixed feelings on the subject. While there are
certain issues that I feel that drivers need to be more involved in [1],
I'm not sure if policing every single checkin is the way to go. I
definitely feel that the other factors mentioned, as well as Netscape
management's heavy triaging efforts, played a big role in the stability
of the tree.
Given that there are only 7 drivers (according to the roadmap page),
that you're all basically in the same sets of timezones and that you've
got your own code to work on, things went pretty well. There were times
however where there was a nice 10-20 hr lull between a request and a
response and I was wondering why we don't have more drivers or better
coverage by drivers. 10-20 hrs may seem like some serious crybaby
whining until you realize that the requestor may have had similiar wait
times for each the r= and sr=. All so that the reviewers can say "oh,
that's a no brainer. <rubberstamp>". Not all checkins are no-brainers
but neither are they all tree terraforming changes. I think there
should be more granularity in the approval system if we were going to
stick with it.
> Of course if the quality of the code checked into the trunk
> deteriorates noticeably, we'll do something. We might reinstate the
> 'a=' requirement, maybe something else. We haven't figured this out
> yet because we're hoping it won't be necessary.
Several of us have talked numerous times about branching off development
for various modules instead of having a free-for-all development on the
trunk. While I don't see this happening anytime soon (pre 1.0), I hope
that we can eventually stabilize modules to the point where using a
stable branch of xpcom, necko, layout, etc is actually realistic.
- cls
[1] Things such as:
What features do we built by default and why.
How to reduce development downtime in an open tree
Getting a consensus about handling 3rd-party concerns affecting the
entire tree
(like the printf embedding issue)
