11:50 a.m.
Hi all. It has been brought to my attention that my description of my
future vision of rawhide as explained here is much clearer than previous
attempts (including the current "no frozen rawhide" wiki page). So I
felt it prudent to forward it along to the devel list for more eyes to
look upon it and comment if desired.
Thanks!
-------- Forwarded Message --------
From: Jesse Keating <jkeating(a)redhat.com>
Reply-to: fedora-advisory-board(a)redhat.com
To: fedora-advisory-board(a)redhat.com
Subject: Re: "What is the Fedora Project?"
Date: Wed, 21 Oct 2009 18:58:08 -0700
On Wed, 2009-10-21 at 20:35 -0400, Paul W. Frields wrote:
> >I've heard a bit of preliminary rumbling about DSCM-like
Rawhides -- a
> >way for developers to have trees that move at their pace, and are
> >possibly quite broken from time to time in ways that differ from each
> >other. If we were able to develop such a scenario, why not also
> >provide the flipside of this idea -- make the One True Rawhide the
> >place where we take in changes that don't break the world, while
> >they're cobbled on in the other trees? Whether this is an extension
> >of the "KoPeR" idea or something entirely difficult, it merits
serious
> >consideration.
>
> I very much like the aspect of the more stable rawhide here.
Jesse Keating brought up some concerns about integration, but aren't
those concerns something that people would be interested in solving?
(I'm assuming those people are the wide variety of engineers working
in the Fedora community who are smarter than I.)
So my plans are really funny. I plan to make rawhide more unstable more
of the time, and I plan to make "rawhide" more stable more of the time.
Crazy eh? How can I do this? By splitting "rawhide" in two.
Rawhide as we know it, /pub/fedora/linux/releases/development/ will
remain "rawhide". We may even change the path to say rawhide, just to
catch things up and well I like keeping mirrors on their toes. Rawhide
will be a repository of developmental and experimental packages. Things
being worked on for the future. It will /not/ be an installable tree,
rather it will just be a repository of packages, to be added on to an
already stable "base", eg you'd install F12, and enable rawhide to test
rawhide. This will significantly lower the complaints that "rawhide
isn't installable".
The second face of rawhide, will be the "pending release", that is when
it comes time to feature freeze a release, we'll split it away from
rawhide. We'll publish to /pub/fedora/linux/releases/test/13-pending/
or some such. THIS tree will be installable. It will be composed each
night, and we'll use bodhi to manage updates to this tree. That means
this tree will have it's own "updates testing" where potential freeze
breaks can be tested and commented on by all, but won't risk the base
tree. If testing pans out, it'll get tagged for the release, if not
it'll get thrown away. This tree will spawn 13-Alpha, 13-Beta, the
snapshots in between, and eventually pub/fedora/linux/releases/13.
Remember that first rawhide? Yeah, it kept going, unfrozen, leaping
toward Fedora 14. You could still install 13-Alpha, or 13-pending, and
enable/update to rawhide to start testing Fedora 14 stuff.
What does this accomplish? It provides a very easy release valve.
Instead of closing the valve and building up pressure while we freeze,
and tempting people to push things into our pending release that really
don't belong, we'll provide them a normal, never ending release of
pressure, called rawhide. You can always find the latest stuff in
rawhide, there is nothing newer (unless we make KoPeRs happen). We
don't have to worry about "rawhide" being installable. We don't have
to
worry about people dumping highly experimental or developmental stuff in
our pending release. We don't have to worry about the giant pile of
builds for the next release building up while we polish the pending
release. We don't have to worry about the giant pile of 0-day updates
building up while we polish the pending release, as we'll be pushing
these updates as we go.
This is my vision on how to accomplish both a always active development
stream, and a more stable pending release stream, keeping everybody
happy. Want to help? I'll be at FUDCon Toronto discussing roadblocks
to this vision and discussing why this vision sucks if anybody thinks
that it does. Or just find me on IRC/email if you want to chat about
it.
_______________________________________________
fedora-advisory-board mailing list
fedora-advisory-board(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-advisory-board
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
12:05 p.m.
On Thu, 2009-10-22 at 09:50 -0700, Jesse Keating wrote:
This is my vision on how to accomplish both a always active
development
stream, and a more stable pending release stream, keeping everybody
happy. Want to help? I'll be at FUDCon Toronto discussing roadblocks
to this vision and discussing why this vision sucks if anybody thinks
that it does. Or just find me on IRC/email if you want to chat about
it.
Not a bad idea. In all honesty, I find rawhide is rarely fully
installable out of the "box" anyway...this isn't a grumble! I think
it's
better to embrace reality and have multiple trees, though I am
interested in whether that pending release couldn't also one day have a
counterpart that had more longevity - a "testing" release (not the same
as the "testing" that we currently have through updates) :)
Jon.
12:55 p.m.
On Thu, 2009-10-22 at 09:50 -0700, Jesse Keating wrote:
Hi all. It has been brought to my attention that my description of
my
future vision of rawhide as explained here is much clearer than previous
attempts (including the current "no frozen rawhide" wiki page). So I
felt it prudent to forward it along to the devel list for more eyes to
look upon it and comment if desired.
Thanks!
-------- Forwarded Message --------
From: Jesse Keating <jkeating(a)redhat.com>
Reply-to: fedora-advisory-board(a)redhat.com
To: fedora-advisory-board(a)redhat.com
Subject: Re: "What is the Fedora Project?"
Date: Wed, 21 Oct 2009 18:58:08 -0700
On Wed, 2009-10-21 at 20:35 -0400, Paul W. Frields wrote:
> > >I've heard a bit of preliminary rumbling about DSCM-like Rawhides -- a
> > >way for developers to have trees that move at their pace, and are
> > >possibly quite broken from time to time in ways that differ from each
> > >other. If we were able to develop such a scenario, why not also
> > >provide the flipside of this idea -- make the One True Rawhide the
> > >place where we take in changes that don't break the world, while
> > >they're cobbled on in the other trees? Whether this is an extension
> > >of the "KoPeR" idea or something entirely difficult, it merits
serious
> > >consideration.
> >
> > I very much like the aspect of the more stable rawhide here.
>
> Jesse Keating brought up some concerns about integration, but aren't
> those concerns something that people would be interested in solving?
> (I'm assuming those people are the wide variety of engineers working
> in the Fedora community who are smarter than I.)
>
>
So my plans are really funny. I plan to make rawhide more unstable more
of the time, and I plan to make "rawhide" more stable more of the time.
Crazy eh? How can I do this? By splitting "rawhide" in two.
Rawhide as we know it, /pub/fedora/linux/releases/development/ will
remain "rawhide". We may even change the path to say rawhide, just to
catch things up and well I like keeping mirrors on their toes. Rawhide
will be a repository of developmental and experimental packages. Things
being worked on for the future. It will /not/ be an installable tree,
rather it will just be a repository of packages, to be added on to an
already stable "base", eg you'd install F12, and enable rawhide to test
rawhide. This will significantly lower the complaints that "rawhide
isn't installable".
The second face of rawhide, will be the "pending release", that is when
it comes time to feature freeze a release, we'll split it away from
rawhide. We'll publish to /pub/fedora/linux/releases/test/13-pending/
or some such. THIS tree will be installable. It will be composed each
night, and we'll use bodhi to manage updates to this tree. That means
this tree will have it's own "updates testing" where potential freeze
breaks can be tested and commented on by all, but won't risk the base
tree. If testing pans out, it'll get tagged for the release, if not
it'll get thrown away. This tree will spawn 13-Alpha, 13-Beta, the
snapshots in between, and eventually pub/fedora/linux/releases/13.
Remember that first rawhide? Yeah, it kept going, unfrozen, leaping
toward Fedora 14. You could still install 13-Alpha, or 13-pending, and
enable/update to rawhide to start testing Fedora 14 stuff.
So to make this a reality, we need to ensure that whatever is in rawhide
has a *>=* ENVR than anything in the other trees. So I assume that when
submitting a bodhi update, bodhi would check rawhide and ensure that
whatever you were about to submit to 13-pending was <= whatever was in
rawhide. Otherwise we'd get into a great big mess of not being able to
update to rawhide packages because whatever was in 13-pending was
'newer' than rawhide. Right?
We should have this anyway just to help upgradability between distros;
bodhi should not allow a package to be added to an update if it's a
"newer" ENVR than that same package in any of the "newer" distros.
Dan
1:02 p.m.
On Thu, 2009-10-22 at 10:55 -0700, Dan Williams wrote:
So to make this a reality, we need to ensure that whatever is in
rawhide
has a *>=* ENVR than anything in the other trees. So I assume that when
submitting a bodhi update, bodhi would check rawhide and ensure that
whatever you were about to submit to 13-pending was <= whatever was in
rawhide. Otherwise we'd get into a great big mess of not being able to
update to rawhide packages because whatever was in 13-pending was
'newer' than rawhide. Right?
We should have this anyway just to help upgradability between distros;
bodhi should not allow a package to be added to an update if it's a
"newer" ENVR than that same package in any of the "newer" distros.
Yes, but it may happen before the bodhi stage, when we get autoqa
working on post-build tests. This kind of check could happen at SCM
commit time, package build time, or finally bodhi push time. Seems
reasonable that we'd want to catch it as early as possible, but that
does force people to work on rawhide first, then work on the pending
release which may be under critical time pressure. Certainly something
to discuss. Catching it at bodhi time seems too late.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
1:19 p.m.
On Thu, 2009-10-22 at 11:02 -0700, Jesse Keating wrote:
On Thu, 2009-10-22 at 10:55 -0700, Dan Williams wrote:
> So to make this a reality, we need to ensure that whatever is in rawhide
> has a *>=* ENVR than anything in the other trees. So I assume that when
> submitting a bodhi update, bodhi would check rawhide and ensure that
> whatever you were about to submit to 13-pending was <= whatever was in
> rawhide. Otherwise we'd get into a great big mess of not being able to
> update to rawhide packages because whatever was in 13-pending was
> 'newer' than rawhide. Right?
>
> We should have this anyway just to help upgradability between distros;
> bodhi should not allow a package to be added to an update if it's a
> "newer" ENVR than that same package in any of the "newer"
distros.
Yes, but it may happen before the bodhi stage, when we get autoqa
working on post-build tests. This kind of check could happen at SCM
commit time, package build time, or finally bodhi push time. Seems
reasonable that we'd want to catch it as early as possible, but that
does force people to work on rawhide first, then work on the pending
release which may be under critical time pressure. Certainly something
to discuss. Catching it at bodhi time seems too late.
We could allow adding
numbers after the dist tag in release for this
purpose. And if the fixed package would upgrade to a newer upstream
version it should not be too big hassle to build it in the rawhide tree
first.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
1:39 p.m.
Tomas Mraz wrote:
We could allow adding numbers after the dist tag in release for this
purpose.
That is already allowed, and encouraged, for branch-specific modfications,
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Minor_release_bu...
-- Rex
2:19 p.m.
On Thu, 2009-10-22 at 13:39 -0500, Rex Dieter wrote:
Tomas Mraz wrote:
> We could allow adding numbers after the dist tag in release for this
> purpose.
That is already allowed, and encouraged, for branch-specific modfications,
http://fedoraproject.org/wiki/Packaging/NamingGuidelines#Minor_release_bu...
Heh, dunno why I thought it is disallowed. Then I don't see any problem
with enforcing n-v-r ordering during cvs tagging.
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
1:33 p.m.
On Thu, 2009-10-22 at 11:02 -0700, Jesse Keating wrote:
On Thu, 2009-10-22 at 10:55 -0700, Dan Williams wrote:
> So to make this a reality, we need to ensure that whatever is in rawhide
> has a *>=* ENVR than anything in the other trees. So I assume that when
> submitting a bodhi update, bodhi would check rawhide and ensure that
> whatever you were about to submit to 13-pending was <= whatever was in
> rawhide. Otherwise we'd get into a great big mess of not being able to
> update to rawhide packages because whatever was in 13-pending was
> 'newer' than rawhide. Right?
>
> We should have this anyway just to help upgradability between distros;
> bodhi should not allow a package to be added to an update if it's a
> "newer" ENVR than that same package in any of the "newer"
distros.
Yes, but it may happen before the bodhi stage, when we get autoqa
working on post-build tests. This kind of check could happen at SCM
commit time, package build time, or finally bodhi push time. Seems
reasonable that we'd want to catch it as early as possible, but that
does force people to work on rawhide first, then work on the pending
release which may be under critical time pressure. Certainly something
to discuss. Catching it at bodhi time seems too late.
Good point. SCM commit time (or tag time) with a CVS hook would be
awesome as long as the hook was fast enough.
Dan
2:47 p.m.
On Thu, 2009-10-22 at 11:33 -0700, Dan Williams wrote:
Good point. SCM commit time (or tag time) with a CVS hook would be
awesome as long as the hook was fast enough.
Note, I didn't say "CVS", I said "SCM" (:
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
4:55 p.m.
On Thu, Oct 22, 2009 at 11:02:42 -0700,
Jesse Keating <jkeating(a)redhat.com> wrote:
Yes, but it may happen before the bodhi stage, when we get autoqa
working on post-build tests. This kind of check could happen at SCM
commit time, package build time, or finally bodhi push time. Seems
reasonable that we'd want to catch it as early as possible, but that
does force people to work on rawhide first, then work on the pending
release which may be under critical time pressure. Certainly something
to discuss. Catching it at bodhi time seems too late.
The *.fcxx.1 trick can be used to work around that if necessary. That
may not be desirable though, as it seems to catch people by surprise.
3:47 p.m.
On Thu, 22 Oct 2009 09:50:54 -0700, Jesse Keating <jkeating(a)redhat.com> wrote:
Hi all. It has been brought to my attention that my description of
my
future vision of rawhide as explained here is much clearer than previous
attempts (including the current "no frozen rawhide" wiki page). []
Actually, the "no frozen rawhide" was very clear and this message
just boggles the mind.
What does this accomplish? It provides a very easy release valve.
Instead of closing the valve and building up pressure while we freeze,
and tempting people to push things into our pending release that really
don't belong, we'll provide them a normal, never ending release of
pressure, called rawhide. []
Great, you made life of lazy developers easy. What about users of
Rawhide? I had Rawide installed on my main desktop since RHL 6.
What am I supposed to do now? What tree to run? Your proposal
has no guidelines for me (unlike the proposal to stop freezing
Rawhide, which IMHO had a lot of merit).
Note, I'm not interested in testing things "sometimes". If I did,
I would've been using RHEL WS or something. I want an always-useable
development tip tree.
The problem here is that Rawhide was a useful distribution for years.
We were Gentoo before Gentoo, minus meaningless recompiles. And now?
-- Pete
4:20 p.m.
On Thu, 2009-10-22 at 14:47 -0600, Pete Zaitcev wrote:
On Thu, 22 Oct 2009 09:50:54 -0700, Jesse Keating
<jkeating(a)redhat.com> wrote:
> Hi all. It has been brought to my attention that my description of my
> future vision of rawhide as explained here is much clearer than previous
> attempts (including the current "no frozen rawhide" wiki page). []
Actually, the "no frozen rawhide" was very clear and this message
just boggles the mind.
> What does this accomplish? It provides a very easy release valve.
> Instead of closing the valve and building up pressure while we freeze,
> and tempting people to push things into our pending release that really
> don't belong, we'll provide them a normal, never ending release of
> pressure, called rawhide. []
Great, you made life of lazy developers easy. What about users of
Rawhide? I had Rawide installed on my main desktop since RHL 6.
What am I supposed to do now? What tree to run? Your proposal
has no guidelines for me (unlike the proposal to stop freezing
Rawhide, which IMHO had a lot of merit).
Note, I'm not interested in testing things "sometimes". If I did,
I would've been using RHEL WS or something. I want an always-useable
development tip tree.
The problem here is that Rawhide was a useful distribution for years.
We were Gentoo before Gentoo, minus meaningless recompiles. And now?
-- Pete
I wonder where your confusion comes from. With this rewording of the
proposal, the proposal doesn't change. Rawhide the path on the mirror
(pub/fedora/linux/releases/development/) never freezes, never stops.
It's always developmental and testing packages. It is always there. It
never freezes. You can turn on that repo and just run with it from now
until you decide you don't want to use computers anymore.
The proposal, both wordings, say that we'll stop slowing down rawhide,
stop trying to use that path as a testing/polish point for a release.
We'll do that somewhere else and let rawhide keep flowing.
So you can continue to run rawhide all you want. Your entry point to
rawhide may change slightly, you may have to start with the current
Fedora release or the current testing release for the next Fedora, and
then upgrade to the rawhide package set, but once you've done that you
just stick on rawhide and never look back.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
4:42 p.m.
New subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora Project?"])
Le Jeu 22 octobre 2009 23:20, Jesse Keating a écrit :
So you can continue to run rawhide all you want. Your entry point
to
rawhide may change slightly, you may have to start with the current
Fedora release or the current testing release for the next Fedora, and
then upgrade to the rawhide package set, but once you've done that you
just stick on rawhide and never look back.
IMHO you should be honest and call your F-next rawhide, and find some other
name for the "experimental stuff" sandbox. Because your F-next is effectively
what rawhide has been since before Fedora, and your rawhide is what people who
do not care about releng have been trying to turn rawhide into in the past
years. Well they can get their no-rules playground but I don't see why we
should also give them the rawhide name. It has a fine history, much better
than the eating babies ogre caricature.
--
Nicolas Mailhot
3:07 a.m.
On Thu, 22 Oct 2009 14:20:13 -0700, Jesse Keating <jkeating(a)redhat.com> wrote:
I wonder where your confusion comes from. With this rewording of
the
proposal, the proposal doesn't change. []
So you can continue to run rawhide all you want. Your entry point
to
rawhide may change slightly, you may have to start with the current
Fedora release or the current testing release for the next Fedora, and
then upgrade to the rawhide package set, but once you've done that you
just stick on rawhide and never look back.
That works for me, thanks a lot.
-- Pete
4:18 p.m.
On Thu, 2009-10-22 at 09:50 -0700, Jesse Keating wrote:
Hi all. It has been brought to my attention that my description of
my
future vision of rawhide as explained here is much clearer than previous
attempts (including the current "no frozen rawhide" wiki page). So I
felt it prudent to forward it along to the devel list for more eyes to
look upon it and comment if desired.
I have two particular nits with it. One, it's pretty unwieldy,
especially for part time maintainers (thinking how many hoops we'll have
to jump through just to keep our packages up to date). Having to jump
through the Bodhi hoops every time we just want to put a trivial update
into a release that won't be coming out for five months feels like a
pain. I'd worry about a lot of stuff going stale and smelly in the
middle of the Bodhi process somewhere as maintainers lose track of where
the hell they're up to with the four releases they have to cope with
(the last two already-released releases, the upcoming release, and
"rawhide").
Two, it makes testing things a bit more complex. Those of us who like to
test upcoming stuff in real use - i.e. on our main machines - will have
to choose whether to test "rawhide", in which case we'll have more pain
to deal with ourselves and won't be contributing as much to testing of
the next stable release, or test the next stable release, in which case
we aren't helping maintainers by making sure the stuff they're putting
in "rawhide" isn't totally broken.
But overall, the positives could certainly outweigh the negatives. Just
thought I'd flag up the two major concerns I have in case anything could
be done about them.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
6:41 p.m.
On Thu, 2009-10-22 at 14:18 -0700, Adam Williamson wrote:
I have two particular nits with it. One, it's pretty unwieldy,
especially for part time maintainers (thinking how many hoops we'll have
to jump through just to keep our packages up to date). Having to jump
through the Bodhi hoops every time we just want to put a trivial update
into a release that won't be coming out for five months feels like a
pain.
Who said anything about 5 months. 3 months max, which is just slightly
longer than the amount of time they spend now doing Trac tickets to get
something in.
I'd worry about a lot of stuff going stale and smelly in the
middle of the Bodhi process somewhere as maintainers lose track of where
the hell they're up to with the four releases they have to cope with
(the last two already-released releases, the upcoming release, and
"rawhide").
"rawhide" would never use bodhi. If you build in devel/ it shows up in
rawhide the next day. End of story. Bodhi would only be used for the
pending and already done releases.
Two, it makes testing things a bit more complex. Those of us who like to
test upcoming stuff in real use - i.e. on our main machines - will have
to choose whether to test "rawhide", in which case we'll have more pain
to deal with ourselves and won't be contributing as much to testing of
the next stable release, or test the next stable release, in which case
we aren't helping maintainers by making sure the stuff they're putting
in "rawhide" isn't totally broken.
For people like you, you'd just keep jumping when we branch off the next
release. Like it or not, this is happening /already/. dist-f13 already
has 953 packages with updates, and it isn't published /anywhere/
for /anybody/ to test it. We can only make that better, not worse.
But overall, the positives could certainly outweigh the negatives. Just
thought I'd flag up the two major concerns I have in case anything could
be done about them.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
7:18 p.m.
New subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora Project?"])
I think this is an awesome idea, and yes I think this "version" of the
verbage is more clear. Kudos to Jesse (and all those involved in the
development of the idea of the "split rawhide") and I hope to see this
come to fruition.
-Adam
--
http://maxamillion.googlepages.com
---------------------------------------------------------
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
9:05 p.m.
New subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora Project?"])
On Thu, 22 Oct 2009, Adam Miller wrote:
I think this is an awesome idea, and yes I think this
"version" of the
verbage is more clear. Kudos to Jesse (and all those involved in the
development of the idea of the "split rawhide") and I hope to see this
come to fruition.
I agree, how can I help?
-Mike
9:29 p.m.
New subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora Project?"])
I would also like to jump on the help train if there is anything I am able
to lend a hand with.
-Adam (From Android)
On Oct 22, 2009 9:05 PM, "Mike McGrath" <mmcgrath(a)redhat.com> wrote:
On Thu, 22 Oct 2009, Adam Miller wrote: > I think this is an awesome idea,
and yes I think this "ve...
I agree, how can I help?
-Mike
-- fedora-devel-list mailing list fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/list...
2:24 a.m.
New subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora Project?"])
Dne 23.10.2009 02:18, Adam Miller napsal(a):
I think this is an awesome idea, and yes I think this
"version" of the
verbage is more clear. Kudos to Jesse (and all those involved in the
development of the idea of the "split rawhide") and I hope to see this
come to fruition.
Just wanted to add my +1 and this is as good place as any other.
Matěj
--
http://www.ceplovi.cz/matej/, Jabber: mcepl<at>ceplovi.cz
GPG Finger: 89EF 4BC6 288A BF43 1BAB 25C3 E09F EF25 D964 84AC
Experience is what you get when you don't get what you want.
-- Dan Stanford
6:08 a.m.
New subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora Project?"])
On Fri, Oct 23, 2009 at 8:24 AM, Matěj Cepl <mcepl(a)redhat.com> wrote:
Just wanted to add my +1 and this is as good place as any other.
+1
--
Ismael Olea
http://olea.org/diario/
1:22 a.m.
On Thu, Oct 22, 2009 at 14:18:23 -0700,
Adam Williamson <awilliam(a)redhat.com> wrote:
Two, it makes testing things a bit more complex. Those of us who like to
test upcoming stuff in real use - i.e. on our main machines - will have
to choose whether to test "rawhide", in which case we'll have more pain
to deal with ourselves and won't be contributing as much to testing of
the next stable release, or test the next stable release, in which case
we aren't helping maintainers by making sure the stuff they're putting
in "rawhide" isn't totally broken.
The impression I got (which might be wrong), is that it was expected that
people would test specific packages from rawhide and not be expected to
be running it all at once. Porbably the best equvialent to current rawhide
would be enabling updates-testing for the pending release. People that
needed some that wouldn't break unexpectedly, but still wanted to try out
the new stuff could run the pending release without updates-testing.
8:58 p.m.
Bruno Wolff III wrote:
The impression I got (which might be wrong), is that it was expected
that
people would test specific packages from rawhide and not be expected to
be running it all at once.
That just doesn't work. The network of dependencies and reverse dependencies
generally ends up dragging in half of the distro after the first core
library soname bump (e.g. OpenSSL, OpenLDAP or the like).
Kevin Kofler
3:56 p.m.
New subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora Project?"])
On Thu, Oct 22, 2009 at 4:50 PM, Jesse Keating <jkeating(a)redhat.com> wrote:
Rawhide as we know it, /pub/fedora/linux/releases/development/ will
remain "rawhide". We may even change the path to say rawhide, just to
catch things up and well I like keeping mirrors on their toes. Rawhide
will be a repository of developmental and experimental packages. Things
being worked on for the future. It will /not/ be an installable tree,
rather it will just be a repository of packages, to be added on to an
already stable "base", eg you'd install F12, and enable rawhide to test
rawhide. This will significantly lower the complaints that "rawhide
isn't installable".
So as I understand it there are a number of reasons why rawhide might
not be installable, but broadly they fall into two major categories:
* Anaconda
* Critpath packages
- Dependency/rebuild issues
- Bugs in %posts (like the user/group one we ran into with dbus)
- Core bugs (graphics drivers)
It seems like we're basically just skipping Anaconda, since you won't
be able to yum if there are depsolving issues (ok, modulo
--skip-broken), and for the latter two you don't end up with a
"working" system.
Let me do a counter-proposal:
We simply do not let showstopper regressions in the critpath stay in
rawhide. If something in critpath has a showstopper, it halts all
further commits to the entire critpath until it's resolved (either
fixed, or reverted). The definition of "showstopper" might be "AutoQA
fails". And since AutoQA will have been doing some basic smoketesting
of the installer, we have to be producing installer images as a side
effect.
4:11 p.m.
New subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora Project?"])
On Fri, 2009-10-23 at 20:56 +0000, Colin Walters wrote:
On Thu, Oct 22, 2009 at 4:50 PM, Jesse Keating
<jkeating(a)redhat.com> wrote:
>
> Rawhide as we know it, /pub/fedora/linux/releases/development/ will
> remain "rawhide". We may even change the path to say rawhide, just to
> catch things up and well I like keeping mirrors on their toes. Rawhide
> will be a repository of developmental and experimental packages. Things
> being worked on for the future. It will /not/ be an installable tree,
> rather it will just be a repository of packages, to be added on to an
> already stable "base", eg you'd install F12, and enable rawhide to
test
> rawhide. This will significantly lower the complaints that "rawhide
> isn't installable".
So as I understand it there are a number of reasons why rawhide might
not be installable, but broadly they fall into two major categories:
* Anaconda
* Critpath packages
- Dependency/rebuild issues
- Bugs in %posts (like the user/group one we ran into with dbus)
- Core bugs (graphics drivers)
It seems like we're basically just skipping Anaconda, since you won't
be able to yum if there are depsolving issues (ok, modulo
--skip-broken), and for the latter two you don't end up with a
"working" system.
Let me do a counter-proposal:
We simply do not let showstopper regressions in the critpath stay in
rawhide. If something in critpath has a showstopper, it halts all
further commits to the entire critpath until it's resolved (either
fixed, or reverted). The definition of "showstopper" might be "AutoQA
fails". And since AutoQA will have been doing some basic smoketesting
of the installer, we have to be producing installer images as a side
effect.
I... don't see how this helps, other than piss off the rest of the
crit-path maintainers while one thing is broken.
AutoQA will be running at some point, and it can be doing the
qa /before/ things get tagged for rawhide, so if you break deps with
your build, it doesn't get in, unless you force it and then you face the
wrath of releng/qa. To catch core bugs, we'll need a bit more advanced
autoqa, doing more than just repo level testing but doing actual package
testing. That will grow over time and again can be done pre-tag.
Your counter proposal also does nothing to help the dual or sometimes
triple role we try to put on "rawhide" the path.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
4:15 p.m.
New subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora Project?"])
On Fri, Oct 23, 2009 at 9:11 PM, Jesse Keating <jkeating(a)redhat.com> wrote:
AutoQA will be running at some point, and it can be doing the
qa /before/ things get tagged for rawhide,
Oh, I didn't realize there would be a distinction between "built in
koji" and "rawhide" now. If that's the case, than this sounds fine to
me! The point is basically that we need some sort of stable, defined
baseline for what you get when you try to install "rawhide". Testing
before tagging sounds good.
4:42 p.m.
New subject: The future of "rawhide" (was [Fwd: Re: "What is the Fedora Project?"])
On Fri, 2009-10-23 at 21:15 +0000, Colin Walters wrote:
Oh, I didn't realize there would be a distinction between
"built in
koji" and "rawhide" now. If that's the case, than this sounds fine
to
me! The point is basically that we need some sort of stable, defined
baseline for what you get when you try to install "rawhide". Testing
before tagging sounds good.
Yeah, there are multiple prongs to our attack to make Fedora development
better. In this thread I was mostly talking about what types of changes
go into the repos and which repos get produced each night. Autoqa has
other plans to help, one of which being testing before tagging.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
5322
days inactive
5326
days old
26 comments
15 participants
participants (15)
-
Adam Miller -
Adam Williamson -
Bruno Wolff III -
Colin Walters -
Dan Williams -
Ismael Olea -
Jesse Keating -
Jon Masters -
Kevin Kofler -
Matej Cepl -
Mike McGrath -
Nicolas Mailhot -
Pete Zaitcev -
Rex Dieter -
Tomas Mraz