fuel-dev team mailing list archive

[Andrew Woodward <awoodward@xxxxxxxxxxxx>]

I was thinking that it is still important to understand how we got where
that rebase was reasonable to consider so that we can learn from it and
avoid issues like this in the future.

I'd like to document the good and bad practices that I observed that got us
to this point (Please feel free to comment, correct, etc..)

1) We created a feature branch 'Havana'.
  a) GOOD. Feature branches, in which related changes are iterated through
is a normal development process. This alone is not an issue, when properly
kept re-based from master, it should be trivial to merge at nearly any time
  b) BAD the branch was long lived. At any point where the feature branch
is stable (ie it wont break what's already in the master) It should be
merged into the master. Sometimes this requires disabling function in the
feature if it might cause issues in the master. A good mark early in the
release schedule is weekly merges. Once a feature freeze occurs, changes
should only be fixes, and a feature branch is no longer necessary.
  c) BAD it wasn't rebased onto the master frequently. By the time we got
around to merging the feature branch there where so many conflicting
changes that it became very difficult to merge the branch into the master,
hence the rebase of master

2) Back-porting fixes
  a) GOOD. Back-porting fixes between master and release / stable is a
great way to fix issues in a previous release when related code is updated
as part of continued development.
  b) BAD, we back-ported code from a feature branch into master. This is
just wrong and probably the main reason we ended up with a bad commit
history. The assumption is that at some point the feature branch will be
merged into master, there is no reason to create conflicts by adding them
to both feature and master.
  c) BAD, we didn't have a release / stable branch to back-port commits
into for stable/3.2, this encouraged back-ports to be performed into master.
  d)NOTE If it's important to make a change before the feature can be
merged, the better practice is to commit into master, and keep the feature
rebased onto the master.


3) stable / release branches
  b) BAD we haven't been creating / using them.
  c) GOOD as discussed above, we will start using them.


~ Andrew



On Fri, Nov 15, 2013 at 10:59 AM, Andrew Woodward <awoodward@xxxxxxxxxxxx>wrote:

> This sounds good and will keep us in-line with other projects so that it
> is easier to for others to contribute.
>
> Andrew
>
>
> On Fri, Nov 15, 2013 at 10:33 AM, Dmitry Borodaenko <
> dborodaenko@xxxxxxxxxxxx> wrote:
>
>> +1
>> I think this approach can work, as long as we review the stable branch
>> on a regular basis to see if it's got any commits that didn't make it
>> into master.
>>
>> On Fri, Nov 15, 2013 at 6:49 AM, Mike Scherbakov
>> <mscherbakov@xxxxxxxxxxxx> wrote:
>> > As Vladimir & Dmitry P. assured me, merges performed are not that
>> painful as
>> > it could be. We agreed that such "push -f" MUST NEVER happen again.
>> > Hopefully, it is not even possible for the code on stackforge, but we
>> still
>> > have to care about Fuel Library (github.com/Mirantis/fuel.git).
>> >
>> > Simple rebase, or more complicated one should help for those who based
>> on
>> > commits which were modified by master rebase.
>> >
>> > Currently we have two main branches in all repos:
>> >
>> > master. This is for 4.0 release, and all development and bug fixes
>> should go
>> > here.
>> > 3.2-fixes. This is for 3.2.1 maintenance release, and all fixes which
>> go to
>> > master and considered as required for 3.2.1, must be submitted to this
>> > branch as well.
>> >
>> > For further development, there is the following suggestion (which we
>> tried
>> > to follow unless started to do crazy things. Now we just need to agreed
>> and
>> > create branching policy):
>> >
>> > Stay as much as possible compliant to OpenStack branching model
>> > Keep the work in master branch
>> > When code freeze is announced, create stable/<version> branch. This
>> branch
>> > should be used only for release fixes, no new features should be
>> accepted.
>> > master branch will be used for new features. Fixes proposed to
>> > stable/<version> branch, of course, should be pull requested into master
>> > too.
>> > When release comes out, we tag corresponding commits.
>> >
>> > Does this sound as a good approach? Any concerns / suggestions? For the
>> > current situation - is it Ok to proceed with suggested approach, or we
>> need
>> > to consider something else?
>> >
>> > Thanks,
>> >
>> >
>> > On Fri, Nov 15, 2013 at 3:16 AM, Dmitry Borodaenko
>> > <dborodaenko@xxxxxxxxxxxx> wrote:
>> >>
>> >> +10 on behalf of the US team!
>> >>
>> >> We have finished the mop-up, all missed commits are on pull request:
>> >> https://github.com/Mirantis/fuel/pull/848
>> >>
>> >> Cheers,
>> >> -Dmitry & Andrew
>> >>
>> >> On Thu, Nov 14, 2013 at 1:15 PM, Mike Scherbakov
>> >> <mscherbakov@xxxxxxxxxxxx> wrote:
>> >> > Colleagues,
>> >> > let's NEVER EVER do such a thing again.
>> >> >
>> >> > Let me know who and what is affected as a result of this push, and
>> what
>> >> > we
>> >> > can do now. Team, what's your opinion, should we keep going,
>> carefully
>> >> > reviewing every merge, or simply push -f of what was in master
>> before?
>> >> >
>> >> > Please, NO branch changes and any "push -f" since now without my
>> >> > approval.
>> >> >
>> >> > Thank you,
>> >> >
>> >> > On Nov 14, 2013 8:34 PM, "Dmitry Borodaenko" <
>> dborodaenko@xxxxxxxxxxxx>
>> >> > wrote:
>> >> >>
>> >> >> Vladimir,
>> >> >>
>> >> >> Please give people a warning next time you go for nuclear options
>> like
>> >> >> rebasing the master branch. If we knew you're not going to merge
>> >> >> havana back into master, we could have tried to help.
>> >> >>
>> >> >> Andrew Woodward has looked at havana branch on Tuesday and it looked
>> >> >> like the only major issue with merging it was the rename of quantum
>> to
>> >> >> neutron, which had file renames and changes in the same commit
>> >> >> throwing git off the track. We had discussed how this could be
>> >> >> addressed by splitting havana branch in half and carefully rebasing
>> >> >> pre-rename and post-rename changes. We didn't get around to trying
>> >> >> this approach yesterday because we were assuming you and Sergey V.
>> are
>> >> >> already working on something similar, and now that havana is the new
>> >> >> master it's too late to rebase any of its commits.
>> >> >>
>> >> >> Instead, now we need to review every single commit in 3.2-fixes and
>> >> >> cherry-pick everything that is missing from the new master. It is
>> >> >> tedious work, but still doable and necessary. I plan doing this
>> today
>> >> >> with Andrew's help, please let me know if someone else has already
>> >> >> started working on this so that we don't duplicate our efforts.
>> >> >>
>> >> >> Thanks,
>> >> >>
>> >> >> On Thu, Nov 14, 2013 at 5:43 AM, Vladimir Kuklin <
>> vkuklin@xxxxxxxxxxxx>
>> >> >> wrote:
>> >> >> > And, please, be careful, because master branch was updated with
>> >> >> > havana
>> >> >> > by
>> >> >> > use of `push -f` due to lots of merge conflicts.
>> >> >> >
>> >> >> >
>> >> >> > On Thu, Nov 14, 2013 at 5:26 PM, Vladimir Kuklin
>> >> >> > <vkuklin@xxxxxxxxxxxx>
>> >> >> > wrote:
>> >> >> >>
>> >> >> >> Team
>> >> >> >>
>> >> >> >> We now have 3.2.1 pointing to 3.2-fixes and master pointing to
>> >> >> >> havana
>> >> >> >> code. We need to update corresponding CI jobs to make them
>> >> >> >> consistent.
>> >> >> >> If
>> >> >> >> you have code you wanted to go to 3.2.1 - rebase and request it
>> to
>> >> >> >> 3.2-fixes. If your code is compliant for both branches - rebase
>> and
>> >> >> >> request
>> >> >> >> to both of them.
>> >> >> >>
>> >> >> >> --
>> >> >> >> Yours Faithfully,
>> >> >> >> Vladimir Kuklin,
>> >> >> >> Senior Deployment Engineer,
>> >> >> >> Mirantis, Inc.
>> >> >> >> +7 (495) 640-49-04
>> >> >> >> +7 (926) 702-39-68
>> >> >> >> Skype kuklinvv
>> >> >> >> 45bk3, Vorontsovskaya Str.
>> >> >> >> Moscow, Russia,
>> >> >> >> www.mirantis.com
>> >> >> >> www.mirantis.ru
>> >> >> >> vkuklin@xxxxxxxxxxxx
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Yours Faithfully,
>> >> >> > Vladimir Kuklin,
>> >> >> > Senior Deployment Engineer,
>> >> >> > Mirantis, Inc.
>> >> >> > +7 (495) 640-49-04
>> >> >> > +7 (926) 702-39-68
>> >> >> > Skype kuklinvv
>> >> >> > 45bk3, Vorontsovskaya Str.
>> >> >> > Moscow, Russia,
>> >> >> > www.mirantis.com
>> >> >> > www.mirantis.ru
>> >> >> > vkuklin@xxxxxxxxxxxx
>> >> >> >
>> >> >> > --
>> >> >> > You received this message because you are subscribed to the Google
>> >> >> > Groups
>> >> >> > "fuel-core-team" group.
>> >> >> > To unsubscribe from this group and stop receiving emails from it,
>> >> >> > send
>> >> >> > an
>> >> >> > email to fuel-core-team+unsubscribe@xxxxxxxxxxxx.
>> >> >> > For more options, visit
>> >> >> > https://groups.google.com/a/mirantis.com/groups/opt_out.
>> >> >>
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Dmitry Borodaenko
>> >> >>
>> >> >> --
>> >> >> You received this message because you are subscribed to the Google
>> >> >> Groups
>> >> >> "fuel-core-team" group.
>> >> >> To unsubscribe from this group and stop receiving emails from it,
>> send
>> >> >> an
>> >> >> email to fuel-core-team+unsubscribe@xxxxxxxxxxxx.
>> >> >> For more options, visit
>> >> >> https://groups.google.com/a/mirantis.com/groups/opt_out.
>> >>
>> >>
>> >>
>> >> --
>> >> Dmitry Borodaenko
>> >
>> >
>> >
>> >
>> > --
>> > Mike Scherbakov
>>
>>
>>
>> --
>> Dmitry Borodaenko
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "fuel-core-team" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to fuel-core-team+unsubscribe@xxxxxxxxxxxx.
>> For more options, visit
>> https://groups.google.com/a/mirantis.com/groups/opt_out.
>>
>
>