On Wed, 10 Oct 2012 14:25:37 -0700
Jesse Keating <jkeating@xxxxxxxxxx> wrote:
snip
> > As we have both already stated and agreed on, the installer is
> > unique. Our development process is so very much tied to the Fedora
> > release schedule. There is no easy way for us to develop something
> > large like a new installer and not have it tied to a release. This
> > became harder for us when we stopped doing rawhide nightly composes
> > many years ago (and I have no idea if those are happening again
> > these days). People don't go and download a new installer to try
> > it out. You download a release of something and try installing
> > it. Our only way to get that to users is to follow the Fedora
> > release schedule, unless we want to start making our own
> > distribution.
> >
> > I know what you're getting at and it's that newui was a huge
> > feature and that's made our lives hard. Unfortunately, the Fedora
> > release schedule is such that work like this is always painful for
> > us.
>
>
> So the no images in rawhide thing was kinda my doing. It came from a
> meeting a few years ago with release engineering, QA, installer team,
> and others, where we looked at how our development process was going
> and where all the painful points where.
>
> One of the major pain points identified was how frequently rawhide
> wasn't installable, and how it would turn people away. After talking
> with folks it seemed like a better idea was to /not/ present a broken
> set of images each night to people when we had no idea of they would
> work. Instead what we wanted to do was keep rawhide as just a
> repository of packages. We would then create "known good" images
> that people could use as a starting point to get on rawhide, from
> that point it was just yum update every day.
>
> Where this may have failed is in the creation of the known good
> images. Of course to know they're good, they must be created first,
> then tested. There was schedule points for creating composes to
> smoke test, with the hopes of identifying a compose that was "good
> enough" to be promoted as a last known good. I think we're probably
> missing some infrastructure here, and some cooperation between
> installer devs and qa and releng.
Actually, we tried to get this done for F18 (the fedora build service
GSoC project) and simply ran out of time. We have most of the
infrastructure needed and to the best of my knowledge, nobody was
against the idea - it just wasn't done in time for F18.
I know that Amit (the student who worked on the GSoC project - now
working for Red Hat) and I are still interested in making this happen,
we just haven't had the time to do anything about it since the F18
release started up and the system is not ready for public use yet.
The idea is to eventually have a system that is capable of the
following:
- keep multiple base repos for devs to work with
- allow for selective package updates in the repos
* The only requirement would be to be able to download the new
packages from koji using the koji client.
- accept custom kickstarts
- build live, DVD and netinstall images on demand
- host the built images for a certain amount of time before reclaiming
the space
Some of those features are a little farther than others (mostly repo
management instead of basing off of rawhide/f18 etc.) but it's all
do-able.
> The happy world I envisioned was an installer team able to work on
> their own on large changes, not bothered by people constantly telling
> them that rawhide was broken, again. When the team thought they'd
> reached some milestone and wanted to start getting testing, they
> would work with QA and releng to get some images produced and ran
> through smoke tests. If good, promoted, if not fix it and try again,
> iterate. If this happy world isn't something we think can be
> managed, then we really should re-evaluate the no images in rawhide
> thing again.
Honestly, I'd love to see something like this happen. I think it would
lead to less total pain for all involved - for qa, anaconda devs and
probably other devs as well. It would require quite a bit of work to
figure out how we'd manage such a process and implement any tooling
needed to do so but it would probably be worth at least looking in to.
Tim
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
