There is a file in the maps project (under tagging directory)
Your entry for R3_8_maintenance and R4_2_maintenance
R3_8_maintenance (i.e. one maintenance branch, for both, with makes
sense for most teams)
Your entry for Kepler (master branch of the the maps
project or org.eclipse.releng to be exact) is git://git.eclipse.org/gitroot/equinox/rt.equinox.p2.git
That's the line to change to "master", if
that's what you decide to do. I mention all this about maintenance vs Kepler since
originally Ian said, "...However, for maintenance,
it doesn't really make sense..." So my round-about point is even if you go with "master"
for Kepler, you'll still have a maintenance branch to keep accurate (cherry
picking from one to other, or merging, or whatever).
I know of one team that literally used only "master"
for Juno maintenance and Kepler, until recently, since all they were doing
was literally maintenance, but as SR1 winds down, they too now have two
So, I hope P2's "maintenance" has been going
to R3_8_maintenance, as well as master/integration! :) [If it was supposed
to be for Juno SR1, that is].
Pascal Rapicault <pascal@xxxxxxxxxxxxx>
P2 developer discussions
09/04/2012 09:13 PM
Master v. Integration
Thanks for the details David.
How do we tell the build which branch to use as build
On 2012-09-04, at 9:05 PM, David M Williams wrote:
No, we have several "autotaggers"
that use master only, directly.
The only warning is you need to be careful as you approach milestones,
releases, what ever, and not push something to master thinking "it
won't effect current build", since it will. In other words, you need
to break old habits.
Jumping ahead, the general recommendation (I've heard) is to remove the
integration branch if no longer used, to help avoid confusion. (Since
its only purpose was to mark what to include in current build, it doesn't
contain meaningful tags or history ... is my understanding). [You'd
have to open a releng bug and get some help with deleting this branch,
since we normally don't allow deletion of branches, except <commit_id>/featurebranch
An alternative, to master-integration distinction is to always do "prep
work" in feature branch, such as <committer_id>/bugxOrfeatureY,
you can push that to repo, have others review, write code to it (in their
own commit_id/ branch), do tests, etc., and once all set to merge what
should be merged merge that into master. (and, then, yes, can delete <committer_id>/
branches when no longer needed or useful, without releng help).
I'm all for reducing the overhead. However was not that added to satisfy
the requirements of automated tagging?
On 2012-09-04, at 4:50 PM, Ian Bull wrote:
Due to the long weekend I forgot to merge master into integration this
week. This isn't very serious (since we are early in the development
cycle), but it means we need to wait another week to test changes, etc...
I'm wondering if we still need both branches for p2? Having two branches
makes sense during active development, where things may get committed that
shouldn't be included in a weekly integration build. However, for maintenance,
it doesn't really make sense -- especially when you consider we typically
just merge everything each week anyways.
What do you think about building p2 from master each week?