[sldev] About the http-texture project

[Philippe Bossut (Merov Linden)]

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