On Wed, 2 Dec 2015 06:42:09 -0500 (EST)
Kamil Paral <kparal(a)redhat.com> wrote:
If the update is pending stable and just not pushed, it might sense
to move it one day, yes (most probably skipping weekends, though). If
it needs more testing, we might decide to postpone it a several days.
If it's not available at all yet, waiting an extra week might be the
right choice. So it would depend on the situation and best guess of
folks at Go/No-Go.
But then no one knows whats happening. People could assume it's go and
do a bunch of release prep, but find out it's not and then have wasted
their time (or at least rushed when they had more time).
> Leaves less time to sync mirrors,
> update common bugs, etc etc.
I would say the opposite - all of that can start happening right
away, it's not blocked on waiting for the FN-x push. So in case the
announcement gets out on Tuesday as usual, it's the same time, but if
it gets pushed back to Wednesday or later day, it's more time for
these tasks to happen. The only exception is that FN-x updates repo,
which will get shorter sync time because we want to make sure people
download the fixed packages, not old ones. Currently that behavior is
There's a bunch of things that coordinate for the release. IMHO
shifting it a few days would make those more difficult.
"Hey mirrors, here's f23 content, our release is... sometime next week,
we don't have our crap together enough to tell you what day, but expect
someday the bit will flip and you will get a bunch more traffic. Hope
that helps you"
> So, the alternative there would be to slip a week to get it pushed,
> but some people may find that excessive.
That's why I wanted to propose something more flexible, but hey, it's
just an idea.
In the future, these issues should be tracked by blocker bugs app
using bugzilla tracker and a specific keyword, so we should not lose
track of this. But as mentioned, pushing to stable is not enough, we
also need to make sure old content is not served to users. That's why
the "dropping alternative metadata from metalink" idea. We can file a
releng ticket for this, and either include a description of what
needs to be done, or link to some wiki SOP. QA can take care of all
of that. The only thing that we need to ensure is that it really is
handled before the announcement goes live, so it needs to be listed
somewhere in RelEng/Infra "new release" SOP.
I definitely like the idea of tracking this better and making sure to
tell releng whats needed. In fact, I think that may be all we need,
especially with bodhi2 pushing updates faster than 1 did.