On Fri, Feb 3, 2012 at 9:54 AM, Brian de Alwis <[email protected]>wrote:
> Can we turn this off around milestone builds? > > I guess in my ideal world, we would always keep master open. Once we > start into an M period, any necessary bug fixes should be committed to the > integration branch first and then merged back into master. > > That would be a different process than we have now. Our integration branch is really a pointer onto the master branch that tells auto-tagging where to start. My proposal is just that we remove the manual step where we update integration to the new location on master. We deliberately chose not to generate any kind of merge commits for the integration branch and to keep integration as FF merges from master so as to avoid polluting our branch with a lot of little "diamonds". That, plus the potential to confuse some other git tooling, like git bisect or git blame. We can discuss some other process around milestone time (like creating a milestone6 branch and only building that), either in another thread or in a bug. But I would have concerns 1) we should be focused on testing the milestone and getting that out the door, 2) I don't want them have merge commits from the final fixes in milestone6 vs master that we start binding the next week, and 3) it seems like people could push stuff to their own topic branches, and then merge them into master when it re-opens after the milestone is declared, and 4) we disable nightly builds in favour of integration builds until the milestone is out the door, so the value of master is just a holding place (admittedly pre-merged). Later, PW -- Paul Webster Hi floor. Make me a sammich! - GIR
_______________________________________________ e4-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/e4-dev
