[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [p2-dev] Master v. Integration
|
Thanks for all the help David.
Sorry for the confusion about maintenance. When I said 'maintenance' it was directed and both 'Kepler' branch (master). While I'm hesitant to say that p2 is solely in maintenance mode, the current form of working is completely re-active. That is, a bug comes in, someone contributes a fix, it's 'blindly' merged with integration, and it's built. Some are released to Juno SR_X as well.
In this case, the 'blindly merge' doesn't seem to provide much help.
Having said that, one advantage of the merging is that it does bring a second pair of eyes to each contribution. While I don't claim to review each contribution in full, it does give some awareness of what's happening in the code base. I'll bring this up tomorrow on the RT PMC call to get some feedback from others.
Thanks again.
Cheers,
Ian
On Tue, Sep 4, 2012 at 8:22 PM, David M Williams
<david_williams@xxxxxxxxxx> wrote:
There is a file in the maps project (under tagging directory)
called repositories.txt.
Your entry for R3_8_maintenance and R4_2_maintenance
says
git://git.eclipse.org/gitroot/equinox/rt.equinox.p2.git
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
integration
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
branches.
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].
HTH
From:
Pascal Rapicault <pascal@xxxxxxxxxxxxx>
To:
P2 developer discussions
<p2-dev@xxxxxxxxxxx>,
Date:
09/04/2012 09:13 PM
Subject:
Re: [p2-dev]
Master v. Integration
Sent by:
p2-dev-bounces@xxxxxxxxxxx
Thanks for the details David.
How do we tell the build which branch to use as build
input?
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).
HTH
From: Pascal
Rapicault <pascal@xxxxxxxxxxxxx>
To: P2
developer discussions <p2-dev@xxxxxxxxxxx>,
Date: 09/04/2012
08:32 PM
Subject: Re:
[p2-dev] Master v. Integration
Sent by: p2-dev-bounces@xxxxxxxxxxx
I'm all for reducing the overhead. However was not that added to satisfy
the requirements of automated tagging?
Pascal
On 2012-09-04, at 4:50 PM, Ian Bull wrote:
Hi everyone,
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?
Cheers,
Ian
--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com
| http://twitter.com/eclipsesource
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
_______________________________________________
p2-dev mailing list
p2-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/p2-dev
--
R. Ian Bull | EclipseSource Victoria | +1 250 477 7484
http://eclipsesource.com |
http://twitter.com/eclipsesource