fuel-dev team mailing list archive

[Andrew Woodward <awoodward@xxxxxxxxxxxx>]

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.
>