<div dir="ltr">I am not involved in Glance, however this was well worth reading for the experiences during the cycle, not just as a PTL but as a team and the communication of improving the software development process.<div><br></div><div><div class="gmail_extra"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div><div><div><span style="color:rgb(102,102,102)"><br></span><br></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Wed, Mar 9, 2016 at 11:47 PM, Bhandaru, Malini K <span dir="ltr"><<a href="mailto:malini.k.bhandaru@intel.com" target="_blank">malini.k.bhandaru@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Flavio, Glance and OpenStack benefited during your reign or period of humble service.<br>
Will miss you at the helm. Also thank you for anointing/attracting two new solid cores: Brian and Sabari<br>
Malini<br>
<div><div class="h5"><br>
<br>
-----Original Message-----<br>
From: Tom Fifield [mailto:<a href="mailto:tom@openstack.org">tom@openstack.org</a>]<br>
Sent: Wednesday, March 09, 2016 7:55 PM<br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [glance] Glance Mitaka: Passing the torch<br>
<br>
A beautiful post, sir. Thank you for everything!<br>
<br>
On 09/03/16 22:15, Flavio Percoco wrote:<br>
><br>
> Greetings,<br>
><br>
> I'm not going to run for Glance's PTL position for the Newton timeframe.<br>
><br>
> There are many motivations behind this choice. Some of them I'm<br>
> willing to discuss in private if people are interested but I'll go as<br>
> far as saying there are personal and professional reasons for me to<br>
> not run again.<br>
><br>
> As I've always done in my past cycles as PTL, I'd like to take some<br>
> time to summarize what's happened in the past cycle not only for the<br>
> new PTL to know what's coming up but for the community to know how<br>
> things went.<br>
><br>
> Before I even start, I'd like to thank everyone in the Glance community.<br>
> I truly<br>
> believe this was a great cycle for the project and the community has<br>
> gotten stronger. None of this would have been possible without the<br>
> help of all of you and for that, I'm deeply in debt with you all. It<br>
> does not just take an employer to get someone to contribute to a<br>
> project. Being paid, for those who are, to do Open Source is not<br>
> enough. It takes passion, motivation and a lot of patience to analyze<br>
> a technology, think out of the box and look for ways it can be<br>
> improved either by fixing bugs or by implementing new features. The<br>
> amount of time and dedication this process requires is probably worth<br>
> way more than what we get back from it.<br>
><br>
> Now, with all that being said, here's Glance Mitaka for all of you:<br>
><br>
> Completed Features<br>
> ==================<br>
><br>
> I think I've mentioned this already but I'm proud of it so I'll say it<br>
> again.<br>
> The prioritization and scheduling of Glance Mitaka went so well that<br>
> we managed to release M-3 without any feature freeze exception (FFE)<br>
> request. This doesn't mean all the features were implemented. In fact,<br>
> at least 4 were pushed back to Newton. However, the team communicated,<br>
> reviewed, sprinted and coded in such a way that we were able to<br>
> re-organize the schedule to avoid wasting time on things we new<br>
> weren't going to make it. This required transparency and hard<br>
> decisions but that's part of the job, right?<br>
><br>
> * [0] CIM Namespace Metadata<br>
> * [1] Support download from and upload to Cinder volumes<br>
> * [2] Glance db purge utility<br>
> * [3] Deprecate Glance v3 API<br>
> * [4] Implement trusts for Glance<br>
> * [5] Migrate the HTTP Store to Use Requests<br>
> * [6] Glance Image Signing and Verification<br>
> * [7] Supporting OVF Single Disk Image Upload<br>
> * [8] Prevention of Unauthorized errors during upload/download in<br>
> Swift driver<br>
> * [9] Add filters using an ‘in’ operator<br>
><br>
> [0]<br>
> <a href="http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme</a><br>
> nted/cim-namespace-metadata-definitions.html<br>
><br>
> [1]<br>
> <a href="http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme</a><br>
> nted/cinder-store-upload-download.html<br>
><br>
> [2]<br>
> <a href="http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme</a><br>
> nted/database-purge.html<br>
><br>
> [3]<br>
> <a href="http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme</a><br>
> nted/deprecate-v3-api.html<br>
><br>
> [4]<br>
> <a href="http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme</a><br>
> nted/glance-trusts.html<br>
><br>
> [5]<br>
> <a href="http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme</a><br>
> nted/http-store-on-requests.html<br>
><br>
> [6]<br>
> <a href="http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme</a><br>
> nted/image-signing-and-verification-support.html<br>
><br>
> [7]<br>
> <a href="http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme</a><br>
> nted/ovf-lite.html<br>
><br>
> [8]<br>
> <a href="http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme</a><br>
> nted/prevention-of-401-in-swift-driver.html<br>
><br>
> [9]<br>
> <a href="http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme</a><br>
> nted/v2-add-filters-with-in-operator.html<br>
><br>
><br>
> If the above doesn't sound impressive to you, let me fill you in with<br>
> some extra info about Glance's community.<br>
><br>
> Community<br>
> =========<br>
><br>
> Glance's community currently has 12 core members, 3 of which joined<br>
> during Mitaka and 2 of those 3 members joined at the end of the cycle.<br>
> That means the team ran on 9 reviewers for most of the cycle except<br>
> that out of those 9, 1 left the team and joined later in the cycle and<br>
> 3 folks weren't super active this cycle. That left the team with 5<br>
> constant reviewers throughout the cycle.<br>
><br>
> Now, the above is *NOT* to say that the success of the cycle is thanks<br>
> to those<br>
> 5 constant reviewers. On the contrary, it's to say that we've managed<br>
> to build a community capable of working together with other non-core<br>
> reviewers.<br>
> This was a<br>
> key thing for this cycle.<br>
><br>
> I don't think it's a secret to anyone that, at the beginning of the<br>
> cycle, the community was fragile and somewhat split. There were<br>
> different opinions on what Glance should (or shouldn't) look like,<br>
> what new features Glance should (or<br>
> shouldn't) have and where the project should be headed in the next 6<br>
> months.<br>
><br>
> The team sat down, the team talked and the team agreed on what the<br>
> project should be and that's what the team did in the Mitaka cycle.<br>
> Sharing one message with the rest of the OpenStack community (and<br>
> especially new Glance<br>
> contributors) was a key for the community to become stronger.<br>
><br>
> What changed? What did the community do differently?<br>
><br>
> Priorities and Goals<br>
> --------------------<br>
><br>
> Mitaka was the first cycle that Glance strictly followed a list of<br>
> priorities [0]. Funny enough, 2 of those priorities didn't make it in<br>
> Mitaka but we'll get to that in a bit.<br>
><br>
> The list of priorities didn't do it all by itself. The list of<br>
> priorities gave us a target, a goal. It helped us to remain focused.<br>
> It kept us on track.<br>
> However, it did way more than that. The list of priorities allowed us for:<br>
><br>
> * Sending a clear message of what the community has agreed on and where the<br>
>   community is headed<br>
> * Selecting a narrow list of features that we would be able to work on and<br>
>   review throughout the cycle<br>
> * Scheduling and splitting reviews to accommodate the priorities<br>
><br>
> Of those points, I believe the second one is the one that really did<br>
> it for us.<br>
> We kept the set of new features small so that we could focus on what<br>
> was important. We had more proposals than we approved and we rejected<br>
> the rest based on our priorities. This is something I'd like to see<br>
> happening again in Glance and I'd like to encourage the next PTL to do<br>
> the same and be *strict* about it.<br>
><br>
> [0]<br>
> <a href="http://specs.openstack.org/openstack/glance-specs/priorities/mitaka-pr" rel="noreferrer" target="_blank">http://specs.openstack.org/openstack/glance-specs/priorities/mitaka-pr</a><br>
> iorities.html<br>
><br>
><br>
> Reduce the review backlog<br>
> -------------------------<br>
><br>
> We abandoned patches [0]! We removed from the review queue all the<br>
> patches that, for 2 or more months, had been in merge conflict, had<br>
> had -1/-2 from cores or had had -1 from jenkins (hope I'm not missing<br>
> something here). We did that and we made the backlog shorter, we kept<br>
> in the review list what was really relevant at that moment.<br>
><br>
> Something important about the above is that we didn't abandon patches<br>
> that had stalled for lack of reviews. We prioritized those, we bumped<br>
> those to the top of our review list and we provided the reviews those<br>
> patches deserved. Some of them landed, some didn't but the important<br>
> bit is that those patches were reviewed.<br>
> Glance's current backlog (verified patches, Workflow 0 and no -2s) is<br>
> less than<br>
> 90 patches across all projects (likely way less than that but I just<br>
> did a rough<br>
> count) and the most important thing is that *ALL* these patches have<br>
> received reviews in 2016. Now, if you don't think this is great, you<br>
> should have seen our backlog before.<br>
><br>
> Now, there's no point in cleaning up the review queue if we're going<br>
> to let it fill up again. Right? This is where the community<br>
> awesomeness comes to light. We created a review dashboard[1], which<br>
> some folks used to organize their reviews. I found it super useful, I<br>
> used it to prioritize my reviews and help other folks to prioritize<br>
> theirs. When you're given an organized list of reviews rather than<br>
> just a list of random reviews, it's *way* easier for you to know what<br>
> to review.<br>
> That right there is the key. To know what to review. I believe, in<br>
> Mitaka, the team knew what to focus on and the team also knew someone<br>
> in the community was ready to provide a fresher, cleaner, list of<br>
> reviews they could focus on. Some folks would prefer to go and make up<br>
> a list themselves, others will prefer to have one ready. Either way,<br>
> having a clear story of where the focus should go is the key to help<br>
> reviews move faster. Remove the noise, it distracts from people from<br>
> what's really important.<br>
><br>
> [0] <a href="http://stackalytics.com/?user_id=glancebot@mailinator.com" rel="noreferrer" target="_blank">http://stackalytics.com/?user_id=glancebot@mailinator.com</a><br>
> [1] <a href="http://bit.ly/glance-dashboard" rel="noreferrer" target="_blank">http://bit.ly/glance-dashboard</a><br>
><br>
> Review Days<br>
> -----------<br>
><br>
> Not really a new thing. This has happened before and we just kept<br>
> doing it. The difference, perhaps, is that we increased the number of<br>
> review days in the cycle. We tried to do at least 1 review day per<br>
> milestone and we're now doing a Review Monday until the end of the<br>
> cycle to get as many bug fixes as possible in before the release. RC1<br>
> is looking good already!<br>
><br>
> So, if you'd ask me, I believe what changed was the community. The<br>
> community got together, polished some things, and focused on what's<br>
> important *the project*.<br>
> If you read between lines, the above shows one constant pattern, the<br>
> community matured and it found what its placed in the OpenStack<br>
> community.<br>
><br>
> Single Team<br>
> -----------<br>
><br>
> The Glance team is now back to being a single reviewing machine rather<br>
> than several, isolated, teams with specific tasks, which sometimes<br>
> ended up duplicated. The Glance Driver's team has been merged into the<br>
> Glance Core team and the Glare team (Artifacts) is not using the Fast<br>
> Track anymore.<br>
><br>
> Having smaller teams has resulted in a very useful thing to do for<br>
> other projects. Depending on the size of the project, it'd be possible<br>
> to map tasks to smaller teams and then reduce them once the job is<br>
> done ;).<br>
> Unfortunately, given<br>
> Glance's team size, this ended up adding *more* things to do to<br>
> members of those smaller teams that were also part of the other teams<br>
> as well.<br>
><br>
> One reason to mention this is because we'll have the temptation to do<br>
> this again in the future but, as it's been proven thus far, Glance's<br>
> community is not big enough to make such splits worth it and those end<br>
> up causing more harm to the community than good.<br>
><br>
> Spec Freeze<br>
> -----------<br>
><br>
> The team incorporated a spec freeze in this cycle. The dates that were<br>
> picked were not the most ideal ones but the freeze helped a lot to<br>
> bring back focus on code reviews and coding. This freeze put a<br>
> timeline on folks to get their proposals ready, hence forcing them to<br>
> have enough time to implement such proposals. Having open milestones<br>
> distracts the community from the schedule.<br>
> Announcing such milestones in advance and providing constant reminders<br>
> helped with making sure folks were prepared and ready to react.<br>
><br>
><br>
> Was it all rainbows?<br>
> ====================<br>
><br>
> No, it was not. There were and there are *many* things we need to work<br>
> on and improve. For instance, 2 of the priorities didn't make it this<br>
> cycle.<br>
> One of<br>
> them (Nova's adoption of Glance's v2) simply requires a bit of more<br>
> work and it specifically requires a better alignment with the Nova<br>
> community's priorities.<br>
> In other words, Nova needs to make this a priority for them.<br>
><br>
> The second priority that missed the deadline is the refactor of the<br>
> image import workflow. Some of you might be thinking "Guys, you had 1<br>
> job, *ONE* job and it was to discuss and implement that refactor".<br>
> Well, turns out that such refactor has an impact on *every* cloud and<br>
> it's not something the team can afford to change a third time (yes,<br>
> this is the second time the image import workflow is refactored). I'm<br>
> actually happy it didn't make it in Mitaka because that gave the team<br>
> more time to evaluate the proposal that had been discussed at the<br>
> summit, the issues around it and the different alternatives.<br>
> Nonetheless, I am a<br>
> bit sad about how things evolved with this proposal because at the<br>
> very beginning of the cycle we were a bit naive in our planning of this work.<br>
> That is<br>
> to say, that we should've probably known from the beginning that we<br>
> wouldn't have had the time to implement this spec and that it would<br>
> have taken us the whole cycle to discuss it. The problem is not that<br>
> we didn't know it to begin with but the fact that we weren't able to<br>
> communicate that to the community from the beginning. I don't think<br>
> this is a big deal, though. We realized soon enough that we shouldn't<br>
> rush this and that dedicating the cycle to discuss this spec was more<br>
> better than rushing it and then have a poor implementation of it.<br>
><br>
> We also experimented with a new process for lite specs and it was not<br>
> a huge success. This impacted some of the lite specs that had been<br>
> proposed but we did our best to come out of that situation without<br>
> impacting other's people work. In fact, that situation not just<br>
> highlighted the issues we had with the process but the team<br>
> responsible for it (the glance-drivers team), which ended up being<br>
> merged into the glance core team (as I mentioned in the previous<br>
> section). This process is being refactored and you can learn a bit<br>
> more about it in this review[0].<br>
><br>
> There's one more thing I wish we would have dedicated more time on.<br>
> That's tempest. Unfortunately, given the time available, size of the<br>
> team and the priorities we had, tempest did not receive as much love<br>
> as we'd have loved to.<br>
> There are several tempest tests that need to be cleaned up a bit,<br>
> especially on the V2 side.<br>
><br>
> [0] <a href="https://review.openstack.org/#/c/282516/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/282516/</a><br>
><br>
> To the Glance Community<br>
> =======================<br>
><br>
> All the credits for the above goes to you! As a PTL I don't think I<br>
> can take<br>
> *any* credit for what I consider a successful cycle brought by the<br>
> community itself. I instead recognize that it was all possible because<br>
> the community decided to go back to being awesome. I'm a believer that<br>
> the PTL's role is all about enabling the community to be awesome.<br>
> Planning, prioritization, scheduling, etc. it all serves a single<br>
> goal, which is to allow the community for doing what they know best<br>
> and focus on that.<br>
><br>
> I've enjoyed every single of my stages in this community. Rushing<br>
> through reviews, coding like crazy, ranting like crazy, leading the<br>
> community and back to reviewing like crazy. These years as a member of<br>
> Glance's community have taught me a lot about this project and how<br>
> critical it is for the rest of the community. As I always say, it's<br>
> one of those projects that can take your whole cloud down without you<br>
> even noticing but I do hope you notice it.<br>
><br>
> Glance is often referred to as a simple project (true), as a small<br>
> project (kinda true) and sometimes as not super cool (false). I'd like<br>
> to remind you that not only Glance is a "cool" project to work on but<br>
> it's also super critical for OpenStack. As I remind you this, I'd like<br>
> to urge you to help the project stay on track across the cycles.<br>
> Glance (as every other projects) depends on the ability of its<br>
> community to dictate what's best for it.<br>
><br>
> Glance's interoperability has been compromised and there's a plan to<br>
> help bringing it back. Let's get that done. Glance's v1 is not<br>
> considered secure and it must be deprecated. Let's do that as well.<br>
> Glance's stability and security has shown some weaknesses. Let's not<br>
> ignore that. Working on new features is always sexy. Working on the<br>
> new cool stuff that other projects are doing might seem like a must do<br>
> task. I'd argue and say there's a time for everything and, while<br>
> Glance shares OpenStack's priorities, there are times where the<br>
> project needs to take a step back, put itself together again and start<br>
> again. I don't believe Glance has left that self-healing period and<br>
> I'd like to urge the whole community to keep this in mind.<br>
><br>
> To the new PTL<br>
> ==============<br>
><br>
> Listen! Listen to the things the OpenStack community has to say.<br>
> Listen to the things external folks have to say. Most importantly,<br>
> listen to what the Glance community has to say. Glance is not a<br>
> playground for making random decisions. If you listen to what the<br>
> community has to say, it'll be easy enough to know what to do and what<br>
> the next steps are. However, you should be ready for making hard<br>
> decisions and you need to have the courage to do so. During the last<br>
> elections, I wrote a post[0] about what being a PTL means and I'd like<br>
> to encourage you to read it, even if you've done so already.<br>
><br>
> If you look at the goals we set for Glance during Mitaka and the<br>
> results we achieved, you'll soon notice what the priorities for the<br>
> next cycle should be.<br>
> The community will help shaping those priorities but the baseline is<br>
> there already.<br>
><br>
> A great cycle is not measured on how many features the community is<br>
> able to implement. Therefore, I encourage you to not fall under the<br>
> temptation of approving as many specs as possible. It is *perfectly<br>
> fine* to say no to specs because they conflict with the project's<br>
> priorities. The more specs the team approves, the more code there will<br>
> be, the more people the project will need to complete the feature<br>
> (code wise and review wise). Keep the release small, keep it concise,<br>
> keep it focused. It's extremely important to communicate the intent of<br>
> the release to the rest of the community. Do not forget Glance *is* a<br>
> critical piece of every cloud.<br>
><br>
> Glance's community is not formed by the core team. It's formed by<br>
> every person willing to dedicate time to the project either on reviews<br>
> or code. Work with them, encourage them. They *are* helping the<br>
> project. Some folks simply don't want to do reviews, that's fine. They<br>
> are still helping with code and bug fixes.<br>
> Recognize that and make sure they feel part of the community because<br>
> they are.<br>
> Expanding the core team is great as long as you can ensure folks in<br>
> the team are aligned with the team's priorities. Welcome new members<br>
> and do it gradually.<br>
><br>
> One more thing, learn to delegate. During my time as a PTL, I relied<br>
> on other members as much as possible for keeping up with some tasks.<br>
> For instance, Erno Kuvaja helped immensely with releases and stable<br>
> maintenance, Nikhil Komawar kept the team updated about the<br>
> cross-project initiatives, Stuart Mclaren, Hemanth Makkapati and Brian<br>
> Rosmaita worked with the vulnerability team on security issues, etc.<br>
> Thanks to all of them for their immense help and I do hope you'll keep<br>
> up at what you're doing :). In other words, burnout is real and you<br>
> gotta take care of yourself too. Work with the community, there's no<br>
> need to take everything on your shoulders as you might end up dropping<br>
> some balls. When folks don't show up on reviews and they don't share<br>
> their opinions, do not give those as granted. Find them and ask for<br>
> it.<br>
><br>
> And please, I beg you, let's get rid of v1!<br>
><br>
> [0] <a href="http://blog.flaper87.com/post/something-about-being-a-ptl/" rel="noreferrer" target="_blank">http://blog.flaper87.com/post/something-about-being-a-ptl/</a><br>
><br>
> Thanks for reading this long email (or to at least have bothered to<br>
> skip till the end of it ;) Flavio<br>
><br>
> P.S: I've posted this in my blog too:<br>
> <a href="http://blog.flaper87.com/post/glance-mitaka-passing-the-torch" rel="noreferrer" target="_blank">http://blog.flaper87.com/post/glance-mitaka-passing-the-torch</a><br>
> /<br>
><br>
><br>
> ______________________________________________________________________<br>
</div></div>> ____ OpenStack Development Mailing List (not for usage questions)<br>
<div class="HOEnZb"><div class="h5">> Unsubscribe:<br>
> <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div></div>