Chris Seawood wrote:
>
> WOO HOO!!!! ;-)
Ding dong the witch is dead? :)
>
> 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.
Agreed.
>
> 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.
I think that all of us were aware of the time lag after getting
reviews/super-reviews/approvals added to the process of getting code
into the tree. I know that when I'm working on smaller bugs I develop
this kind of 'fire and forget' mentaility. Once you have a patch you
want to get it into the tree and move on.
At least in my mind ( I don't think that I've ever discussed this with
the other drivers ) one of the goals of drivers was to add that barrier
so that you couldn't just drop something into the tree and move on. You
really were responsible and people would spend time looking at
everything. It enforces caring long term for the code that you check in.
It also meant that a small group of people were aware of every chunk of
code that went into the tree. I think that this helped in tracking
regressions and watching for possible problems in those areas of the
code where there were checkins. This is one of the reasons why keeping
the numbers of drivers small is good. Once you start getting larger
than that number of people you start to run into scaling problems. Not
everyone can keep up and you start delegating. Most of the time,
delegation is OK but not in this case. Each of the drivers was doing a
lot of the same work as the others and covering the same work over and
over again. This led to a small group of people who really know what's
going on with the tree.
Anyway, I digress. I'm babbling now.
>
>
>> 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.
Well I've tried to assert some drivers leverage there but you weren't
having any of it. :)
> How to reduce development downtime in an open tree
and how to balance it with quality.
> Getting a consensus about handling 3rd-party concerns affecting the
> entire tree
> (like the printf embedding issue)
Personally, I don't consider that a 3rd party concern and it's not just
embedding. I want those out of the build, period. We have PR_LOG() for
a reason.
--Chris
--
------------
Christopher Blizzard
http://people.redhat.com/blizzard/
Mozilla.org - we're on a mission from God. Still.
------------
