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

[will]

Ok.  So for 1.1 all we need to do is merge whatever needs to go into 1.1 
that isn't already there which (I think) is just the libtorrent changes.

Then we need to figure out what to do with translations.  I don't know 
anything about translations, so...  I don't know what to do here, but 
Matt mentioned issues earlier.

I'll try to figure out how to document the workflow and make the changes 
to the wiki to alleviate the problem I'm having where people keep asking 
me about how to build Miro and they've got the wrong branch and the 
wrong requirements and ...  sorting it out takes several exchanges of email.

We'll continue testing on trunk and the 1.0 branch.  How do we specify 
which svn nightly issues are on for bugs in bugzilla?  Should we have 
"svn nightly stable" and "svn nightly unstable"?

Are there any other issues we need to sort out?


Nick Nassar wrote:
> I think we should designate the "Democracy-Player-1.0" branch as the
> "stable" branch and put all of the "stable" bug fixes and features
> into that.  When we're approaching a release, we'll tag that branch.
> 
> We don't need to branch for 1.1. The reason we branched for earlier
> minor revisions is that we wanted to be able to check new features into
> trunk without disrupting the release. We'll still be able to do that.
> 
>>>>>> "will" == will <willg at bluesock.org> writes:
> 
>     will> Hrm....  I agree with a lot of what you're saying, but I think
>     will> we don't have enough people working on the project to manage a
>     will> more complex workflow.
> 
>     will> So...  say we don't go with reverting the workflow to "trunk
>     will> is for the next release", how do we get to 1.1 from here?
> 
> 
>     will> Nick Nassar wrote:
>     >> 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