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
