On Mon, 02 Nov 2015 01:28:07 +0000
You are. ;)Sérgio Basto <sergio@xxxxxxxxxx> 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@xxxxxxxxxx>
> > 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.
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
真実はいつも一つ！/ Always, there's only one truth!
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
