fuel-dev team mailing list archive

[Mike Scherbakov <mscherbakov@xxxxxxxxxxxx>]

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<http://stackoverflow.com/questions/4084868/how-do-i-recover-resynchronise-after-someone-pushes-a-rebase-or-a-reset-to-a-pub>
should
help for those who based on commits which were modified by master rebase.

Currently we have two main branches in all repos:

   1. master. This is for 4.0 release, and all development and bug fixes
   should go here.
   2. 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):

   1. Stay as much as possible compliant to OpenStack branching model
   2. Keep the work in *master *branch
   3. 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.
   4. 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