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 <[email protected]>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 <[email protected]> > To: P2 developer discussions <[email protected]>, > Date: 09/04/2012 09:13 PM > Subject: Re: [p2-dev] Master v. Integration > Sent by: [email protected] > ------------------------------ > > > > 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 <*[email protected]*<[email protected]> > > > To: P2 developer discussions > <*[email protected]*<[email protected]>>, > > Date: 09/04/2012 08:32 PM > Subject: Re: [p2-dev] Master v. Integration > Sent by: *[email protected]* <[email protected]> > ------------------------------ > > > > 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://eclipsesource.com/> | * > http://twitter.com/eclipsesource* <http://twitter.com/eclipsesource> > _______________________________________________ > p2-dev mailing list* > **[email protected]* <[email protected]>* > **https://dev.eclipse.org/mailman/listinfo/p2-dev*<https://dev.eclipse.org/mailman/listinfo/p2-dev> > _______________________________________________ > p2-dev mailing list* > **[email protected]* <[email protected]>* > **https://dev.eclipse.org/mailman/listinfo/p2-dev*<https://dev.eclipse.org/mailman/listinfo/p2-dev> > > _______________________________________________ > p2-dev mailing list* > **[email protected]* <[email protected]> > https://dev.eclipse.org/mailman/listinfo/p2-dev > _______________________________________________ > p2-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/p2-dev > > > _______________________________________________ > p2-dev mailing list > [email protected] > https://dev.eclipse.org/mailman/listinfo/p2-dev > > -- R. Ian Bull | EclipseSource Victoria | +1 250 477 7484 http://eclipsesource.com | http://twitter.com/eclipsesource
_______________________________________________ p2-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/p2-dev
