Why can't we include Alexandra to fuel-core group then, which will have +2 in every repo? Instead of (yet unclear to me) program-release & program-milestone groups.
No objections for introducing additional per-repo core teams, my +1 on that part. > I’ve seen a few +1s in this thread and no -1s so according to lazy consensus the decision is made positive. I don't think we waited long enough. I'm not sure if we have defined policy somewhere in OpenStack wiki, but at least [1] states about 5 days. [1] https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess On Mon, Jan 26, 2015 at 1:19 PM, Roman Prykhodchenko <m...@romcheg.me> wrote: > Hi fellows, > > I’ve seen a few +1s in this thread and no -1s so according to lazy > consensus the decision is made positive. > > Basing on that I will propose the initial core group members for > python-fuelclient in a separate thread by picking python-devs from the > original fuel-core group. > > > - romcheg > > > 24 січ. 2015 о 21:39 Roman Prykhodchenko <m...@romcheg.me> написав(ла): > > > > 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 > > > __________________________________________________________________________ > 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 > > -- Mike Scherbakov #mihgen
__________________________________________________________________________ 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