On Wed, 2 Dec 2015 06:42:09 -0500 (EST) Kamil Paral <kpa...@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 > undefined. 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. Sure. ;) ...snip... > 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. kevin
pgpVfqJY7ZUIt.pgp
Description: OpenPGP digital signature
-- test mailing list test@lists.fedoraproject.org To unsubscribe: http://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org
