On Thu, Jul 3, 2014 at 5:00 AM, Jeremy Stanley fu...@yuggoth.org wrote:
On 2014-07-02 22:19:29 +0400 (+0400), Yuriy Taraday wrote:
[...]
It looks like mirrors will have to bear having a number of dead branches
in
them - one for each release.
A release manager will delete proposed/juno
On 2014-07-03 11:20:43 +0400 (+0400), Yuriy Taraday wrote:
I mean other mirrors like we have in our local net. Given not so
good connection to upstream repos (the reason we have this mirror
in the first place) I can't think of reliable way to clean them
up. Where can I find scripts that
Hello.
On Fri, Jun 27, 2014 at 4:44 PM, Thierry Carrez thie...@openstack.org
wrote:
For all those reasons, we decided at the last summit to use unique
pre-release branches, named after the series (for example,
proposed/juno). That branch finally becomes stable/juno at release
time. In
On 2014-07-02 16:14:52 +0400 (+0400), Yuriy Taraday wrote:
Why do we need these short-lived 'proposed' branches in any form?
Why can't we just use release branches for this and treat them as
stable when appropriate tag is added to some commit in them?
The primary reasons are:
1. People
On 2014-07-02 22:19:29 +0400 (+0400), Yuriy Taraday wrote:
[...]
It looks like mirrors will have to bear having a number of dead branches in
them - one for each release.
A release manager will delete proposed/juno when stable/juno is
branched from it, and branch deletions properly propagate to
On 6/27/2014 7:44 AM, Thierry Carrez wrote:
Hi everyone,
Since the dawn of time, we have been using milestone-proposed branches
for milestone and final release branches. Those would get
milestone-critical and release-critical bugfixes backports, while the
master branch can continue to be open
Hi everyone,
Since the dawn of time, we have been using milestone-proposed branches
for milestone and final release branches. Those would get
milestone-critical and release-critical bugfixes backports, while the
master branch can continue to be open for development.
However, reusing the same
