Of course I mean program-release and program-milestone.

> 24 січ. 2015 о 02:37 Roman Prykhodchenko <m...@romcheg.me> написав(ла):
> 
> Aleksandra,
> 
> 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 <afedor...@mirantis.com> 
>> написав(ла):
>> 
>> 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 <m...@romcheg.me> 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: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> 
>> 
>> 
>> 
>> -- 
>> Aleksandra Fedorova
>> Fuel Devops Engineer
>> bookwar
>> 
>> __________________________________________________________________________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to