[sldev] Philip's viewer; was: Tuesday Hippotropolis Meeting w/voice

[Philippe Bossut (Merov Linden)]

Hi Mike,

On Apr 7, 2009, at 12:59 PM, Mike Monkowski wrote:
> One thing that was brought up was that code review is a good thing.   
> So
> make the code review the gatekeeper.  Nothing gets into Philip's  
> branch
> unless it goes through a code review, which could be a regularly
> scheduled meeting on Hippotropolis (or elsewhere) or it could be  
> called
> by Philip whenever he feels like it.  Anyone could comment on the  
> code,
> but Philip would be the ultimate "go" or "no go" authority.

I don't think that Philip will be the unique gatekeeper for patch  
blessing. The plan right now is to have a (initially small) group of  
committers which role will be to review, sign off and commit the  
patches. These committers will held regular meetings with Philip who,  
as the BDFL, will keep them in line with the broad objectives of that  
branch.

> Is documentation (on the wiki?) required for a "go"?

Depends on the extend of the fix/feature. For sure, a PJIRA entry *is*  
required.

> Before I spend my time coding, I might want to know whether it has a
> chance of making it into Philip's viewer.  Do we need a design  
> review as
> well?

Light process which should include: PJIRA and discussion on sldev. The  
go / no go should be made public so, in the end, everybody will  
internalize what kind of work is done on that branch.

> That gets stuff in, but how does it get back out to trunk?  How often?
> Who does it?

Good question! We'll have to log a request and lobby internally to get  
a patch merged back to trunk. The point is that those features / bug  
fixes, will have been battle tested by the community and their value  
(and popularity) well established.

> And how do other changes to trunk (or RC?) get into Philip's branch?
> Who keeps the two in sync?

The Lindens on the committer group will be doing merge from trunk on a  
regular basis. CG has been doing this since a week (see the svn log).  
I'm expecting to be doing that on a regular basis as well.

> What happens when LL code changes break the
> new features?  What about when my feature breaks your feature?  Who is
> responsible for fixing them?

This is a common problem of multi branch development. This is a reason  
actually to avoid messing with parts of the code we know are under  
construction on the trunk. The http-texture part of the code though  
won't be modified by other development for a while, is critical for  
perf improvement and will require lots and lots of testing. That being  
said, when something gets broken as part of a merge, that's the person  
doing the merge who's in charge of fixing things up, potentially with  
the help of the developers.

> If I fix something that came from trunk or
> RC, how does it get fixed back there?

See above about merge back to trunk. Fixes on RC will likely be  
migrated as patches.

> If someone abandons his code, how does it get removed?

Code doesn't rust and shouldn't be that badly designed / documented  
that only its designer can do something with it. If it's the case, it  
shouldn't make it into the branch in the first place. If it's a  
problem of copyright or attribution you're alluding to, remember that  
each dev must sign a contribution license agreement. So the net-net is  
that I don't see the rationale to remove code unless it's bad.

Cheers
- Merov