Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [papyrus-rt-dev] Branch for post 0.8 commits
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.

https://git.eclipse.org/r/#/q/status:open+(p:papyrus-rt/org.eclipse.papyrus-rt+OR+p:www.eclipse.org/papyrus-rt)

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 commits

I 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:

Hello everyone.

Young-Soo and I are already working on some port-0.8 bugs and Simon wants to have a branch for this. So we want to create a branch but we are not sure what to call it. Checking the Papyrus conventions, it looks like branch naming follows one of these forms:

bugs/<number>
committers/<name>/<topic>
streams/<major.minor>-maintenance

Are there any other forms?

So I was wondering if we should create

streams/0.9-maintenance

although the name sounds misleading. My understanding is that the 'maintenance' branches are for commits after the release. Is that right?

How about something like

streams/0.9-prerelease

or something like that? The idea is that the "prerelease" branch would be rebased onto master once 0.8 is released. 

And if there are objections to that, maybe we do one just for us (Zeligsoft), perhaps 

committers/zeligsoft/0.9

?

Thoughts?

--
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 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


Back to the top