Proposed change to Development

Hi list.

th and I just discussed a possible change to the current way of development
and we like to hear your opinion on it:

The current model is like this:
1. Patch is submitted to SubMaster
2. Patch is reviewed and commented/voted on
	2.1. Patch may be rejected at this point
	2.2. Patch may be discarded and resubmitted with changes
	2.3. Patch may be applied if it doesn't affect CORE packages
	     or parts outside the package/ directory.
3. Patch is tested in a Crystal and Bootdisk build
4. Crystal and Bootdisk build are tested in an installation
5. Patch may be found to not work. Continue at 2.
6. Patch may be found to work and be applied

For development on larger parts of ROCK, points 3. and 4. take a lot of time,
usually a week. This can slow down development of these larger parts. A
current example is the integration of /etc/net into Crystal.

th and I discussed a way to keep the review part intact while at the same
time allowing for faster development on /etc/net and similar projects.
This is what we came up with:

We can create branches in the rock-linux subversion repository. Developers
working on the respective branch will get write access there. For example

	rock-linux/branches/etcnet

for the integration of /etc/net into ROCK. Developers can then directly commit
their changes there. When they are done, they request a 'svn merge' of this
branch into trunk.
Submaster is to be modified to allow for this kind of requests.
The smng server can even display the patch by doing a 'svn diff'.

Here is an example of how this might work. This is based on the
"Feature Branch" section of
	http://svnbook.red-bean.com/nightly/en/svn.branchmerge.commonuses.html

At the start of a project - say /etc/net integration - the head developer of
that project asks for a branch to be created and write access given to the
developers that work on that project.
A branch is then created by means of 'svn cp trunk branches/etcnet'.
Work continues both in trunk and the etcnet branch. The branch should get
the changes in trunk regularly. The mechanism to do that is 'svn merge'.
This is the job of the branch developers.
When work on the branch is done, a merge of the branch into trunk is
requested. This will then be subject to the same kind of review as patches
are with the current system.

A merge request can look like this:

/etc/net integration team:
	merge work on /etc/net into trunk.
	svn merge -r 8912:9123 svn://www.rocklinux.net/rock-linux/branches/etcnet



The advantage of this is that developers can work together on certain
projects without having to wait for a week for every change to be applied.
Another advantage is that meta-information from 'svn mv' 'svn del' and
'svn add' is preserved. With 'diff' based operation, that information may be
lost unless people are really careful.


Comments, please!


Greetings,
	blindy
-- 
 _  _     _   _            _   
| \| |___| |_| |_  __ _ __| |__
| .` / -_)  _| ' \/ _` / _| / /
|_|\_\___|\__|_||_\__,_\__|_\_\
| |  (_)_ _ _  ___ __
| |__| | ' \ || \ \ /
|____|_|_||_\_,_/_\_\
Play Nethack anywhere with an x86 computer:
	http://www.crash-override.net/nethacklinux.html

_______________________________________________
rock-devel mailing list
[email protected]
http://www.rocklinux.net/mailman/listinfo/rock-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFFL0dbr0OTeImXvg8RAq50AJ4mi7D9kFJAmZWgbcU7UEA+lIGIMQCfXwCv
gmLHzbyg2mglyhRiJ8LPwgU=
=Ibon
-----END PGP SIGNATURE-----