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

[Philip Rosedale]

Adding some thoughts... Robin and Merov have made some good responses 
too...

I am a huge believer in transparency and freedom:  Inotherwards, if you 
are fearless about telling people early and often what you are doing, 
you are probably doing the right things without needing to be told.  At 
Linden most folks (about 85%+) publish weekly emails to the entire 
company listing what their objectives are for the week, and how they did 
last week.  Perhaps we could do that here too!!  It might be interesting.

So in that spirit, I'd say that sending mail to SL-dev saying "I am 
about to start working on X, what do folks think?" seems like a great 
idea.  Design review suggests an approval process barring further work, 
which I don't think would be appropriate.   But talk on this list about 
what you think would make sense to put into this viewer before starting 
coding work - Yes!

Also I agree with what merov said about committers, it seems like 
building a growing list of committers who distribute the load of giving 
feedback on what should/shouldn't go in is the right strategy.

P

Mike Monkowski wrote:
> Very good meeting, but I still have questions about the process.
>
> 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.
>
> Is documentation (on the wiki?) required for a "go"?
>
> 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?
>
> That gets stuff in, but how does it get back out to trunk?  How often? 
> Who does it?
>
> And how do other changes to trunk (or RC?) get into Philip's branch? 
> Who keeps the two in sync?  What happens when LL code changes break 
> the new features?  What about when my feature breaks your feature?  
> Who is responsible for fixing them?  If I fix something that came from 
> trunk or RC, how does it get fixed back there?
>
> If someone abandons his code, how does it get removed?
>
> I'll probably think of more questions, but this will do for now.
>
> Mike
> Mm Alder