Re: [openstack-dev] EOL and Stable Contributions (was Juno is flubber at the gate)
> On Feb 10, 2015, at 9:21 AM, Dean Troyer wrote: > > On Tue, Feb 10, 2015 at 9:20 AM, Kevin Bringard (kevinbri) > wrote: > ATC is only being given to folks committing to the current branch > (https://ask.openstack.org/en/question/45531/atc-pass-for-the-openstack-summit/). > > Secondly, it's difficult to get stack-analytics credit for back ports, as the > preferred method is to cherry pick the code, and that keeps the original > author's name. > > My fear is that we're going in a direction where trunk is the sole focus and > we're subsequently going to lose the support of the majority of the operators > and enterprises at which point we'll be a fun research project, but little > more. > > [I've cherry-picked above what I think are the main points here... not > directed at you Kevin.] No offense taken! I just wanted to start a conversation about it, so mission accomplished :-D > > This is not Somebody Else's Problem. > > Stable maintenance is Not Much Fun, no question. Those who have demanded the > loudest that we (the development community) maintain these stable branches > need to be the one supporting it the most. (I have no idea how that matches > up today, so I'm not pointing out anyone in particular.) > > * ATC credit should be given, stable branch maintenance is a contribution to > the project, no question. 100% agree, which really is my entire point. I also noticed that since the original message went out, it's been clarified that "current release" is meant to mean "any OpenStack contributions during the current release cycle" (paraphrase based on my reading of the clarification), which would include stable branches. I'm personally OK with this. I don't think the foundation should cover the cost of anyone who's contributed even a single bug fix in the last year (or whatever time period). Mostly I just want to make sure we're not scaring people away from working on stable branches. Like we've stipulated, maintenance isn't a lot of fun nor is it high profile. If we don't give people an incentive to do it, it's entirely likely they'll just say screw it. > * I have a bit of a problem with stack-analytics being an issue partially > because that is not what should be driving corporate contributions and > resource allocation. But it does. Relying on a system with known anomalies > like the cherry-pick problem gets imperfect results. Also agree. The only reason I mention it is that, as you stated, a lot of companies use it as a metric, and it does matter. If you want to get an OpenStack related job, chances are if you don't show up in Stack Analytics, you're going to have a harder time of it. Jeremy made a good point that we should work that out with SA, which is unrelated to "OpenStack" specifically. Perhaps it's just a matter of better documenting how to properly commit to stable branches if you want it to be tracked. > * The vast majority of the OpenStack contributors are paid to do their work > by a (most likely) Foundation member company. These companies choose how to > allocate their resources, some do quite well at scratching their particular > itches, some just make a lot of noise. If fun is what drives them to select > where they apply resources, then they will reap what they sow. Again, I completely agree. But, as we've seen companies like to tout what they're doing. I personally do a lot of work on the stable branches, upstream when I can, but a lot of times I'm doing work on stuff that's been EOL or for which the issue I'm working on isn't considered "stability work". In those cases my work never goes upstream. Combine this with the SA issues, and that's a lot of out of band work. > > The voice of operators/users/deployers in this conversation should be > reflected through the entity that they are paying to provide operational > cloud services. It's those directly consuming the code from openstack.org > that are responsible here because they are the ones directly making money by > either providing public/private cloud services, or reselling a productized > OpenStack or providing consulting services and the like. > > This should not stop users/operators from contributing information, > requirements or code in any way. But if they have to go around their vendor > then that vendor has failed them. This, I disagree with. Not only does it make the assumption that anyone running OS "for profit" is either chasing trunk or paying a vendor, but it creates a potential fragmentation nightmare and chokes down the number of entities willing to invest into the project. If I'm paying vendor X for operational cloud services, and it's stated that they're who should be voicing my interests in the community 1) What happens when my interests and that of another customer of vendor X conflict? But 2) Why should I invest in the community? I'm paying a vendor, it's their problem. In fact, why do I even have operators who could pote
Re: [openstack-dev] EOL and Stable Contributions (was Juno is flubber at the gate)
On 2015-02-10 10:21:58 -0600 (-0600), Dean Troyer wrote: [...] > ATC credit should be given, stable branch maintenance is a > contribution to the project, no question. [...] Just to keep this particular misconception from spinning out of control, as I mentioned elsewhere in this thread they absolutely already do. Stable branch changes are treated no differently from any other Gerrit changes in this regard. -- 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] EOL and Stable Contributions (was Juno is flubber at the gate) [metrics]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 The voice of operators/users/deployers in this conversation should be reflected through the entity that they are paying to provide operational cloud services. Let’s be careful here: I hope you didn’t mean to say that operators/users/deployers voices should only be heard when they pay a vendor to get OpenStack (and I don’t think you did, but it read that way a bit). It's those directly consuming the code from openstack.org that are responsible here because they are the ones directly making money by either providing public/private cloud services, or reselling a productized OpenStack or providing consulting services and the like. Sure, I agree those folks certainly have an interest...but I don’t believe it’s solely their responsibility and that "the development community" has none. If the development community has no responsibility for maintaining stable code, why have stable branches at all? If we aren’t incentivizing contributions to stable code, we’re encouraging forking, IMHO. There’s a balance to be struck here. I think what’s being voiced in this thread is that we haven’t gotten to that place yet where there are good incentives to contribute to stable branch (not just back porting fixes, but dealing with gate problems, etc as well) and we’d like to figure out how to improve that situation. At Your Service, Mark T. Voelker OpenStack Architect On Feb 10, 2015, at 11:21 AM, Dean Troyer wrote: On Tue, Feb 10, 2015 at 9:20 AM, Kevin Bringard (kevinbri) wrote: ATC is only being given to folks committing to the current branch (https://ask.openstack.org/en/question/45531/atc-pass-for-the-openstack-summit/). Secondly, it's difficult to get stack-analytics credit for back ports, as the preferred method is to cherry pick the code, and that keeps the original author's name. My fear is that we're going in a direction where trunk is the sole focus and we're subsequently going to lose the support of the majority of the operators and enterprises at which point we'll be a fun research project, but little more. [I've cherry-picked above what I think are the main points here... not directed at you Kevin.] This is not Somebody Else's Problem. Stable maintenance is Not Much Fun, no question. Those who have demanded the loudest that we (the development community) maintain these stable branches need to be the one supporting it the most. (I have no idea how that matches up today, so I'm not pointing out anyone in particular.) * ATC credit should be given, stable branch maintenance is a contribution to the project, no question. * I have a bit of a problem with stack-analytics being an issue partially because that is not what should be driving corporate contributions and resource allocation. But it does. Relying on a system with known anomalies like the cherry-pick problem gets imperfect results. * The vast majority of the OpenStack contributors are paid to do their work by a (most likely) Foundation member company. These companies choose how to allocate their resources, some do quite well at scratching their particular itches, some just make a lot of noise. If fun is what drives them to select where they apply resources, then they will reap what they sow. The voice of operators/users/deployers in this conversation should be reflected through the entity that they are paying to provide operational cloud services. It's those directly consuming the code from openstack.org that are responsible here because they are the ones directly making money by either providing public/private cloud services, or reselling a productized OpenStack or providing consulting services and the like. This should not stop users/operators from contributing information, requirements or code in any way. But if they have to go around their vendor then that vendor has failed them. 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 -BEGIN PGP SIGNATURE- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJU2kAYAAoJELUJLUWGN7CbJpEQAJJmw/RlgRMxVSyuWZpcvJmn nWVLw3KJTspGz5V9clFG6QYgDR5ygWNz51e+QT0Ps+baOWxq9Figwur2yyYfOt8c hissfjL+OPG2QRrAQOwys7n2s5bSb28ePvO+/benY1PykAknpZX4lq28V4gfqRX9 +2ZjxNs+orkj0cuDi1KdhZPjfo1fuZ07GgCjFy1Xuqq7rYBLfrkEffmF2dbxF67R aHxbTWe9CgX6IlTL1p5rH7wCKyYQrkFUEXXG3w3CpdWJQ4Ky2bvC/JyKX8wFOkqp AL7voCvG0zwPV+BHBVabqobC7qb+7+uYd6IQRovuxVxcl9ZdI0o9GQyhcXf890IQ Sq8Z+PApzOvd8pxQdpq0SBYlVZUsjuBe3YGfvmHg/3hyto+FUzKhJOfjfLepST5U tThEQzSnfZwfgnTkI3/rN9zMvlg7vsP15lRJzRx+ycQhyzTJZdlEiA+yIQF3tdrZ h1ZW1M4Dc9R/R56jRV3YeSxY1wMUlBHm4Gn+uKVS3q/dKjIOkYjJEEDVcDd/wCYh Uknp5GFsZi6Uvj0Dgymllrk7HCustzEhog4r0mORH6W0HtYVK0U/NvaRFXkF/VS0 4aWArCzC603glUMNIdD8x6Nw5LTXK16ENk9
Re: [openstack-dev] EOL and Stable Contributions (was Juno is flubber at the gate) [metrics]
On Tue, 2015-02-10 at 15:20 +, Kevin Bringard (kevinbri) wrote: > I've been talking with a few people about this very thing lately, and > I think much of it is caused by what appears to be our actively > discouraging people from working on it. Most notably, ATC is only > being given to folks committing to the current branch > (https://ask.openstack.org/en/question/45531/atc-pass-for-the-openstack-summit/). As Jeremy clarified, this is wrong. I edited the answer to be even more explicit. > Secondly, it's difficult to get stack-analytics credit for back > ports, as the preferred method is to cherry pick the code, and that > keeps the original author's name. I've personally gotten a few commits > into stable, but have nothing to show for it in stack-analytics (if > I'm doing it wrong, I'm happy to be corrected) First I want to clarify that git history on http://activity.openstack.org visualizes commits (merged changes, more properly) to all branches, not just trunk. That said, we probably still miss some attribution there because we count "committers" only by looking at the "author" of a change. If backports are cherry-picked and therefore retain the author then the new owner is not *counted* as a new contributor. I highlight that the scope of Activity Board is not to create vanity charts but only to highlight trends that are useful to understand the health of the community. It never had any intention to be precise because 100% precision is hard. That said, I'm adding the metrics tag because if there is a way to add owners of back-ports to the count of contributors to OpenStack that'd be good. And if we want to improve the number of contributors to stable release, we may even create a new panel to show such trend. Do you agree we need to look in detail, separately to contributors to stable and to trunk instead of one blob? /stef __ 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] EOL and Stable Contributions (was Juno is flubber at the gate)
> > > Secondly, it's difficult to get stack-analytics credit for back > > ports, as the preferred method is to cherry pick the code, and > > that keeps the original author's name. I've personally gotten a > > few commits into stable, but have nothing to show for it in > > stack-analytics (if I'm doing it wrong, I'm happy to be > > corrected). > [...] > Stackalytics isn't an official OpenStack project, but you should > file a bug[2] against it if there's a feature you want its authors > to consider adding. Stackalytics tracks commits into stable branches, e.g. for Neutron stable/juno they are visible at http://stackalytics.com/?metric=commits&module=neutron&release=juno. Commits are also shown in activity log for specific project or person, so if someone interested in pulling them into weekly report - they will be there. Thanks, Ilya 2015-02-10 19:45 GMT+03:00 Jeremy Stanley : > On 2015-02-10 15:20:46 + (+), Kevin Bringard (kevinbri) wrote: > [...] > > I've been talking with a few people about this very thing lately, > > and I think much of it is caused by what appears to be our > > actively discouraging people from working on it. Most notably, ATC > > is only being given to folks committing to the current branch > > ( > https://ask.openstack.org/en/question/45531/atc-pass-for-the-openstack-summit/ > ). > > The comments on that answer are somewhat misleading, so I'll follow > up there as well to set the record straight. The script[1] which > identifies ATCs for the purpose of technical elections and summit > passes is based entirely on Gerrit owners (uploaders) of changes > merged to official projects within a particular time period. It > doesn't treat master differently from any other branches. People who > do the work to upload backports to stable branches absolutely do get > counted for this purpose. People who only review changes uploaded by > others do not (unless they are manually added to the "extra-atcs" > file in the openstack/governance repo), but that is the case for all > branches including master so not something stable-branch specific. > > Though I *personally* hope that is not the driving force to convince > people to work on stable support. If it is, then we've already lost > on this front. > > > Secondly, it's difficult to get stack-analytics credit for back > > ports, as the preferred method is to cherry pick the code, and > > that keeps the original author's name. I've personally gotten a > > few commits into stable, but have nothing to show for it in > > stack-analytics (if I'm doing it wrong, I'm happy to be > > corrected). > [...] > > Stackalytics isn't an official OpenStack project, but you should > file a bug[2] against it if there's a feature you want its authors > to consider adding. > > [1] > https://git.openstack.org/cgit/openstack-infra/system-config/tree/tools/atc/email_stats.py > [2] https://bugs.launchpad.net/stackalytics/+filebug > -- > 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 > __ 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] EOL and Stable Contributions (was Juno is flubber at the gate)
On 2015-02-10 15:20:46 + (+), Kevin Bringard (kevinbri) wrote: [...] > I've been talking with a few people about this very thing lately, > and I think much of it is caused by what appears to be our > actively discouraging people from working on it. Most notably, ATC > is only being given to folks committing to the current branch > (https://ask.openstack.org/en/question/45531/atc-pass-for-the-openstack-summit/). The comments on that answer are somewhat misleading, so I'll follow up there as well to set the record straight. The script[1] which identifies ATCs for the purpose of technical elections and summit passes is based entirely on Gerrit owners (uploaders) of changes merged to official projects within a particular time period. It doesn't treat master differently from any other branches. People who do the work to upload backports to stable branches absolutely do get counted for this purpose. People who only review changes uploaded by others do not (unless they are manually added to the "extra-atcs" file in the openstack/governance repo), but that is the case for all branches including master so not something stable-branch specific. Though I *personally* hope that is not the driving force to convince people to work on stable support. If it is, then we've already lost on this front. > Secondly, it's difficult to get stack-analytics credit for back > ports, as the preferred method is to cherry pick the code, and > that keeps the original author's name. I've personally gotten a > few commits into stable, but have nothing to show for it in > stack-analytics (if I'm doing it wrong, I'm happy to be > corrected). [...] Stackalytics isn't an official OpenStack project, but you should file a bug[2] against it if there's a feature you want its authors to consider adding. [1] https://git.openstack.org/cgit/openstack-infra/system-config/tree/tools/atc/email_stats.py [2] https://bugs.launchpad.net/stackalytics/+filebug -- 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] EOL and Stable Contributions (was Juno is flubber at the gate)
On Tue, Feb 10, 2015 at 9:20 AM, Kevin Bringard (kevinbri) < kevin...@cisco.com> wrote: > ATC is only being given to folks committing to the current branch ( > https://ask.openstack.org/en/question/45531/atc-pass-for-the-openstack-summit/ > ). > Secondly, it's difficult to get stack-analytics credit for back ports, as > the preferred method is to cherry pick the code, and that keeps the > original author's name. > > My fear is that we're going in a direction where trunk is the sole focus > and we're subsequently going to lose the support of the majority of the > operators and enterprises at which point we'll be a fun research project, > but little more. > [I've cherry-picked above what I think are the main points here... not directed at you Kevin.] This is not Somebody Else's Problem. Stable maintenance is Not Much Fun, no question. Those who have demanded the loudest that we (the development community) maintain these stable branches need to be the one supporting it the most. (I have no idea how that matches up today, so I'm not pointing out anyone in particular.) * ATC credit should be given, stable branch maintenance is a contribution to the project, no question. * I have a bit of a problem with stack-analytics being an issue partially because that is not what should be driving corporate contributions and resource allocation. But it does. Relying on a system with known anomalies like the cherry-pick problem gets imperfect results. * The vast majority of the OpenStack contributors are paid to do their work by a (most likely) Foundation member company. These companies choose how to allocate their resources, some do quite well at scratching their particular itches, some just make a lot of noise. If fun is what drives them to select where they apply resources, then they will reap what they sow. The voice of operators/users/deployers in this conversation should be reflected through the entity that they are paying to provide operational cloud services. It's those directly consuming the code from openstack.org that are responsible here because they are the ones directly making money by either providing public/private cloud services, or reselling a productized OpenStack or providing consulting services and the like. This should not stop users/operators from contributing information, requirements or code in any way. But if they have to go around their vendor then that vendor has failed them. 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
Re: [openstack-dev] EOL and Stable Contributions (was Juno is flubber at the gate)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 - -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 The sentiment that Kevin is expressing here has come up informally at past Operator’s meetups as well, which makes sense given that relatively few operators are chasing trunk vs using a stable release. I would hypothesize that there’s probably actually a fair bit of interest among operators in having well maintained stable branches but there are disincentives that keep them from pitching in more. Let’s see if we can bring that to light a bit—I’ve added an item on the etherpad to discuss this in Philadelphia at the Operator’s midcycle meetup in a few weeks. [1] If folks who are attending aren’t familiar with the current stable branch policies and team structure, you may want to read through the wiki first. [2] [1] https://etherpad.openstack.org/p/PHL-ops-meetup [2] https://wiki.openstack.org/wiki/StableBranch At Your Service, Mark T. Voelker OpenStack Architect On Feb 10, 2015, at 10:20 AM, Kevin Bringard (kevinbri) wrote: Since this is sort of a topic change, I opted to start a new thread. I was reading over the "Juno is Fubar at the Gate" thread, and this bit stood out to me: So I think it's time we called the icehouse branch and marked it EOL. We originally conditioned the longer support window on extra people stepping forward to keep things working. I believe this latest issue is just the latest indication that this hasn't happened. Issue 1 listed above is being caused by the icehouse branch during upgrades. The fact that a stable release was pushed at the same time things were wedged on the juno branch is just the latest evidence to me that things aren't being maintained as they should be. Looking at the #openstack-qa irc log from today or the etherpad about trying to sort this issue should be an indication that no one has stepped up to help with the maintenance and it shows given the poor state of the branch. Most specifically: "We originally conditioned the longer support window on extra people stepping forward to keep things working ... should be an indication that no one has stepped up to help with the maintenance and it shows given the poor state of the branch". I've been talking with a few people about this very thing lately, and I think much of it is caused by what appears to be our actively discouraging people from working on it. Most notably, ATC is only being given to folks committing to the current branch (https://ask.openstack.org/en/question/45531/atc-pass-for-the-openstack-summit/). Secondly, it's difficult to get stack-analytics credit for back ports, as the preferred method is to cherry pick the code, and that keeps the original author's name. I've personally gotten a few commits into stable, but have nothing to show for it in stack-analytics (if I'm doing it wrong, I'm happy to be corrected). My point here isn't to complain that I, or others, are not getting credit, but to point out that I don't know what we expected to happen to stable branches when we actively dis-incentivize people from working on them. Working on hardening old code is generally far less interesting than working on the cool shiny new features, and many of the productionalization issues we run into aren't uncovered until it's being run at scale which in turn is usually by a big company who likely isn't chasing trunk. My fear is that we're going in a direction where trunk is the sole focus and we're subsequently going to lose the support of the majority of the operators and enterprises at which point we'll be a fun research project, but little more. - - -- Kevin __ 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 - -BEGIN PGP SIGNATURE- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJU2i1eAAoJELUJLUWGN7CbmPEQAKV/9RPgKt6jwvq0bzhFCJPF hz2LOC8M5Fk1wINGUcvwGjiphCwGMSD9p6IYx7PAzMrnbhLqQa0exCmo4DUi3jdV qNC1A6juScrHjyQMcQ3dBS4Z4QEh0S964n2Ae/uoWydpDe8WGy4DQRLTNy+mCIg5 ROManHAWcQ3Cr5fYkFSeGQgaoROypj2Eebvv4kiYDPQVkjK1o49hpybxe5v0zR/Y 6kuacoZCK8h6X8b4CrbG+t/vCy8dqWIUB1j67VBojRDpe1p0yQqA3IJ72DLPfTw5 0GzUecfW781ZP5fHQSwhbg7t31UYXBpo9xszltXBiNynHRktA7BwYwj+YAFCKgNZ sQ/gZOruqR+Os8/+pngA23PCGvuCUsTamUCkQUs4mCHjdvPq/BNFg0qGNeeheLQq CzlldwqcPY5py3KfmipIZakH1wZ2S/DU/snuAhVatTjVHqO1leyk5asHYVVAnwCQ 96vawAHcIXEN4dPcXpcYBiiTE1mgq+0FQgVGsr4fQ2BkRYDN9rmOdVp+mG7b7QM0 jhK+POQqj+ojnQOKwA2ygQUglDY8MxjmfCrMukkWQylmYVb09Z0cOMFfMMw7YfU3 pWGP6BIfCManduqVBqFvTMxh/dCGIGq3LwrXo23qmukdgSIVRuj16XPZqXZ5xtv/ A6NV//pQXxvO4d+l4bBk =cT3X - -END PGP SIGNATURE- -BEGIN PGP SIGNATURE- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJU2i1jAAoJELUJLUWGN7CbsDIP/i0CyFC1FOL7SSC3IFLvVd9r sJw/AmH4e5oc0FwBlyF6PJa4vqhK3SYMRE1/mOUs/zpM8IRrMafkf83w2aSYrskw 5kYYYOyv