| Re: [papyrus-rt-dev] Feature freeze and git repo |
Hi,
Well, I think it really depends on what will happen on this branch until Neon.0
For Papyrus, we had a few features which were not ready for M7. They were supposed to join this Oxygen branch, but in practice, it seems that most of the work on these branches has been suspended for now. So, right now, we have 5 releng commits (To maintain dependencies) and 0 feature commit. If things stay like that until RC4, I won’t even bother integrating the branch
I see two other scenarios:
- There are very few feature commits and some releng commits
o An interactive rebase, skipping the releng commits, makes more sense
- There are more features than releng commits
o Merge makes more sense
The issue with merge compared to cherry pick/(interactive) rebase really starts when you have parallel version management (Which is why we can’t merge anything from Maintenance to Master on Papyrus, and vice-versa). So, yeah, rebase, rebase interactive, merge or nothing... Whatever is more relevant when the time actually comes to reintegrate the branch :)
Camille
De : papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De la part de Christian Damus
Envoyé : mercredi 25 mai 2016 16:39
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : Re: [papyrus-rt-dev] Feature freeze and git repo_______________________________________________
Hi, Camille,
This does clarify things, thanks. But why this rebasing, just to avoid two merge commits? It seems to me riskier to do such a large-scale rebase, which will sprinkle resolution of merge conflicts throughout potentially all of the commits that had accumulated along the Oxygen branch. In the merge scenario, conflicts are resolved exactly once and all in the merge commit. There shouldn’t then be any conflicts at all in the second merge that brings Oxygen back into master. Note also that if there are conflicts in the rebase, the same files will probably have to be manually merged again and again in subsequent commits, which is more work and therefore more prone to a mistake being made along the way. Unless, of course, you first squash all of Oxygen into one, which I wouldn’t recommend because it’s nice to have all of the commit history laid out.
Anyways, if this is how Papyrus wants to work it, I’m not sure that I would like to do the same in Papyrus-RT. What have our project leads to offer on the subject?
cW
On 25 May, 2016 at 10:25:53, LETAVERNIER Camille (camille.letavernier@xxxxxx) wrote:
Hi,
The idea is that, until the Neon.0 release, the Oxygen and the Neon branches are independent. Then, once Neon.0 is released, Oxygen is rebased on top of master/Neon, and becomes the new master. The former Oxygen branch is then deleted and never reused
So that’s a one-shot rebase. For users of the master branch, this will be fast-forward (Because Oxygen is rebased on master, *then* becomes master). For users of the Oxygen branch, they should stop using it after the rebase (The branch will be deleted, or simply not used anymore; the rebased version of the Oxygen branch does not need to be pushed – it will be pushed as ‘master’. This doesn’t introduce any conflict)
You should really see this Oxygen branch as a ‘temporary feature branch’, with exactly the same workflow: independent lifecycle, until it is rebased on master (one-shot) and then forgotten
I hope this clarifies things :)
Regards,
Camille
De : papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De la part de Christian Damus
Envoyé : mercredi 25 mai 2016 15:59
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : Re: [papyrus-rt-dev] Feature freeze and git repo
Hi, Camille,
Okay, so the Oxygen branch will be merged into master once the Neon release has shipped, right? That is the only way to ensure that master continues to fast-forward, which is an absolute requirement IMO.
Are you sure about rebasing the Oxygen branch periodically on master? If this Oxygen branch is intended to be used by anyone in their local clones, then it will break fast-forward for them, which is significantly complicates those developers’ lives. The way to keep Oxygen up-to-date with master is by periodically merging master into Oxygen.
cW
On 25 May, 2016 at 09:53:21, LETAVERNIER Camille (camille.letavernier@xxxxxx) wrote:
Hi Christian,
I think there’s a confusion here. The idea is to follow the pattern that we recently adopted for Papyrus/Oxygen, i.e. having a temporary branch for new features that won’t make it into Neon.0 (For Papyrus we used a bugs/xxxx-Oxygen branch)
So:
- Master is Neon.0
- There is currently no maintenance branch for Papyrus-RT (I think)
- New features cannot target Master (yet), because the Feature Freeze is already in place
Once Papyrus-RT 1.0 is released (~ in June, with Neon.0):
- A new ‘maintenance-Neon’ branch will be created from the latest ‘master’ commit (Exact name to be defined)
- The Oxygen feature branch will be rebased on ‘master’
- ‘master’ will be updated to this new Oxygen feature branch (So master will actually become Oxygen, in a fast-forward way)
This approach introduces no compatibility issue (The temporary Oxygen/Feature branch can be deleted at this point)
Regards,
Camille
De : papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De la part de Christian Damus
Envoyé : mercredi 25 mai 2016 15:42
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : Re: [papyrus-rt-dev] Feature freeze and git repo
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.
cW
On 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?
On Wed, May 25, 2016 at 8:14 AM MAGGI Benoit <Benoit.MAGGI@xxxxxx> wrote:
Hi Camille,
Thanks for the information, that explains why I didn’t find any official wiki on the subject.
Benoit,
De : papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De la part de LETAVERNIER Camille
Envoyé : mercredi 25 mai 2016 13:36
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>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)
Camille
De :papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De la part de MAGGI Benoit
Envoyé : mercredi 25 mai 2016 13:32
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>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
De :papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De la part de Christian Damus
Envoyé : mardi 24 mai 2016 21:33À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : Re: [papyrus-rt-dev] Feature freeze and git repo
Hi, Ernesto,
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.
HTH,
Christian
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.
On Tue, May 24, 2016 at 2:45 PM Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Hi, Ernesto,
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)?
Thanks,
Christian
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élineLe 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".
Sounds good?
On Wed, May 18, 2016 at 4:02 AM LETAVERNIER Camille <Camille.LETAVERNIER@xxxxxx> wrote:
Ø 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
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>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.
On Tue, May 17, 2016 at 4:20 AM LETAVERNIER Camille <Camille.LETAVERNIER@xxxxxx> wrote:
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
Hello everyone.
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?
--
Ernesto Posse
Zeligsoft
_______________________________________________
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 listpapyrus-rt-dev@xxxxxxxxxxxTo change your delivery options, retrieve your password, or unsubscribe from this list, visithttps://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_______________________________________________
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