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]> To: P2 developer discussions <[email protected]>, Date: 09/04/2012 08:32 PM Subject: Re: [p2-dev] Master v. Integration Sent by: [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://twitter.com/eclipsesource _______________________________________________ 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 _______________________________________________ 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
_______________________________________________ p2-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/p2-dev
