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
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting privileges
