Re: Non-image blocker process change proposal

> > Here we go: > > https://git.fedorahosted.org/cgit/fedora-qa.git/tree/track-previous-release-blocker.py > > #!/usr/bin/env python2 > > there's no excuse for this. ;) I'll do better in future, I promise! :) > > What's the deal with making args.nvr a list then requiring it to be > exactly

Re: Non-image blocker process change proposal

On Wed, 2016-03-02 at 09:45 -0500, Kamil Paral wrote: > > > > > > > > It would be nice of course if there was a tool for doing this, then the > > > text could be reduced to 'run the magic tool and make sure it says OK'. > > I'll do some thinking whether I can write such a magical tool. > Here we

Re: Non-image blocker process change proposal

> > > It would be nice of course if there was a tool for doing this, then the > > > text could be reduced to 'run the magic tool and make sure it says OK'. > > > > I'll do some thinking whether I can write such a magical tool. > > Here we go: >

Re: Non-image blocker process change proposal

> > It would be nice of course if there was a tool for doing this, then the > > text could be reduced to 'run the magic tool and make sure it says OK'. > > I'll do some thinking whether I can write such a magical tool. Here we go:

Re: Non-image blocker process change proposal

On Tue, 2016-03-01 at 06:28 -0500, Kamil Paral wrote: > > > > IIRC the text in fact uses "unaddressed" specifically *instead* of > > saying "open", as a slight fudge for cases where a bug might still be > > open but is in fact fully 'addressed'. We *are* reducing the likelihood > > of that

Re: Non-image blocker process change proposal

> > Then I added the process of tracking AcceptedPreviousRelease fixes > > and verifying that the related updates repo metalink is in shape. > > This generally looks fine, my only concern is that it's extremely > specific stuff that might go stale quite easily. But since it's not at > all an

Re: Non-image blocker process change proposal

> Hello folks, > > I'd like to return to the high-level overview for this topic and discuss the > changes we plan to do in our SOPs. Since there was not much feedback, we agreed on a QA meeting that I'll just go ahead and draft all related SOP changes. Here we go: 1. SOP blocker bug process:

Re: Non-image blocker process change proposal

> > Do you have some other ideas/proposals, in general or in some specific > > situations regarding the slip length? > > > I'm wondering if there would be interest in hosting a file containing > upgrade requirements for each version. For example it could have the > package version requirements

Re: Non-image blocker process change proposal

On Wed, 2016-01-13 at 10:13 -0700, Chris Murphy wrote: > On Tue, Jan 12, 2016 at 6:06 PM, Samuel Sieb wrote: > > On 01/12/2016 08:37 AM, Kamil Paral wrote: > > > > > > Do you have some other ideas/proposals, in general or in some > > > specific > > > situations regarding the

Re: Non-image blocker process change proposal

On Wed, Jan 13, 2016 at 2:55 PM, Adam Williamson wrote: > On Wed, 2016-01-13 at 10:13 -0700, Chris Murphy wrote: >> On Tue, Jan 12, 2016 at 6:06 PM, Samuel Sieb wrote: >> > On 01/12/2016 08:37 AM, Kamil Paral wrote: >> > > >> > > Do you have some

Re: Non-image blocker process change proposal

On Tue, Jan 12, 2016 at 6:06 PM, Samuel Sieb wrote: > On 01/12/2016 08:37 AM, Kamil Paral wrote: >> >> Do you have some other ideas/proposals, in general or in some specific >> situations regarding the slip length? >> > I'm wondering if there would be interest in hosting a file

Re: Non-image blocker process change proposal

On 01/12/2016 08:37 AM, Kamil Paral wrote: Do you have some other ideas/proposals, in general or in some specific situations regarding the slip length? I'm wondering if there would be interest in hosting a file containing upgrade requirements for each version. For example it could have the

Re: Non-image blocker process change proposal

> Up top I'd like to note there are really kind of two buckets of > 'special blockers' for any given release. If the release being > validated is N, they are: > > 1) Bugs for which the fix must be in the 0-day update set for N > 2) Bugs for which the fix must be stable in N-1 and N-2 by N release

Re: Non-image blocker process change proposal

> 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. I see 3 parts here: 1. tracking these issues (that will be done by QA with our new trackers) 2.

Re: Non-image blocker process change proposal

On Wed, 2 Dec 2015 06:42:09 -0500 (EST) Kamil Paral 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

Re: Non-image blocker process change proposal

On Fri, 2015-12-04 at 12:20 -0600, Dennis Gilmore wrote: > there is the potential always of hitting issues. with upgrades. an older > release gets a higher nvr and things get messy. It is not an issue just at > release time. This is true, but release time is important, because we're very

Re: Non-image blocker process change proposal

On Wednesday, December 02, 2015 06:42:09 AM Kamil Paral wrote: > > > Taking all of this into account, would this be a reasonable idea? > > > 1. At Go/No-Go voting time, all updates which block F-N release but > > > belong to F-M (M > > is not

Re: Non-image blocker process change proposal

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/02/2015 06:42 AM, Kamil Paral wrote: >>> Taking all of this into account, would this be a reasonable >>> idea? 1. At Go/No-Go voting time, all updates which block F-N >>> release but belong to F-M (M>> pushed

Re: Non-image blocker process change proposal

> > Taking all of this into account, would this be a reasonable idea? > > 1. At Go/No-Go voting time, all updates which block F-N release but > > belong to F-M (M > is not the case and it's the last blocking issue, selected tasks > > (like

Re: Non-image blocker process change proposal

On Tue, 1 Dec 2015 07:21:04 -0500 (EST) Kamil Paral wrote: > Taking all of this into account, would this be a reasonable idea? > 1. At Go/No-Go voting time, all updates which block F-N release but > belong to F-M (M is not

Re: Non-image blocker process change proposal

On Tue, 2015-12-01 at 19:40 -0700, Kevin Fenzi wrote: > One thing that perhaps we could improve is to somehow note these > sorts > of things to releng. I just checked irc logs and I didn't see any > mention of that dnf-system-upgrade plugin update being important > until > nov 3rd. Would a tracker

Re: Non-image blocker process change proposal

> I've tried to find out some of the technical details of this. Mirrormanager > publishes the current hash of repomd.xml, and also hashes of usually up to > two older repomd.xml files. You can see it here: > https://mirrors.fedoraproject.org/metalink?repo=rawhide=x86_64 > It's the tag in and

Re: Non-image blocker process change proposal

> Accepted0Day (for bugs where the fix must appear in 0-day updates for > the new release) > AcceptedStable (for bugs where the fix must appear in updates for the > previous stable release(s) by release day of the new release) > > I'm not 100% married to either of those, especially the second. If

Re: Non-image blocker process change proposal

> OK. I was just trying to point out that there needs to be about 1-2 day > period (releng knows best) between the 0 day push and the actual > announcement. Maybe that's why we usually have 4 days between Go and the > announcement? I don't know whether there's a releng process for it or not, > but

Re: Non-image blocker process change proposal

On Fri, 2015-11-20 at 16:18 +0530, Sudhir D wrote: > > > I don't think it's appropriate to turn FEs into blockers automatically, > > in fact there are obvious cases where it certainly wouldn't be > > appropriate: bugs in non-blocking desktops are typically taken as FEs, > > for instance, as are

Re: Non-image blocker process change proposal

On Wed, 2015-11-18 at 16:36 -0800, Adam Williamson wrote: > #2 MOAR METADATA > > > The alternative is to make the existing Blocker trackers do more work. > In this model we wouldn't add any new tracker bugs; we'd just add new > 'magic words' in the Whiteboard field. Right now,

Re: Non-image blocker process change proposal

> >> Well, here's our latest mess-up: > >> https://bodhi.fedoraproject.org/updates/FEDORA-2015-e00b75e39f > >> dnf-plugin-system-upgrade-0.7.0-1.fc22 had enough karma for stable > >> on > > Oct 29, which was Go/No-Go day. Therefore it was considered "resolved". > > > > "Had enough karma" != queued

Re: Non-image blocker process change proposal

On Wed, 18 Nov 2015 16:36:16 -0800 Adam Williamson wrote: > #2 MOAR METADATA > > > The alternative is to make the existing Blocker trackers do more work. > In this model we wouldn't add any new tracker bugs; we'd just add new > 'magic words' in the

Re: Non-image blocker process change proposal

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/20/2015 07:16 AM, Kamil Paral wrote: >> The biggest issue is this, I think. We probably need to encode >> "Special Blockers" into the Go/No-Go process. I don't think that >> assurance that it will be fixed on time is necessarily good >>

Re: Non-image blocker process change proposal

> > My suggestion would be that we make sure 'blockerbugs' includes > > lists of each type of blocker. Ahead of and at Go/No-Go meetings, > > we would want to have a formal assurance from the person > > responsible for fixing the bug that the fix would be provided by a > > certain time - say, one

Re: Non-image blocker process change proposal

> #2 MOAR METADATA > > > The alternative is to make the existing Blocker trackers do more work. > In this model we wouldn't add any new tracker bugs; we'd just add new > 'magic words' in the Whiteboard field. Right now, an accepted blocker > is identified by the string

Re: Non-image blocker process change proposal

On 11/19/2015 11:40 PM, Adam Williamson wrote: On Thu, 2015-11-19 at 19:09 +0530, Sudhir D wrote: I suggest we have only one ZeroDay i.e., for Final and do away with intermediate ones. As I see it, ZeroDay comes with cost and we also need to have basic sanity testcases automated to ensure

Re: Non-image blocker process change proposal

Stephen Gallagher píše v Čt 19. 11. 2015 v 15:50 -0500: > On 11/18/2015 07:36 PM, Adam Williamson wrote: > > > With either approach, the basic goal is to make it more feasible > > to keep an eye on each of the different categories of 'release > > blocker' bugs; right now we have solid processes

Re: Non-image blocker process change proposal

On 11/20/2015 03:56 PM, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/20/2015 07:16 AM, Kamil Paral wrote: The biggest issue is this, I think. We probably need to encode "Special Blockers" into the Go/No-Go process. I don't think that assurance that it will be

Re: Non-image blocker process change proposal

On Thu, 2015-11-19 at 19:09 +0530, Sudhir D wrote: > > I suggest we have only one ZeroDay i.e., for Final and do away with > intermediate ones. > As I see it, ZeroDay comes with cost and we also need to have basic > sanity testcases automated to ensure ZeroDay fixes won't > introduce/regress

Re: Non-image blocker process change proposal

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/18/2015 07:36 PM, Adam Williamson wrote: > With either approach, the basic goal is to make it more feasible > to keep an eye on each of the different categories of 'release > blocker' bugs; right now we have solid processes in place for >

Re: Non-image blocker process change proposal

On 11/19/2015 06:06 AM, Adam Williamson wrote: Hi, folks! It's been a recurring issue in the blocker review / release validation process in recent times that we run across bugs that qualify as blockers, but for which the fix does not need to be in the final frozen media or install trees.

Non-image blocker process change proposal

Hi, folks! It's been a recurring issue in the blocker review / release validation process in recent times that we run across bugs that qualify as blockers, but for which the fix does not need to be in the final frozen media or install trees. Common cases are bugs related to upgrading, especially