SLDev Open Source Viewer - Revision history

Redirect fixer: SLDev Viewer Development Process has been moved, it is now a redirect to Snowglobe Development Process

2009-05-18T23:09:59Z

SLDev Viewer Development Process has been moved, it is now a redirect to Snowglobe Development Process

← Older revision		Revision as of 16:09, 18 May 2009
Line 1:		Line 1:
	#REDIRECT [[~~SLDev Viewer~~ Development Process]]		#REDIRECT [[Snowglobe Development Process]]

Rob Linden: Merged with the old HTTP Texture Development page

2009-05-06T19:07:42Z

Merged with the old HTTP Texture Development page

← Older revision		Revision as of 12:07, 6 May 2009
Line 1:		Line 1:
	~~=What is the SLDev Open Source Viewer?=~~		#REDIRECT [[SLDev Viewer Development Process]]

	~~See [https://blogs.secondlife.com/community/technology/blog/2009/03/30/intensifying-open-source-efforts Philip's blog post] for the initial announcement.~~

	~~Merov posted on SLDev:~~

	''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 simply won't make it there and that's ok. People will still be able to get those features in the "Second Life OSS" download though.''

	~~This document is an edited version of some of Merov's other comments on the SLDev list combined with an edited outline originally by Mike Monkowski.~~

	~~=How do I contribute to it?=~~
	~~==Talk to the mailing list==~~

	~~First, you might want to have a discussion about your idea. Chat on the~~ [[SLDev ~~\| SLDev mailing list~~]]~~. Create a [[Issue tracker \| JIRA entry]] and see if others agree with you. Refine the JIRA entry to get the idea clearly defined.~~

	~~==Write your code==~~

	~~Writing code isn't just writing the lines of C++. It's also documenting the code, designing a test plan, doing the actual testing, and making sure it works in a variety of situations.~~

	When you think it's solid, you should create a patch file (using a diff tool like svn diff) and attach the patch to the JIRA. You should attach the test plan in the JIRA, either directly in a comment, an attached document, or a nonvolatile link to it on the web.

	~~==Get your code reviewed==~~

	You should then ask in the JIRA, and possibly on SLDev, for comments on the code and for people to help by trying out the test plan. Give people time (at least a day, maybe quite a bit more depending on the complexity of your submission and the timing) to evaluate it and comment.

	~~Keep in mind that a positive, engaged attitude on SLDev and in JIRA is likely to garner more support than a more negative approach.~~

	~~==Get it committed to the repository==~~

	~~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. Engage folks on SLDev to get support: are people interested by~~
	~~the feature, is this a worthy issue to fix?~~

	~~If there is community~~
	~~support and a good review of the code from committers, the patch will~~
	~~be taken in and committed by one of the committers. Eventually, if your~~
	~~contributions are significant and in line with the project,~~
	~~other committers might propose that you to become a committer himself. The~~
	~~committers group grows by internal recommendations 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.~~

	~~==Track it through the merge process==~~

	~~Some contributions may merge back to the official viewer someday. That~~
	~~will be up to the LL~~
	~~viewer team to cherry pick and merge patches/commits separately.~~

	~~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.~~

Merov Linden: /* Talk to the mailing list */

2009-05-01T20:02:58Z

Talk to the mailing list

← Older revision		Revision as of 13:02, 1 May 2009
Line 12:		Line 12:
	==Talk to the mailing list==		==Talk to the mailing list==

	First, you might want to have a discussion about your idea. Chat on the SLDev mailing list. Create a JIRA and see if others agree with you. Refine the JIRA to get the idea clearly defined.		First, you might want to have a discussion about your idea. Chat on the [[SLDev \| SLDev mailing list]]. Create a [[Issue tracker \| JIRA entry]] and see if others agree with you. Refine the JIRA entry to get the idea clearly defined.

	==Write your code==		==Write your code==

Merov Linden: /* What is the SLDev Open Source Viewer? */

2009-05-01T19:55:43Z

What is the SLDev Open Source Viewer?

← Older revision		Revision as of 12:55, 1 May 2009
Line 5:		Line 5:
	Merov posted on SLDev:		Merov posted on SLDev:

	''We do hope that most of the innovations battle-tested here will		''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 simply won't make it there and that's ok. People will still be able to get those features in the "Second Life OSS" download though.''
	eventually make it to the official viewer codebase but things that are
	clearly not mainstream enough or not very popular with this community
	simply won't make it there and that's ok. People will still be able to
	get those features in the "Second Life OSS" download though.''

	This document is an edited version of some of Merov's other comments on the SLDev list combined with an edited outline originally by Mike Monkowski.		This document is an edited version of some of Merov's other comments on the SLDev list combined with an edited outline originally by Mike Monkowski.


	=How do I contribute to it?=		=How do I contribute to it?=

Joshua Linden: /* Get it committed to the repository */

2009-05-01T15:25:19Z

Get it committed to the repository

← Older revision		Revision as of 08:25, 1 May 2009
Line 34:		Line 34:

	It's like almost any other FLOSS project: there is a group of		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		'''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		difference with the "old LL way of doing things" is that this group of
	committers has Lindens and non-Lindens. Engage folks on SLDev to get support: are people interested by		committers has Lindens '''and''' non-Lindens. Engage folks on SLDev to get support: are people interested by
	the feature, is this a worthy issue to fix?		the feature, is this a worthy issue to fix?

Line 46:		Line 46:
	committers group grows by internal recommendations only.		committers group grows by internal recommendations only.

	If someone objects (and if our community is alive, there will be		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		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		list. If there's a really contentious decision to be made (split

Joshua Linden: /* Get it committed to the repository */

2009-05-01T15:25:01Z

Get it committed to the repository

← Older revision		Revision as of 08:25, 1 May 2009
Line 34:		Line 34:

	It's like almost any other FLOSS project: there is a group of		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		''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		difference with the "old LL way of doing things" is that this group of
	committers has Lindens and non-Lindens. Engage folks on SLDev to get support: are people interested by		committers has Lindens and non-Lindens. Engage folks on SLDev to get support: are people interested by

Q Linden: New page: =What is the SLDev Open Source Viewer?= See [https://blogs.secondlife.com/community/technology/blog/2009/03/30/intensifying-open-source-efforts Philip's blog post] for the initial announc...

2009-05-01T14:54:44Z

New page: =What is the SLDev Open Source Viewer?= See [https://blogs.secondlife.com/community/technology/blog/2009/03/30/intensifying-open-source-efforts Philip's blog post] for the initial announc...

New page

=What is the SLDev Open Source Viewer?=

See [https://blogs.secondlife.com/community/technology/blog/2009/03/30/intensifying-open-source-efforts Philip's blog post] for the initial announcement.

Merov posted on SLDev:

''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
simply won't make it there and that's ok. People will still be able to
get those features in the "Second Life OSS" download though.''

This document is an edited version of some of Merov's other comments on the SLDev list combined with an edited outline originally by Mike Monkowski.

=How do I contribute to it?=
==Talk to the mailing list==

First, you might want to have a discussion about your idea. Chat on the SLDev mailing list. Create a JIRA and see if others agree with you. Refine the JIRA to get the idea clearly defined.

==Write your code==

Writing code isn't just writing the lines of C++. It's also documenting the code, designing a test plan, doing the actual testing, and making sure it works in a variety of situations.

When you think it's solid, you should create a patch file (using a diff tool like svn diff) and attach the patch to the JIRA. You should attach the test plan in the JIRA, either directly in a comment, an attached document, or a nonvolatile link to it on the web.

==Get your code reviewed==

You should then ask in the JIRA, and possibly on SLDev, for comments on the code and for people to help by trying out the test plan. Give people time (at least a day, maybe quite a bit more depending on the complexity of your submission and the timing) to evaluate it and comment.

Keep in mind that a positive, engaged attitude on SLDev and in JIRA is likely to garner more support than a more negative approach.

==Get it committed to the repository==

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. Engage folks on SLDev to get support: are people interested by
the feature, is this a worthy issue to fix?

If there is community
support and a good review of the code from committers, the patch will
be taken in and committed by one of the committers. Eventually, if your
contributions are significant and in line with the project,
other committers might propose that you to become a committer himself. The
committers group grows by internal recommendations 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.

==Track it through the merge process==

Some contributions may merge back to the official viewer someday. That
will be up to the LL
viewer team to cherry pick and merge patches/commits separately.

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.