fuel-dev team mailing list archive

[Roman Alekseenkov <ralekseenkov@xxxxxxxxxxxx>]

Team,

Thank you for the call. Let's keep doing this.

Mike,

As discussed, please unset assignee for the bugs your team is not actively
working on. So they can be picked up by the US engineering team.

Thanks,
Roman

On Monday, December 16, 2013, Mike Scherbakov wrote:

> Dmitry,
> thank you for bringing this up in a constructive manner with proposed
> changes. With the additional stuff, discussed on the call - let me provide
> our agreements.
>
> Before going into every point, we agreed that we are following OpenStack
> development model and would like to stick with it as far as we can, and
> reuse all the existing tools, such as OpenStack Infra, Gerrit,
> github.com/stackforge, launchpad. The closer we are with OpenStack flows,
> the easier life for both newcomers into Fuel from OpenStack community and
> Fuel developers.
>
> *1. Branch management for maintenance releases*
>
>    - We had 3.2-fixes branch created, it worked good unless minor issues
>    with a few forgotten commits which were not proposed to master at the same
>    time as they were proposed to master.
>    - We will create stable/4.0 branch right before the code freeze
>    announcement, which will include all required links / information
>    - git whatchanged can not be used to compare branches: it sees merges
>    as another commits. Current situation is all required fixes were proposed
>    and merged to master from 3.2-fixes - verified by Dmitry Pyzhov (fuel-main,
>    fuel-astute), Vladimir Kuklin (fuel-library) and Tatyana Leontovich
>    (fuel-ostf)
>    - I fully agree that core reviewers must not accept code into stable
>    branch unless it is merged into master or patchset has a description why it
>    should be only in stable branch. In the long run, we need to see if it is
>    possible to configure Jenkins to automatically "-1" such requests to stable
>    branches.
>    - Let's keep following existing workflows as far as we can go with
>    them:
>    https://wiki.openstack.org/wiki/StableBranch
>    https://wiki.openstack.org/wiki/GerritJenkinsGit
>
> *2. Management and code review of feature development branches*
>
>    - > reject changes that are too large and/or contain messy revision
>    history - all agree on this. All core reviewers - please keep an attention.
>    - Code is unreviewed for a long time
>    As we moved away from Kanban board - it is harder and harder for leads
>    to keep an eye on every patchset. Instead, as we agreed - let's evangelize
>    to follow another approach - as a developer, my work is not complete unless
>    my code is merged into master and bug / blueprint is closed. So, team
>    lead's job here is to control if developers push hard enough to make their
>    code reviewed and merged. Dear Team Leads, please take a careful look at
>    those patchsets which are not updated for more than a few days - and ping
>    developers. Dear Developers, please don't wait to be pinged or punished,
>    don't leave your code for abandonment :)
>    - > when going through reviews, start with fixes for critical bugs -
>    With you here, my ++
>    - > Don't merge a review request if there's an older review request
>    that can also be merged - With you here too, ++
>
>
> *3. Bugs triage*
> My suggestion is simply to follow:
> https://wiki.openstack.org/wiki/Bugs and
> https://wiki.openstack.org/wiki/BugTriage.
>  I have to admit though that some additional notes are required to make it
> easy to set appropriate status, and may be for triaging as well. For
> example, if one OSTF test fails because of test itself - it should never be
> Critical, but if whole OSTF doesn't work - I believe it should. As we use
> OSTF for OpenStack deployment verification, including system tests, we can
> easily miss the point when we break something else.
> Please do not hesitate to propose additions to the links above specific
> for Fuel only.
>
>
> Some other questions raised:
> *WIP branches *should* be maintainable despite on anything*
> I believe we should not have such branches despite on anything :) Let's
> discuss every situation when it is needed, and see if there is anything we
> can do.
> I do not want to see such branches, as it will be always hard to merge and
> review later. So, if possible, it should be split on several pieces which
> could be merged independently, even if many parts are stubbed / not even
> enabled (with corresponding comments of course).
>
> *Core reviewers*
> As we agreed on the core reviewers/management meeting - Dmitry Borodaenko
> is added to the team of core reviewers. Congrats! :)
>
> Bogdan D. - on your question about branches creation, please talk to
> Dmitry Pyzhov.
>
> Thanks!
>
>
> On Wed, Dec 11, 2013 at 5:55 PM, Bogdan Dobrelya <bdobrelia@xxxxxxxxxxxx>wrote:
>
>  On 12/11/2013 03:42 PM, Vladimir Kuklin wrote:
>
> or git review <branch_name> if you are requesting change to another branch
> than master
>
>  Yes, I already have a forks for most of main fuel repos, I use them for
> storing my WIP branches, because I cannot create any branches at main repo,
> and
> *that* was the 1st subject of discussion for long running R & D activities.
> And the 2nd subject was addressed to "long-lived feature branches with
> many commits and thousands of lines"
>
> (Yet another thing that everyone seems to agree on is that huge
>
> long-lived feature branches with many commits and thousands of lines
> worth of changes are evil and dangerous. Luckily, the move to Gerrit
> will make it hard enough to maintain and merge multi-commit branches,
> and will push people towards committing and merging changes in smaller
> self-sufficient chunks.)
>
> So, I was initially asking to elaborate, what if such WIP branches
> *should* be maintainable despite on anything, and how (what is the best
> practice for now?)
>
>
>
>
> On Wed, Dec 11, 2013 at 5:37 PM, Miroslav Anashkin <manashkin@xxxxxxxxxxxx
> > wrote:
>
> And do not use push, use `git review` without parameters
>
>
> On Wed, Dec 11, 2013 at 5:36 PM, Miroslav Anashkin <manashkin@xxxxxxxxxxxx
> > wrote:
>
> Please fork stackforge repo to your account first and use the forked
> version
>
>
> On Wed, Dec 11, 2013 at 4:57 PM, Bogdan Dobrelya <bdobrelia@xxxxxxxxxxxx>wrote:
>
>  On 12/11/2013 01:35 PM, Oleg Gelbukh wrote:
>
> Looks like fuel.config already have this configuration actually:
>
>
> https://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/gerrit/acls/stackforge/fuel.config#n5
>
>  Did you check if you actually can create a branch?
>
>  Yes,
>
> Mike Scherbakov
> #mihgen
>