Fedora 23 Final RC10 status is GO !

Mon Nov 2 17:45:36 UTC 2015

On Mon, Nov 2, 2015 at 12:33 PM, Kevin Fenzi <kevin at scrye.com> wrote:

> On Mon, 02 Nov 2015 01:28:07 +0000
> Sérgio Basto <sergio at serjux.com> wrote:
>
> > On Dom, 2015-11-01 at 17:53 +0000, Peter Robinson wrote:
> > > On Sun, Nov 1, 2015 at 5:06 PM, Sérgio Basto <sergio at serjux.com>
> > > wrote:
> > > > On Sex, 2015-10-30 at 17:47 +0100, Jan Kurik wrote:
> > > >> At the third round of Fedora 23 Final Go/No-Go Meeting, that just
> > > >> ends, has been Fedora 23 Final-RC10 declared as GOLD.
> > > >> GA of this release is planed on Tuesday 2015-Nov-03.
> > > >>
> > > > Today we got 531 updates for F23 , IMO, you should include it on
> > > > Fedora 23 Final before GA , doesn't make sense (to me) after
> > > > download an ISO have 1/2 Giga of updates, but this happens since
> > > > RedHad 9 at least . IMO, testing team should respin ISO with
> > > > updates and testing again . I have some difficulty in following
> > > > all development, fortunately Fedora is always at great speed, but
> > > > it is not easy to follow. And do more tests we not lose anything,
> > > > IMHO.
> > >
> > > The problem is we have to freeze sometime to ensure stability in the
> > > installer platform, the live and other images which are static. If
> > > not it's too much of a moving target to try and QA and ensure
> > > everything works as expected. To freeze is a fairly standard
> > > procedure for all distro development.
> >
> > Make an respin for F23 with stable updates, IMHO, should not break
> > anything, because at this stage, just stable things are being pushed.
> > So it should be just one more loop in testing phase, anyway if breaks
> > something test team can freeze process again, until provide a  fix.
> > This is not new !, respins of fedoraunity was an example and we
> > already have living respins [1], so we just need do new respin
> > officially!. Shouldn't be a big deal, If I'm not mistaken.
>
> You are. ;)
>
> So, in order to do what you are wanting we need (at least) 3 things:
>
> 1) releng has to make every daily compose a full compose of all
> deliverables. We have actually been working toward this, and perhaps
> for f24 we will get there. However, even if we do that, we can't make
> the daily composes ready for release unless we change our processes
> (test composes/daily composes now have some flags where they do things
> like pop up the 'this is a test release' dialog in the installer, and
> they are called "TC" in the image names).
>
>
I'm hopeful we can get to this with Rawhide prior to the branching point,
but can our infrastructure handle it? I'm somewhat ignorant of the
capabilities of the Fedora infrastructure...

> 2) QA would need to be able to do a full release validation on a set of
> deliverables _every day_. Again, we are making progress here, we have
> openQA now doing a lot of daily install testing, and taskotron doing a
> bunch of testing of things to keep broken packages out of composes.
> That said, there's a lot of stuff that just cannot be automated:
> testing with specific hardware, looking at issues that aren't in test
> cases (like the last minute help in anaconda issue), etc.
> Additionally, while I know QA folks have done hero testing and
> validated a RC in a day, I think they would revolt if you told them
> they had to do this every single day, and I would not blame them at
> all.
>
>
Perhaps full release validation could occur on composes every two weeks for
branched releases? Or is that still too demanding?

> 3) Finally we would need some way to roll back broken things. We have
> distro-sync right now, but it cannot always downgrade things. If/when
> problems are found sometimes a specific package can be found that
> causes the problem, but sometimes it's a lot more complex. Humans need
> to dig in and figure out what happened and how to fix it. We could just
> say "always use distro-sync in a pre-release, and if you run into
> problems, too bad, just re-install" but I think many of our testers
> would find this unacceptable.
>
>
Could we slip in some settings for TCs that trigger distro-sync behavior
by default on "dnf upgrade"? Or would this still be undesirable?

> While I am very happy someone is doing live-respins, I don't think they
> go through a complete release validation cycle. There's been talk in
> the past of doing updated deliverables on a "well, they composed"
> basis, but the idea never got too far.
>
>
I think it'd be pretty nice if we could use our mix of automated tests and
checks for composing weekly snapshots of rawhide that would be
"installable" and "usable". This is not a particularly new idea[0], but in
light of the openSUSE guys being able to pull it off with Tumbleweed, I
don't see why we can't get there too. It might be a little more "raw" than
Tumbleweed and serve somewhat a different purpose, but I think it would
make testing the state of the development tree far easier.

> kevin
>

[0]: https://fedoraproject.org/wiki/Israwhidebroken.com_Proposal

-- 
真実はいつも一つ！/ Always, there's only one truth!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20151102/4f1b527d/attachment-0001.html>