fuel-dev team mailing list archive

[Mike Scherbakov <mscherbakov@xxxxxxxxxxxx>]

Folks, I went the following way - I thought is there anything missing in
OpenStack source code repositories management in terms of all branching and
etc., so I can add what is missing there.

And I found NO such gaps. The documents are pretty large, but I think they
have everything what we discussed here and in other places:
https://wiki.openstack.org/wiki/GerritJenkinsGit
https://wiki.openstack.org/wiki/StableBranch
https://wiki.openstack.org/wiki/StableBranchRelease

It applies to stackforge obviously, and we just need to replicate same
branching/merging-rebasing approach to github.com/mirantis/fuel.git. I just
want to underline a few important things:

   1. I suggest myself as a single approval point for all changes with
   branching, including:
      - code freeze announcements
      - creating of stable branches
      - removing of stable branches
      - tagging the releases
      - creation of new repositories or movement of code pieces between
      repositories
   2. Before applying any changes to branches / releases, it must be
   discussed with the team
   3. Let's not create other documentation for this such as
this<https://mirantis.jira.com/wiki/display/PRD/Developing+Fuel+Library>.
   If you think we really need some additional info / change, read those 3
   docs above twice. If you still think that change is required - let's follow
   up here  / in #fuel-dev / in #openstack-infra
   4. As of a current moment, I suggest following leads to keep watching
   master and propose required fixes to stable branches:
      - Dmitry Pyzhov - for fuel-main / nailgun / net-verify / dhcp / UI
      components
      - Tatyana Leontovich - for OSTF
      - Vladimir Kuklin - for Fuel Library


Let me know if all said above sounds reasonable to follow for the sake of
development processes quality and comfort, and any suggestions are very
welcome as always.

Regards,


On Sun, Nov 17, 2013 at 2:57 AM, Sergey Vasilenko
<svasilenko@xxxxxxxxxxxx>wrote:

> This sound as Neutron project workflow. We can try use it. why not?
>
>
> On Fri, Nov 15, 2013 at 6:49 PM, 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<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
>>
>> --
>> 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.
>>
>
>


-- 
Mike Scherbakov
#mihgen