fuel-dev team mailing list archive

[Mike Scherbakov <mscherbakov@xxxxxxxxxxxx>]

We did. Bugs can be picked up by anyone to help.

Also, please take a look at bugs with Fuel Python Team or UI Team
assignees, it is simply a group - so you can also take a look there and
re-assign on yourself.

Regards,


On Mon, Dec 16, 2013 at 9:50 PM, Roman Alekseenkov <
ralekseenkov@xxxxxxxxxxxx> wrote:

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


-- 
Mike Scherbakov
#mihgen