Re: [openstack-dev] [release][ptl][all] self-service branch management

2016-12-16 Thread Doug Hellmann 
Excerpts from joehuang's message of 2016-12-16 01:03:03 +:
> Hello, Doug,
> 
> This is great. One question about the branch patches. In the past, when a new 
> branch was created, we often have to update the devstack plugin to pull the 
> code from correct branch. So if self-service branch management is available, 
> will the devstack plugin will be updated with one patch too?

The branching script makes 3 updates:

1. Modify .gitreview in the branch to make the default for patches
   submitted to that branch work properly.
2. Modify tox.ini in the branch to update the URL for the constraints
   file, for projects using constraints.
3. Update the Sphinx files for release notes build in master to add the
   new branch page.

We don't do anything with devstack plugins, but we can consider
other updates if there is enough consistency across projects to
make it possible to script them.

Doug

> 
> Best Regards
> Chaoyi Huang (joehuang)
> 
> 
> From: Doug Hellmann [d...@doughellmann.com]
> Sent: 14 December 2016 21:45
> To: openstack-dev
> Subject: [openstack-dev] [release][ptl][all] self-service branch management
> 
> [Sending again due to mail delivery issues.]
> 
> The release team is pleased to announce that the branch automation
> work is now complete, and that teams can now manage feature and
> stable branch creation through the openstack/releases repository.
> 
> Creating a branch is very similar to creating a release: Edit the
> appropriate file in the releases repo to add the branch information,
> let the release team review it, and then when the patch is approved
> the bots make your branch. New branches come with patches to update
> .gitreview, reno, and constraint settings where needed.
> 
> For the complete details about how to format a branch request, see
> the README.rst file in the repo [1].
> 
> Thanks, as always, to the Infra team for their help in implementing
> this automation.
> 
> Doug
> 
> [1] http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n63
> 

__
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] [release][ptl][all] self-service branch management

2016-12-15 Thread joehuang 
Hello, Doug,

This is great. One question about the branch patches. In the past, when a new 
branch was created, we often have to update the devstack plugin to pull the 
code from correct branch. So if self-service branch management is available, 
will the devstack plugin will be updated with one patch too?

Best Regards
Chaoyi Huang (joehuang)


From: Doug Hellmann [d...@doughellmann.com]
Sent: 14 December 2016 21:45
To: openstack-dev
Subject: [openstack-dev] [release][ptl][all] self-service branch management

[Sending again due to mail delivery issues.]

The release team is pleased to announce that the branch automation
work is now complete, and that teams can now manage feature and
stable branch creation through the openstack/releases repository.

Creating a branch is very similar to creating a release: Edit the
appropriate file in the releases repo to add the branch information,
let the release team review it, and then when the patch is approved
the bots make your branch. New branches come with patches to update
.gitreview, reno, and constraint settings where needed.

For the complete details about how to format a branch request, see
the README.rst file in the repo [1].

Thanks, as always, to the Infra team for their help in implementing
this automation.

Doug

[1] http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n63

__
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] [release][ptl][all] self-service branch management

2016-12-14 Thread Tony Breeds 
On Wed, Dec 14, 2016 at 08:51:29AM -0500, Ian Cordasco wrote:

> I do have one question, will creating the branch's end-of-life
> eventually work the same way? For example, Glance's projects were
> missed in the recent liberty end of life work. Could we submit a

For the record glance repos were deliberately pushed to phase 2 as when I
generated the list there was an open review to tag the EOL release and then
once that was done it' was only partially successful and I wanted to allow for
any corrective action required.

> review to do that work so Josh & Tony don't have to or is that
> something that isn't planned to work through openstack/releases?

As Jeremy and Doug have explained that's the plan but it'll be pike before most
of the tools are written and then we'll be blocked on the 2.14 (possibly 2.13)
gerrit release and deployment to our infrastructure.

Yours Tony.


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] [release][ptl][all] self-service branch management

2016-12-14 Thread Doug Hellmann 
Excerpts from Emilien Macchi's message of 2016-12-14 15:34:27 -0500:
> On Wed, Dec 14, 2016 at 8:45 AM, Doug Hellmann  wrote:
> > [Sending again due to mail delivery issues.]
> >
> > The release team is pleased to announce that the branch automation
> > work is now complete, and that teams can now manage feature and
> > stable branch creation through the openstack/releases repository.
> >
> > Creating a branch is very similar to creating a release: Edit the
> > appropriate file in the releases repo to add the branch information,
> > let the release team review it, and then when the patch is approved
> > the bots make your branch. New branches come with patches to update
> > .gitreview, reno, and constraint settings where needed.
> >
> > For the complete details about how to format a branch request, see
> > the README.rst file in the repo [1].
> >
> > Thanks, as always, to the Infra team for their help in implementing
> > this automation.
> 
> That's awesome, and we were looking forward to it.
> Regarding schedule, it's not clear to me when we *have to* propose the 
> branches.
> 
> For example in TripleO, we've noticed that our work on upgrades
> usually happens more at the end of a cycle so we would like to wait
> for the last time before branching our repos.
> Example with Ocata, when would you suggest to start branching?

We will expect most teams following the cycle-with-milestones model
to branch at RC1, as part of the usual milestone-centric process.

Projects following-the cycle-with-intermediary or cycle-trailing
models should branch when the equivalent of their first release
candidate is ready. It's going to be up to the individual teams to
decide that, because you're better placed to know when it's too
early to branch. Keep in mind that the reason the milestone-based
projects use release candidates is to have a stable version of the
project ready to be tested before being marked as a final release.

Based on that criteria, when development (feature and bug fixing)
slows down toward the end of the cycle, start thinking about
branching.

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] [release][ptl][all] self-service branch management

2016-12-14 Thread Emilien Macchi 
On Wed, Dec 14, 2016 at 8:45 AM, Doug Hellmann  wrote:
> [Sending again due to mail delivery issues.]
>
> The release team is pleased to announce that the branch automation
> work is now complete, and that teams can now manage feature and
> stable branch creation through the openstack/releases repository.
>
> Creating a branch is very similar to creating a release: Edit the
> appropriate file in the releases repo to add the branch information,
> let the release team review it, and then when the patch is approved
> the bots make your branch. New branches come with patches to update
> .gitreview, reno, and constraint settings where needed.
>
> For the complete details about how to format a branch request, see
> the README.rst file in the repo [1].
>
> Thanks, as always, to the Infra team for their help in implementing
> this automation.

That's awesome, and we were looking forward to it.
Regarding schedule, it's not clear to me when we *have to* propose the branches.

For example in TripleO, we've noticed that our work on upgrades
usually happens more at the end of a cycle so we would like to wait
for the last time before branching our repos.
Example with Ocata, when would you suggest to start branching?

> Doug
>
> [1] http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n63
>
> __
> 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

Re: [openstack-dev] [release][ptl][all] self-service branch management

2016-12-14 Thread Doug Hellmann 
Excerpts from Jeremy Stanley's message of 2016-12-14 14:28:30 +:
> On 2016-12-14 08:51:29 -0500 (-0500), Ian Cordasco wrote:
> [...]
> > I do have one question, will creating the branch's end-of-life
> > eventually work the same way? For example, Glance's projects were
> > missed in the recent liberty end of life work. Could we submit a
> > review to do that work so Josh & Tony don't have to or is that
> > something that isn't planned to work through openstack/releases?
> 
> The EOL process is still a little different because it relies on
> branch deletion, which is not an explicit permission we can delegate
> in the version of Gerrit we're running today. There's some
> indication that it will be possible in Gerrit 2.14 (not yet
> released) and we might even be able to backport that feature to 2.13
> (the version to which we're currently working on upgrading). So yes,
> there is an expectation we will safely automate EOL'ing but we don't
> have an exact timeline for it yet.

When we discussed it at the summit, the idea was to think about it
this cycle with the intent of implementing it for Pike. If we take
the approach we've used for the other automation, that would mean
scripting it out to run manually, then building something to take
inputs for the scripts from the YAML files in the releases repo
while still running the scripts manually, and then running all of
that automatically in the job. It sounds like that last part is
blocked for now, but we should be able to make some progress on the
rest of it.

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] [release][ptl][all] self-service branch management

2016-12-14 Thread Ian Cordasco 
 

-Original Message-
From: Jeremy Stanley <fu...@yuggoth.org>
Reply: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Date: December 14, 2016 at 08:30:22
To: OpenStack Development Mailing List (not for usage questions) 
<openstack-dev@lists.openstack.org>
Subject:  Re: [openstack-dev] [release][ptl][all] self-service branch management

> On 2016-12-14 08:51:29 -0500 (-0500), Ian Cordasco wrote:
> [...]
> > I do have one question, will creating the branch's end-of-life
> > eventually work the same way? For example, Glance's projects were
> > missed in the recent liberty end of life work. Could we submit a
> > review to do that work so Josh & Tony don't have to or is that
> > something that isn't planned to work through openstack/releases?
>  
> The EOL process is still a little different because it relies on
> branch deletion, which is not an explicit permission we can delegate
> in the version of Gerrit we're running today. There's some
> indication that it will be possible in Gerrit 2.14 (not yet
> released) and we might even be able to backport that feature to 2.13
> (the version to which we're currently working on upgrading). So yes,
> there is an expectation we will safely automate EOL'ing but we don't
> have an exact timeline for it yet.

Awesome! Thank you so much for that answer. =D

--  
Ian Cordasco


__
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] [release][ptl][all] self-service branch management

2016-12-14 Thread Jeremy Stanley 
On 2016-12-14 08:51:29 -0500 (-0500), Ian Cordasco wrote:
[...]
> I do have one question, will creating the branch's end-of-life
> eventually work the same way? For example, Glance's projects were
> missed in the recent liberty end of life work. Could we submit a
> review to do that work so Josh & Tony don't have to or is that
> something that isn't planned to work through openstack/releases?

The EOL process is still a little different because it relies on
branch deletion, which is not an explicit permission we can delegate
in the version of Gerrit we're running today. There's some
indication that it will be possible in Gerrit 2.14 (not yet
released) and we might even be able to backport that feature to 2.13
(the version to which we're currently working on upgrading). So yes,
there is an expectation we will safely automate EOL'ing but we don't
have an exact timeline for it yet.
-- 
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-dev] [release][ptl][all] self-service branch management

2016-12-14 Thread Doug Hellmann 
The release team is pleased to announce that the branch automation
work is now complete, and that teams can now manage feature and
stable branch creation through the openstack/releases repository.

Creating a branch is very similar to creating a release: Edit the
appropriate file in the releases repo to add the branch information,
let the release team review it, and then when the patch is approved
the bots make your branch. New branches come with patches to update
.gitreview, reno, and constraint settings where needed.

For the complete details about how to format a branch request, see
the README.rst file in the repo [1].

Thanks, as always, to the Infra team for their help in implementing
this automation.

Doug

[1] http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n63

__
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] [release][ptl][all] self-service branch management

2016-12-14 Thread Ian Cordasco 
-Original Message-
From: Doug Hellmann <d...@doughellmann.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev@lists.openstack.org>
Date: December 14, 2016 at 07:47:58
To: openstack-dev <openstack-dev@lists.openstack.org>
Subject:  [openstack-dev] [release][ptl][all] self-service branch management

> [Sending again due to mail delivery issues.]
>
> The release team is pleased to announce that the branch automation
> work is now complete, and that teams can now manage feature and
> stable branch creation through the openstack/releases repository.
>
> Creating a branch is very similar to creating a release: Edit the
> appropriate file in the releases repo to add the branch information,
> let the release team review it, and then when the patch is approved
> the bots make your branch. New branches come with patches to update
> .gitreview, reno, and constraint settings where needed.
>
> For the complete details about how to format a branch request, see
> the README.rst file in the repo [1].
>
> Thanks, as always, to the Infra team for their help in implementing
> this automation.
>
> Doug
>
> [1] http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n63

This looks excellent, Doug!

Thank you Release & Infra teams!

I do have one question, will creating the branch's end-of-life
eventually work the same way? For example, Glance's projects were
missed in the recent liberty end of life work. Could we submit a
review to do that work so Josh & Tony don't have to or is that
something that isn't planned to work through openstack/releases?

Cheers,
--
Ian Cordasco

__
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] [release][ptl][all] self-service branch management

2016-12-14 Thread Doug Hellmann 
[Sending again due to mail delivery issues.]

The release team is pleased to announce that the branch automation
work is now complete, and that teams can now manage feature and
stable branch creation through the openstack/releases repository.

Creating a branch is very similar to creating a release: Edit the
appropriate file in the releases repo to add the branch information,
let the release team review it, and then when the patch is approved
the bots make your branch. New branches come with patches to update
.gitreview, reno, and constraint settings where needed.

For the complete details about how to format a branch request, see
the README.rst file in the repo [1].

Thanks, as always, to the Infra team for their help in implementing
this automation.

Doug

[1] http://git.openstack.org/cgit/openstack/releases/tree/README.rst#n63

__
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