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