[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