Re: [openstack-dev] [relmgt] PTL candidacy for Pike

[Emilien Macchi]

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

[Thierry Carrez]

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

[Doug Hellmann]

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

[openstack-dev] [RelMgt] PTL Candidacy

[Thierry Carrez]

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

[Tristan Cacqueray]

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

[Thierry Carrez]

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

[Tristan Cacqueray]

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

[Thierry Carrez]

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

Re: [openstack-dev] [RelMgt] PTL candidacy

[Tristan Cacqueray]

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