[mdt-papyrus.dev] Erratum Re: Branch Conventions for Papyrus Git Repo

["Christian W. Damus" <give.a.damus@xxxxxxxxx>]

Hi again, Team,

Sorry for the noise.  I made a late-night editorial mistake in my previous e-mail.  The proposal for maintenance stream branches should look like this:

-------- 8< --------

Streams

These branches are "production code" tracking maintenance branches for successive releases, named "streams/<major.minor>-maintenance" where <major.minor> is a feature release number.  e.g.,

• streams/
• 0.9-maintenance
• 0.10-maintenance
• 1.0-maintenance (next autumn)

-------- >8 --------

cW

On 2013-08-29, at 10:35 PM, Christian W. Damus <give.a.damus@xxxxxxxxx> wrote:

Hi, Team,

As I mentioned before, I like the naming conventions that the CDO project uses to organize topic branches.  The CDO project encourages the use of branches for development of particularly involved (or shared) effort on Bugzilla work items, as well as committers' own exploratory work for whatever reasons.  I would like to propose that Papyrus adopt a similar naming convention for branches, namely that:

Topic branches are designated as being of one of three kinds:

Bugs

These branches have changes that are specific to some particular Bugzilla, for example a large/complex enhancement or some collaborative work on a bug by multiple committers.  These are named "bugs/<bug-id>" where <bug-id> is the Bugzilla bug number, e.g.,

• bugs/415371

for my enhancement that extends Papyrus Search into CDO repositories.  This is one that I would actually like to push, soon, so that I can give other committers a view of API refactorings that I have in the works in code that they are likely to be working on.

Committers

These branches are for private or shared work that a committer is doing that doesn't pertain to a specific bug.  Usually it would be integrating changes in progress on several different bugs (because probably we shouldn't be using the Eclipse repo for our own whimsical explorations that don't trace to Bugzilla?)  These are named "committers/<user-id>/<whatever>" where <user-id> is the committer's user ID on the Eclipse servers and <whatever> is the committer's own arbitrary organization of branches within that tree.  e.g.,

• committers/cdamus/
• cdo_kepler
• cdo_luna
• committers/cletavernier/
• robotml/
• models
• diagrams

(just making up some stuff for Camille by way of example; sorry)

Streams

These branches are "production code" tracking maintenance branches for successive release, named "<major.minor>-maintenance" where <major.minor> is a feature release number.  e.g.,

• 0.9-maintenance
• 0.10-maintenance
• 1.0-maintenance (next autumn)

-------- 8< --------

Thoughts?  Concerns?  Raging enthusiasm?

For myself, I would like to have this settled sooner than later because, as I mentioned, I have API refactorings in the Papyrus Search plug-ins that I would like to share with the team but that aren't yet ready to integrate into master for Luna.

Thanks,

Christian