Hi developers,
I have a little suggestion for everyone playing on branches. We all know branches
are both an opportunity, when opened to explore new paths, and a headache when
they try to come home.
For every branch that is not just a playground, I'd like to see the following:
* a clear cut objective of the branch, that is clearly stated somewhere and mantained,
should amendments be necessary. A branch that does a single crisp change has
a much better change of getting back into trunk.
* a changelog that summarizes what has been done on the branch. This server two
purposes, it allows people to track what's going on without having to skim thru the
svn commits or svn log, and provides PMC an overview of what happened when
the developer(s) ask for merger into trunk.
I know I'm guilty in this respect, me too, but since branches are become common place
I'd like at least to have them more manageable.
Finally, since both Geotools and Geoserver (with 1.4.x branch) do have a modular
architecture, think hard if the purpose of the branch could not be better served with
a separate module (and no need to branch 
)
Any other suggestions in this respect? In my opinion some branch guideline would
be a nice addition to the developer guide and the development effort itself.
Comments welcome
Cheers
Andrea
A defined timeline to merge branches back onto trunk will help too. It's always hard to "finish" a project unless you have a deadline. Even if it isn't complete, you can gain a lot by merging over at reasonable intervals.
Brent Owens
(The Open Planning Project)
Andrea Aime wrote:
Hi developers,
I have a little suggestion for everyone playing on branches. We all know branches
are both an opportunity, when opened to explore new paths, and a headache when
they try to come home.
For every branch that is not just a playground, I'd like to see the following:
* a clear cut objective of the branch, that is clearly stated somewhere and mantained,
should amendments be necessary. A branch that does a single crisp change has
a much better change of getting back into trunk.
* a changelog that summarizes what has been done on the branch. This server two
purposes, it allows people to track what's going on without having to skim thru the
svn commits or svn log, and provides PMC an overview of what happened when
the developer(s) ask for merger into trunk.
I know I'm guilty in this respect, me too, but since branches are become common place
I'd like at least to have them more manageable.
Finally, since both Geotools and Geoserver (with 1.4.x branch) do have a modular
architecture, think hard if the purpose of the branch could not be better served with
a separate module (and no need to branch )
Any other suggestions in this respect? In my opinion some branch guideline would
be a nice addition to the developer guide and the development effort itself.
Comments welcome
Cheers
Andrea
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Hi all,
Having been working on a branch I might have one or two things to add :). I had a huge rant all planned but then realized that that is not the point of this thread.
So to save you lots of reading I will just submit my suggestion.
I would like to see the project more reluctant to letting people branch. As an alternative perhaps the project could allow for more "unstable" development. It might tick people off short term but in my opinion a bit of annoyance is better then having someone lose 6 months of work, and never having that work recontributed back to the core.
I know that this has been proposed before but perhaps we could adopt a scheme in which odd numbered releases are "unstable", during which R&D is allowed on trunk.
-Justin
Andrea Aime wrote:
Hi developers,
I have a little suggestion for everyone playing on branches. We all know branches
are both an opportunity, when opened to explore new paths, and a headache when
they try to come home.
For every branch that is not just a playground, I'd like to see the following:
* a clear cut objective of the branch, that is clearly stated somewhere and mantained,
should amendments be necessary. A branch that does a single crisp change has
a much better change of getting back into trunk.
* a changelog that summarizes what has been done on the branch. This server two
purposes, it allows people to track what's going on without having to skim thru the
svn commits or svn log, and provides PMC an overview of what happened when
the developer(s) ask for merger into trunk.
I know I'm guilty in this respect, me too, but since branches are become common place
I'd like at least to have them more manageable.
Finally, since both Geotools and Geoserver (with 1.4.x branch) do have a modular
architecture, think hard if the purpose of the branch could not be better served with
a separate module (and no need to branch )
Any other suggestions in this respect? In my opinion some branch guideline would
be a nice addition to the developer guide and the development effort itself.
Comments welcome
Cheers
Andrea
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
!DSPAM:1004,448c171c43302095110867!
--
Justin Deoliveira
The Open Planning Project
jdeolive@anonymised.com
Justin Deoliveira wrote:
Hi all,
Having been working on a branch I might have one or two things to add :). I had a huge rant all planned but then realized that that is not the point of this thread.
So to save you lots of reading I will just submit my suggestion.
I would like to see the project more reluctant to letting people branch. As an alternative perhaps the project could allow for more "unstable" development. It might tick people off short term but in my opinion a bit of annoyance is better then having someone lose 6 months of work, and never having that work recontributed back to the core.
I know that this has been proposed before but perhaps we could adopt a scheme in which odd numbered releases are "unstable", during which R&D is allowed on trunk.
Hmmm... I think to some extent the grass is always greener on the other side. GeoTools used to be trunk was the place of development work, but the problem was that someone would always be adding something new, and things would never settle. We were in beta for years.
At this point I'm really not convinced that a change in process will really change things, there are ways that each can be frustrating. The thing to do is to manage better whatever route we choose. I think Andrea's suggestion is a good one.
One could easily see trunk being the place of development and people just being more loose with such things, and making it an even more unpleasant place to work than a branch. Also work that is just not ready for prime time could either be released in a poor state, or else hold up everything else. I argue that in theory there's a slight advantage to doing branching, but either way the much more important thing is to manage it all well.
Chris
-Justin
Andrea Aime wrote:
Hi developers,
I have a little suggestion for everyone playing on branches. We all know branches
are both an opportunity, when opened to explore new paths, and a headache when
they try to come home.
For every branch that is not just a playground, I'd like to see the following:
* a clear cut objective of the branch, that is clearly stated somewhere and mantained,
should amendments be necessary. A branch that does a single crisp change has
a much better change of getting back into trunk.
* a changelog that summarizes what has been done on the branch. This server two
purposes, it allows people to track what's going on without having to skim thru the
svn commits or svn log, and provides PMC an overview of what happened when
the developer(s) ask for merger into trunk.
I know I'm guilty in this respect, me too, but since branches are become common place
I'd like at least to have them more manageable.
Finally, since both Geotools and Geoserver (with 1.4.x branch) do have a modular
architecture, think hard if the purpose of the branch could not be better served with
a separate module (and no need to branch )
Any other suggestions in this respect? In my opinion some branch guideline would
be a nice addition to the developer guide and the development effort itself.
Comments welcome
Cheers
Andrea
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org