Hi, Ernesto,
I was actually suggesting literally “neon.x” as the name, not meaning “x” to be a placeholder for any numbers or anything. Just something that means “this is the continuation of the neon development stream for incremental releases based on the first Neon release”.
We cannot rename the master branch and rename other branches as master. That is extremely disruptive to git clones.
I have no idea how gerrit associates its own branches to the main repository’s branches, whether symbolically by name (which a rename would break) or by commit hashes (which a rename would not break) or something else. Sorry.
cWOn 25 May, 2016 at 09:36:58, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:
I imagine that Papyrus-RT inherited the same
restrictions as Papyrus. Does anyone know if that's the case?
Perhaps the project leaders (Remi, Simon) have permissions to
delete/rename?
As for the name of the new temporary branch, I'm fine with
neon.X. I think it's supposed to be neon.0.1 since we have been
using 1.0.1 in Bugzilla for everything new, but Charles mentioned
that 1.0.1 might be renamed 1.1, in which case the new branch
should be neon.1. Any thoughts or opinions on this?
@Christian: the way I understood the workflow described by
Camille (and he can confirm or correct me) is that after 'master'
is renamed into 'maintenance' (or something else) and the 'neon.X'
branch is rebased then 'neon.X' would be renamed 'master'.
Also, another technical issue. I already pushed a gerrit to
this new 1.0.1. Renaming the branch should not affect that,
right?
Hi Camille,
Thanks for the information, that explains why I
didn’t find any official wiki on the subject.
Benoit,
Objet :
[PROVENANCE INTERNET] Re: [papyrus-rt-dev] Feature freeze and git
repo
Hi Benoit,
This is a restriction we have specifically requested for the
Papyrus GIT Repository, because we had a lot of mistakes done by
committers, causing a lot of mess and confusion
This is not a generic Eclipse restriction
(Although Papyrus is not the only project doing this)
Objet :
[PROVENANCE INTERNET] Re: [papyrus-rt-dev] Feature freeze and git
repo
Hi,
I fear you won’t be able to delete/rename this
branch.
There seems to be some eclipse restriction to
avoid messing up the repositories
You can check some of the bugs Git/Community [1]
[2]
I didn’t found the official documentation, but
from my experience on Papyrus Repository, normal committers
(I J) can only :
-
create branches without restriction
-
delete/rename branches following the pattern
bugs/* or committers/*
For other manipulation you should open a community
bug with a +1 from project leader.
Regards,
Benoit
Ps: @Christian : In the specific eclipse context
you can imagine having only branch following the release train
(luna,mars,neon,oxygen…) and put the Head to the latest name. But
it would be very hard to understand that for non-eclipse
newcomers.
1 :
https://bugs.eclipse.org/bugs/buglist.cgi?component=Git&list_id=14472810&product=Community
2 :
https://bugs.eclipse.org/bugs/show_bug.cgi?id=362363
Envoyé : mardi 24 mai 2016 21:33
There
has been much discussion about the nature of the maintenance
releases at the Simultaneous Release / Planning Council level, to
the point where I think there was general agreement that the term
“maintenance” was deprecated and the X.1, X.2, etc. naming scheme
was adopted for the Simultaneous Release. So, yeah, I suppose
we shouldn’t use the “maintenance” term in our branch name any
more, either.
Unfortunately,
we already had a branch named “neon.” Perhaps “neon.x” would
clearly indicate that it’s the continuation of the neon development
stream?
Deleting
a remote branch would have to be done on the command-line using the
"git branch -d -r" command. I think any committer should have
permission to do that, but I’m not sure. You can also rename
it, which might be safer anyways, with "git branch -m”. But
do ask on the list before doing that in case anybody has already
based local branches on it.
I’ve
never done a git workflow that involves renaming master to another
name. That seems very odd to me. Presumably this
involves also renaming some other branch as “master" because, of
course, we expect always to have a master. I would find it
very unsettling that the nature of my master branch changes
drastically when I do a pull. It is generally bad form to
rename any heads in the shared repo that clones are referencing as
upstreams because it results in surprising pulls with outcomes
(merges or rebases) that developers have little chance of
understanding.
On
24 May, 2016 at 15:10:00, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:
Hi
Christian. I see. Yes, it would be ambiguous. I'm open to other
names, but is "1.0-maintenance" the right name? To me that suggests
bug fixes, while this new branch is intended for new features and
functionality, as discussed, and as Camille explained in this
thread, once there is a release, 'master' is renamed 'maintenance'
and this temporary branch is rebased. So I created the branch with
this name rather than "maintenance" to be in line with that.
Also,
there is a technical problem: I don't know how to delete branches
on Gerrit. The Gerrit dashboard shows me only a "Create branch"
button, and nothing else, no "Rename" or "Delete"
branch.
The
name “1.0.1” would be confused with the eventual tag of that name,
so that a checkout command would be ambiguous.
Could
we name it “1.0-maintenance”, instead, as is commonly done in
Eclipse Modeling Projects (at least UML2 and Papyrus)?
On
24 May, 2016 at 11:08:50, Céline JANSSENS (celine.janssens@xxxxxxxxxxx) wrote:
Hello
Ernesto,
Good Idea, i'm going to create a specific Job gerrit for this
Branch !
Regards
Céline
Le
24/05/2016 à 16:57, Ernesto Posse a écrit :
Hello.
I didn't hear from anyone else, so I created a new branch called
"1.0.1".
This
branch is intended to be temporary. The idea is that before
release, commits on master should be bug fixes, and anything that
is a new feature should go on this 1.0.1 branch.
On
release we'll rename "master" as "maintenance" or "release", and
we'll rebase "1.0.1".
Ø While it's true that between feature freeze and
release we should focus on testing and fixing bugs, I think having
a branch that fully builds new features could be helpful and
simplify the integration of new features once we release. I'm not
sure I like having pending changes hanging on Gerrit particularly
in the case where there is more than one Gerrit on top of another,
which become a pain to merge later on. And I also prefer having few
items in my Gerrit dashboard ;)
I agree; that’s exactly why we wanted to
experiment this for the Neon/Oxygen transition. As it happens, the
Oxygen branch has not been used yet, but at least we have a place
where new features can be integrated, built and tested if we ever
need it
Ø
In fact, the "anti-gitflow" approach advocated in
[2] seems to be closer to what you describe:
Much closer indeed, except for the “Release” part
of this article: our Maintenance branches have to evolve in
parallel to the master branch, so they remain forever, and we
indeed have duplicate (“cherry picks”) commits between Maintenance
and Master branches. We can’t merge these branches, because
versions evolve independently (e.g. when Mars moves from 1.1.0 to
1.1.1, Neon M1 goes from 1.1.0 to 1.2.0. Also, some fixes involve
breaking APIs, so we usually implement a quick workaround for the
maintenance branch, and a proper, larger fix on master). So we
actually need maintenance branches that remain forever.
Regards,
Camille
De :
papyrus-rt-dev-bounces@xxxxxxxxxxx
[mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De la part
de Ernesto Posse
Envoyé : mardi 17 mai 2016 21:31
Objet :
Re:
[papyrus-rt-dev] Feature freeze and git repo
I like the idea of a temporary branch for new
features, a little bit like in the gitflow model [1], although that
seems to use a merge approach rather than a rebase approach like
us, and it has its drawbacks [2].
In fact, the "anti-gitflow" approach advocated
in [2] seems to be closer to what you describe: consistent with the
goal of keeping a linear history, making other branches temporary,
creating a branch for the release (i.e. the "maintenance" branch).
That sounds good to me.
While it's true that between feature freeze
and release we should focus on testing and fixing bugs, I think
having a branch that fully builds new features could be helpful and
simplify the integration of new features once we release. I'm not
sure I like having pending changes hanging on Gerrit particularly
in the case where there is more than one Gerrit on top of another,
which become a pain to merge later on. And I also prefer having few
items in my Gerrit dashboard ;)
So if we are voting, I'd vote for having a
feature branch, renaming 'master' to 'maintenance' after release
and rebasing the feature branch.
Hi,
In Papyrus, we don’t switch branches until the
final release (Which is RC4 for us). Any new feature is postponed
(e.g. pending on Gerrit) until the release is complete. This is
mainly to avoid reconfiguring the build & scripts due to
switching branches.
We’re however experimenting a new approach this
year: we’ve created a new branch after Feature Freeze (M7), for the
next release. This is a temporary branch, that will be rebased to
master after the final release (RC4). Once the branch is rebased,
the current master will be renamed to maintenance, and the rebased
branch will become the new master
The point with this approach is to be able to push
new features on a dedicated branch, where we can have complete
builds/validation, and we can merge several features on the same
branch to identify conflicts early, without changing the current
structure for the master branch (Same branch name, same build
configuration...)
We don’t have too many contributions on this new
branch, so it’s hard to tell whether it was useful at all. In
general, at this time, we should be focusing on bug fixes anyway;
not on features for the next yearly release. So, I’d say, new
branches can wait :) but it really depends on your plans and
contributions
Regards,
Camille
De :
papyrus-rt-dev-bounces@xxxxxxxxxxx
[mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De la part
de Ernesto Posse
Envoyé : mardi 17 mai 2016 02:32
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : [papyrus-rt-dev] Feature freeze and git
repo
Since we have feature freeze this Friday, I
was wondering how are we going to deal with it in the git repo. Are
we going to create a "1.0.0" branch and continue 1.0.1 development
on master, or are we going to create a "1.0.1" branch and let
master be 1.0.0 with only bug fixes committed on it, or something
else? What does Papyrus do?
--
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
--
|
Céline JANSSENS
Software
Engineer
+33 (0)2 44 47 23 23
|
|
Mail : cej@xxxxxxxxxxx
|
6 rue Léonard De Vinci - BP 0119 - 53001 LAVAL Cedex - FRANCE
www.all4tec.net
|
|
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
_______________________________________________
papyrus-rt-dev mailing list
papyrus-rt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/papyrus-rt-dev
|