a general practice is to have program-core and program-milestone groups. That 
approach fits for fuel-* as well because there’s only one separate team that 
does releases for all projects.
What other folks think about that?

- romcheg

> 23 січ. 2015 о 18:36 Aleksandra Fedorova <> написав(ла):
> How should we deal with release management?
> Currently I don't do any merges for stackforge/fuel-* projects but I
> need access to all of them to create branches at Hard Code Freeze.
> Should we create separate fuel-release group for that? Should it be
> unified group for all repositories or every repository needs its own?
> On Fri, Jan 23, 2015 at 7:04 PM, Roman Prykhodchenko <> wrote:
>> Hi folks!
>> After moving python-fuelclient to its own repo some of you started asking a 
>> good question which is How do we manage core rights in different Fuel 
>> repositories. The problem is that there is a single fuel-core group which is 
>> used for all fuel-* repos, except for python-fuelclient.
>> The approach mentioned above does not work very well at the moment and so 
>> I’d like to propose a different one:
>> - Every new or separated project shoud introduce it’s own -core group.
>> -  That group vill only contain active core reviewers for only that project.
>> -  Removing or adding people will be done according to Approved OpenStack 
>> rules.
>> - fuel-core group will be reduced to the smallest possible number of people 
>> and only include the guys
>> who must have decision making powers according to Fuel project’s rules.
>> - fuel-core will be included to any other fuel-*core group
>> - elections to the fuel-core group will take place according to Fuel’s 
>> policies
>> - fuel-core group members are required for supervising reasons and taking an 
>> action in emergency cases
>> - romcheg
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
> -- 
> Aleksandra Fedorova
> Fuel Devops Engineer
> bookwar
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:

OpenStack Development Mailing List (not for usage questions)

Reply via email to