Re: [openstack-dev] [relmgt] PTL candidacy for Pike
On Thu, Jan 26, 2017 at 7:24 AM, Thierry Carrez wrote: > Hi! > > I would like to submit my candidacy to return as PTL of the Release > Management team for the Pike cycle. > > You may remember me as the release manager from Bexar to Grizzly, and > PTL of the Release Management team from Havana to Liberty. I'd like to > thank Doug Hellmann for his service as PTL from Mitaka to Ocata. Under > his leadership, the Release Management team transformed from an artisan > shop into a highly efficient and scalable factory. His focus on writing > down everything and introducing automation everywhere will make the work > of succeeding him easier than ever. But we always wanted to introduce > regular PTL rotation in the team, so Doug won't run again, and for Pike > I volunteer to take back that baton. > > I would personally prefer to let someone else take it (and would love to > see other election candidates for this role !), but during this cycle we > probably failed to grow new members who would want to take over team > leadership. People with interest in cross-project functions like Release > Management and time to dedicate to it are a rare resource those days. Thanks for volunteering, Thierry! (and Doug for your outstanding work in the last cycles). Maybe could you (and Doug) document (if not done already, sorry if that's the case) your tasks on Release management, and the "things to know" about this topic, on https://releases.openstack.org. Also we could eventually organize a training session during a PTG (or virtual?), to get attraction from folks volunteering to help and eventually become good enough to apply PTL one day. Just some ideas here, feel free to comment. > If elected, my plan is to: > > - continue in the direction set by Doug toward more self-service > automation around Release Management, and focus the team on providing a > framework, advice and last-minute sanity checks before tagging releases. > > - anticipate changes that we may need to do to accommodate the > introduction of new programming languages. > > - add a few new members in the team, to grow the set of people able to > participate in a PTL rotation scheme in the future. > > Thanks for reading until the last line! > > -- > 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 -- Emilien Macchi __ 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-dev] [relmgt] PTL candidacy for Pike
Hi! I would like to submit my candidacy to return as PTL of the Release Management team for the Pike cycle. You may remember me as the release manager from Bexar to Grizzly, and PTL of the Release Management team from Havana to Liberty. I'd like to thank Doug Hellmann for his service as PTL from Mitaka to Ocata. Under his leadership, the Release Management team transformed from an artisan shop into a highly efficient and scalable factory. His focus on writing down everything and introducing automation everywhere will make the work of succeeding him easier than ever. But we always wanted to introduce regular PTL rotation in the team, so Doug won't run again, and for Pike I volunteer to take back that baton. I would personally prefer to let someone else take it (and would love to see other election candidates for this role !), but during this cycle we probably failed to grow new members who would want to take over team leadership. People with interest in cross-project functions like Release Management and time to dedicate to it are a rare resource those days. If elected, my plan is to: - continue in the direction set by Doug toward more self-service automation around Release Management, and focus the team on providing a framework, advice and last-minute sanity checks before tagging releases. - anticipate changes that we may need to do to accommodate the introduction of new programming languages. - add a few new members in the team, to grow the set of people able to participate in a PTL rotation scheme in the future. Thanks for reading until the last line! -- 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-dev] [relmgt] PTL Candidacy
I am announcing my candidacy for PTL for the Release Management team for the Mitaka release cycle. Although I only formally joined the release management team during the Liberty cycle, I have been active in release-related activities for much longer while serving as the PTL for Oslo. I worked with the release and infrastructure teams to develop the release tools and processes we use for Oslo libraries, and applying them to other projects that now manage libraries. I am a core reviewer on the requirements repository, and this cycle I started the work on automating project releases using the new openstack/releases repository. I was also involved in the process of moving server projects away from date-based versioning to using quasi-semantic versioning. Late in the Liberty cycle I started building reno, a new release note management tool, based on some requirements we gathered within the release team. My goal for the release team during Mitaka is to automate more of the work with a review process that allows projects to be self-service, with some lightweight oversight to manage release timing, version numbers, and messaging. I would like to complete the work we have started in the releases repository to allow project teams to ask for releases at any point in the cycle, thereby encouraging them to shift from a milestone-based to “intermediate” release model. Changing release models will reduce the effort required to create a release by removing some of the pressure to synchronize the activities of all projects on milestones and make it easier to release more often, while still giving us the benefits of stable branches for longer-term maintenance of selected versions. Milestones can become guidelines, rather than hard deadlines. Doug __ 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] [RelMgt] PTL Candidacy
confirmed On 04/08/2015 06:18 AM, Thierry Carrez wrote: > Hello list, > > I'm announcing my candidacy for OpenStack Release Cycle Management PTL > for the Liberty cycle. > > Release Management is a function that existed since the inception of > OpenStack and I always filled that role, so this candidacy may sound > like business as usual. I like to think there are a lot of important > changes we need to implement during the Liberty cycle though, which > makes it extra-interesting. > > First, we need to scale and evolve the various Release Cycle Management > subteams to accommodate the big-tent initiative. How to scale those > central activities to a higher number of OpenStack projects ? That > effort is already started for the stable maintenance subteam, which > implemented a number of structural changes to support more projects > while preserving the ideals outlined in the Stable branch policy. For > the release subteam, that means evolving from doing only direct release > management to providing advice, reusable tools and documented processes. > It is a pretty significant change that will require a bit of work and > recruitment in the team, and I'd like to lead that change if you give me > your trust. > > Second, we need to have a discussion on long-term evolution of the > release model to better serve our users. The "6-month cycle with 3 > intermediary milestones" was always a compromise between our stable > support and documentation capacity and our goal of "releasing early, > releasing often". As our base projects slowly mature and we welcome more > "OpenStack" projects, we want to reconsider that trade-off and at least > bring some flexibility to it. I think my experience there can be useful > while we navigate that treacherous pass. > > You'll note that I'm not mentioning the Vulnerability Management Subteam > anymore, since that one got reassigned to the new "Security" team that > just got approved. > > Thank you for your consideration ! > signature.asc Description: OpenPGP digital 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
[openstack-dev] [RelMgt] PTL Candidacy
Hello list, I'm announcing my candidacy for OpenStack Release Cycle Management PTL for the Liberty cycle. Release Management is a function that existed since the inception of OpenStack and I always filled that role, so this candidacy may sound like business as usual. I like to think there are a lot of important changes we need to implement during the Liberty cycle though, which makes it extra-interesting. First, we need to scale and evolve the various Release Cycle Management subteams to accommodate the big-tent initiative. How to scale those central activities to a higher number of OpenStack projects ? That effort is already started for the stable maintenance subteam, which implemented a number of structural changes to support more projects while preserving the ideals outlined in the Stable branch policy. For the release subteam, that means evolving from doing only direct release management to providing advice, reusable tools and documented processes. It is a pretty significant change that will require a bit of work and recruitment in the team, and I'd like to lead that change if you give me your trust. Second, we need to have a discussion on long-term evolution of the release model to better serve our users. The "6-month cycle with 3 intermediary milestones" was always a compromise between our stable support and documentation capacity and our goal of "releasing early, releasing often". As our base projects slowly mature and we welcome more "OpenStack" projects, we want to reconsider that trade-off and at least bring some flexibility to it. I think my experience there can be useful while we navigate that treacherous pass. You'll note that I'm not mentioning the Vulnerability Management Subteam anymore, since that one got reassigned to the new "Security" team that just got approved. Thank you for your consideration ! -- 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] [RelMgt] PTL candidacy
confirmed On 24/09/14 08:56 AM, Thierry Carrez wrote: > I am writing to announce my candidacy for OpenStack Release Cycle > Management PTL. > > This is a little-known program, so I'll take the bi-yearly opportunity > to explain what this covers: > > 1. Release Management > This is about coordinating the process that will turn the master > branches of the integrated projects into a common release at the end of > our development cycle. It's no longer a one-person job: Russell Bryant > and Sean Dague, in particular, have stepped up during the Juno cycle to > help me there. > > 2. Stable Maintenance > This is about maintaining stable branches, reviewing backports according > to our Stable branch policy, and publishing point releases from time to > time. Alan Pevec is our subteam lead there, playing the drum that keeps > us all in sync. > > 3. Vulnerability Management > This is about handling incoming vulnerability reports and push them > through our patching and advisory process. Tristan de Cacqueray has been > taking on the bulk of the work there. > > If I get elected, we have several challenges ahead of us for the Kilo > cycle. In particular, we'll need to adapt our rules and processes to > either support more projects, or follow structural changes (if any). > > For example, I think the centralized stable maintenance team does not > scale that well beyond 10 projects, and we may need to refactor it into > team-specific stable maintenance groups. If we adopt Monty's layer #1, > the release management team will have less work to produce the common > release, but will need to educate and build reusable tooling for > everyone else to be able to handle releases. These are interesting times :) > > Thanks for taking the time to read this! > signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [RelMgt] PTL candidacy
I am writing to announce my candidacy for OpenStack Release Cycle Management PTL. This is a little-known program, so I'll take the bi-yearly opportunity to explain what this covers: 1. Release Management This is about coordinating the process that will turn the master branches of the integrated projects into a common release at the end of our development cycle. It's no longer a one-person job: Russell Bryant and Sean Dague, in particular, have stepped up during the Juno cycle to help me there. 2. Stable Maintenance This is about maintaining stable branches, reviewing backports according to our Stable branch policy, and publishing point releases from time to time. Alan Pevec is our subteam lead there, playing the drum that keeps us all in sync. 3. Vulnerability Management This is about handling incoming vulnerability reports and push them through our patching and advisory process. Tristan de Cacqueray has been taking on the bulk of the work there. If I get elected, we have several challenges ahead of us for the Kilo cycle. In particular, we'll need to adapt our rules and processes to either support more projects, or follow structural changes (if any). For example, I think the centralized stable maintenance team does not scale that well beyond 10 projects, and we may need to refactor it into team-specific stable maintenance groups. If we adopt Monty's layer #1, the release management team will have less work to produce the common release, but will need to educate and build reusable tooling for everyone else to be able to handle releases. These are interesting times :) Thanks for taking the time to read this! -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [RelMgt] PTL candidacy
confirmed n 03/31/2014 12:19 PM, Thierry Carrez wrote: > Hi everyone, > > I'm writing to announce my candidacy for the Release management Program > Technical Lead position. > > The Release management program is composed of 3 subteams. > > On the release cycle management front, during the Icehouse cycle we > successfully handled the additional load by switching to a new weekly > release meeting format and having 1:1s PTL sync points before the actual > meeting, to concentrate meeting time on cross-project issues. I think it > worked well and I would like to continue under the same format for Juno. > > On the stable branch team front, moving from 13-month to 11-month > support period helped in keeping stable branches sane, and Alan and Adam > kept issuing point releases on schedule. > > On the vulnerability management front, we expanded the team with two new > OSSA coordinators and managed to keep on top of incoming issues. We also > started work to clarify which repositories were covered by security > support and have clear contact points in each program for security response. > > If elected at this position for the Juno cycle I intend to continue > these efforts. On the release cycle management side we'll have a new > integrated project (Sahara) and I'll work on spreading the load of the > release management role a bit further (a goal internally codenamed > "Project Vacation"). We'll try to maintain stable branch support > timeframes at their current levels. We'll work on Vulnerability > Management Team tooling, so that security patches are easier to produce > and test, and OSSAs are easier to review and publish. > > Thanks for your consideration ! > signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [RelMgt] PTL candidacy
Hi everyone, I'm writing to announce my candidacy for the Release management Program Technical Lead position. The Release management program is composed of 3 subteams. On the release cycle management front, during the Icehouse cycle we successfully handled the additional load by switching to a new weekly release meeting format and having 1:1s PTL sync points before the actual meeting, to concentrate meeting time on cross-project issues. I think it worked well and I would like to continue under the same format for Juno. On the stable branch team front, moving from 13-month to 11-month support period helped in keeping stable branches sane, and Alan and Adam kept issuing point releases on schedule. On the vulnerability management front, we expanded the team with two new OSSA coordinators and managed to keep on top of incoming issues. We also started work to clarify which repositories were covered by security support and have clear contact points in each program for security response. If elected at this position for the Juno cycle I intend to continue these efforts. On the release cycle management side we'll have a new integrated project (Sahara) and I'll work on spreading the load of the release management role a bit further (a goal internally codenamed "Project Vacation"). We'll try to maintain stable branch support timeframes at their current levels. We'll work on Vulnerability Management Team tooling, so that security patches are easier to produce and test, and OSSAs are easier to review and publish. Thanks for your consideration ! -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
