| Re: [mdt-papyrus.dev] Erratum Re: Branch Conventions for Papyrus Git Repo |
|
Hi, The new branches layout is ready.
@Christian: I haven’t renamed the cdo_kepler branch. Feel free to move it to your committer folder, or remove it if you’re using the SVN history
instead. The Kepler maintenance branch is now
streams/0.10-maintenance The Luna development branch is
master Regards, __________________________ Camille Letavernier +33 (0)1 69 08 00 59 -
camille.letavernier@xxxxxx CEA LIST - Laboratoire d'Ingénierie dirigée par les modèles pour les Systèmes Embarqués (LISE) Papyrus :
http://www.eclipse.org/papyrus De : mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de LETAVERNIER Camille Hi all, Okay, so we’ll have the following structure : master streams/ -
0.9-maintenance -
0.10-maintenance committers/ -
…
o
…
o
… bugs/ -
123456 archives/ -
svn/
o
… For branches related to resolved/fixed bugs, should we delete them afterwards? For the “committers”, we have some cases (Currently one) where a non-committer is contributing a branch (viewpoints), which requires some review.
So using the committer-id under the committers/ folder would not be possible in this case.
I’m going to create the streams branches and move the deprecated branches to archives (They won’t be deleted for now). The sandbox/ folder probably doesn’t make sense anymore with this branches organization, so I think we should consider it deprecated. Regards, __________________________ Camille Letavernier +33 (0)1 69 08 00 59 -
camille.letavernier@xxxxxx CEA LIST - Laboratoire d'Ingénierie dirigée par les modèles pour les Systèmes Embarqués (LISE) Papyrus :
http://www.eclipse.org/papyrus De :
mdt-papyrus.dev-bounces@xxxxxxxxxxx [mailto:mdt-papyrus.dev-bounces@xxxxxxxxxxx]
De la part de Ed Willink Hi Christian 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.,
-------- >8 -------- cW On 2013-08-29, at 10:35 PM, Christian W. Damus <give.a.damus@xxxxxxxxx> wrote:
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.,
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.,
(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.,
-------- 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
_______________________________________________ mdt-papyrus.dev mailing list mdt-papyrus.dev@xxxxxxxxxxx https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
No virus found in this message. |