[sldev] About the http-texture project

[Philip Rosedale]

Philippe's explanation (below) is great!  I would add:

I think it is appropriate that we don't yet have a well-defined 
process!  Every open source project is a bit different, and this one 
will probably be even more different given the scope of SL, the 
complexity of the system, and the fact that we are co-designing many new 
capabilities that are as yet unimagined.   So it is OK that we don't 
have all the wiki docs in place or ducks in a row.  Let's work together 
through a few projects and document what makes the most sense.  

Philip

Philippe Bossut (Merov Linden) wrote:
> Hi Mike,
>
> On Apr 30, 2009, at 11:43 AM, Mike Monkowski wrote:
>
>   
>> Philippe Bossut (Merov Linden) wrote:
>>     
>>> Not sure which missing documentation you're referring to but we  
>>> have 3  at the moment:
>>>       
>> OK, let's say Joe Sldev (I think the name is Serbian) has a great  
>> idea that he want's to get into the SL viewer.
>>
>> Is this new open source viewer (aka http-texture) his new open  
>> source portal or is it a sneaky underhanded backdoor to infiltrate  
>> the viewer codebase?
>>     
>
> Our goal with the OSS viewer has been made clear by Philip (see https://blogs.secondlife.com/community/technology/blog/2009/03/30/intensifying-open-source-efforts) 
> . We do hope that most of the innovations battle tested here will  
> eventually make it to the official viewer codebase but things that are  
> clearly not mainstream enough or not very popular with this community  
> won't simply make it there and that's ok. People will still be able to  
> get those features in the "Second Life OSS" download though.
>
> So, for Joe Sldev, the "Second Life OSS" project is the right one to  
> get his new feature in a fairly well distributed viewer, tested and  
> amended by a knowledgeable community, you.
>
>   
>> He has a PJIRA entry with a patch file.  How does that make its way  
>> to the SVN project?  Does he have to worry about getting it into the  
>> SVN branch?  Are there gatekeepers along the way?  What if someone  
>> objects?    Do we end up with SVN wars like Wiki wars?
>>     
>
> It's like almost any other FLOSS project: there is a group of  
> *committers* that do have commit privileges to the svn tree. The big  
> difference with the "old LL way of doing things" is that this group of  
> committers has Lindens *and* non-Lindens. After submitting his  
> contribution to the JIRA, Joe Sldev should engage folks on this  
> mailing list to get support for his feature: are people interested by  
> the feature, is this a worthy issue to fix. If there is community  
> support and a good review of his code from committers, the patch will  
> be taken in and committed by one of the committers. Eventually, if Joe  
> Sldev does quite a bit of good contributions in line with the project,  
> the committers will propose Joe to become a committer himself. The  
> committers group grows by co-optation only.
>
> If someone objects (and if our community is alive, there *will* be  
> someone to object...), we debate and try to reach a consensus on this  
> list. If there's a really contentious decision to be made (split  
> debate), Philip, our BDFL (Benevolent Dictator For Life), will weight  
> in and make the decision.
>
> As for avoiding wars, we won't have SVN wars since the group of  
> committers will be co-opted. Obviously, the committers will be careful  
> co-opting only people who share their view and philosophy of  
> development. If one committer will all of a sudden commit  
> controversial patches with no respect for due debate or the general  
> direction of the project (as decided by the BDFL), he or she'll see  
> his/her commit rights revoked. The BDFL has full authority in that  
> matter.
>
>   
>> When the project gets merged to the branch, and the branch to the  
>> trunk, and the trunk to the RC, and the RC to the standard viewer,  
>> who does all that merging?  Does anyone test it along the way?  Does  
>> everything in the project get merged at once, or do selected patches  
>> get merged separately?
>>     
>
> That's a lot of question and each project (RC, maint, etc...) has its  
> own way of ensuring quality and consistency of its project, mitigating  
> agility vs prudence. As far as the merge back to the official viewer  
> of "Second Life OSS" feature is concerned, that'll be up to the LL  
> viewer team to cherry pick and merge patches/commits separately. I'll  
> admit that this is not easy to do. Making this more manageable is one  
> of the big reason for the push to hg (mercurial) which does make  
> merges from various sources much more easier than svn.
>
>   
>> Does anybody document what's going on?  Does anyone even document  
>> the new or modified functionality?  Where?  At what point of the  
>> process?
>>     
>
> Every feature *must* have a JIRA attached with relevant doc and test  
> plan. If too big for the JIRA, the JIRA record should point to a wiki  
> doc. Contributors should expect to document their code, write test  
> plans, etc... I'm not for writing a long list of enforced rules and  
> regulations as we don't know yet how deep those patches will be. If I  
> have to make a guess based on the ones I've seen from Robin Aimee and  
> a couple of others, I'm not expecting this to become super process  
> heavy. As a general philosophy, we should all strive for a high level  
> of quality for contributions. Writing a patch and throwing it to JIRA  
> hoping others will write the code documentation, test plan, build and  
> test the code, etc... won't get Joe Sldev very far.
>
> Cheers,
> - Merov
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/SLDev
> Please read the policies before posting to keep unmoderated posting privileges
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090501/38f63dd8/attachment.htm