[Develop] trunk and branches - the new (old) deal

[Nick Nassar]

As someone working on what would go into a "big change" branch, I have a
big problem with your proposal.

As I understand it, your proposal basically comes down to moving the 1.x
"stable" branch to trunk and moving major new features go into their own
branches.  Instead of doing this, I think we should go with your other
suggestions of adding support for building nightlies from multiple
branches to our scripts, better documentation, and writing scripts to
automate translation work.


I think we still need an "unstable" branch that contains all of the new
features.  I don't want to split the trunk branch into lots of different
unstable branches.

I'm working on major UI changes that will be too unstable to include in
trunk for a long time, will need some testing early on and lots of
testing towards the end of their development, and integrate closely with
other "big change" branches.

Your proposal will make life easier for the 1.x releases in the short
term but make adding new features more difficult.

Going through each of the problems you have with the current system.

Merging. Your proposal creates more merging problems for experimental
branches.  We'll have to periodically merge in changes from stable, then
make a giant merge once our experimental branch is done.  Then, all the
other people working on experiemental branches will need to merge that
giant merge into their experiemental branch. So, what would have been
lots of little merges will turn into several large non-trivial merges.
It also means that stable will get blasted with large changes all at
once.

Translations. With your new proposal, experimental branches just don't
get translated.  That means if there's an i18n problem, I don't know
about it until my code has been merged into the stable branch. That's
worth the trouble of uploading two sets of translations to launchpad
instead of one. If time spent uploading translations is a problem, one
of us should just write a script to automate it.  If a string in one
branch is translated, launchpad is smart enouogh to suggest that same
string for the other branch, so this won't cost ours translators too
much time either.

Repository Complexity. I don't think your proposal makes things less
confusing for contributors.  It's a common convention that trunk is
"unstable" and stable versions are kept in branches. Also, having
separate branches for each features makes it difficult for people who
want to test or develop these new features. They have to know what
branch their feature is in.

Testing and nightly builds. I want people to start testing my new
features before they're stable enough for the general public, and I want
them to be tested with other major features so we catch unexpected
interactions early. Your proposal makes that impossible.  If having a
"stable" nightly and an "unstable" nightly is causing trouble or
confusing, one of us should spend the time to fix it.

What does everyone else think?

Nick

>>>>> "will" == will  <willg at bluesock.org> writes:

    will> So...  I thought it was a good idea to do future development
    will> in the trunk and then merge 1.1 changes down to the 1.0
    will> branch.  I'm regretting that at this point.

    will> The the problems are four-fold:

    will> 1. It requires a lot of non-trivial merging.

    will> 2. We'll have to maintain translations for multiple
    will> branches--which is potentially more work; bdk mentioned we
    will> could write a script to merge translations and figure it out,
    will> but I think this complexifies the matter enough that it could
    will> cause other issues that we'd spend time chasing down.

    will> 3. It makes our repository setup more complex for
    will> contributors.  It causes us to go through and update all of
    will> our documentation regarding which branch is for what
    will> development and keep these up to date (which we didn't do).
    will> I've had several conversations with people trying to build
    will> Miro and having problems and then trying to explain that we're
    will> doing different development in different branches and ...  Too
    will> hard.

    will> 4. Nightlies and testing is more complex.  "svn nightly" in
    will> Bugzilla suddenly isn't useful enough--we need to know which
    will> branch the problem is in.


    will> Matt spent a bunch of time adding support for building
    will> nightlies for multiple branches, but are we getting the same
    will> amount of testing for multiple branches?

    will> The third problem could be fixed with a written explanation of
    will> the plan and better documentation.

    will> The second problem could probably be fixed with additional
    will> scripts to manage translation merging and such or just making
    will> translators work on multiple translations.

    will> The first is a problem whichever way the merging goes.

    will> We've got a small number of developers still and a small
    will> number of "big changes" in the works, so I think it's better
    will> to optimize our time in regards to simplifying testing and
    will> production of new releases.  Thus the new plan...  (which is
    will> really the old plan before I suggested a terrible idea).


    will> The new plan ============

    will> We're thinking that the new plan going forward should be this:

    will> 1. The trunk is for development on "the next release".
    will> Currently "the next release" is 1.1.  Following the release of
    will> 1.1 it'll be whatever the following release is...  1.2
    will> probably.

    will> 2. The Democracy-Player-x.x branches are for maintenance
    will> releases.  For example, when we release Miro 1.1, then the
    will> Democracy-Player-1.1 branch will be for 1.1 maintenance--not
    will> for 1.2 development.

    will> 3. Any future development that isn't scheduled to land in "the
    will> next release" gets its own branch in the tree.  For example,
    will> bdk's work to split the front end from the back end is in
    will> branches/frontend-startup/ (to be renamed when he sees fit).
    will> It's possible svnmerge will alleviate issues with this since
    will> merging will be in one direction from one source: the trunk to
    will> the branch.


    will> Fixes for the 1.1 release =========================

    will> To fix the mild debacle we're in, we need to do the following
    will> soon:

    will> 1. Remove whatever changes that are in trunk that aren't going
    will> with 1.1.  I think this is limited to bdk's frontend
    will> separation changes.  Are Luc's build changes going with 1.1?

    will> 2. Update the documentation in the wiki to reflect the new
    will> plan.

    will> 3. Revert to doing nightlies on the trunk.

    will> 4. Revert to doing translations on the trunk.

    will> 5. Fix the version number on the trunk from 1.5 to 1.1.


    will> Going forward =============

    will> 1. Development for "the next release" is done in the trunk.

    will> 2. Development on features or other things that are not
    will> landing in "the next release" go into a branch.


    will> Comments/suggestions?  =====================

    will> Does this sound ok going forward?  What other aspects of
    will> development and releases are not accounted for in this plan?

    will> Can we either get these changes done or figure out how else to
    will> fix the mild mess we have before tomorrow (Thursday -
    will> 12/13/2007) so that we can have all the pieces in place for
    will> finishing up the 1.1 release and getting it out next week.

    will> /will _______________________________________________ Develop
    will> mailing list Develop at pculture.org
    will> http://participatoryculture.org/mailman/listinfo/develop