Re: [openstack-dev] The Evolution of core developer to maintainer?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/02/2015 02:26 PM, Joe Gordon wrote: So, let me take a step back here. I would like to see at least 2 to 3x more people in a given project to feel empowered and have badges, and make it possible for part time upstream developers to hold some of said badges. It sounds like you more or less agree with that goal. So how do you propose we get there? Because having 15 core reviewers for all of nova is just not cutting it. My $.02 on this: http://blog.leafe.com/the-core-deficiency/ - -- - -- Ed Leafe -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJVJCG3AAoJEKMgtcocwZqLPfEQAJT2Xp1qDpPrhaL5ZM1QvyHP 1iGwTnt10ATH9vFWRmAAYucR3QGF8E0RQyFi2V5W/poRJpiuY+UiTaoqzOq3bXjQ 0IjSFo6AKN8z5igMog0Hp82dvuJe8C1VfxO2GP76MJjqdHT7CvXEmAdHzknRVmcB soWAMJ2W/V8Fn0niXzfHf/jN+LksxmNPzFm5YIaZbexsKw0zhYz3Y32LbX1Shffm 4FO/uTmLZqw5uvMlHZYb9RC5Hhe6AJ+53UxY4CUXnAAt2cWZYFTJuogw6hx3LBXQ Tc7NUUHrI1xLEyx5ZnLFesnuBnkbc4ER08OPgOIqcecy4UqGnVQfNmYvFNePjpq3 GD/T7bP3HYjZ3E4BsfrfIQDO2IjpC3yfSTWmTF9FJiVwhy8EFQd/w3kRztGpafPO 7y2K7irdk5AB0nsL0tM1nvTTBk0lYqXsgyvSWopaZCk/0LwxeUETOmKXeFPA6hgS r+/U2jJDCr2WjRbwbvPhuFWKVwf391LUnz3qrVhlUq3xQEY0N/+IBGb+7n0sc6hu V76S6jHmxkF7XWPXGP2E8BClvpCEjMToLEULLDYr5Xilvx2iqLyugEmDE9o3uBLi GSQcxsw70nhDheRldNEeJDxEv1ABvn7Kxn5UFX8RYNLVAdMaSBLlinHqBtOJ5T2E O5SroR+ltyB2f1n0UEGJ =ELkQ -END PGP SIGNATURE- __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
Joe Gordon wrote: On Thu, Apr 2, 2015 at 3:14 AM, Thierry Carrez thie...@openstack.org mailto:thie...@openstack.org wrote: Joe Gordon wrote: I cannot speak for all projects, but at least in Nova you have to be a nova-core to be part of nova-drivers. And would you describe that as a good thing ? If John Garbutt is so deep into release liaison work that he can't sustain a review rate suitable to remain a core reviewer, would you have him removed from the maintainers group ? If someone steps up and works full-time on triaging bugs in Nova (and can't commit to do enough reviews as a result), would you exclude that person from your maintainers group ? I want to empower that person and recognize them in some semi formal capacity and make sure they have all the correct permissions. I do not want a single flat 'maintainers' group, I think we need a hierarchical notion of maintainers, where different people can end up with very different responsibilities (and ACLs -- but that is a implementation detail). OK, so I probably misread your proposal[1]. My understanding was you wanted a single flat maintainers group that would purely replace core reviewers, keep the same rights and just add duties to the already-existing reviewing duties. [1] https://review.openstack.org/#/c/163660/ Since I thought project leadership needs to be expressed in a much more diverse and inclusive way (and explicitly not tied to +2 rights), I opposed such simple renaming. From what you're saying now your objective is the same as mine. I'm not sure the maintainers group needs to be purely hierarchical (I think I'd prefer it to be a set of duties with no hierarchy between them), but I agree that: - today core reviewers are the only visible project duty, and we need to expose and reward all the others, as separate attributes - we could use a blanket term (maintainers ?) to describe the people holding one or more of those attributes. OpenStack governance mandates that core developers are ultimately the PTL's choice. Since the PTL is regularly elected by all contributors, that prevents aristocracy. Can you site your source for this? Because the earliest reference to 'Core Developer' (what you are calling core reviewer -- even though that is not the original name) that I could find says nothing about it ultimately being the PTLs choice. PTLs have (and always had) ultimate say over their project matters. That includes how to select core reviewers (or how reviews should be performed). A lot of projects let their PTL directly determine who should (and should no longer) be on the core list. https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess Now it's true that very early on, a lot of PTLs adopted a more open process to help in that selection. That doesn't mean they can't bypass the process. Personally I think that the apparently open process for core selection just resulted in reinforcing the aristocracy. This is why I encourage PTLs to own the content of core reviewing teams more directly. However in some projects, core reviewers have to be approved by existing core reviewers. That is an aristocracy. In those projects, if you Which projects do it differently? The Swift PTL always just announced additions. I seem to remember TripleO under Robert Collins directly adding members. Also Nova under Russell Bryant removed inactive members without asking for an existing core members poll. (and that is all good). That said, I agree with you that most projects copied the existing cores must agree rule. So this is where you loose me. Has there ever been a case of a project's PTL adding/removing people from the core team where the PTL goes against the majority of the core developers? You say that an early (unwritten?) goal of the system we have is to prevent 'aristocracy,' but all I see is 'aristocracy'. Obviously the PTL would only overrule the majority of his core reviewers in extreme cases. Imagine this extreme case: core reviewers in a project have become a pure aristocracy, nobody can get in anymore, fresh ideas and code are systematically rejected. There is a divide between contributors to the project (doing the work) and core reviewers. Project is completely blocked. At the next election, a PTL candidate campaigns on fixing this by dramatically changing the core team. Contributors rally to that candidacy, candidate is elected. Once elected, the PTL can fix the core team without asking the existing aristocracy blessing. Now I agree that it's a governance safety valve, designed to solve a mostly theoretical case. But sometimes having a bucket stops here rule is sufficient to prevent conflict. For example conflicts between two projects can be escalated to the TC for final resolution. In effect, that never happens: said projects usually solve the issue between themselves rather than ask the TC to arbitrate. The same effect
Re: [openstack-dev] The Evolution of core developer to maintainer?
On Fri, Apr 3, 2015 at 1:39 AM, Thierry Carrez thie...@openstack.org wrote: Joe Gordon wrote: On Thu, Apr 2, 2015 at 3:14 AM, Thierry Carrez thie...@openstack.org mailto:thie...@openstack.org wrote: Joe Gordon wrote: I cannot speak for all projects, but at least in Nova you have to be a nova-core to be part of nova-drivers. And would you describe that as a good thing ? If John Garbutt is so deep into release liaison work that he can't sustain a review rate suitable to remain a core reviewer, would you have him removed from the maintainers group ? If someone steps up and works full-time on triaging bugs in Nova (and can't commit to do enough reviews as a result), would you exclude that person from your maintainers group ? I want to empower that person and recognize them in some semi formal capacity and make sure they have all the correct permissions. I do not want a single flat 'maintainers' group, I think we need a hierarchical notion of maintainers, where different people can end up with very different responsibilities (and ACLs -- but that is a implementation detail). OK, so I probably misread your proposal[1]. My understanding was you wanted a single flat maintainers group that would purely replace core reviewers, keep the same rights and just add duties to the already-existing reviewing duties. [1] https://review.openstack.org/#/c/163660/ So that proposal was not the end goal it was supposed to be a very tiny first step down this path. I see how that was misleading. Since I thought project leadership needs to be expressed in a much more diverse and inclusive way (and explicitly not tied to +2 rights), I opposed such simple renaming. From what you're saying now your objective is the same as mine. I'm not sure the maintainers group needs to be purely hierarchical (I think I'd Hierarchical, in the sense of subsystem maintainers. Not all duties would have to be that way though. prefer it to be a set of duties with no hierarchy between them), but I agree that: - today core reviewers are the only visible project duty, and we need to expose and reward all the others, as separate attributes ++ - we could use a blanket term (maintainers ?) to describe the people holding one or more of those attributes. ++ OpenStack governance mandates that core developers are ultimately the PTL's choice. Since the PTL is regularly elected by all contributors, that prevents aristocracy. Can you site your source for this? Because the earliest reference to 'Core Developer' (what you are calling core reviewer -- even though that is not the original name) that I could find says nothing about it ultimately being the PTLs choice. PTLs have (and always had) ultimate say over their project matters. That includes how to select core reviewers (or how reviews should be performed). A lot of projects let their PTL directly determine who should (and should no longer) be on the core list. https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess Now it's true that very early on, a lot of PTLs adopted a more open process to help in that selection. That doesn't mean they can't bypass the process. Personally I think that the apparently open process for core selection just resulted in reinforcing the aristocracy. This is why I encourage PTLs to own the content of core reviewing teams more directly. However in some projects, core reviewers have to be approved by existing core reviewers. That is an aristocracy. In those projects, if you Which projects do it differently? The Swift PTL always just announced additions. I seem to remember TripleO under Robert Collins directly adding members. Also Nova under Russell Bryant removed inactive members without asking for an existing core members poll. (and that is all good). That said, I agree with you that most projects copied the existing cores must agree rule. It sounds like writing down this aspect of the PTL powers may be something worth writing down in the governance repo somewhere? So this is where you loose me. Has there ever been a case of a project's PTL adding/removing people from the core team where the PTL goes against the majority of the core developers? You say that an early (unwritten?) goal of the system we have is to prevent 'aristocracy,' but all I see is 'aristocracy'. Obviously the PTL would only overrule the majority of his core reviewers in extreme cases. Imagine this extreme case: core reviewers in a project have become a pure aristocracy, nobody can get in anymore, fresh ideas and code are systematically rejected. There is a divide between While a safety valve like this is fine, I am not sure if its existence is why these issues have never arose, and have a hard time imagining this safety valve actually being used. If this did happen there is a better safety
Re: [openstack-dev] The Evolution of core developer to maintainer?
On 04/01/2015 06:07 PM, Ian Wienand wrote: On 04/02/2015 09:02 AM, Jeremy Stanley wrote: but since parties who don't understand our mostly non-hierarchical community can see those sets of access controls, they cling to them as a sign of importance and hierarchy of the people listed within. Once code is submitted, there *is* a hierarchy. The only way something gets merged in OpenStack is by Brownian motion of this hierarchy. These special cores float around and as a contributor you just hope that two of them meet up and decide your change is ready. You have zero insight into when this might happen, if at all. The efficiency is appalling but somehow we get there in the end. This agrees with my experience as a new OpenStack contributor. The process seemed very opaque, there was very little in the way of timely feedback, and it was frustrating not knowing if something was going to be reviewed in a day or a month (or two). A year later I'm starting to see the relationships but it's still not as clear as it could be. IMO requiring two cores to approve *every* change is too much. What we should do is move the responsibility downwards. Currently, as a contributor I am only 1/3 responsible for my change making it through. I write it, test it, clean it up and contribute it; then require the extra 2/3 to come from the hierarchy. If you only need one core, then core and myself share the responsibility for the change. In my mind, this better recognises the skill of the contributor -- we are essentially saying we trust you. Interesting idea. Makes me wonder about the history...where did the two cores to approve model come from originally? Were there bad experiences previously with just one approver, or did it start out with two approvers? Chris __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
On 2 April 2015 at 03:07, Ian Wienand iwien...@redhat.com wrote: IMO requiring two cores to approve *every* change is too much. What we should do is move the responsibility downwards. Currently, as a contributor I am only 1/3 responsible for my change making it through. I write it, test it, clean it up and contribute it; then require the extra 2/3 to come from the hierarchy. If you only need one core, then core and myself share the responsibility for the change. In my mind, this better recognises the skill of the contributor -- we are essentially saying we trust you. I frankly disagree. There are a number of fixes that have come in that look good, particularly to somebody not intimately familiar with a particular area of code, that turn out to have all sorts of nasty side effects that were only spotted by the second (or in some cases third, forth) core to come along. If you compare the velocity of openstack to many opensource projects, it is *huge*. We really are making very rapid progress, in so many areas, every single cycle. I'm starting to worry that we are pushing velocity above vision, code quality, and many other things. I think we want to reduce the expectation that your feature (or even contentious bug fix) is likely to get merged in days - the project is sufficiently big that that is in fact unlikely. -- Duncan Thomas __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
Le 02/04/2015 03:19, Jay Pipes a écrit : On 04/01/2015 12:31 PM, Duncan Thomas wrote: On 1 April 2015 at 10:04, Joshua Harlow harlo...@outlook.com mailto:harlo...@outlook.com wrote: +1 to this. There will always be people who will want to work on fun stuff and those who don't; it's the job of leadership in the community to direct people if they can (but also the same job of that leadership to understand that they can't direct everyone; it is open-source after all and saying 'no' to people just makes them run to some other project that doesn't do this...). IMHO (and a rant probably better for another thread) but I've seen to many projects/specs/split-outs (ie, scheduler tweaks, constraint solving scheduler...) get abandoned because of cores saying this or that is the priority right now (and this in all honesty pisses me off); I don't feel this is right (cores should be leaders and guides, not dictators); if a core is going to tell anyone that then they better act as a guide to the person they are telling that to and make sure they lead that person they just told no; after all any child can say no but it takes a real man/woman to go the extra distance... So I think saying no is sometimes a vital part of the core team's role, keeping up code quality and vision is really hard to do while new features are flooding in, and doing architectural reworking while features are merging is an epic task. There are also plenty of features that don't necessarily fit the shared vision of the project; just because we can do something doesn't mean we should. For example: there are plenty of companies trying to turn Openstack into a datacentre manager rather than a cloud (i.e. too much focus on pets .v. cattle style VMs), and I think we're right to push back against that. Amen to the above. All of it. Right now there are some strong indications that there are areas we are very weak at (nova network still being preferred to neutron, the amount of difficultly people had establishing 3rd party CI setups for cinder) that really *should* be prioritised over new features. That said, some projects can be worked on successfully in parallel with the main development - I suspect that a scheduler split out proposal is one of them. This doesn't need much/any buy-in from cores, it can be demonstrated in a fairly complete state before it is evaluated, so the only buyi-in needed is on the concept. Ha, I had to laugh at this last paragraph :) You mention the fact that nova-network is still very much in use in the paragraph above (for good reasons that have been highlighted in other threads). And yet you then go on to suspect that a nova-scheduler split would something that would be successfully worked on in parallel... The Gantt project tried and failed to split the Nova scheduler out (before it had any public or versioned interfaces). The solver scheduler has not gotten any traction not because as Josh says some cores are acting like dictators but because it doesn't solve the right problem: it makes more complex scheduling placement decisions in a different way from the Nova scheduler, but it doesn't solve the distributed scale problems in the Nova scheduler architecture. If somebody developed an external generic resource placement engine that scaled in a distributed, horizontal fashion and that had well-documented public interfaces, I'd welcome that work and quickly work to add a driver for it inside Nova. But both Gantt and the solver scheduler fall victim to the same problem: trying to use the existing Nova scheduler architecture when it's flat-out not scalable. Alright, now that I've said that, I'll wait here for the inevitable complaints that as a Nova core, I'm being a dictator because I speak my mind about major architectural issues I see in proposals. And that's also why the more I'm reviewing, the more I'm thinking that people need to have a basic understanding of all the Nova repository and not only a specific asset if they want to provide a new feature, just because of the technical debt and all the inherited interactions. Take the scheduler as an example again : most of the commits related to it are also impacting objects, cells, db migrations to quote the most related. I was originally pro giving a limited set of merge powers to subteams for a specific codepath, but my personal experience made me think that it can't work that way in Nova at the moment - just because everything is intersected. So, yeah, before kicking-off new features, we need at least people enough aware of the global state to give their voice on if it's doable or not. I don't want to say it would be a clique or a gang blessing good people or bad people, just architects that have enough knowledge to know if it will work - or not. Good ideas can turn into bad implementations just because of the existing tech debt. And there is nothing
Re: [openstack-dev] The Evolution of core developer to maintainer?
Joe Gordon wrote: On Thu, Apr 2, 2015 at 3:14 AM, Thierry Carrez thie...@openstack.org mailto:thie...@openstack.org wrote: Joe Gordon wrote: My main objection to the model you propose is its binary nature. You bundle core reviewing duties with drivers duties into a single group. That simplification means that drivers have to be core reviewers, and that core reviewers have to be drivers. Sure, a lot of core reviewers are good candidates to become drivers. But I think bundling the two concepts excludes a lot of interesting people from being a driver. I cannot speak for all projects, but at least in Nova you have to be a nova-core to be part of nova-drivers. And would you describe that as a good thing ? If John Garbutt is so deep into release liaison work that he can't sustain a review rate suitable to remain a core reviewer, would you have him removed from the maintainers group ? If someone steps up and works full-time on triaging bugs in Nova (and can't commit to do enough reviews as a result), would you exclude that person from your maintainers group ? I want to empower that person and recognize them in some semi formal capacity and make sure they have all the correct permissions. I do not want a single flat 'maintainers' group, I think we need a hierarchical notion of maintainers, where different people can end up with very different responsibilities (and ACLs -- but that is a implementation detail). If someone steps up and owns bug triaging in a project, that is very interesting and I'd like that person to be part of the drivers group. In our current model, not sure why they would need to be part of drivers. the bug triage group is open to anyone. I think we are talking past each other. I'm not saying bug triagers have It appears that we are talking past each other, at least we agree on something. to be drivers. I'm saying bug triagers should be *allowed* to potentially become drivers, even if they aren't core reviewers. That is including of all forms of project leadership. You are the one suggesting that maintainers and core reviewers are the same thing, and therefore asking that all maintainers/drivers have to be core reviewers, actively excluding non-reviewers from that project leadership class. Saying core reviewers and maintainers are the same thing, you basically exclude people from stepping up to the project leadership unless they are code reviewers. I think that's a bad thing. We need more people volunteering to own bug triaging and liaison work, not less. I don't agree with this statement, I am not saying reviewing and maintenance need to be tightly coupled. You've been proposing to rename core reviewers to maintainers. I'm not sure how that can be more tightly coupled... All core reviewers in our current model should be responsible for maintenance of the project, but not all maintainers need to be responsible for reviewing code anywhere in the project. [...] I really want to know what you meant be 'no aristocracy' and the why behind that. Aristocracies are self-selecting, privileged groups. Aristocracies require that current group members agree on any new member addition, basically limiting the associated privilege to a caste. Aristocracies result in limited gene pool, tunnel vision and echo chamber effects. OpenStack governance mandates that core developers are ultimately the PTL's choice. Since the PTL is regularly elected by all contributors, that prevents aristocracy. Can you site your source for this? Because the earliest reference to 'Core Developer' (what you are calling core reviewer -- even though that is not the original name) that I could find says nothing about it ultimately being the PTLs choice. https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess Where is the current documentation on this? However in some projects, core reviewers have to be approved by existing core reviewers. That is an aristocracy. In those projects, if you Which projects do it differently? So this is where you loose me. Has there ever been a case of a project's PTL adding/removing people from the core team where the PTL goes against the majority of the core developers? You say that an early (unwritten?) goal of the system we have is to prevent 'aristocracy,' but all I see is 'aristocracy'. It sounds like if a goal was no aristocracy then we have miserably failed at that. But frankly I don't know to prevent what you call aristocracy. associate more rights and badges to core reviewing (like by renaming it maintainer and bundle driver responsibilities with it), I think you actually extend the aristocracy problem rather
Re: [openstack-dev] The Evolution of core developer to maintainer?
On 02/04/15 12:26 +0200, Thierry Carrez wrote: Maru Newby wrote: [...] Many of us in the Neutron community find this taxonomy restrictive and not representative of all the work that makes the project possible. We seem to be after the same end goal. I just disagree that renaming core reviewers to maintainers is a positive step toward that goal. Worse, 'cores' are put on a pedastal, and not just in the project. Every summit a 'core reviewer dinner' is held that underscores the glorification of this designation. I deeply regret that, and communicated to the sponsor holding it the problem with this +2 dinner the very first time it was held. FWIW it's been renamed to VIP dinner and no longer limited to core reviewers, but I'd agree with you that the damage was already done. By proposing to rename 'core reviewer' to 'maintainer' the goal was to lay the groundwork for broadening the base of people whose valuable contribution could be recognized. The goal was to recognize not just review-related contributors, but also roles like doc/bug/test czar and cross-project liaison. The statue of the people filling these roles today is less if they are not also ‘core’, and that makes the work less attractive to many. That's where we disagree. You see renaming core reviewer to maintainer has a way to recognize a broader type of contributions. I see it as precisely resulting in the opposite. Simply renaming core reviewers to maintainers just keeps us using a single term (or class) to describe project leadership. And that class includes +2 reviewing duties. So you can't be a maintainer if you don't do core reviewing. That is exclusive, not inclusive. What we need to do instead is reviving the drivers concept (we can rename it maintainers if you really like that term), separate from the core reviewers concept. One can be a project driver and a core reviewer. And one can be a project driver *without* being a core reviewer. Now *that* allows to recognize all valuable contributions, and to be representative of all the work that makes the project possible. While I don't think renaming core reviewers to maintainers will fix the problem, I do recognize this as a step forward on fixing the issue. It just states that we know there's been a misunderstanding on what the purpose of the team is and we're working on changing that. This being said, there are projects that have the drivers and the cores team split already. Glance being one of them. This allows for allowing people to focus on the areas they are most interested in. Cheers, Flavio -- @flaper87 Flavio Percoco pgpixpK8v1Bdw.pgp Description: PGP signature __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
Joe Gordon wrote: My main objection to the model you propose is its binary nature. You bundle core reviewing duties with drivers duties into a single group. That simplification means that drivers have to be core reviewers, and that core reviewers have to be drivers. Sure, a lot of core reviewers are good candidates to become drivers. But I think bundling the two concepts excludes a lot of interesting people from being a driver. I cannot speak for all projects, but at least in Nova you have to be a nova-core to be part of nova-drivers. And would you describe that as a good thing ? If John Garbutt is so deep into release liaison work that he can't sustain a review rate suitable to remain a core reviewer, would you have him removed from the maintainers group ? If someone steps up and works full-time on triaging bugs in Nova (and can't commit to do enough reviews as a result), would you exclude that person from your maintainers group ? If someone steps up and owns bug triaging in a project, that is very interesting and I'd like that person to be part of the drivers group. In our current model, not sure why they would need to be part of drivers. the bug triage group is open to anyone. I think we are talking past each other. I'm not saying bug triagers have to be drivers. I'm saying bug triagers should be *allowed* to potentially become drivers, even if they aren't core reviewers. That is including of all forms of project leadership. You are the one suggesting that maintainers and core reviewers are the same thing, and therefore asking that all maintainers/drivers have to be core reviewers, actively excluding non-reviewers from that project leadership class. Saying core reviewers and maintainers are the same thing, you basically exclude people from stepping up to the project leadership unless they are code reviewers. I think that's a bad thing. We need more people volunteering to own bug triaging and liaison work, not less. I don't agree with this statement, I am not saying reviewing and maintenance need to be tightly coupled. You've been proposing to rename core reviewers to maintainers. I'm not sure how that can be more tightly coupled... [...] I really want to know what you meant be 'no aristocracy' and the why behind that. Aristocracies are self-selecting, privileged groups. Aristocracies require that current group members agree on any new member addition, basically limiting the associated privilege to a caste. Aristocracies result in limited gene pool, tunnel vision and echo chamber effects. OpenStack governance mandates that core developers are ultimately the PTL's choice. Since the PTL is regularly elected by all contributors, that prevents aristocracy. However in some projects, core reviewers have to be approved by existing core reviewers. That is an aristocracy. In those projects, if you associate more rights and badges to core reviewing (like by renaming it maintainer and bundle driver responsibilities with it), I think you actually extend the aristocracy problem rather than reduce it. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
Maru Newby wrote: [...] Many of us in the Neutron community find this taxonomy restrictive and not representative of all the work that makes the project possible. We seem to be after the same end goal. I just disagree that renaming core reviewers to maintainers is a positive step toward that goal. Worse, 'cores' are put on a pedastal, and not just in the project. Every summit a 'core reviewer dinner' is held that underscores the glorification of this designation. I deeply regret that, and communicated to the sponsor holding it the problem with this +2 dinner the very first time it was held. FWIW it's been renamed to VIP dinner and no longer limited to core reviewers, but I'd agree with you that the damage was already done. By proposing to rename 'core reviewer' to 'maintainer' the goal was to lay the groundwork for broadening the base of people whose valuable contribution could be recognized. The goal was to recognize not just review-related contributors, but also roles like doc/bug/test czar and cross-project liaison. The statue of the people filling these roles today is less if they are not also ‘core’, and that makes the work less attractive to many. That's where we disagree. You see renaming core reviewer to maintainer has a way to recognize a broader type of contributions. I see it as precisely resulting in the opposite. Simply renaming core reviewers to maintainers just keeps us using a single term (or class) to describe project leadership. And that class includes +2 reviewing duties. So you can't be a maintainer if you don't do core reviewing. That is exclusive, not inclusive. What we need to do instead is reviving the drivers concept (we can rename it maintainers if you really like that term), separate from the core reviewers concept. One can be a project driver and a core reviewer. And one can be a project driver *without* being a core reviewer. Now *that* allows to recognize all valuable contributions, and to be representative of all the work that makes the project possible. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/02/2015 03:22 AM, Sylvain Bauza wrote: I was originally pro giving a limited set of merge powers to subteams for a specific codepath, but my personal experience made me think that it can't work that way in Nova at the moment - just because everything is intersected. So, yeah, before kicking-off new features, we need at least people enough aware of the global state to give their voice on if it's doable or not. I don't want to say it would be a clique or a gang blessing good people or bad people, just architects that have enough knowledge to know if it will work - or not. Good ideas can turn into bad implementations just because of the existing tech debt. And there is nothing that we can avoid that, unless we have mentors that can help us finding the right path. Don't get me wrong : again, it's not giving more powers to people, it's basically stating that cores are by definition people who have the global knowledge. It *can* work, as long as the cores hold the all-important +W. I'm sure that having your +1 on a scheduler-related patch now makes cores feel more confident that the change is correct for the scheduler, so making your vote a +2 would streamline the process. But as you correctly point out, they have a deeper knowledge of the entire project, and need to validate that the change won't adversely affect other parts, so holding the +W for cores would minimize the chance of adding to tech debt. - -- - -- Ed Leafe -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJVHVuCAAoJEKMgtcocwZqLjcwQAIOzkKTLCjWLV84bqoCJX6Ai D/zzqMCoOOYyj341lrfVM2SxkJX6+awQfe75WNo46u4nEC1CZp5EscZpbrIUIxG2 Bic5l2cjKQmvKEIyvNrAb1g3mmC50mEUscZwfvrUr4QUamwL0wNm7jkZBMVlAGMd uD2My/HRqnls/FhCMGprzTI+zeowa4KdUWuZUC5CfGZg/GFVty2/k4u0Jej5nla9 efoQ49VG3M2g+Ipxhg1sgVWvru+7E2pfCNd3lFVt+C/gwJUrQ7x36nQkOIR8OtyN j9BH5NqJ+8qDIqEvQIaI1ToaBwwNn4JK1XsKfj41wt+YFym4qS0o8/wKuup+5Syj q1m29yWZwFfFXqYoLqfqHQJ34bY3CTFS7OllXGX1KkMh7MfMffbwbPZn67ICYnoY 4Q4ed/QQOzDnzvH3MAOwVfaeNq8vL8u/x5C2rotXQmcihJrrgi5MWfATayiuNGpj Sfi++C1MDgW61I1ehFrgHcW2sQ6vvuyErA9e8mm0xPBO/o+64gL4dmqnU2U6rfTx KBR6Q9vXJXoFBvCmrFMv+F7vk+XDEUUP5uoXj8069/lXblQxZwowH4ijJql2RwlI COUsWahnKAp05F8CiMKxaIF/R7UeHslTLer7yE+dwmNTqIVF1ylj0ToOxnSXV/WK f7sPIo9aHtfZbPO+d8uV =Euob -END PGP SIGNATURE- __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
On Apr 2, 2015, at 3:26 AM, Thierry Carrez thie...@openstack.org wrote: Maru Newby wrote: [...] Many of us in the Neutron community find this taxonomy restrictive and not representative of all the work that makes the project possible. We seem to be after the same end goal. I just disagree that renaming core reviewers to maintainers is a positive step toward that goal. Worse, 'cores' are put on a pedastal, and not just in the project. Every summit a 'core reviewer dinner' is held that underscores the glorification of this designation. I deeply regret that, and communicated to the sponsor holding it the problem with this +2 dinner the very first time it was held. FWIW it's been renamed to VIP dinner and no longer limited to core reviewers, but I'd agree with you that the damage was already done. By proposing to rename 'core reviewer' to 'maintainer' the goal was to lay the groundwork for broadening the base of people whose valuable contribution could be recognized. The goal was to recognize not just review-related contributors, but also roles like doc/bug/test czar and cross-project liaison. The statue of the people filling these roles today is less if they are not also ‘core’, and that makes the work less attractive to many. That's where we disagree. You see renaming core reviewer to maintainer has a way to recognize a broader type of contributions. I see it as precisely resulting in the opposite. Simply renaming core reviewers to maintainers just keeps us using a single term (or class) to describe project leadership. And that class includes +2 reviewing duties. So you can't be a maintainer if you don't do core reviewing. That is exclusive, not inclusive. The important part of my statement above was ‘lay the groundwork for’. We were intended to change the name as a _precursor_ to changing the role itself to encompass more than just those with +2 rights. Nobody in their right mind would assume that changing the name by itself could fix the situation, but we thought it would be a good signal as to our intent to broaden the scope of recognized contribution. What we need to do instead is reviving the drivers concept (we can rename it maintainers if you really like that term), separate from the core reviewers concept. One can be a project driver and a core reviewer. And one can be a project driver *without* being a core reviewer. Now *that* allows to recognize all valuable contributions, and to be representative of all the work that makes the project possible. As Joe and I have said, Nova and Neutron already have drivers teams and they fill a different role from what you are suggesting. Can you think of a more appropriate name that isn’t already in use for what you are proposing? Maru __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
Jay Pipes wrote: On 04/01/2015 12:31 PM, Duncan Thomas wrote: On 1 April 2015 at 10:04, Joshua Harlow harlo...@outlook.com mailto:harlo...@outlook.com wrote: +1 to this. There will always be people who will want to work on fun stuff and those who don't; it's the job of leadership in the community to direct people if they can (but also the same job of that leadership to understand that they can't direct everyone; it is open-source after all and saying 'no' to people just makes them run to some other project that doesn't do this...). IMHO (and a rant probably better for another thread) but I've seen to many projects/specs/split-outs (ie, scheduler tweaks, constraint solving scheduler...) get abandoned because of cores saying this or that is the priority right now (and this in all honesty pisses me off); I don't feel this is right (cores should be leaders and guides, not dictators); if a core is going to tell anyone that then they better act as a guide to the person they are telling that to and make sure they lead that person they just told no; after all any child can say no but it takes a real man/woman to go the extra distance... So I think saying no is sometimes a vital part of the core team's role, keeping up code quality and vision is really hard to do while new features are flooding in, and doing architectural reworking while features are merging is an epic task. There are also plenty of features that don't necessarily fit the shared vision of the project; just because we can do something doesn't mean we should. For example: there are plenty of companies trying to turn Openstack into a datacentre manager rather than a cloud (i.e. too much focus on pets .v. cattle style VMs), and I think we're right to push back against that. Amen to the above. All of it. Right now there are some strong indications that there are areas we are very weak at (nova network still being preferred to neutron, the amount of difficultly people had establishing 3rd party CI setups for cinder) that really *should* be prioritised over new features. That said, some projects can be worked on successfully in parallel with the main development - I suspect that a scheduler split out proposal is one of them. This doesn't need much/any buy-in from cores, it can be demonstrated in a fairly complete state before it is evaluated, so the only buyi-in needed is on the concept. Ha, I had to laugh at this last paragraph :) You mention the fact that nova-network is still very much in use in the paragraph above (for good reasons that have been highlighted in other threads). And yet you then go on to suspect that a nova-scheduler split would something that would be successfully worked on in parallel... The Gantt project tried and failed to split the Nova scheduler out (before it had any public or versioned interfaces). The solver scheduler has not gotten any traction not because as Josh says some cores are acting like dictators but because it doesn't solve the right problem: it makes more complex scheduling placement decisions in a different way from the Nova scheduler, but it doesn't solve the distributed scale problems in the Nova scheduler architecture. If somebody developed an external generic resource placement engine that scaled in a distributed, horizontal fashion and that had well-documented public interfaces, I'd welcome that work and quickly work to add a driver for it inside Nova. But both Gantt and the solver scheduler fall victim to the same problem: trying to use the existing Nova scheduler architecture when it's flat-out not scalable. Alright, now that I've said that, I'll wait here for the inevitable complaints that as a Nova core, I'm being a dictator because I speak my mind about major architectural issues I see in proposals. Let the beatings commence, haha. j/k :) I think it's fine to speak your mind btw. I just wish we had a better way to speak our mind and somehow make more comprimises and/or engage those who may have the wrong idea (say about the solver scheduler) and instead engage them with some kind of 'something' to comprimise so that both the disagreeing party and the people working on said scheduler come to an agreement. Maybe that involves a lot of work (it does); maybe even phone calls - between folks... but it seems like something we need to work on to be a better and more accepting community. Best, -jay __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
On Apr 1, 2015, at 7:19 PM, Jay Pipes jaypi...@gmail.com wrote: On 04/01/2015 12:31 PM, Duncan Thomas wrote: On 1 April 2015 at 10:04, Joshua Harlow harlo...@outlook.com mailto:harlo...@outlook.com wrote: +1 to this. There will always be people who will want to work on fun stuff and those who don't; it's the job of leadership in the community to direct people if they can (but also the same job of that leadership to understand that they can't direct everyone; it is open-source after all and saying 'no' to people just makes them run to some other project that doesn't do this...). IMHO (and a rant probably better for another thread) but I've seen to many projects/specs/split-outs (ie, scheduler tweaks, constraint solving scheduler...) get abandoned because of cores saying this or that is the priority right now (and this in all honesty pisses me off); I don't feel this is right (cores should be leaders and guides, not dictators); if a core is going to tell anyone that then they better act as a guide to the person they are telling that to and make sure they lead that person they just told no; after all any child can say no but it takes a real man/woman to go the extra distance... So I think saying no is sometimes a vital part of the core team's role, keeping up code quality and vision is really hard to do while new features are flooding in, and doing architectural reworking while features are merging is an epic task. There are also plenty of features that don't necessarily fit the shared vision of the project; just because we can do something doesn't mean we should. For example: there are plenty of companies trying to turn Openstack into a datacentre manager rather than a cloud (i.e. too much focus on pets .v. cattle style VMs), and I think we're right to push back against that. Amen to the above. All of it. Right now there are some strong indications that there are areas we are very weak at (nova network still being preferred to neutron, the amount of difficultly people had establishing 3rd party CI setups for cinder) that really *should* be prioritised over new features. That said, some projects can be worked on successfully in parallel with the main development - I suspect that a scheduler split out proposal is one of them. This doesn't need much/any buy-in from cores, it can be demonstrated in a fairly complete state before it is evaluated, so the only buyi-in needed is on the concept. Ha, I had to laugh at this last paragraph :) You mention the fact that nova-network is still very much in use in the paragraph above (for good reasons that have been highlighted in other threads). And yet you then go on to suspect that a nova-scheduler split would something that would be successfully worked on in parallel... The Gantt project tried and failed to split the Nova scheduler out (before it had any public or versioned interfaces). The solver scheduler has not gotten any traction not because as Josh says some cores are acting like dictators but because it doesn't solve the right problem: it makes more complex scheduling placement decisions in a different way from the Nova scheduler, but it doesn't solve the distributed scale problems in the Nova scheduler architecture. If somebody developed an external generic resource placement engine that scaled in a distributed, horizontal fashion and that had well-documented public interfaces, I'd welcome that work and quickly work to add a driver for it inside Nova. But both Gantt and the solver scheduler fall victim to the same problem: trying to use the existing Nova scheduler architecture when it's flat-out not scalable. Alright, now that I've said that, I'll wait here for the inevitable complaints that as a Nova core, I'm being a dictator because I speak my mind about major architectural issues I see in proposals. Isn't this last statement the crux of the perception issue? You're not a dictator because you're a core, you're a dictator because you're saying no (and I mean that in a good way.) I'd assume that any -1 with a strong technical basis would be valid, core or not. Cores happen to usually be the ones saying no most often, because they tend to have a broader/deeper understanding of the code base/architecture/direction. Correlation/causation fallacy at play, and the gist of the re-naming/re-structuring would be to make the structure less prone to that mis-perception. Best, -jay __ 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:
Re: [openstack-dev] The Evolution of core developer to maintainer?
On Apr 2, 2015, at 9:02 AM, Thierry Carrez thie...@openstack.org wrote: Maru Newby wrote: On Apr 2, 2015, at 3:26 AM, Thierry Carrez thie...@openstack.org wrote: What we need to do instead is reviving the drivers concept (we can rename it maintainers if you really like that term), separate from the core reviewers concept. One can be a project driver and a core reviewer. And one can be a project driver *without* being a core reviewer. Now *that* allows to recognize all valuable contributions, and to be representative of all the work that makes the project possible. As Joe and I have said, Nova and Neutron already have drivers teams and they fill a different role from what you are suggesting. The only team I heard you and Joe mention is the one approving specs, and that one is called nova-specs-core, not nova-drivers: https://review.openstack.org/#/admin/groups/302,members The one I'm speaking about always existed in the capacity I'm describing (project leadership, people actually making sure the project goes somewhere and all the boring tasks get done), and is defined at: https://launchpad.net/~nova-drivers Regardless of what you are seeing for Nova, the Neutron community calls this team ‘drivers’ and documents it as such in the wiki: https://wiki.openstack.org/wiki/Neutron-drivers Maru Can you think of a more appropriate name that isn’t already in use for what you are proposing? I'm not proposing anything new. I'm saying we should just use (or revive the use of) existing teams (nova-core, nova-drivers) to achieve our goals of being representative of all the work that makes the project possible. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
On Thu, Apr 2, 2015 at 3:14 AM, Thierry Carrez thie...@openstack.org wrote: Joe Gordon wrote: My main objection to the model you propose is its binary nature. You bundle core reviewing duties with drivers duties into a single group. That simplification means that drivers have to be core reviewers, and that core reviewers have to be drivers. Sure, a lot of core reviewers are good candidates to become drivers. But I think bundling the two concepts excludes a lot of interesting people from being a driver. I cannot speak for all projects, but at least in Nova you have to be a nova-core to be part of nova-drivers. And would you describe that as a good thing ? If John Garbutt is so deep into release liaison work that he can't sustain a review rate suitable to remain a core reviewer, would you have him removed from the maintainers group ? If someone steps up and works full-time on triaging bugs in Nova (and can't commit to do enough reviews as a result), would you exclude that person from your maintainers group ? I want to empower that person and recognize them in some semi formal capacity and make sure they have all the correct permissions. I do not want a single flat 'maintainers' group, I think we need a hierarchical notion of maintainers, where different people can end up with very different responsibilities (and ACLs -- but that is a implementation detail). If someone steps up and owns bug triaging in a project, that is very interesting and I'd like that person to be part of the drivers group. In our current model, not sure why they would need to be part of drivers. the bug triage group is open to anyone. I think we are talking past each other. I'm not saying bug triagers have It appears that we are talking past each other, at least we agree on something. to be drivers. I'm saying bug triagers should be *allowed* to potentially become drivers, even if they aren't core reviewers. That is including of all forms of project leadership. You are the one suggesting that maintainers and core reviewers are the same thing, and therefore asking that all maintainers/drivers have to be core reviewers, actively excluding non-reviewers from that project leadership class. Saying core reviewers and maintainers are the same thing, you basically exclude people from stepping up to the project leadership unless they are code reviewers. I think that's a bad thing. We need more people volunteering to own bug triaging and liaison work, not less. I don't agree with this statement, I am not saying reviewing and maintenance need to be tightly coupled. You've been proposing to rename core reviewers to maintainers. I'm not sure how that can be more tightly coupled... All core reviewers in our current model should be responsible for maintenance of the project, but not all maintainers need to be responsible for reviewing code anywhere in the project. [...] I really want to know what you meant be 'no aristocracy' and the why behind that. Aristocracies are self-selecting, privileged groups. Aristocracies require that current group members agree on any new member addition, basically limiting the associated privilege to a caste. Aristocracies result in limited gene pool, tunnel vision and echo chamber effects. OpenStack governance mandates that core developers are ultimately the PTL's choice. Since the PTL is regularly elected by all contributors, that prevents aristocracy. Can you site your source for this? Because the earliest reference to 'Core Developer' (what you are calling core reviewer -- even though that is not the original name) that I could find says nothing about it ultimately being the PTLs choice. https://wiki.openstack.org/wiki/Governance/Approved/CoreDevProcess Where is the current documentation on this? However in some projects, core reviewers have to be approved by existing core reviewers. That is an aristocracy. In those projects, if you Which projects do it differently? So this is where you loose me. Has there ever been a case of a project's PTL adding/removing people from the core team where the PTL goes against the majority of the core developers? You say that an early (unwritten?) goal of the system we have is to prevent 'aristocracy,' but all I see is 'aristocracy'. It sounds like if a goal was no aristocracy then we have miserably failed at that. But frankly I don't know to prevent what you call aristocracy. associate more rights and badges to core reviewing (like by renaming it maintainer and bundle driver responsibilities with it), I think you actually extend the aristocracy problem rather than reduce it. So, let me take a step back here. I would like to see at least 2 to 3x more people in a given project to feel empowered and have badges, and make it possible for part time upstream developers to hold some of said badges. It sounds like you
Re: [openstack-dev] The Evolution of core developer to maintainer?
On 03/31/2015 06:24 PM, John Griffith wrote: What is missing for me here however is who picks these special people. I'm convinced that this does more to promote the idea of special contributors than anything else. Maybe that's actually what you want, but it seemed based on your message that wasn't the case. Anyway, core nominations are fairly objective in my opinion and is *mostly* based on number of reviews and perceived quality of those reviews (measured somewhat by disagreement rates etc). What are the metrics for this special group of folks that you're proposing we empower and title as maintainers? Do I get to be a maintainer, is it reserved for a special group of people, a specific company? What's the criteria? Do *you* get to be a maintainer? What standards are *Maintainers* held to? Who/How do we decide he/she is doing their job? Are there any rules about representation and interests (keeping the team of people balanced). What about the work by those maintainers that introduces more/new bugs? I think Joe's comments about giving more people more responsibility make a lot of sense. I worked with the Linux kernel more-or-less professionally for about a decade, and while the kernel project has its problems there were a things about its maintainer model that I liked. 1) There was a MAINTAINERS file at the top level in the source, listing who was currently responsible for what areas of code, along with their contact information. Generally this was one or two people, with larger subsystems having a mailing list as well. 2) The maintainers were generally chosen by consensus because they were the experts in that area, they had time available, and they were willing to take on the task. Usually when a maintainer stepped down there was someone to take their place who had been working closely with them for some time. 3) If you found a bug in a particular area, you could look up that area and find out who was in charge and take the problem to them. Similarly, if you wanted to contribute some code in a particular area there was a relatively small number of specific people that you could to talk to about whether the change made sense, or what modifications would be needed to get it accepted. I think some of this exists informally within OpenStack, but it's not obvious to a newcomer who they need to talk to if they have an issue with libvirt, or with the scheduler, or with the DB, or some minutiae of the REST API. (Sorry for the nova-specific examples, it's where I've spent most of my time.) I don't know what sort of process would be appropriate for selecting these people within OpenStack, but I think it would be useful to follow Joe's suggestion and give people approval privileges within a subsection. It's *hard* to find people that are able to wrap their heads around the entirety of something like nova. I suspect it would be easier to find people willing to own a smaller piece of the code. Chris __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
John Griffith wrote: On Tue, Mar 31, 2015 at 4:30 PM, Joe Gordon joe.gord...@gmail.com mailto:joe.gord...@gmail.com wrote: I am starting this thread based on Thierry's feedback on [0]. Instead of writing the same thing twice, you can look at the rendered html from that patch [1]. Neutron tried to go from core to maintainer but after input from the TC and others, they are keeping the term 'core' but are clarifying what it means to be a neutron core [2]. [2] does a very good job of showing how what it means to be core is evolving. From everyone is a dev and everyone is a reviewer. No committers or repo owners, no aristocracy. Some people just commit to do a lot of reviewing and keep current with the code, and have votes that matter more (+2). (Theirry) To a system where cores are more then people who have votes that matter more. Neutron's proposal tries to align that document with what is already happening. 1. They share responsibility in the project's success. 2. They have made a long-term, recurring time investment to improve the project. 3. They spend their time doing what needs to be done to ensure the projects success, not necessarily what is the most interesting or fun. I think there are a few issues at the heart of this debate: 1. Our current concept of a core team has never been able to grow past 20 or so people, even for really big projects like nova and cinder. Why is that? How do we delegate responsibility for subsystems? How do we keep growing? 2. If everyone is just developers and reviewers who is actually responsible for the projects success? How does that mesh with the ideal of no 'aristocracy'? Do are early goals still make sense today? Do you feel like a core deveper/reviewer (we initially called them core developers) [1]: In OpenStack a core developer is a developer who has submitted enough high quality code and done enough code reviews that we trust their code reviews for merging into the base source tree. It is important that we have a process for active developers to be added to the core developer team. Or a maintainer [1]: 1. They share responsibility in the project’s success. 2. They have made a long-term, recurring time investment to improve the project. 3. They spend that time doing whatever needs to be done, not necessarily what is the most interesting or fun. Maintainers are often under-appreciated, because their work is harder to appreciate. It’s easy to appreciate a really cool and technically advanced feature. It’s harder to appreciate the absence of bugs, the slow but steady improvement in stability, or the reliability of a release process. But those things distinguish a good project from a great one. [0] https://review.openstack.org/#/c/163660/ [1] http://docs-draft.openstack.org/60/163660/3/check/gate-governance-docs/f386acf//doc/build/html/resolutions/20150311-rename-core-to-maintainers.html [2] https://review.openstack.org/#/c/164208/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Hey Joe, I mentioned in last weeks TC meeting that I didn't really see a burning need to change or create new labels; but that's probably beside the point. So if I read this it really comes down to a number of people in the community want core to mean something more than special reviewer is that right? I mean regardless of whether you change the name from core to maintainer I really don't care. If it makes some folks feel better to have that title/label associated with themselves that's cool by me (yes I get the *extra* responsibilities part you lined out). +1 to this. I feel we have much much much bigger things to be thinking about than just labels. Maybe this was a misunderstanding of this mail thread but in all honesty who cares... What is missing for me here however is who picks these special people. I'm convinced that this does more to promote the idea of special contributors than anything else. Maybe that's actually what you want, but it seemed based on your message that wasn't the case. Anyway, core nominations are fairly objective in my opinion and is *mostly* based on number of reviews and perceived quality of those reviews (measured somewhat by disagreement rates etc). What are the metrics for this special group of folks that you're proposing we empower and title as maintainers? Do I get to be a maintainer, is it reserved
Re: [openstack-dev] The Evolution of core developer to maintainer?
On Tue, 31 Mar 2015, Anita Kuno wrote: I am really having a problem with a lack of common vision. Now this may just be my problem here, and if it is, that is fine, I'll own that. It's not just you. But other folks, as Dean mentions above, do indicate in their language that they feel something was present at one point and is either gone now or is in danger of going. I haven't got enough history to know if it was once around and is now gone, but I get powerful sense that it is not here now. In part I think this, like so many other things, is an issue of scale and growth: Things get fuzzy as they expand and diffuse so it is inevitable. But I also think that part of it is about identity. People often ask me what OpenStack _is_ and I really struggle to give a concise answer. There are a lot of economic factors driving that lack of identity: Many parties want to be under the OpenStack umbrella because being there has cachet and other value. It's a tricky business because at many levels, including: * project inclusion under the big tent * contributions (of all types) from everyone (people who are 100% of time dedicated to projects to casual passers by) * properly acknowledging the value of contributions of different types we want to be inclusive (and non-aristocratic) yet by being inclusive we cause the diffusion that we then need to counteract in some way to manage the culture. This doesn't really answer your question about what to name things, but I think the question is missing the forest for the trees. It's common in large groups that are trying to collaborate to see them reach a point where they say oops, we're not working as well as we want to, important things are being dropped and then to discover that one of the primary drivers for that lack of effectiveness is because people aren't actually working towards the same goal and a reason they aren't is because they've been using similar words to talk about issues, but meaning entirely different things. You gotta have shared language and shared understanding before you can go on to create the shared goals which are required to really be collaborating. In the compressed and rushed environment that we're working in it is easy to skip the part where we establish the shared language. It seems that underlying Joe posting this thread is an invitation to do the hard word of finding and formalizing some language so that we can use that to set some goals that we all share. -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
Joe Gordon wrote: I am starting this thread based on Thierry's feedback on [0]. Instead of writing the same thing twice, you can look at the rendered html from that patch [1]. Neutron tried to go from core to maintainer but after input from the TC and others, they are keeping the term 'core' but are clarifying what it means to be a neutron core [2]. [2] does a very good job of showing how what it means to be core is evolving. From everyone is a dev and everyone is a reviewer. No committers or repo owners, no aristocracy. Some people just commit to do a lot of reviewing and keep current with the code, and have votes that matter more (+2). (Theirry) To a system where cores are more then people who have votes that matter more. Neutron's proposal tries to align that document with what is already happening. 1. They share responsibility in the project's success. 2. They have made a long-term, recurring time investment to improve the project. 3. They spend their time doing what needs to be done to ensure the projects success, not necessarily what is the most interesting or fun. A bit of history is useful here. We used[1] to have 4 groups for each project, mostly driven by the need to put people in ACL groups. The PTL (which has ultimate control), the Drivers (the trusted group around the PTL which had control over blueprint targeting in Launchpad), the Core reviewers (which have +2 on the repos in Gerrit), and the bug team (which had special Launchpad bugs rights like the ability to confirm stuff). [1] https://wiki.openstack.org/wiki/Launchpad_Teams_and_Gerrit_Groups In that model, drivers is closer to what you describe for maintainers -- people invested 100% in the project success, and able to spend 95% of the work time to ensure it. My main objection to the model you propose is its binary nature. You bundle core reviewing duties with drivers duties into a single group. That simplification means that drivers have to be core reviewers, and that core reviewers have to be drivers. Sure, a lot of core reviewers are good candidates to become drivers. But I think bundling the two concepts excludes a lot of interesting people from being a driver. If someone steps up and owns bug triaging in a project, that is very interesting and I'd like that person to be part of the drivers group. That said, bug triaging (like core reviewing) is a full time job. You can't expect the person who owns bug triaging to commit to the level of reviewing that core reviewers commit to. It's also a different skillset. Saying core reviewers and maintainers are the same thing, you basically exclude people from stepping up to the project leadership unless they are code reviewers. I think that's a bad thing. We need more people volunteering to own bug triaging and liaison work, not less. So, in summary: * I'm not against reviving the concept of drivers * I'm against making core reviewing a requirement for drivers * I'm for recognizing other duties (like bug triaging or liaison work) as being key project leadership positions Hope this clarifies, -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
Joe Gordon wrote: On Tue, Mar 31, 2015 at 5:46 PM, Dean Troyer dtro...@gmail.com mailto:dtro...@gmail.com wrote: On Tue, Mar 31, 2015 at 5:30 PM, Joe Gordon joe.gord...@gmail.com mailto:joe.gord...@gmail.com wrote: Do you feel like a core deveper/reviewer (we initially called them core developers) [1]: In OpenStack a core developer is a developer who has submitted enough high quality code and done enough code reviews that we trust their code reviews for merging into the base source tree. It is important that we have a process for active developers to be added to the core developer team. Or a maintainer [1]: 1. They share responsibility in the project’s success. 2. They have made a long-term, recurring time investment to improve the project. 3. They spend that time doing whatever needs to be done, not necessarily what is the most interesting or fun. First, I don't think these two things are mutually exclusive, that's a false dichotomy. They sound like two groups of attributes (or roles), both of which must be earned in the eyes of the rest of the project team. Frankly, being a PTL is your maintainer list on steroids for some projects, except that the PTL is directly elected. +1000 Yes, these are not orthogonal ideas. The question should be rephrased to 'which description do you identify the most with: core developer/reviewer or maintainer?' - Some people are core reviewers and maintainers (or drivers, to reuse the openstack terminology we already have for that) - Some people are core reviewers only (because they can't commit 90% of their work time to work on project priorities) - Some people are maintainers/drivers only (because their project duties don't give them enough time to also do reviewing) - Some people are casual developers / reviewers (because they can't spend more than 30% of their day on project stuff) All those people are valuable. Simply renaming core reviewers to maintainers (creating a single super-developer class) just excludes valuable people. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
On Wed, Apr 01 2015, Joshua Harlow wrote: +1 to this. There will always be people who will want to work on fun stuff and those who don't; it's the job of leadership in the community to direct people if they can (but also the same job of that leadership to understand that they can't direct everyone; it is open-source after all and saying 'no' to people just makes them run to some other project that doesn't do this...). +1, and as a casual contributor to a lot of different projects in OpenStack, I think there is a lot of work to be done in that area. The leadership is too scarce and too rarely available in general and random people are discouraging others to contribute regularly with bad feedbacks. IMHO (and a rant probably better for another thread) but I've seen to many projects/specs/split-outs (ie, scheduler tweaks, constraint solving scheduler...) get abandoned because of cores saying this or that is the priority right now (and this in all honesty pisses me off); I don't feel this is right (cores should be leaders and guides, not dictators); if a core is going to tell anyone that then they better act as a guide to the person they are telling that to and make sure they lead that person they just told no; after all any child can say no but it takes a real man/woman to go the extra distance... +1 And I'm not sure it's completely orthogonal to this thread actually. It's sort of funny looking back over the years. We used to complain over and over that we don't have enough reviewers, and that reviewing is crucial but under appreciated work. Since then there's all sorts of people striving to spend time doing reviews and provide in some cases real constructive feedback. Now we seem to be saying reviewing isn't where it's at, anybody can do that; bug fixes is the new coolness. I think there are others way to address this by the way, possibly more effective ways. Heck, you could even do commit credits; it costs five bug fixes to the overall project before you can commit a feature (ok, don't take me seriously there). Maybe I'm misinterpreting some of this, maybe there's something in between. Regardless I personally need a good deal more detail before I form my opinion. The problem I see now, is that random people who has very little knowledge of $PROJECT or OpenStack as its whole jump in random review and put a -1 in Gerrit. And then never remove it. And then your patch is stuck for ever in review. Probably because we pushed people to review patches, because we needed review, etc. Personally this is hitting me back a lot and I'm getting more and more tired of that. How can you have people reviewing code when then never even wrote a patch on the project? I've _never_ used only review numbers to put people to core reviewer. We had people trying to play the game that way, but I don't think you can become a core reviewer any code if you never fixed a bug nor wrote a patch in a project. -- Julien Danjou // Free Software hacker // http://julien.danjou.info signature.asc Description: PGP signature __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
On 04/01/2015 05:41 AM, Thierry Carrez wrote: Joe Gordon wrote: I am starting this thread based on Thierry's feedback on [0]. Instead of writing the same thing twice, you can look at the rendered html from that patch [1]. Neutron tried to go from core to maintainer but after input from the TC and others, they are keeping the term 'core' but are clarifying what it means to be a neutron core [2]. [2] does a very good job of showing how what it means to be core is evolving. From everyone is a dev and everyone is a reviewer. No committers or repo owners, no aristocracy. Some people just commit to do a lot of reviewing and keep current with the code, and have votes that matter more (+2). (Theirry) To a system where cores are more then people who have votes that matter more. Neutron's proposal tries to align that document with what is already happening. 1. They share responsibility in the project's success. 2. They have made a long-term, recurring time investment to improve the project. 3. They spend their time doing what needs to be done to ensure the projects success, not necessarily what is the most interesting or fun. A bit of history is useful here. We used[1] to have 4 groups for each project, mostly driven by the need to put people in ACL groups. The PTL (which has ultimate control), the Drivers (the trusted group around the PTL which had control over blueprint targeting in Launchpad), the Core reviewers (which have +2 on the repos in Gerrit), and the bug team (which had special Launchpad bugs rights like the ability to confirm stuff). [1] https://wiki.openstack.org/wiki/Launchpad_Teams_and_Gerrit_Groups In that model, drivers is closer to what you describe for maintainers -- people invested 100% in the project success, and able to spend 95% of the work time to ensure it. My main objection to the model you propose is its binary nature. You bundle core reviewing duties with drivers duties into a single group. That simplification means that drivers have to be core reviewers, and that core reviewers have to be drivers. Sure, a lot of core reviewers are good candidates to become drivers. But I think bundling the two concepts excludes a lot of interesting people from being a driver. If someone steps up and owns bug triaging in a project, that is very interesting and I'd like that person to be part of the drivers group. That said, bug triaging (like core reviewing) is a full time job. You can't expect the person who owns bug triaging to commit to the level of reviewing that core reviewers commit to. It's also a different skillset. Saying core reviewers and maintainers are the same thing, you basically exclude people from stepping up to the project leadership unless they are code reviewers. I think that's a bad thing. We need more people volunteering to own bug triaging and liaison work, not less. So, in summary: * I'm not against reviving the concept of drivers * I'm against making core reviewing a requirement for drivers * I'm for recognizing other duties (like bug triaging or liaison work) as being key project leadership positions ++ __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
On 2015-04-01 11:41:29 +0200 (+0200), Thierry Carrez wrote: [...] We used[1] to have 4 groups for each project, mostly driven by the need to put people in ACL groups. The PTL (which has ultimate control), the Drivers (the trusted group around the PTL which had control over blueprint targeting in Launchpad), the Core reviewers (which have +2 on the repos in Gerrit), and the bug team (which had special Launchpad bugs rights like the ability to confirm stuff). [...] And here is the crux of the situation, which I think bears highlighting. These empowered groups are (or at least started out as) nothing more than an attempt to map responsibilities onto the ACLs available to our projects in the tools we use to do the work. Coming up with some new pie-in-the-sky model of leadership hierarchy is an interesting thought exercise, but many people in this discussion are losing sight of the fact that the model we have is determined to a great extent by the tools we use. Change the tools and you may change the model, but changing the model doesn't automatically change the tools to support it (and those proposing a new model need to pony up the resources to implement it in _reality_, not just in _thought_). Responsibilities not tied to specific controls in our tools do exist in abundance, but they tend to be more fluid and ad-hoc because in most cases there's been no need to wrap authorization/enforcement around them. What I worry is happening is that as a community we're enshrining the arbitrary constructs which we invented to be able to configure our tools sanely. I see this discussion as an attempt to recognize those other responsibilities as well, but worry that creation of additional unnecessary authorization/enforcement process will emerge as a solution and drive us further into pointless bureaucracy. -- Jeremy Stanley __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
On Wed, Apr 01 2015, Jeremy Stanley wrote: Responsibilities not tied to specific controls in our tools do exist in abundance, but they tend to be more fluid and ad-hoc because in most cases there's been no need to wrap authorization/enforcement around them. What I worry is happening is that as a community we're enshrining the arbitrary constructs which we invented to be able to configure our tools sanely. I see this discussion as an attempt to recognize those other responsibilities as well, but worry that creation of additional unnecessary authorization/enforcement process will emerge as a solution and drive us further into pointless bureaucracy. +1 We never used so fine grained ACLs in Ceilometer. If a person knows enough about the project, sounds responsible and is helping, then I'm giving him/her the rights to help the project. Which usually includes all the right so that person is not blocked by some ACL if he/she wants suddenly to give his/her advice on a piece of code or triage some bugs. I've never seen big mistakes, and we don't have a lot of unrecoverable mistakes. In the end I prefer to give forgiveness than permission. -- Julien Danjou /* Free Software hacker http://julien.danjou.info */ signature.asc Description: PGP signature __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
On 1 April 2015 at 10:04, Joshua Harlow harlo...@outlook.com wrote: +1 to this. There will always be people who will want to work on fun stuff and those who don't; it's the job of leadership in the community to direct people if they can (but also the same job of that leadership to understand that they can't direct everyone; it is open-source after all and saying 'no' to people just makes them run to some other project that doesn't do this...). IMHO (and a rant probably better for another thread) but I've seen to many projects/specs/split-outs (ie, scheduler tweaks, constraint solving scheduler...) get abandoned because of cores saying this or that is the priority right now (and this in all honesty pisses me off); I don't feel this is right (cores should be leaders and guides, not dictators); if a core is going to tell anyone that then they better act as a guide to the person they are telling that to and make sure they lead that person they just told no; after all any child can say no but it takes a real man/woman to go the extra distance... So I think saying no is sometimes a vital part of the core team's role, keeping up code quality and vision is really hard to do while new features are flooding in, and doing architectural reworking while features are merging is an epic task. There are also plenty of features that don't necessarily fit the shared vision of the project; just because we can do something doesn't mean we should. For example: there are plenty of companies trying to turn Openstack into a datacentre manager rather than a cloud (i.e. too much focus on pets .v. cattle style VMs), and I think we're right to push back against that. Right now there are some strong indications that there are areas we are very weak at (nova network still being preferred to neutron, the amount of difficultly people had establishing 3rd party CI setups for cinder) that really *should* be prioritised over new features. That said, some projects can be worked on successfully in parallel with the main development - I suspect that a scheduler split out proposal is one of them. This doesn't need much/any buy-in from cores, it can be demonstrated in a fairly complete state before it is evaluated, so the only buyi-in needed is on the concept. This is a common development mode in the kernel world too. -- Duncan Thomas __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
On Apr 1, 2015, at 3:52 AM, Thierry Carrez thie...@openstack.org wrote: Joe Gordon wrote: On Tue, Mar 31, 2015 at 5:46 PM, Dean Troyer dtro...@gmail.com mailto:dtro...@gmail.com wrote: On Tue, Mar 31, 2015 at 5:30 PM, Joe Gordon joe.gord...@gmail.com mailto:joe.gord...@gmail.com wrote: Do you feel like a core deveper/reviewer (we initially called them core developers) [1]: In OpenStack a core developer is a developer who has submitted enough high quality code and done enough code reviews that we trust their code reviews for merging into the base source tree. It is important that we have a process for active developers to be added to the core developer team. Or a maintainer [1]: 1. They share responsibility in the project’s success. 2. They have made a long-term, recurring time investment to improve the project. 3. They spend that time doing whatever needs to be done, not necessarily what is the most interesting or fun. First, I don't think these two things are mutually exclusive, that's a false dichotomy. They sound like two groups of attributes (or roles), both of which must be earned in the eyes of the rest of the project team. Frankly, being a PTL is your maintainer list on steroids for some projects, except that the PTL is directly elected. +1000 Yes, these are not orthogonal ideas. The question should be rephrased to 'which description do you identify the most with: core developer/reviewer or maintainer?' - Some people are core reviewers and maintainers (or drivers, to reuse the openstack terminology we already have for that) - Some people are core reviewers only (because they can't commit 90% of their work time to work on project priorities) - Some people are maintainers/drivers only (because their project duties don't give them enough time to also do reviewing) - Some people are casual developers / reviewers (because they can't spend more than 30% of their day on project stuff) That's a nice, concise list. I like that. All those people are valuable. Simply renaming core reviewers to maintainers (creating a single super-developer class) just excludes valuable people. I don't care about the name, but... It's been interesting to watch reactions to the naming thing, because some folks see maintainer as an upgrade, and some don't, and it's easy to tell what someone's reaction will be simply by the bias they're bringing to that word. I'd like to see in the text of any of the proposals where it actually advocates a super developer, because I'm not seeing it, and the constant repeating of this meme isn't helping. Thanks, doug -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
On 04/01/2015 12:31 PM, Duncan Thomas wrote: On 1 April 2015 at 10:04, Joshua Harlow harlo...@outlook.com mailto:harlo...@outlook.com wrote: +1 to this. There will always be people who will want to work on fun stuff and those who don't; it's the job of leadership in the community to direct people if they can (but also the same job of that leadership to understand that they can't direct everyone; it is open-source after all and saying 'no' to people just makes them run to some other project that doesn't do this...). IMHO (and a rant probably better for another thread) but I've seen to many projects/specs/split-outs (ie, scheduler tweaks, constraint solving scheduler...) get abandoned because of cores saying this or that is the priority right now (and this in all honesty pisses me off); I don't feel this is right (cores should be leaders and guides, not dictators); if a core is going to tell anyone that then they better act as a guide to the person they are telling that to and make sure they lead that person they just told no; after all any child can say no but it takes a real man/woman to go the extra distance... So I think saying no is sometimes a vital part of the core team's role, keeping up code quality and vision is really hard to do while new features are flooding in, and doing architectural reworking while features are merging is an epic task. There are also plenty of features that don't necessarily fit the shared vision of the project; just because we can do something doesn't mean we should. For example: there are plenty of companies trying to turn Openstack into a datacentre manager rather than a cloud (i.e. too much focus on pets .v. cattle style VMs), and I think we're right to push back against that. Amen to the above. All of it. Right now there are some strong indications that there are areas we are very weak at (nova network still being preferred to neutron, the amount of difficultly people had establishing 3rd party CI setups for cinder) that really *should* be prioritised over new features. That said, some projects can be worked on successfully in parallel with the main development - I suspect that a scheduler split out proposal is one of them. This doesn't need much/any buy-in from cores, it can be demonstrated in a fairly complete state before it is evaluated, so the only buyi-in needed is on the concept. Ha, I had to laugh at this last paragraph :) You mention the fact that nova-network is still very much in use in the paragraph above (for good reasons that have been highlighted in other threads). And yet you then go on to suspect that a nova-scheduler split would something that would be successfully worked on in parallel... The Gantt project tried and failed to split the Nova scheduler out (before it had any public or versioned interfaces). The solver scheduler has not gotten any traction not because as Josh says some cores are acting like dictators but because it doesn't solve the right problem: it makes more complex scheduling placement decisions in a different way from the Nova scheduler, but it doesn't solve the distributed scale problems in the Nova scheduler architecture. If somebody developed an external generic resource placement engine that scaled in a distributed, horizontal fashion and that had well-documented public interfaces, I'd welcome that work and quickly work to add a driver for it inside Nova. But both Gantt and the solver scheduler fall victim to the same problem: trying to use the existing Nova scheduler architecture when it's flat-out not scalable. Alright, now that I've said that, I'll wait here for the inevitable complaints that as a Nova core, I'm being a dictator because I speak my mind about major architectural issues I see in proposals. Best, -jay __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
On 04/02/2015 09:02 AM, Jeremy Stanley wrote: but since parties who don't understand our mostly non-hierarchical community can see those sets of access controls, they cling to them as a sign of importance and hierarchy of the people listed within. There is no hierarchy for submitting code -- that is good. We all know situations in a traditional company where people say that's foo's area, we don't work on that. Once code is submitted, there *is* a hierarchy. The only way something gets merged in OpenStack is by Brownian motion of this hierarchy. These special cores float around and as a contributor you just hope that two of them meet up and decide your change is ready. You have zero insight into when this might happen, if at all. The efficiency is appalling but somehow we get there in the end. IMO requiring two cores to approve *every* change is too much. What we should do is move the responsibility downwards. Currently, as a contributor I am only 1/3 responsible for my change making it through. I write it, test it, clean it up and contribute it; then require the extra 2/3 to come from the hierarchy. If you only need one core, then core and myself share the responsibility for the change. In my mind, this better recognises the skill of the contributor -- we are essentially saying we trust you. People involved in openstack are not idiots. If a change is controversial, or a reviewer isn't confident, they can and will ask for assistance or second opinions. This isn't a two-person-key system in a nuclear missile silo; we can always revert. If you want cores to be less special then talking about it or calling them something else doesn't help -- the only way is to make them actually less special. -i __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
On 04/01/2015 03:23 AM, Julien Danjou wrote: The problem I see now, is that random people who has very little knowledge of $PROJECT or OpenStack as its whole jump in random review and put a -1 in Gerrit. And then never remove it. And then your patch is stuck for ever in review. Probably because we pushed people to review patches, because we needed review, etc. Personally this is hitting me back a lot and I'm getting more and more tired of that. How can you have people reviewing code when then never even wrote a patch on the project? We encourage people to do code reviews as a way to get involved in the project, to learn about the code base, to learn from the core reviewer team. We encourage people to do bug fixing and commit useful patches in the same way. If the core team won't take the time to help new contributors participate in the project, that is a problem with the core team members. If you don't like someone's review feedback, tell them. Teach them and guide them to more productive contributions. If you don't speak up, you cannot expect the person to change their actions. I've _never_ used only review numbers to put people to core reviewer. We had people trying to play the game that way, but I don't think you can become a core reviewer any code if you never fixed a bug nor wrote a patch in a project. Show me a single person that is in a core team or that has been nominated for a core team that never pushed a patch or fixed a bug in the project. Best, -jay __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/01/2015 06:31 PM, Duncan Thomas wrote: Right now there are some strong indications that there are areas we are very weak at (nova network still being preferred to neutron I don't think it's correct. As per latest summit survey [1], nova-network was used by 30% of production sites, while other setups are neutron based. [1]: http://superuser.openstack.org/articles/openstack-user-survey-insights-november-2014 /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJVHCEmAAoJEC5aWaUY1u57JAgIANi8w8w7GUtpWji+VywxKET0 /fFTQEZdhRhmba36fZ8CTGcUNX0yRmjrSV5RXa5UjGQIEJ9G6bI2KYIVWCBSc+xq 01H/D6JFuHfPYT7b1XoCUw4KYEH7KYA+FzjsRLLAMbVesljuCyjcn9ukCdP6r2Ze IiL18+CBwHeF3buSjEvWPhxi0pygpcKDSD6t/3hXhGcBIFd88I+l9EGvu2+j3H7Y gfpjyUNrrGlwRUnnR8AoN1T6gtOfHRKG6m07z+4DxYclNBL1KnkTMRCFprmnE82l yUT50fnztnnKhKqi0+jjCx7eww4g2U2tm0F1/83VJQVMjbcrpP5EZpUpRP5jHfM= =DJW6 -END PGP SIGNATURE- __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
Julien Danjou wrote: On Wed, Apr 01 2015, Jeremy Stanley wrote: Responsibilities not tied to specific controls in our tools do exist in abundance, but they tend to be more fluid and ad-hoc because in most cases there's been no need to wrap authorization/enforcement around them. What I worry is happening is that as a community we're enshrining the arbitrary constructs which we invented to be able to configure our tools sanely. I see this discussion as an attempt to recognize those other responsibilities as well, but worry that creation of additional unnecessary authorization/enforcement process will emerge as a solution and drive us further into pointless bureaucracy. +1 We never used so fine grained ACLs in Ceilometer. If a person knows enough about the project, sounds responsible and is helping, then I'm giving him/her the rights to help the project. Which usually includes all the right so that person is not blocked by some ACL if he/she wants suddenly to give his/her advice on a piece of code or triage some bugs. I've never seen big mistakes, and we don't have a lot of unrecoverable mistakes. In the end I prefer to give forgiveness than permission. +1 Thank you thank you thank you for being a good/decent human :) (I also prefer to do the same...) __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
Duncan Thomas wrote: On 1 April 2015 at 10:04, Joshua Harlow harlo...@outlook.com mailto:harlo...@outlook.com wrote: +1 to this. There will always be people who will want to work on fun stuff and those who don't; it's the job of leadership in the community to direct people if they can (but also the same job of that leadership to understand that they can't direct everyone; it is open-source after all and saying 'no' to people just makes them run to some other project that doesn't do this...). IMHO (and a rant probably better for another thread) but I've seen to many projects/specs/split-outs (ie, scheduler tweaks, constraint solving scheduler...) get abandoned because of cores saying this or that is the priority right now (and this in all honesty pisses me off); I don't feel this is right (cores should be leaders and guides, not dictators); if a core is going to tell anyone that then they better act as a guide to the person they are telling that to and make sure they lead that person they just told no; after all any child can say no but it takes a real man/woman to go the extra distance... So I think saying no is sometimes a vital part of the core team's role, keeping up code quality and vision is really hard to do while new features are flooding in, and doing architectural reworking while features are merging is an epic task. There are also plenty of features that don't necessarily fit the shared vision of the project; just because we can do something doesn't mean we should. For example: there are plenty of companies trying to turn Openstack into a datacentre manager rather than a cloud (i.e. too much focus on pets .v. cattle style VMs), and I think we're right to push back against that. Sure say 'no' but guide the person u just told to that to in a way that gets them to work on something that both of you find useful; just saying no and to 'shove off' (for lack of a better saying) IMHO isn't the right thing to do. It should IMHO be the responsibility of the person saying 'no' to someone else (I guess this is the core team?) to man up and guide the person they said 'no' to (and not the other way around). I don't feel like this has happened though (but maybe I'm to much in my own little world). Right now there are some strong indications that there are areas we are very weak at (nova network still being preferred to neutron, the amount of difficultly people had establishing 3rd party CI setups for cinder) that really *should* be prioritised over new features. Sure; I'm not gonna associate blame; but I feel like something hasn't worked out right and I start to look at the TC for some of this, bu I'm not gonna go much deeper into this since blame is a bad thing to try to place (and doesn't really help make anything better)... That said, some projects can be worked on successfully in parallel with the main development - I suspect that a scheduler split out proposal is one of them. This doesn't need much/any buy-in from cores, it can be demonstrated in a fairly complete state before it is evaluated, so the only buyi-in needed is on the concept. This is a common development mode in the kernel world too. Agreed. -- Duncan Thomas __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
On Wed, Apr 1, 2015 at 2:41 AM, Thierry Carrez thie...@openstack.org wrote: Joe Gordon wrote: I am starting this thread based on Thierry's feedback on [0]. Instead of writing the same thing twice, you can look at the rendered html from that patch [1]. Neutron tried to go from core to maintainer but after input from the TC and others, they are keeping the term 'core' but are clarifying what it means to be a neutron core [2]. [2] does a very good job of showing how what it means to be core is evolving. From everyone is a dev and everyone is a reviewer. No committers or repo owners, no aristocracy. Some people just commit to do a lot of reviewing and keep current with the code, and have votes that matter more (+2). (Theirry) To a system where cores are more then people who have votes that matter more. Neutron's proposal tries to align that document with what is already happening. 1. They share responsibility in the project's success. 2. They have made a long-term, recurring time investment to improve the project. 3. They spend their time doing what needs to be done to ensure the projects success, not necessarily what is the most interesting or fun. A bit of history is useful here. We used[1] to have 4 groups for each project, mostly driven by the need to put people in ACL groups. The PTL (which has ultimate control), the Drivers (the trusted group around the PTL which had control over blueprint targeting in Launchpad), the Core reviewers (which have +2 on the repos in Gerrit), and the bug team (which had special Launchpad bugs rights like the ability to confirm stuff). [1] https://wiki.openstack.org/wiki/Launchpad_Teams_and_Gerrit_Groups In that model, drivers is closer to what you describe for maintainers -- people invested 100% in the project success, and able to spend 95% of the work time to ensure it. I am having a hard time aligning your description to what we have today. This comparison misses what IMHO is the most important parts of the maintainers model, subsystem maintainers. Maintaining a subsystem doesn't need to be a full time job. My main objection to the model you propose is its binary nature. You bundle core reviewing duties with drivers duties into a single group. That simplification means that drivers have to be core reviewers, and that core reviewers have to be drivers. Sure, a lot of core reviewers are good candidates to become drivers. But I think bundling the two concepts excludes a lot of interesting people from being a driver. I cannot speak for all projects, but at least in Nova you have to be a nova-core to be part of nova-drivers. If someone steps up and owns bug triaging in a project, that is very interesting and I'd like that person to be part of the drivers group. In our current model, not sure why they would need to be part of drivers. the bug triage group is open to anyone. That said, bug triaging (like core reviewing) is a full time job. You can't expect the person who owns bug triaging to commit to the level of reviewing that core reviewers commit to. It's also a different skillset. Saying core reviewers and maintainers are the same thing, you basically I don't want to make it harder for people to feel empowered to help, I want to make it easier. exclude people from stepping up to the project leadership unless they are code reviewers. I think that's a bad thing. We need more people volunteering to own bug triaging and liaison work, not less. I don't agree with this statement, I am not saying reviewing and maintenance need to be tightly coupled. Why do we review code? http://docs.openstack.org/infra/manual/developers.html#code-review gives a incomplete list of what we are looking for. But I think it boils down two two general components: * Does the change make sense in the context of the project? * Does the patch pass our code quality requirements (testing, pythonic, formatting, commit message, logging etc.)? If someone doesn't have a good grasp of the code they are trying to maintain they won't be able to review if the patch makes sense or not. In this case, yes you really cannot be responsible for a piece of code if you don't understand it -- but we have this constraint today. As for the second aspect of reviewing, this has a lot less to do with what the patch is doing and instead how it is doing it. There is no reason reviews for code quality need to be coupled with anything else. I think our idea of combining two separate review criteria into a single review (and ACL) is making things more confusing. So, in summary: * I'm not against reviving the concept of drivers * I'm against making core reviewing a requirement for drivers * I'm for recognizing other duties (like bug triaging or liaison work) as being key project leadership positions Hope this clarifies, I really want to know what you meant be 'no aristocracy' and the
Re: [openstack-dev] The Evolution of core developer to maintainer?
On Apr 1, 2015, at 6:09 AM, Jeremy Stanley fu...@yuggoth.org wrote: And here is the crux of the situation, which I think bears highlighting. These empowered groups are (or at least started out as) nothing more than an attempt to map responsibilities onto the ACLs available to our projects in the tools we use to do the work. Coming up with some new pie-in-the-sky model of leadership hierarchy is an interesting thought exercise, but many people in this discussion are losing sight of the fact that the model we have is determined to a great extent by the tools we use. Change the tools and you may change the model, but changing the model doesn't automatically change the tools to support it (and those proposing a new model need to pony up the resources to implement it in _reality_, not just in _thought_). Responsibilities not tied to specific controls in our tools do exist in abundance, but they tend to be more fluid and ad-hoc because in most cases there's been no need to wrap authorization/enforcement around them. What I worry is happening is that as a community we're enshrining the arbitrary constructs which we invented to be able to configure our tools sanely. I see this discussion as an attempt to recognize those other responsibilities as well, but worry that creation of additional unnecessary authorization/enforcement process will emerge as a solution and drive us further into pointless bureaucracy. Given how important trust and relationships are to the functioning of individual projects, I think we’re past the point where we should allow our tooling to be the limiting factor in how we structure ourselves. Do we need finer-grained permissions in gerrit to enable something like subtree maintainers? I don't believe we do. In large projects like Neutron, there is no such thing as someone who knows everything anymore, so we all need to be aware of our limitations and know not to merge things we don't understand without oversight from those of our peers that do. Responsibility in this case could be subject to social rather than tool-based oversight. Maru __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
On 1 April 2015 at 12:52, Thierry Carrez thie...@openstack.org wrote: Yes, these are not orthogonal ideas. The question should be rephrased to 'which description do you identify the most with: core developer/reviewer or maintainer?' - Some people are core reviewers and maintainers (or drivers, to reuse the openstack terminology we already have for that) - Some people are core reviewers only (because they can't commit 90% of their work time to work on project priorities) - Some people are maintainers/drivers only (because their project duties don't give them enough time to also do reviewing) - Some people are casual developers / reviewers (because they can't spend more than 30% of their day on project stuff) All those people are valuable. Simply renaming core reviewers to maintainers (creating a single super-developer class) just excludes valuable people. Ok, I'd misunderstood the proposal further up the thread when I replied before. This sounds eminently sensible. There's certainly no hard at all in recognising large contributions other than reviews, and bug triage is almost becoming as large a job at various points in the cycle. -- Duncan Thomas __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
On Apr 1, 2015, at 1:47 PM, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-04-01 12:00:53 -0700 (-0700), Maru Newby wrote: Given how important trust and relationships are to the functioning of individual projects, I think we’re past the point where we should allow our tooling to be the limiting factor in how we structure ourselves. I'm definitely not suggesting that either, merely pointing out that if you have an ACL which, for example, defines the set of people able to push a particular button then it's helpful to have a term for that set of people. As soon as you start to conflate that specific permission with other roles and responsibilities then the term for it gets overloaded. To me a core reviewer is just that: people with accounts in the .*-core Gerrit groups granted the ability to push a review button indicating that a proposed change is suitable to merge. Whether or not those same people are also afforded permissions outside that system is orthogonal. I find your perspective on the term ‘core reviewer’ to be interesting indeed, and for me it underscores the need to consider whether using the term outside of gerrit is justified. Maru __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
On 2015-04-01 14:35:22 -0700 (-0700), Maru Newby wrote: I find your perspective on the term ‘core reviewer’ to be interesting indeed, and for me it underscores the need to consider whether using the term outside of gerrit is justified. Agreed, that's why I said I'm worried that our community is enshrining an implementation detail, and ascribing something more to it than is warranted. Many of the people who have access to mark changes as ready to merge also do bug triage or undertake thankless refactoring of the code commons or set development priorities or write documentation or translate strings or... these are all valuable contributions within the community. Some of these require access to specific controls in our tools granted based on the trust of the community, while others do not, and many of us do more than just one of these things at a time too. There are certainly some nuanced relationships between various tasks, and how our community self-organizes determines some of this. However I'm not sure codifying it and wrapping those relationships in process and policy is always beneficial. I really just wanted to warn against the temptation I've seen for people to confuse the work being done (which is valuable) for the permissions needed to safely do some of that work (which is merely an implementation detail). Work which can be done without needing special permission is not necessarily any less valuable than that which requires addition to some access control; but since parties who don't understand our mostly non-hierarchical community can see those sets of access controls, they cling to them as a sign of importance and hierarchy of the people listed within. -- Jeremy Stanley __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
On Apr 1, 2015, at 2:52 AM, Thierry Carrez thie...@openstack.org wrote: - Some people are core reviewers and maintainers (or drivers, to reuse the openstack terminology we already have for that) - Some people are core reviewers only (because they can't commit 90% of their work time to work on project priorities) - Some people are maintainers/drivers only (because their project duties don't give them enough time to also do reviewing) - Some people are casual developers / reviewers (because they can't spend more than 30% of their day on project stuff) All those people are valuable. Simply renaming core reviewers to maintainers (creating a single super-developer class) just excludes valuable people. I hear that you believe that the proposal to rename 'core reviewer' to 'maintainer' in Neutron was intended to entrench privilege. Nothing could be further from the truth - it was actually intended to break it down. As per Joe’s recent reply, ‘drivers’ in Nova have to be core reviewers. This is true in Neutron as well. I think a more accurate taxonomy, at least in Neutron, is the following: - Everyone that participates in the project is a 'contributor' - Some contributors are 'core reviewers' - members of the team with merge rights on a primary repo and a responsibility to actively review for that repo. - Some core reviewers are 'drivers' - members of a team with merge rights on the spec repo and a responsibility to actively review for that repo. This is obviously a gross simplification, but it should serve for what I'm trying to communicate. Many of us in the Neutron community find this taxonomy restrictive and not representative of all the work that makes the project possible. Worse, 'cores' are put on a pedastal, and not just in the project. Every summit a 'core reviewer dinner' is held that underscores the glorification of this designation. By proposing to rename 'core reviewer' to 'maintainer' the goal was to lay the groundwork for broadening the base of people whose valuable contribution could be recognized. The goal was to recognize not just review-related contributors, but also roles like doc/bug/test czar and cross-project liaison. The statue of the people filling these roles today is less if they are not also ‘core’, and that makes the work less attractive to many. Given the TC's apparent mandate to define the organizational taxonomy that a project like Neutron is allowed to use, I would ask you and your fellow committee members to consider addressing the role that the current taxonomy plays in valuing reviewing ahead of other forms of contribution. It provides disincentive against other forms of contribution, since they aren’t recognized on an equal footing, and I think this needs to change if we want to ensure the long-term viability of projects like Neutron (if not OpenStack as a whole). Maru __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
On 2015-04-01 12:00:53 -0700 (-0700), Maru Newby wrote: Given how important trust and relationships are to the functioning of individual projects, I think we’re past the point where we should allow our tooling to be the limiting factor in how we structure ourselves. I'm definitely not suggesting that either, merely pointing out that if you have an ACL which, for example, defines the set of people able to push a particular button then it's helpful to have a term for that set of people. As soon as you start to conflate that specific permission with other roles and responsibilities then the term for it gets overloaded. To me a core reviewer is just that: people with accounts in the .*-core Gerrit groups granted the ability to push a review button indicating that a proposed change is suitable to merge. Whether or not those same people are also afforded permissions outside that system is orthogonal. Do we need finer-grained permissions in gerrit to enable something like subtree maintainers? I don't believe we do. In large projects like Neutron, there is no such thing as someone who knows everything anymore, so we all need to be aware of our limitations and know not to merge things we don't understand without oversight from those of our peers that do. Responsibility in this case could be subject to social rather than tool-based oversight. Right, there's nothing stopping you from doing this now. A lot of our project teams already operate in the way you're describing. -- Jeremy Stanley __ 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
Re: [openstack-dev] The Evolution of core developer to maintainer?
On 03/31/2015 08:46 PM, Dean Troyer wrote: On Tue, Mar 31, 2015 at 5:30 PM, Joe Gordon joe.gord...@gmail.com wrote: Do you feel like a core deveper/reviewer (we initially called them core developers) [1]: In OpenStack a core developer is a developer who has submitted enough high quality code and done enough code reviews that we trust their code reviews for merging into the base source tree. It is important that we have a process for active developers to be added to the core developer team. Or a maintainer [1]: 1. They share responsibility in the project’s success. 2. They have made a long-term, recurring time investment to improve the project. 3. They spend that time doing whatever needs to be done, not necessarily what is the most interesting or fun. First, I don't think these two things are mutually exclusive, that's a false dichotomy. They sound like two groups of attributes (or roles), both of which must be earned in the eyes of the rest of the project team. Frankly, being a PTL is your maintainer list on steroids for some projects, except that the PTL is directly elected. Maintainers are often under-appreciated, because their work is harder to appreciate. It’s easy to appreciate a really cool and technically advanced feature. It’s harder to appreciate the absence of bugs, the slow but steady improvement in stability, or the reliability of a release process. But those things distinguish a good project from a great one. The best maintainers appear to be invisible because stuff Just Works(TM). It feels to me like a couple of things are being conflated here and need to be explicitly stated to break the conversation down into meaningful parts that can be discussed without getting side-tracked: a) How do we scale? How do we spread the project management load? How do we maintain consistency in subteams/subsystems? b) How do we avoid the 'aristoctacy'? c) what did I miss? Taking b) first, the problem being solved needs to be stated. Is it to avoid 'cliques'? Are feelings being hurt because some are 'more-core' than others? Is it to remove being a core team member as a job-review checkbox for some companies? This seems to be bigger than just increasing core reviewer numbers, and tied to some developers being slighted in some way. A) is an organization structure problem. We're seeing the boundaries of startup-style flat organization, and I think we all know we don't want traditional enterprise layers of managers. It seems like there is a progression of advancement for team members: prove yourself and become a core team member/reviewer/whatever. The next step is what I think you want to formalize Joe, and that is those who again prove themselves in some manner to unlock the 'maintainer' achievements. The idea of taking the current becoming-core-team process and repeating it based on existing cores and PTL recommendations doesn't seem like too far of a stretch. I mean really, is any project holding back people who want to do the maintainer role on more than just one pet part of a project? (I know those exist) FWIW, I have not been deeply involved in any of the highly political/vendor-driven projects so this may appear totally ignorant to those realities, but I think that is a clue that those projects are drifting away from the ideals that OpenStack was started with. dt I agree with a lot of what both John and Doug have said so far in their replies to this post but I'll add my thoughts to Dean's post because it happens to be open. I am really having a problem with a lack of common vision. Now this may just be my problem here, and if it is, that is fine, I'll own that. I had a long talk with Monty today about vision and whether or not OpenStack had a common vision once and either lost it or is drifting away from it or never had one in the first place. I won't put words into other people's mouths, so I'll just stick to my own perspective here. I have been operating with the belief that OpenStack did have a common vision, and stated or not stated, it was clear enough to me that I took from it a sense of direction in my activities, what to work on, what was important, what furthered and supported OpenStack. I'm really feeling lost here because I don't feel that anymore. It is possible that it never existed in the first place and I was operating within my own bubble and this actually is the reality. Okay fine, if that is the way it is, that is my problem to deal with. But other folks, as Dean mentions above, do indicate in their language that they feel something was present at one point and is either gone now or is in danger of going. I don't know exactly what to call it but it goes along with the unanswered question Anne Gentle posed to the TC a month or so back which paraphrased was along the line of 'How do we create trust?'. I think I felt trust before and I recognize that on a daily basis I don't now, that
Re: [openstack-dev] The Evolution of core developer to maintainer?
On Tue, Mar 31, 2015 at 5:24 PM, John Griffith john.griffi...@gmail.com wrote: On Tue, Mar 31, 2015 at 4:30 PM, Joe Gordon joe.gord...@gmail.com wrote: I am starting this thread based on Thierry's feedback on [0]. Instead of writing the same thing twice, you can look at the rendered html from that patch [1]. Neutron tried to go from core to maintainer but after input from the TC and others, they are keeping the term 'core' but are clarifying what it means to be a neutron core [2]. [2] does a very good job of showing how what it means to be core is evolving. From everyone is a dev and everyone is a reviewer. No committers or repo owners, no aristocracy. Some people just commit to do a lot of reviewing and keep current with the code, and have votes that matter more (+2). (Theirry) To a system where cores are more then people who have votes that matter more. Neutron's proposal tries to align that document with what is already happening. 1. They share responsibility in the project's success. 2. They have made a long-term, recurring time investment to improve the project. 3. They spend their time doing what needs to be done to ensure the projects success, not necessarily what is the most interesting or fun. I think there are a few issues at the heart of this debate: 1. Our current concept of a core team has never been able to grow past 20 or so people, even for really big projects like nova and cinder. Why is that? How do we delegate responsibility for subsystems? How do we keep growing? 2. If everyone is just developers and reviewers who is actually responsible for the projects success? How does that mesh with the ideal of no 'aristocracy'? Do are early goals still make sense today? Do you feel like a core deveper/reviewer (we initially called them core developers) [1]: In OpenStack a core developer is a developer who has submitted enough high quality code and done enough code reviews that we trust their code reviews for merging into the base source tree. It is important that we have a process for active developers to be added to the core developer team. Or a maintainer [1]: 1. They share responsibility in the project’s success. 2. They have made a long-term, recurring time investment to improve the project. 3. They spend that time doing whatever needs to be done, not necessarily what is the most interesting or fun. Maintainers are often under-appreciated, because their work is harder to appreciate. It’s easy to appreciate a really cool and technically advanced feature. It’s harder to appreciate the absence of bugs, the slow but steady improvement in stability, or the reliability of a release process. But those things distinguish a good project from a great one. [0] https://review.openstack.org/#/c/163660/ [1] http://docs-draft.openstack.org/60/163660/3/check/gate-governance-docs/f386acf//doc/build/html/resolutions/20150311-rename-core-to-maintainers.html [2] https://review.openstack.org/#/c/164208/ __ 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 Hey Joe, I mentioned in last weeks TC meeting that I didn't really see a burning need to change or create new labels; but that's probably beside the point. So if I read this it really comes down to a number of people in the community want core to mean something more than special reviewer is that right? I mean regardless of whether you change the name from core to maintainer I really don't care. If it makes some folks feel better to have that title/label associated with themselves that's cool by me (yes I get the *extra* responsibilities part you lined out). As Doug said in his response, for many projects this is about trying to make the definition of what is expected from a core reflect reality. What is missing for me here however is who picks these special people. I'm convinced that this does more to promote the idea of special contributors than anything else. Maybe that's actually what you want, but it seemed based on your message that wasn't the case. correct, I would like to see the opposite. I think we need to empower and trust more people with more then just the standard +1 vote. Anyway, core nominations are fairly objective in my opinion and is *mostly* based on number of reviews and perceived quality of those reviews (measured somewhat by disagreement rates etc). What are the metrics for this special group of folks that you're proposing we empower and title as maintainers? Do I get to be a maintainer, is it reserved for a special group of people, a specific company? What's the criteria? Do *you* get to be a maintainer? Long term I see two levels of maintainers. General maintainers and subsystem maintainers. Both
Re: [openstack-dev] The Evolution of core developer to maintainer?
On Tue, Mar 31, 2015 at 5:46 PM, Dean Troyer dtro...@gmail.com wrote: On Tue, Mar 31, 2015 at 5:30 PM, Joe Gordon joe.gord...@gmail.com wrote: Do you feel like a core deveper/reviewer (we initially called them core developers) [1]: In OpenStack a core developer is a developer who has submitted enough high quality code and done enough code reviews that we trust their code reviews for merging into the base source tree. It is important that we have a process for active developers to be added to the core developer team. Or a maintainer [1]: 1. They share responsibility in the project’s success. 2. They have made a long-term, recurring time investment to improve the project. 3. They spend that time doing whatever needs to be done, not necessarily what is the most interesting or fun. First, I don't think these two things are mutually exclusive, that's a false dichotomy. They sound like two groups of attributes (or roles), both of which must be earned in the eyes of the rest of the project team. Frankly, being a PTL is your maintainer list on steroids for some projects, except that the PTL is directly elected. Yes, these are not orthogonal ideas. The question should be rephrased to 'which description do you identify the most with: core developer/reviewer or maintainer?' P.S. if you read the linked spec, you will see the maintainer definition is straight from docker. Maintainers are often under-appreciated, because their work is harder to appreciate. It’s easy to appreciate a really cool and technically advanced feature. It’s harder to appreciate the absence of bugs, the slow but steady improvement in stability, or the reliability of a release process. But those things distinguish a good project from a great one. The best maintainers appear to be invisible because stuff Just Works(TM). It feels to me like a couple of things are being conflated here and need to be explicitly stated to break the conversation down into meaningful parts that can be discussed without getting side-tracked: a) How do we scale? How do we spread the project management load? How do we maintain consistency in subteams/subsystems? b) How do we avoid the 'aristoctacy'? c) what did I miss? Well said. Taking b) first, the problem being solved needs to be stated. Is it to avoid 'cliques'? Are feelings being hurt because some are 'more-core' than others? Is it to remove being a core team member as a job-review checkbox for some companies? This seems to be bigger than just increasing core reviewer numbers, and tied to some developers being slighted in some way. I am honestly not actually clear on what this one really means. I think this originates from some of the oral history of OpenStack. As Thierry's said No committers or repo owners, no aristocracy, I think this is related to OpenStack's notion of a flat core team where members of the core team was supposed to be fungible, and all trust each other. I don't think this is about removing being a core from a job review checkbox, this may be about inter company/team politics? Not really sure though. A) is an organization structure problem. We're seeing the boundaries of startup-style flat organization, and I think we all know we don't want traditional enterprise layers of managers. Yes, well said we are seeing the boundaries of the flat style origination in many of the larger projects. It seems like there is a progression of advancement for team members: prove yourself and become a core team member/reviewer/whatever. The next step is what I think you want to formalize Joe, and that is those who again prove themselves in some manner to unlock the 'maintainer' achievements. Two comments 1. Yes, I think we need to clarify the next step once you prove yourself. This is exactly what neutron is doing in there patch. 2. There is a really big second part to this, which is figure a way to scale the 'core teams' beyond that magical size of 20 people. See more below. The idea of taking the current becoming-core-team process and repeating it based on existing cores and PTL recommendations doesn't seem like too far of a stretch. I mean really, is any project holding back people who want to do the maintainer role on more than just one pet part of a project? (I know those exist) I am more concerned about empowering people with the inverse desire. Empower people who are interested in one subsection of a project to be empowered to help maintain that piece and share some of the review/maintenance burden. Take the nova db for example. Pulling the nova db out into its own repo is a lot more pain then its worth, but there are definitely people who are just interested in making sure nova's DB calls are performant. Today these people can review the code, but ultimately two cores are needed to review the code, making it hard for people to feel empowered to own/maintain that code. FWIW, I have not been deeply involved
Re: [openstack-dev] The Evolution of core developer to maintainer?
On Mar 31, 2015, at 6:24 PM, John Griffith john.griffi...@gmail.com wrote: On Tue, Mar 31, 2015 at 4:30 PM, Joe Gordon joe.gord...@gmail.com mailto:joe.gord...@gmail.com wrote: I am starting this thread based on Thierry's feedback on [0]. Instead of writing the same thing twice, you can look at the rendered html from that patch [1]. Neutron tried to go from core to maintainer but after input from the TC and others, they are keeping the term 'core' but are clarifying what it means to be a neutron core [2]. [2] does a very good job of showing how what it means to be core is evolving. From everyone is a dev and everyone is a reviewer. No committers or repo owners, no aristocracy. Some people just commit to do a lot of reviewing and keep current with the code, and have votes that matter more (+2). (Theirry) To a system where cores are more then people who have votes that matter more. Neutron's proposal tries to align that document with what is already happening. 1. They share responsibility in the project's success. 2. They have made a long-term, recurring time investment to improve the project. 3. They spend their time doing what needs to be done to ensure the projects success, not necessarily what is the most interesting or fun. I think there are a few issues at the heart of this debate: 1. Our current concept of a core team has never been able to grow past 20 or so people, even for really big projects like nova and cinder. Why is that? How do we delegate responsibility for subsystems? How do we keep growing? 2. If everyone is just developers and reviewers who is actually responsible for the projects success? How does that mesh with the ideal of no 'aristocracy'? Do are early goals still make sense today? Do you feel like a core deveper/reviewer (we initially called them core developers) [1]: In OpenStack a core developer is a developer who has submitted enough high quality code and done enough code reviews that we trust their code reviews for merging into the base source tree. It is important that we have a process for active developers to be added to the core developer team. Or a maintainer [1]: 1. They share responsibility in the project’s success. 2. They have made a long-term, recurring time investment to improve the project. 3. They spend that time doing whatever needs to be done, not necessarily what is the most interesting or fun. Maintainers are often under-appreciated, because their work is harder to appreciate. It’s easy to appreciate a really cool and technically advanced feature. It’s harder to appreciate the absence of bugs, the slow but steady improvement in stability, or the reliability of a release process. But those things distinguish a good project from a great one. [0] https://review.openstack.org/#/c/163660/ https://review.openstack.org/#/c/163660/ [1] http://docs-draft.openstack.org/60/163660/3/check/gate-governance-docs/f386acf//doc/build/html/resolutions/20150311-rename-core-to-maintainers.html http://docs-draft.openstack.org/60/163660/3/check/gate-governance-docs/f386acf//doc/build/html/resolutions/20150311-rename-core-to-maintainers.html [2] https://review.openstack.org/#/c/164208/ https://review.openstack.org/#/c/164208/ __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org/?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Hey Joe, I mentioned in last weeks TC meeting that I didn't really see a burning need to change or create new labels; but that's probably beside the point. So if I read this it really comes down to a number of people in the community want core to mean something more than special reviewer is that right? I mean Just my $0.02, but I think the intent is the exact opposite. Core reviewers already tend to be doing more than just reviewing. Maybe it’s a simple by-product of the review expertise translating into faster triage, or the relationships developed with other cores making maintenance tasks easier, or an indication that the folks with that much time just end up tending to be cores also, but regardless, the cores in a project end up being more than just reviewers. Which, again, could be coincidence more than title. The intent, as I understand it, is simply to attempt document what’s already going on, in preparation to *split* those responsibilities more, as the current scheme is not working/scaling for some projects. The name change, to me, is just distracting noise. Thanks, doug regardless of whether you change the name from core to maintainer I really don't care. If it makes some folks feel better to
Re: [openstack-dev] The Evolution of core developer to maintainer?
On Tue, Mar 31, 2015 at 4:30 PM, Joe Gordon joe.gord...@gmail.com wrote: I am starting this thread based on Thierry's feedback on [0]. Instead of writing the same thing twice, you can look at the rendered html from that patch [1]. Neutron tried to go from core to maintainer but after input from the TC and others, they are keeping the term 'core' but are clarifying what it means to be a neutron core [2]. [2] does a very good job of showing how what it means to be core is evolving. From everyone is a dev and everyone is a reviewer. No committers or repo owners, no aristocracy. Some people just commit to do a lot of reviewing and keep current with the code, and have votes that matter more (+2). (Theirry) To a system where cores are more then people who have votes that matter more. Neutron's proposal tries to align that document with what is already happening. 1. They share responsibility in the project's success. 2. They have made a long-term, recurring time investment to improve the project. 3. They spend their time doing what needs to be done to ensure the projects success, not necessarily what is the most interesting or fun. I think there are a few issues at the heart of this debate: 1. Our current concept of a core team has never been able to grow past 20 or so people, even for really big projects like nova and cinder. Why is that? How do we delegate responsibility for subsystems? How do we keep growing? 2. If everyone is just developers and reviewers who is actually responsible for the projects success? How does that mesh with the ideal of no 'aristocracy'? Do are early goals still make sense today? Do you feel like a core deveper/reviewer (we initially called them core developers) [1]: In OpenStack a core developer is a developer who has submitted enough high quality code and done enough code reviews that we trust their code reviews for merging into the base source tree. It is important that we have a process for active developers to be added to the core developer team. Or a maintainer [1]: 1. They share responsibility in the project’s success. 2. They have made a long-term, recurring time investment to improve the project. 3. They spend that time doing whatever needs to be done, not necessarily what is the most interesting or fun. Maintainers are often under-appreciated, because their work is harder to appreciate. It’s easy to appreciate a really cool and technically advanced feature. It’s harder to appreciate the absence of bugs, the slow but steady improvement in stability, or the reliability of a release process. But those things distinguish a good project from a great one. [0] https://review.openstack.org/#/c/163660/ [1] http://docs-draft.openstack.org/60/163660/3/check/gate-governance-docs/f386acf//doc/build/html/resolutions/20150311-rename-core-to-maintainers.html [2] https://review.openstack.org/#/c/164208/ __ 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 Hey Joe, I mentioned in last weeks TC meeting that I didn't really see a burning need to change or create new labels; but that's probably beside the point. So if I read this it really comes down to a number of people in the community want core to mean something more than special reviewer is that right? I mean regardless of whether you change the name from core to maintainer I really don't care. If it makes some folks feel better to have that title/label associated with themselves that's cool by me (yes I get the *extra* responsibilities part you lined out). What is missing for me here however is who picks these special people. I'm convinced that this does more to promote the idea of special contributors than anything else. Maybe that's actually what you want, but it seemed based on your message that wasn't the case. Anyway, core nominations are fairly objective in my opinion and is *mostly* based on number of reviews and perceived quality of those reviews (measured somewhat by disagreement rates etc). What are the metrics for this special group of folks that you're proposing we empower and title as maintainers? Do I get to be a maintainer, is it reserved for a special group of people, a specific company? What's the criteria? Do *you* get to be a maintainer? What standards are *Maintainers* held to? Who/How do we decide he/she is doing their job? Are there any rules about representation and interests (keeping the team of people balanced). What about the work by those maintainers that introduces more/new bugs? My feeling on this is that yes a lot of this sort of thing is happening naturally on its own and that's a pretty cool thing IMO. What you're saying though is you want to formalize it? Is the problem that people don't feel
Re: [openstack-dev] The Evolution of core developer to maintainer?
On Tue, Mar 31, 2015 at 5:30 PM, Joe Gordon joe.gord...@gmail.com wrote: Do you feel like a core deveper/reviewer (we initially called them core developers) [1]: In OpenStack a core developer is a developer who has submitted enough high quality code and done enough code reviews that we trust their code reviews for merging into the base source tree. It is important that we have a process for active developers to be added to the core developer team. Or a maintainer [1]: 1. They share responsibility in the project’s success. 2. They have made a long-term, recurring time investment to improve the project. 3. They spend that time doing whatever needs to be done, not necessarily what is the most interesting or fun. First, I don't think these two things are mutually exclusive, that's a false dichotomy. They sound like two groups of attributes (or roles), both of which must be earned in the eyes of the rest of the project team. Frankly, being a PTL is your maintainer list on steroids for some projects, except that the PTL is directly elected. Maintainers are often under-appreciated, because their work is harder to appreciate. It’s easy to appreciate a really cool and technically advanced feature. It’s harder to appreciate the absence of bugs, the slow but steady improvement in stability, or the reliability of a release process. But those things distinguish a good project from a great one. The best maintainers appear to be invisible because stuff Just Works(TM). It feels to me like a couple of things are being conflated here and need to be explicitly stated to break the conversation down into meaningful parts that can be discussed without getting side-tracked: a) How do we scale? How do we spread the project management load? How do we maintain consistency in subteams/subsystems? b) How do we avoid the 'aristoctacy'? c) what did I miss? Taking b) first, the problem being solved needs to be stated. Is it to avoid 'cliques'? Are feelings being hurt because some are 'more-core' than others? Is it to remove being a core team member as a job-review checkbox for some companies? This seems to be bigger than just increasing core reviewer numbers, and tied to some developers being slighted in some way. A) is an organization structure problem. We're seeing the boundaries of startup-style flat organization, and I think we all know we don't want traditional enterprise layers of managers. It seems like there is a progression of advancement for team members: prove yourself and become a core team member/reviewer/whatever. The next step is what I think you want to formalize Joe, and that is those who again prove themselves in some manner to unlock the 'maintainer' achievements. The idea of taking the current becoming-core-team process and repeating it based on existing cores and PTL recommendations doesn't seem like too far of a stretch. I mean really, is any project holding back people who want to do the maintainer role on more than just one pet part of a project? (I know those exist) FWIW, I have not been deeply involved in any of the highly political/vendor-driven projects so this may appear totally ignorant to those realities, but I think that is a clue that those projects are drifting away from the ideals that OpenStack was started with. dt -- Dean Troyer dtro...@gmail.com __ 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
