#5385 Request push systemd-195-2.fc18 through the freeze
Closed: Fixed None Opened 11 years ago by johannbg.

Given that this [1] update is an automatic blocker since fedup is depend on [2] thus it breaks

"For each one of the release-blocking package sets ('minimal', and the package sets for each one of the release-blocking desktops), it must be possible to successfully complete an upgrade from a fully updated installation of the previous stable Fedora release with that package set installed, using any officially recommended upgrade mechanisms. The upgraded system must meet all release criteria."

I here by request that releng pushes systemd-195-2 through the freeze...

1.https://admin.fedoraproject.org/updates/FEDORA-2012-16709/systemd-195-2.fc18
2.https://github.com/wgwoods/fedup-dracut/blob/master/fedup-dracut.spec


(correct me if I'm wrong, but...) this isn't releng's job to decide or implement this.

QA has a clear process that during freezes (like now), only fixes for blocker bugs will be accepted,
http://fedoraproject.org/wiki/QA:SOP_blocker_bug_process

So, I suggest you file a bug, nominate is blocker, and if QA accepts it, it'll get pulled in.

Can't NTH (Nice-To-Have) bugs also get past the freeze? http://fedoraproject.org/wiki/QA:SOP_nth_bug_process

I would consider a number of the bugs fixed here seriously "nice to have".

Replying to [comment:2 mattdm]:

Can't NTH (Nice-To-Have) bugs also get past the freeze? http://fedoraproject.org/wiki/QA:SOP_nth_bug_process

I would consider a number of the bugs fixed here seriously "nice to have".

Then they need to go through the actual QA process QA has in place. Nothing in the SOP you linked to suggests opening a rel-eng ticket and going around the QA team.

Replying to [comment:1 rdieter]:

(correct me if I'm wrong, but...) this isn't releng's job to decide or implement this.

QA has a clear process that during freezes (like now), only fixes for blocker bugs will be accepted,
http://fedoraproject.org/wiki/QA:SOP_blocker_bug_process

So, I suggest you file a bug, nominate is blocker, and if QA accepts it, it'll get pulled in.

Oh really what more information about the QA community would you like to relay to me?

Did adamw put you up to this because he did not get to ping nirik og dgilmore on irc to bypass all transparency and work flow in doing so?

Or is this just general because it was not filed by the Red Hat's QA team we will not do it?

This already was mentions and discussed on last QA meeting along with on https://bugzilla.redhat.com/show_bug.cgi?id=871161

Replying to [comment:4 johannbg]:

Replying to [comment:1 rdieter]:

(correct me if I'm wrong, but...) this isn't releng's job to decide or implement this.

QA has a clear process that during freezes (like now), only fixes for blocker bugs will be accepted,
http://fedoraproject.org/wiki/QA:SOP_blocker_bug_process
Did adamw put you up to this because he did not get to ping nirik og dgilmore on irc to bypass all transparency and work flow in doing so?

No.

Or is this just general because it was not filed by the Red Hat's QA team we will not do it?

No.

This already was mentions and discussed on last QA meeting along with on https://bugzilla.redhat.com/show_bug.cgi?id=871161

If you had mentioned that bug to begin with it would have saved everyone a lot of time.

Replying to [comment:3 jwboyer]:

Replying to [comment:2 mattdm]:

Can't NTH (Nice-To-Have) bugs also get past the freeze? http://fedoraproject.org/wiki/QA:SOP_nth_bug_process
Then they need to go through the actual QA process QA has in place. Nothing in the SOP you linked to suggests opening a rel-eng ticket and going around the QA team.

I wasn't suggesting otherwise — just noting that the process also includes nice-to-have, not just hard blockers.

If you had mentioned that bug to begin with it would have saved everyone a lot of time.

Lack of proper communication seems to be the theme of this release cycle :)

It may be acceptable by Adam and perhaps Red Hat in general to handle these kind of things by irc personal mail or through some various chat clients but it's certainly not acceptable for a whole community where anybody from within the community can file an request for an push through freeze. I'm going come up with and write SOP for QA Community to have a firm work flow for the community to follow so transparency,traceability between those two community are in place.

Meanwhile you guys just have to start to accept the fact that Adam wont be the only one handling these issues in the future...

Your accusations... are at best offbase. Besides, bug #871161 is not yet marked as AcceptedBlocker, so filing here is (still) premature.

Replying to [comment:8 rdieter]:

Your accusations... are at best offbase.

Given that you have been here with the project long enough and you are well educated man thus you are aware of the fact that history repeats itself I'm interesting to hear what you mean by my accusation are at best offbase...

Besides, bug #871161 is not yet marked as AcceptedBlocker, so filing here is (still) premature.

As you wish let's wait for the meeting I seriously doubt that there is any new info that has not already been discussed before and the reason this was not an already an blocker is because we have not been able up to this point to properly test the upgrade tool heck i'm not sure if it has passed it's packaging review yet hence we have needed to punt this along with other upgrade related bugs until it became available.

"Discussed at 2012-10-31 blocker review meeting: http://meetbot.fedoraproject.org/fedora-qa/2012-10-31/f18beta-blocker-review-6.2012-10-31-16.00.log.txt . Agreed that as the process by which upgrade.img will be built and shipped(?) is still not clear we cannot be sure if this actually needs to block the Beta release, but there is a possibility that it might, and in that case, we should pull the fix immediately so we have time to test it, rather than realizing we need it later on and not having time to test it properly.

Therefore the issue is accepted as NTH and we leave the blocker question open, to be determined later if required. This gives us flexibility to take the systemd update now, but back it out again if testing indicates it is broken and we determine we don't actually need it for fedup."

though stictly speaking, that update isn't marked as fixing or unblocking the bug referenced here earlier, 871161 (should it be added?).

Metadata Update from @johannbg:
- Issue set to the milestone: Fedora 18 Beta

7 years ago

Login to comment on this ticket.

Metadata