| Re: [papyrus-rt-dev] Branch for post 0.8 commits |
Hi,
I do agree with Peter. It is very painful to reduce the number of gerrits once the history is too long, as you have to understand back why this gerrit was done, how it can be integrated, etc. Patrick on Papyrus side is having hard time to understand each gerrit, and adapt it to newer versions.
Fortunately, Papyrus-RT is a much smaller project, but it is better to get a good setup in place before getting out of Incubation and/or growing.
Regards,
Rémi
-------------------------------------------------------
Rémi SCHNEKENBURGER
CEA Saclay Nano-INNOV
Institut CARNOT CEA LIST
De : papyrus-rt-dev-bounces@xxxxxxxxxxx [mailto:papyrus-rt-dev-bounces@xxxxxxxxxxx] De la part de Peter Cigéhn
Envoyé : jeudi 20 octobre 2016 10:20
À : papyrus-rt developer discussions <papyrus-rt-dev@xxxxxxxxxxx>
Objet : Re: [papyrus-rt-dev] Branch for post 0.8 commits_______________________________________________
Hi,
But if they are not considered "to be merged", then I guess they simply should be abandoned? Right?
Keep in mind also that even if a Gerrit change is abandoned, you can still access it and get it back.
I really think that we should use Gerrit in "the right way", and only have Gerrit changes open for changes that we actually intend to merge to the related branch. Otherwise we "misuse" Gerrit and we cannot (efficiently) use queries like the one I provided to try to followup the status of incoming changes.
I do know that the Papyrus project have started to cleanup and either abandon or try to merge some very old proposed Gerrit changes that has gotten "stuck" for long. I guess we should try to avoid the same thing happening for Papyrus-RT...
/Peter Cigéhn
On 19 October 2016 at 20:03, Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:
Good to know for future reference.
But I still have a bunch of gerrits under refs/for/master, which should not be considered as "to be merged".
On Wed, Oct 19, 2016 at 2:01 PM Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Yep. A "drafts" segment instead of "for". So thoroughly gittish. 😉
cW
On October 19, 2016 at 13:59:37, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:
And to use gerrit drafts you just push to refs/drafts/<branch>?
On Wed, Oct 19, 2016 at 1:52 PM Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Hi, Ernesto,
I have often used gerrit drafts to post work in the convenient remote storage offered by the Gerrit server, which aren’t yet ready for review. Drafts are nice because they don’t trigger builds, they can’t be merged, and most people can’t even see them. A draft can be published as a review once it is ready for that.
HTH,
Christian
On 19 October, 2016 at 12:40:30, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:
Regarding moving Bugzillas to RESOLVED, it's a good point, but Bugzillas also have other states: VERIFIED and CLOSED, and I do think that the bug should be assigned one of these once it has been merged onto master, but perhaps we could have some flexibility with RESOLVED. To me, and that's my personal interpretation, that state means that the solution to the bug has been implemented, it does not necessarily mean that it is integrated into the rest (i.e. merged onto master). But if we are to have a particular policy about this, one way or the other, it should be explicitly stated, perhaps in Guidelines for the lifecycle of Papyrus-RT bugs.
As for the status of Gerrits, I would take those with a grain of salt, as I have had to use (or perhaps abuse) Gerrit a bit to store temporary and experimental commits. The reason is that in the past, I had to reinstall the developer environment from scratch many, many, many times over, including a complete wipe out of my local git repos (for many reasons, including tests of the Oomph dev setup model, and times where my environment got corrupted), and the simplest way to save such experimental work was to push it to Gerrit. But several of my own outstanding gerrits may no longer be relevant. I'll have to clean them up, and abandon a few. Furthermore, there is also a number of gerrits, not only my own, which are "false starts", for a lack of a better term. The point is that a simple Gerrit query might not give you an accurate impression of what is work that is intended to be merged.
On Wed, Oct 19, 2016 at 12:07 PM Peter Cigéhn <peter.cigehn@xxxxxxxxx> wrote:
Hi,
In general I feel that we need to track the outstanding Gerrit changes in the same way as we track outstanding Bugzillas. I myself have a query setup for Gerrit to list all outstanding Gerrit changes for both Papyrus-RT repos. In general, we have quite a few Gerrit changes that has gotten stuck there...
So this about the "psychological aspect", I think that it would be good in general if we also tried to followup what is happening with Gerrit changes, and not only Bugzillas. If we had such focus on Gerrit as well, then I would not be bothered about loosing track if it is ready or not. For me, Gerrit is an equally important tool for keeping track of what is ready or not.
Regarding moving Bugzillas to RESOLVED, my personal opinion is that this should not be done until they have been merged to master anyway, so resolving Bugzillas that ends up on some topic branch does not feel right either. Then I feel it is better to track Gerrit changes.
Just my personal opinions regarding this... :)
/Peter Cigéhn
On 19 October 2016 at 17:59, Ernesto Posse <eposse@xxxxxxxxxxxxx> wrote:
Right, that is a possibility indeed. I think there is a small difference though: if you actually merge a commit on a branch, you see that reflected in the corresponding bugzilla, and then the bug could be moved to RESOLVED. Maybe it's just psychological, but if a gerrit has not been merged, you can easily loose track of whether it is ready or not.
Anyway, I did create
committers/ysroh/0.9
As a side note, I see a lot of old and disused branches in Gerrit which didn't follow the conventions, including things like "test-01". Perhaps we could do some clean-up there, but I don't seem to have any privileges to either rename or delete these branches.
On Wed, Oct 19, 2016 at 11:49 AM SCHNEKENBURGER Remi 211865 <Remi.SCHNEKENBURGER@xxxxxx> wrote:
Hi,
If it is supposed to live only one week, why not working with Gerrit? The build will be triggered automatically.
Regards
Remi
De : Ernesto Posse
Envoyé : 19/10/2016 17:43
À : Christian Damus; papyrus-rt developer discussions
Objet : Re: [papyrus-rt-dev] Branch for post 0.8 commitsI don't see which job builds that. Did you already delete it?
So for best practices, is that what would be expected? to create a short-lived job?
Or perhaps, if this is only for a week, perhaps we could just have the branch without triggering a job and then when merging or rebasing it into master we could see the effect on the build.
Which is preferable?
On Wed, Oct 19, 2016 at 11:34 AM Christian Damus <give.a.damus@xxxxxxxxx> wrote:
No, they won’t trigger builds in Hudson, unless you create a job for your branch, as I did with for bugs/506005 branch. 😀
cW
On 19 October, 2016 at 11:32:05, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:
Ok, and are there any objections to call a branch committers/<committer-id> without a /<topic>?
Also, commits on such branches will not trigger any Hudson job will they?
On Wed, Oct 19, 2016 at 11:28 AM Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Hi, Ernesto,
There’s nothing preventing Young-Soo or any other committer (or non-committer, using Gerrit) from contributing to a branch named committers/eposse/<whatever>. But I don’t feel very strongly about the names of committer topic branches. It’s just that the committer ID does have meaning to the git server, so you might be limited in what you could do with committers/zeligsoft.
I would like to keep the streams/* restricted to only actual release streams, though.
cW
On 19 October, 2016 at 11:23:05, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:
Hi Christian.
I do agree that committers/zeligsoft looks odd, but the issue is that we would like to merge our work (Young-Soo's and mine), rather than have individual branches waiting for a while. Furthermore, it's more than just one bug, and we don't want to pollute the repo by creating several branches. That's why I proposed those alternatives. Basically the idea is to try to consolidate work done during the pre-0.8 release "freeze" period, where we shouldn't merge any non 0.8 commits onto master. And how about the other alternative: streams/0.9-prerelease?
Thanks
On Wed, Oct 19, 2016 at 11:14 AM Christian Damus <give.a.damus@xxxxxxxxx> wrote:
Hi, Ernesto,
You are correct that streams/0.9-maintenance would be for development of 0.9.x service releases after 0.9.
If it’s just a small-ish bug that you’re working on, I’d recommend the Papyrus convention of bugs/<number>, which I think many Eclipse projects use. Otherwise, if it’s a topic branch, the best is committers/<name>/<topic>. That’s also a Papyrus convention and in general use in other Eclipse projects.
Zeligsoft isn’t a committer, so that would look a bit odd. I seem to recall that the Eclipse Git server has permission rules that recognize the “committers/<committer-id>” pattern and let the matching committer do whatever (s)he likes in there, including non-fast-forward pushes and other destructive actions.
We try to use only these three branching naming patterns in the Papyrus project; there are historical deviations from before we agreed on these.
HTH,
Christian
On 19 October, 2016 at 11:08:42, Ernesto Posse (eposse@xxxxxxxxxxxxx) wrote:
_______________________________________________
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
