Branching

Hi folks

Now that we're rolling a ZBR I'm excited to start working on
0.7.1  
bugs. I'd like to be able to check my work in, so there are
a few  
questions that need answers:

1) What's our branching strategy for the 0.7.x releases?
     a) Branches off trunk that are merged back to trunk at
the time  
of the "dot release"?
     b) Branches off a "0.7" branch that is kept
"0.7 pristine",  
merging the branches back to trunk at the time of "dot
releases"?
     c) Other?

2) What about the work Brian's already doing on 0.8? When
does that  
get merged back to trunk?

It would be nice to set a precedent that everyone is happy
(or at  
least not unhappy) with during the next month or so, so my
intention  
with this thread is to come to that consensus.

-Travis
_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

On 8/14/07, Travis Vachon <travisosafoundation.org>
wrote:

> Now that we're rolling a ZBR I'm excited to start
working on 0.7.1
> bugs. I'd like to be able to check my work in, so there
are a few
> questions that need answers:
>
> 1) What's our branching strategy for the 0.7.x
releases?
>      a) Branches off trunk that are merged back to
trunk at the time
> of the "dot release"?
>      b) Branches off a "0.7" branch that is
kept "0.7 pristine",
> merging the branches back to trunk at the time of
"dot releases"?
>      c) Other?

what i've typically done in the past is create a maintenance
branch
for 0.7 and start spinning rcs off that. once 0.7 final is
out, 0.7.1
work begins on the 0.7 branch. the nature of maintenance
releases is
such that we shouldn't have major refactoring work going on
that would
necessitate any sub-branches. all bug fixes would go onto
the 0.7
branch until 0.7.1 is shipped, at which time those fixes
would all be
merged onto the trunk. future bug fixes would continue on
the 0.7
branch until 0.7.2 is shipped, at which time those fixes
would merged
onto the trunk. and so on and so forth, until the 0.7 line
is declared
dead.

> 2) What about the work Brian's already doing on 0.8?
When does that
> get merged back to trunk?

in the not too distant future after the 0.7 branch is
created. if the
changes i'd been making resulted in widespread breakage, i'd
wait til
all that was resolved before landing the branch, but the
changes are
localized to the dav subsystem, and nothing else in the
server depends
on that. it should be pretty stable now anyway.

i'm not sure what we plan to add to 0.8 other than some
amount of the
dav interop work i've listed on my journal page. we can make
a 0.9
branch off of the trunk when people start to need that, and
anybody
else working on 0.8 can work on the trunk.
_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

On Aug 14, 2007, at 1:30 PM, Travis Vachon wrote:

> Hi folks
>
> Now that we're rolling a ZBR I'm excited to start
working on 0.7.1 
> bugs. I'd like to be able to check my work in, so there
are a few 
> questions that need answers:
>
> 1) What's our branching strategy for the 0.7.x
releases?

Like Brian mentioned in his reply, I also prefer to create a
0.7 branch 
for all 0.7 work and then make the trunk 0.8-SNAPSHOT

This worked well last time with the caveat that the
developers *have* 
to backport all 0.7 bug fixes to the trunk.  If that is not
done then 
it's not worth creating a branch.  Because of the
refactoring that 
normally accompanies a minor rev change, the devs cannot
rely on using 
svn merge to automatically backport fixes in one huge chunk
- too much 
will have most likely changed.

>
> 2) What about the work Brian's already doing on 0.8?
When does that 
> get merged back to trunk?

Brian get's the joy of doing a merge to the trunk as soon as
the trunk 
is tagged as 0.8-SNAPSHOT

---
Bear

Build and Release Engineer
Open Source Applications Foundation (OSAF)
bearosafoundation.org
http://www.osafoundation
.org

bearcode-bear.com
http://code-bear.com

PGP Fingerprint = 9996 719F 973D B11B E111  D770 9331 E822
40B3 CD29



_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

On 8/14/07, Mike <bearcode-bear.com> wrote:

> This worked well last time with the caveat that the
developers *have*
> to backport all 0.7 bug fixes to the trunk.  If that is
not done then
> it's not worth creating a branch.  Because of the
refactoring that
> normally accompanies a minor rev change, the devs
cannot rely on using
> svn merge to automatically backport fixes in one huge
chunk - too much
> will have most likely changed.

i disagree with this. if a change on the maintenance branch
requires
substantial refactoring that might be hard to merge to the
trunk, it's
very likely that's not a change that should be incorporated
into a
maintenance release.

there's a higher annoyance cost in every developer having to
keep the
maintenance branch and trunk in sync after every commit, and
an
increased management overhead, as somebody else has to
review every
commit to make sure it is applied in both places. not so
when we can
so a single merge after every point release.
_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

So the actual mechanics of the branching aside, here are
some things  
to keep in mind about the 0.7.x series:

1. These are going to be bug fix only releases - no new
features, and  
no refactorings unless *absolutely* necessary for a bug fix.
 The  
goal of the 0.7.x series is to continue to stabilize the
software  
once it has been deployed.   Anything that looks remotely
like a  
feature should be targeted for 0.8.  The sole exception that
I can  
think of is making Safari work, and I don't think that will
be the  
target for 0.7.1

2. Releasing these on a regular schedule is important.  One
way of  
making sure that we do this is to restrict the number of
changes that  
we accept.

3. I expect prioritization of fixes to go in these releases
to be  
driven more by QA and PPD than by engineering.   We have not
yet gone  
through the exercise of prioritizing any bugs for 0.7.1, so
you  
should look at 0.7.1 as a holding bin for bugs that will get
spread  
out over 0.7.1, 2, 3, 4, etc.

Ted

On Aug 14, 2007, at 10:30 AM, Travis Vachon wrote:

> Hi folks
>
> Now that we're rolling a ZBR I'm excited to start
working on 0.7.1  
> bugs. I'd like to be able to check my work in, so there
are a few  
> questions that need answers:
>
> 1) What's our branching strategy for the 0.7.x
releases?
>     a) Branches off trunk that are merged back to trunk
at the time  
> of the "dot release"?
>     b) Branches off a "0.7" branch that is
kept "0.7 pristine",  
> merging the branches back to trunk at the time of
"dot releases"?
>     c) Other?
>
> 2) What about the work Brian's already doing on 0.8?
When does that  
> get merged back to trunk?
>
> It would be nice to set a precedent that everyone is
happy (or at  
> least not unhappy) with during the next month or so, so
my  
> intention with this thread is to come to that
consensus.
>
> -Travis
> _______________________________________________
> cosmo-dev mailing list
> cosmo-devlists.osafoundation.org
> http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

On Aug 14, 2007, at 4:05 PM, Brian Moseley wrote:

> On 8/14/07, Mike <bearcode-bear.com> wrote:
>
>> This worked well last time with the caveat that the
developers *have*
>> to backport all 0.7 bug fixes to the trunk.  If
that is not done then
>> it's not worth creating a branch.  Because of the
refactoring that
>> normally accompanies a minor rev change, the devs
cannot rely on using
>> svn merge to automatically backport fixes in one
huge chunk - too much
>> will have most likely changed.
>
> i disagree with this. if a change on the maintenance
branch requires
> substantial refactoring that might be hard to merge to
the trunk, it's
> very likely that's not a change that should be
incorporated into a
> maintenance release.

The refactoring that happens on the *trunk* can and does
cause merge 
issues - I wasn't talking about refactoring on the branch.

> there's a higher annoyance cost in every developer
having to keep the
> maintenance branch and trunk in sync after every
commit, and an
> increased management overhead, as somebody else has to
review every
> commit to make sure it is applied in both places. not
so when we can
> so a single merge after every point release.

The changes have to be merged - whether it's done for each
or as part 
of a single merge is up to the dev team.  I'm just pointing
out that in 
the past the single-release-backport-merge and is often not
simple.

---
Bear

Build and Release Engineer
Open Source Applications Foundation (OSAF)
bearosafoundation.org
http://www.osafoundation
.org

bearcode-bear.com
http://code-bear.com

PGP Fingerprint = 9996 719F 973D B11B E111  D770 9331 E822
40B3 CD29



_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev

On 8/14/07, Mike <bearcode-bear.com> wrote:

> The changes have to be merged - whether it's done for
each or as part
> of a single merge is up to the dev team.  I'm just
pointing out that in
> the past the single-release-backport-merge and is often
not simple.

i've messed these up in the past, so i won't argue, tho i'm
pretty
sure i have it down now. if the rest of the team wants to
commit them
in both places at the same time, then fine.
_______________________________________________
cosmo-dev mailing list
cosmo-devlists.osafoundation.org
http://lists.osafoundation.org/mailman/listinfo/cosmo-d
ev