7:27 a.m.
Hi,
Now that the discussion on this is getting started allow me to chime in with my 2 euro
cents:
In general I like the proposal which can be found here:
http://fedoraproject.org/wiki/FedoraSummit/ReleaseProcess
I've got 2 questions though:
1) I think there should be a procedure to skip update-testing, this will ofcourse be
needed
for security fixes, but also for trivial correct (and somewhat important) fixes and to
fix
brownpaper bag bugs.
2) What about new packages? FE is growing almost daily. One of the huge advantages of the
current
model is that people can get access to new packages within a stable cycle. I like the
whole do not
update unless there is a good reason model to give people more stability, but most new
packages
will not hurt stability of existing packages, and will have 100% impact on our users
unless they
specificly instruct yum to install the new package. There will ofcourse be exceptions,
but as a general
rule of thumb I think it should be normal procedure for new packages to enter the
stable branch so that
all our users can benefit from them (not only those running devel) and so that all our
users can test
them. Remember, release early release often. I think we should do this entering through
updates-testing so
that we can catch any last minute bugs.
Regards,
Hans
7:41 a.m.
Hans de Goede wrote:
Hi,
Now that the discussion on this is getting started allow me to chime in
with my 2 euro cents:
In general I like the proposal which can be found here:
http://fedoraproject.org/wiki/FedoraSummit/ReleaseProcess
I've got 2 questions though:
1) I think there should be a procedure to skip update-testing, this will
ofcourse be needed
for security fixes, but also for trivial correct (and somewhat
important) fixes and to fix
brownpaper bag bugs.
absolutely. This might be handled by
http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem
2) What about new packages? FE is growing almost daily. One of the
huge
advantages of the current
model is that people can get access to new packages within a stable
cycle. I like the whole do not
update unless there is a good reason model to give people more
stability, but most new packages
will not hurt stability of existing packages, and will have 100%
impact on our users unless they
specificly instruct yum to install the new package. There will
ofcourse be exceptions, but as a general
rule of thumb I think it should be normal procedure for new packages
to enter the stable branch so that all our users can benefit from them
(not only those running devel) and so that all our users can test
them. Remember, release early release often. I think we should do this
entering through updates-testing so
that we can catch any last minute bugs.
Are you talking about having a general policy on updates or having a
release freeze like FC instead of rolling updates like FE?
Rahul
8:13 a.m.
On Monday 20 November 2006 08:41, Rahul Sundaram wrote:
Are you talking about having a general policy on updates or having a
release freeze like FC instead of rolling updates like FE?
No, he's asking about introducing new packages to a released product. Say
Fedora 7 goes out the door with a given package set. Three weeks later a
great new package gets added to the Fedora universe, what kind of policy
would there be in making this package available to the Fedora 7 users?
Its an interesting question, one that I'd like to hear opinions on.
Historically we haven't made new packages available in core unless they were
needed by something else already in. However having Extras around helped in
that new packages could get introduced there. Just adding the package in
sounds OK on the surface, but one needs to consider some of the guidelines
we're putting up as far as what can be spun and called Fedora. If a bunch of
new packages show up after Fedora 7 is cut, would somebody be able to make
use of those packages when spinning their cut of Fedora 7? I think it's
pretty safe to say that a lot of these packages wouldn't have a chance to go
through any kind of QA / Testing that Will is trying to put in place.
An interesting topic indeed.
--
Jesse Keating
Release Engineer: Fedora
8:48 a.m.
On Mon, Nov 20, 2006 at 09:13:52AM -0500, Jesse Keating wrote:
Its an interesting question, one that I'd like to hear opinions
on.
Historically we haven't made new packages available in core unless they were
needed by something else already in. However having Extras around helped in
that new packages could get introduced there. Just adding the package in
sounds OK on the surface, but one needs to consider some of the guidelines
we're putting up as far as what can be spun and called Fedora. If a bunch of
new packages show up after Fedora 7 is cut, would somebody be able to make
use of those packages when spinning their cut of Fedora 7? I think it's
pretty safe to say that a lot of these packages wouldn't have a chance to go
through any kind of QA / Testing that Will is trying to put in place.
I think Fedora has fast enough a release schedule that new packages and
major upgrades of existing packages (except when it's the most
straightforward security fix -- thanks, firefox developers!) should wait for
the next release.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
9:03 a.m.
Matthew Miller wrote:
On Mon, Nov 20, 2006 at 09:13:52AM -0500, Jesse Keating wrote:
> Its an interesting question, one that I'd like to hear opinions on.
> Historically we haven't made new packages available in core unless they were
> needed by something else already in. However having Extras around helped in
> that new packages could get introduced there. Just adding the package in
> sounds OK on the surface, but one needs to consider some of the guidelines
> we're putting up as far as what can be spun and called Fedora. If a bunch of
> new packages show up after Fedora 7 is cut, would somebody be able to make
> use of those packages when spinning their cut of Fedora 7? I think it's
> pretty safe to say that a lot of these packages wouldn't have a chance to go
> through any kind of QA / Testing that Will is trying to put in place.
I think Fedora has fast enough a release schedule that new packages and
major upgrades of existing packages (except when it's the most
straightforward security fix -- thanks, firefox developers!) should wait for
the next release.
Why, what is there to loose? I agree with you on major upgrades of existing packages,
but adding a new package to the repo, say a new game for example, will not hurt existing
users in anyway, even if they do a daily yum update it will change nothing for them,
except
an ever so slightly larger metadata download.
Regards,
Hans
9:09 a.m.
On Mon, Nov 20, 2006 at 04:03:45PM +0100, Hans de Goede wrote:
Why, what is there to loose? I agree with you on major upgrades of
existing packages, but adding a new package to the repo, say a new game
for example, will not hurt existing users in anyway, even if they do a
daily yum update it will change nothing for them, except an ever so
slightly larger metadata download.
It encourages people to move to new releases to get new stuff. And of course
skilled users who want the package on an older release can always rebuild
it.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
9:31 a.m.
Matthew Miller wrote:
On Mon, Nov 20, 2006 at 04:03:45PM +0100, Hans de Goede wrote:
> Why, what is there to loose? I agree with you on major upgrades of
> existing packages, but adding a new package to the repo, say a new game
> for example, will not hurt existing users in anyway, even if they do a
> daily yum update it will change nothing for them, except an ever so
> slightly larger metadata download.
It encourages people to move to new releases to get new stuff. And of course
skilled users who want the package on an older release can always rebuild
it.
Lets say we have this merged / unified FC-7, I'm not arguing that we then should
still
allow packages to be added to FC-6, but we should allow adding them to FC-7, so I
don't
buy this argument.
Actually not allowing them in the new unified one, would result in
the opposite of which you advocate, I could still add a new game to FC-6 as that still has
the old
model, but I couldn't add it to FC-7, that will sure motivate people to update to
FC-7.
Ant to quote Ralf:
""Exactly, you'd loose this advantage.
Also you seem to be neglecting that "volunteer contributors" are
interested in seeing their packages being shipped and used, i.e. as part
of the current distro. At least to me contributing packages to "rawhide"
at the price of having to cope with "rawhide" would be highly
non-interesting and non-applicable."
I fully agree with this. I invest a not small amount of time to create new
packages for Fedora, and then I would like our users, or atleast those who are
using a still supported release to be able to use them. Adding packages to a EOL
release is a whole other story, I'm agaist that just like you.
Regards,
Hans
9:01 a.m.
Jesse Keating wrote:
On Monday 20 November 2006 08:41, Rahul Sundaram wrote:
> Are you talking about having a general policy on updates or having a
> release freeze like FC instead of rolling updates like FE?
No, he's asking about introducing new packages to a released product. Say
Fedora 7 goes out the door with a given package set. Three weeks later a
great new package gets added to the Fedora universe, what kind of policy
would there be in making this package available to the Fedora 7 users?
Correct, thats what I'm trying to say.
Its an interesting question, one that I'd like to hear opinions
on.
Historically we haven't made new packages available in core unless they were
needed by something else already in. However having Extras around helped in
that new packages could get introduced there. Just adding the package in
sounds OK on the surface, but one needs to consider some of the guidelines
we're putting up as far as what can be spun and called Fedora.
Can we split the question / discussion in 2 please:
1) Is it allowed to introducing a new package to the online repository /
updates directory of a released product
And if we allow that, only then discuss:
2) Is it allowed to spin a cut of Fedora and still call it Fedora with such
"post release" addon packages included.
Discussing 1) first seems to make sense as without 1) happening there is no 2) to
discuss.
Regards,
Hans
9:05 a.m.
New subject: Core + Extras 2
Jesse Keating wrote:
On Monday 20 November 2006 08:41, Rahul Sundaram wrote:
> Are you talking about having a general policy on updates or having a
> release freeze like FC instead of rolling updates like FE?
No, he's asking about introducing new packages to a released product. Say
Fedora 7 goes out the door with a given package set. Three weeks later a
great new package gets added to the Fedora universe, what kind of policy
would there be in making this package available to the Fedora 7 users?
IMO, barring policy details on how to make it work (which can be hammerred
out later), adding new packages to Fedora after "release" is IMO absolutely
essential.
-- Rex
9:09 a.m.
New subject: Core + Extras 2
On Mon, 2006-11-20 at 09:05 -0600, Rex Dieter wrote:
Jesse Keating wrote:
> On Monday 20 November 2006 08:41, Rahul Sundaram wrote:
>> Are you talking about having a general policy on updates or having a
>> release freeze like FC instead of rolling updates like FE?
>
> No, he's asking about introducing new packages to a released product. Say
> Fedora 7 goes out the door with a given package set. Three weeks later a
> great new package gets added to the Fedora universe, what kind of policy
> would there be in making this package available to the Fedora 7 users?
IMO, barring policy details on how to make it work (which can be hammerred
out later), adding new packages to Fedora after "release" is IMO absolutely
essential.
Definitely - It's one of the essentials the current FE is based on.
Ralf
3:31 p.m.
New subject: Core + Extras 2
Ralf Corsepius wrote:
On Mon, 2006-11-20 at 09:05 -0600, Rex Dieter wrote:
> IMO, barring policy details on how to make it work (which can be hammerred
> out later), adding new packages to Fedora after "release" is IMO
absolutely
> essential.
Definitely - It's one of the essentials the current FE is based on.
Agreed. My main motivation as a packager is to get an application onto
the release I'm using at the moment. Yes, I can maintain my own repo (I
already do for some stuff), but where's the community in that?
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
9:09 a.m.
New subject: Core + Extras 2
On Mon, Nov 20, 2006 at 09:05:24AM -0600, Rex Dieter wrote:
IMO, barring policy details on how to make it work (which can be
hammerred
out later), adding new packages to Fedora after "release" is IMO absolutely
essential.
What can't stand six months of testing in rawhide?
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
9:16 a.m.
New subject: Core + Extras 2
On Mon, Nov 20, 2006 at 10:09:51AM -0500, Matthew Miller wrote:
> out later), adding new packages to Fedora after
"release" is IMO absolutely
> essential.
What can't stand six months of testing in rawhide?
Packaging assumptions which block extras packages, updates which change
name due to trademarks
9:18 a.m.
New subject: Core + Extras 2
On Mon, Nov 20, 2006 at 10:16:21AM -0500, Alan Cox wrote:
> > out later), adding new packages to Fedora after
"release" is IMO absolutely
> > essential.
> What can't stand six months of testing in rawhide?
Packaging assumptions which block extras packages, updates which change
name due to trademarks
? That sounds exactly like a reason to have rawhide rather than dropping
instability into the released distro.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
9:25 a.m.
New subject: Core + Extras 2
On Mon, 2006-11-20 at 10:09 -0500, Matthew Miller wrote:
On Mon, Nov 20, 2006 at 09:05:24AM -0600, Rex Dieter wrote:
> IMO, barring policy details on how to make it work (which can be hammerred
> out later), adding new packages to Fedora after "release" is IMO
absolutely
> essential.
What can't stand six months of testing in rawhide?
Users, who want to use/need
a package, developers/maintainers who want
to see their work used. Rawhide doesn't cater these *user demands*,
rawhide is a mere developer platform trying to cater their demands.
Ralf
9:31 a.m.
New subject: Core + Extras 2
On Mon, Nov 20, 2006 at 04:25:11PM +0100, Ralf Corsepius wrote:
> What can't stand six months of testing in rawhide?
Users, who want to use/need a package, developers/maintainers who want
to see their work used. Rawhide doesn't cater these *user demands*,
rawhide is a mere developer platform trying to cater their demands.
I see this side of it too.
How about stipulating that new packages will only go in the newest release,
and won't be added to older still-supported releases?
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
9:35 a.m.
New subject: Core + Extras 2
Matthew Miller wrote:
On Mon, Nov 20, 2006 at 04:25:11PM +0100, Ralf Corsepius wrote:
>> What can't stand six months of testing in rawhide?
> Users, who want to use/need a package, developers/maintainers who want
> to see their work used. Rawhide doesn't cater these *user demands*,
> rawhide is a mere developer platform trying to cater their demands.
I see this side of it too.
How about stipulating that new packages will only go in the newest release,
and won't be added to older still-supported releases?
That could be done, but whats the gain? We have recently been discussing to wait
with EOL a bit so that users only have to upgrade once every year, thats already pretty
often for some users, why disallow them use / pleasure of newer packages?
Now adding newer packages to EOL. thats bad, but why not to FC-current and
FC-(current-1)?
Early updaters will upgrade soon anyways, and others are very unlikely to upgrade sooner
for one or 2 new packages which they want,
they will probab;y start using atrpms or something like that, which is exactly what we do
not want.
Regards,
Hans
9:36 a.m.
New subject: Core + Extras 2
On Mon, Nov 20, 2006 at 04:35:46PM +0100, Hans de Goede wrote:
Early updaters will upgrade soon anyways, and others are very
unlikely to
upgrade sooner for one or 2 new packages which they want,
they will probab;y start using atrpms or something like that, which is
exactly what we do not want.
Okay, you've convinced me. :)
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
9:44 a.m.
New subject: Core + Extras 2
On Mon, 2006-11-20 at 10:31 -0500, Matthew Miller wrote:
On Mon, Nov 20, 2006 at 04:25:11PM +0100, Ralf Corsepius wrote:
> > What can't stand six months of testing in rawhide?
> Users, who want to use/need a package, developers/maintainers who want
> to see their work used. Rawhide doesn't cater these *user demands*,
> rawhide is a mere developer platform trying to cater their demands.
I see this side of it too.
How about stipulating that new packages will only go in the newest release,
and won't be added to older still-supported releases?
That's the old
"legacy" problem.
My opinion on this: As long as a new package doesn't break something (no
API/ABI changes, no SONAME changes, no package/file conflicts etc.), and
as long somebody is volunteering to *maintain* a package for older
releases, I don't see much reason to hinder this volunteer.
In some cases, this will be possible and easy, in some cases this won't
work out. In FE, in practice, this so far had worked out quite well.
I also don't disagree, that we need a real "cut-off" mark somewhere, say
Fedora(Current-2).
Ralf
9:52 a.m.
New subject: Core + Extras 2
Rex Dieter schrieb:
Jesse Keating wrote:
> On Monday 20 November 2006 08:41, Rahul Sundaram wrote:
>> Are you talking about having a general policy on updates or having a
>> release freeze like FC instead of rolling updates like FE?
> No, he's asking about introducing new packages to a released product. Say
> Fedora 7 goes out the door with a given package set. Three weeks later a
> great new package gets added to the Fedora universe, what kind of policy
> would there be in making this package available to the Fedora 7 users?
IMO, barring policy details on how to make it work (which can be hammerred
out later), adding new packages to Fedora after "release" is IMO absolutely
essential.
+1
CU
thl
9:08 a.m.
On Mon, 2006-11-20 at 09:13 -0500, Jesse Keating wrote:
On Monday 20 November 2006 08:41, Rahul Sundaram wrote:
> Are you talking about having a general policy on updates or having a
> release freeze like FC instead of rolling updates like FE?
No, he's asking about introducing new packages to a released product. Say
Fedora 7 goes out the door with a given package set. Three weeks later a
great new package gets added to the Fedora universe, what kind of policy
would there be in making this package available to the Fedora 7 users?
IMO,
basically like FE has been doing it, so far, except that breaking
APIs, ABIs and packages deps etc. must not happen.
Its an interesting question, one that I'd like to hear opinions
on.
Historically we haven't made new packages available in core unless they were
needed by something else already in. However having Extras around helped in
that new packages could get introduced there.
Exactly, you'd loose this
advantage.
Also you seem to be neglecting that "volunteer contributors" are
interested in seeing their packages being shipped and used, i.e. as part
of the current distro. At least to me contributing packages to "rawhide"
at the price of having to cope with "rawhide" would be highly
non-interesting and non-applicable.
Ralf
9:42 a.m.
Ralf Corsepius wrote:
Also you seem to be neglecting that "volunteer contributors"
are
interested in seeing their packages being shipped and used, i.e. as part
of the current distro. At least to me contributing packages to "rawhide"
at the price of having to cope with "rawhide" would be highly
non-interesting and non-applicable.
+1
Dmitry Butskoy
11:35 a.m.
Ralf Corsepius wrote:
On Mon, 2006-11-20 at 09:13 -0500, Jesse Keating wrote:
> No, he's asking about introducing new packages to a released
product.
> Say
> Fedora 7 goes out the door with a given package set. Three weeks later a
> great new package gets added to the Fedora universe, what kind of policy
> would there be in making this package available to the Fedora 7 users?
IMO, basically like FE has been doing it, so far, except that
breaking
APIs, ABIs and packages deps etc. must not happen.
That language may be a bit too strong, as I can think of cases where an
essential update may end up breaking ABI, though it's not unreasonable to
to make policy such that it *should* (not must) be avoided.
-- Rex
12:56 a.m.
On Mon, 2006-11-20 at 11:35 -0600, Rex Dieter wrote:
Ralf Corsepius wrote:
> On Mon, 2006-11-20 at 09:13 -0500, Jesse Keating wrote:
>> No, he's asking about introducing new packages to a released product.
>> Say
>> Fedora 7 goes out the door with a given package set. Three weeks later a
>> great new package gets added to the Fedora universe, what kind of policy
>> would there be in making this package available to the Fedora 7 users?
> IMO, basically like FE has been doing it, so far, except that breaking
> APIs, ABIs and packages deps etc. must not happen.
That language may be a bit too strong, as I can think of cases where an
essential update may end up breaking ABI, though it's not unreasonable to
to make policy such that it *should* (not must) be avoided.
Well, this
"must" is the core point about all this - Fedora should be a
stable distro.
Where would be the difference to rawhide, otherwise?
Ralf
8:47 a.m.
Ralf Corsepius <rc040203 <at> freenet.de> writes:
> That language may be a bit too strong, as I can think of cases
where an
> essential update may end up breaking ABI, though it's not unreasonable to
> to make policy such that it *should* (not must) be avoided.
Well, this "must" is the core point about all this - Fedora should be a
stable distro.
Where would be the difference to rawhide, otherwise?
* Less bugs (because stuff usually got through Rawhide and/or updates-testing
before, and also because updates which are known to break stuff are not pushed
to the stable distro).
* Less dependency problems within packages shipped by Fedora (as
in "reverse-dependencies get rebuilt for the ABI change and pushed together
with the ABI-changing library update", not as in "ABIs never change"; the
Core/Extras merger will probably make it easier to coordinate ABI changes in
core packages, so the lag between a core library update and all packages
getting rebuilt can in principle be made invisible to the user through
coordination of the pushes).
Kevin Kofler
9:26 a.m.
Ralf Corsepius wrote:
On Mon, 2006-11-20 at 11:35 -0600, Rex Dieter wrote:
> Ralf Corsepius wrote:
>
>> On Mon, 2006-11-20 at 09:13 -0500, Jesse Keating wrote:
>>> No, he's asking about introducing new packages to a released product.
>>> Say
>>> Fedora 7 goes out the door with a given package set. Three weeks later a
>>> great new package gets added to the Fedora universe, what kind of policy
>>> would there be in making this package available to the Fedora 7 users?
>> IMO, basically like FE has been doing it, so far, except that breaking
>> APIs, ABIs and packages deps etc. must not happen.
> That language may be a bit too strong, as I can think of cases where an
> essential update may end up breaking ABI, though it's not unreasonable to
> to make policy such that it *should* (not must) be avoided.
Well, this "must" is the core point about all this - Fedora
should be a
stable distro.
I guess we disagree then. I consider ABI compatibility as just one part
of what defines a stable distro, but, imo, there are certainly cases
where breaking ABI is justified (for essential features, bug fixes, and
yes, stability sometimes).
-- Rex
9:29 a.m.
Ralf Corsepius wrote:
On Mon, 2006-11-20 at 11:35 -0600, Rex Dieter wrote:
> Ralf Corsepius wrote:
>
>> On Mon, 2006-11-20 at 09:13 -0500, Jesse Keating wrote:
>>> No, he's asking about introducing new packages to a released product.
>>> Say
>>> Fedora 7 goes out the door with a given package set. Three weeks later a
>>> great new package gets added to the Fedora universe, what kind of policy
>>> would there be in making this package available to the Fedora 7 users?
>> IMO, basically like FE has been doing it, so far, except that breaking
>> APIs, ABIs and packages deps etc. must not happen.
> That language may be a bit too strong, as I can think of cases where an
> essential update may end up breaking ABI, though it's not unreasonable to
> to make policy such that it *should* (not must) be avoided.
Well, this "must" is the core point about all this - Fedora
should be a
stable distro.
I guess we disagree then. I consider ABI compatibility as just one part
of what defines a stable distro, but, imo, there are certainly cases
where breaking ABI is justified (for essential features, bug fixes, and
yes, stability sometimes).
-- Rex
9:30 a.m.
On Tue, 2006-11-21 at 09:29 -0600, Rex Dieter wrote:
Ralf Corsepius wrote:
> On Mon, 2006-11-20 at 11:35 -0600, Rex Dieter wrote:
>> Ralf Corsepius wrote:
>>
>>> On Mon, 2006-11-20 at 09:13 -0500, Jesse Keating wrote:
>>>> No, he's asking about introducing new packages to a released
product.
>>>> Say
>>>> Fedora 7 goes out the door with a given package set. Three weeks later
a
>>>> great new package gets added to the Fedora universe, what kind of
policy
>>>> would there be in making this package available to the Fedora 7 users?
>>> IMO, basically like FE has been doing it, so far, except that breaking
>>> APIs, ABIs and packages deps etc. must not happen.
>> That language may be a bit too strong, as I can think of cases where an
>> essential update may end up breaking ABI, though it's not unreasonable to
>> to make policy such that it *should* (not must) be avoided.
> Well, this "must" is the core point about all this - Fedora should be a
> stable distro.
I guess we disagree then.
<bitter sarcasm>
Welcome to the wonderful "world of rawhide" - Good Night, Fedora!
You once had been a usable distro, but your masters now seem to be
wanting to convert you into a jungle :(
</bitter sarcasm>
I consider ABI compatibility as just one part
of what defines a stable distro, but, imo, there are certainly cases
where breaking ABI is justified (for essential features, bug fixes, and
yes, stability sometimes).
Please ask RH how they have been handling Core, so far.
I don't know how many times I've been told: "No API-changes, no ABI
upgrade, no feature upgrades, often not even bugfixes (aka
FIXEDRAWHIDE)"!
Ralf
11:31 a.m.
Ralf Corsepius wrote:
On Tue, 2006-11-21 at 09:29 -0600, Rex Dieter wrote:
> I consider ABI compatibility as just one part
> of what defines a stable distro, but, imo, there are certainly cases
> where breaking ABI is justified (for essential features, bug fixes, and
> yes, stability sometimes).
Please ask RH how they have been handling Core, so far.
I don't know how many times I've been told: "No API-changes, no ABI
upgrade, no feature upgrades, often not even bugfixes (aka
FIXEDRAWHIDE)"!
When it comes to breaking API/ABI, I'd say it's primarily the package
maintainers' call to make. You just experienced cases where they chose
not to upgrade, which isn't contrary at all to what I described.
-- Rex
9:55 p.m.
On Tue, 2006-11-21 at 11:31 -0600, Rex Dieter wrote:
Ralf Corsepius wrote:
> On Tue, 2006-11-21 at 09:29 -0600, Rex Dieter wrote:
>> I consider ABI compatibility as just one part
>> of what defines a stable distro, but, imo, there are certainly cases
>> where breaking ABI is justified (for essential features, bug fixes, and
>> yes, stability sometimes).
>
> Please ask RH how they have been handling Core, so far.
>
> I don't know how many times I've been told: "No API-changes, no ABI
> upgrade, no feature upgrades, often not even bugfixes (aka
> FIXEDRAWHIDE)"!
When it comes to breaking API/ABI, I'd say it's primarily the package
maintainers' call to make.
I am inclined to agree in those cases, where a package is of limited
importance, has a very limited number of dependencies and/or a small
userbase, but I can't avoid to disagree in general.
But what would you think of a kernel, GCC, Glibc, Gtk/Gtk or Qt/KDE
maintainer, who breaks things midst of a distro's life time?
Have a look at FE: A classic breakdown is maintainers not paying
attention to SONAMEs/ABIs/APIs and them inadvertently breaking something
by not so.
Most maintainers, after having gone through a learning curse, will try
to circumvent such issues, either by providing compat-packages, by
trying to inform their users in advance, or ... to resort to refraining
from their plans.
Ralf
12:59 p.m.
Ralf Corsepius wrote:
On Tue, 2006-11-21 at 09:29 -0600, Rex Dieter wrote:
> Ralf Corsepius wrote:
>> On Mon, 2006-11-20 at 11:35 -0600, Rex Dieter wrote:
>>> Ralf Corsepius wrote:
>>>
>>>> On Mon, 2006-11-20 at 09:13 -0500, Jesse Keating wrote:
>>>>> No, he's asking about introducing new packages to a released
product.
>>>>> Say
>>>>> Fedora 7 goes out the door with a given package set. Three weeks
later a
>>>>> great new package gets added to the Fedora universe, what kind of
policy
>>>>> would there be in making this package available to the Fedora 7
users?
>>>> IMO, basically like FE has been doing it, so far, except that breaking
>>>> APIs, ABIs and packages deps etc. must not happen.
>>> That language may be a bit too strong, as I can think of cases where an
>>> essential update may end up breaking ABI, though it's not unreasonable
to
>>> to make policy such that it *should* (not must) be avoided.
>> Well, this "must" is the core point about all this - Fedora should be
a
>> stable distro.
> I guess we disagree then.
<bitter sarcasm>
Welcome to the wonderful "world of rawhide" - Good Night, Fedora!
You once had been a usable distro, but your masters now seem to be
wanting to convert you into a jungle :(
</bitter sarcasm>
> I consider ABI compatibility as just one part
> of what defines a stable distro, but, imo, there are certainly cases
> where breaking ABI is justified (for essential features, bug fixes, and
> yes, stability sometimes).
Please ask RH how they have been handling Core, so far.
I don't know how many times I've been told: "No API-changes, no ABI
upgrade, no feature upgrades, often not even bugfixes (aka
FIXEDRAWHIDE)"!
There is no one-size-fits-all solution here. Sometimes, it is just
plain dumb to not break API.
Case study: https://bugzilla.mozilla.org/show_bug.cgi?id=296639 fixes a
few critical security issues and other important bugs by differentiating
priveleged and unpriveleged window objects. Effectively, this is a
complete re-architecturing of the way DOM windows are handled internally
to gecko, required because the previous architecture was flawed by
design. It's a very large patch, which caused quite a number of
regressions. Still, it was deemed necessary to get this fix into Red
Hat Enterprise Linux 2.1, 3, and 4 for security purposes in a meeting
with our security response team, product management, QA, and myself.
Option A: wait for someone else to do something. wait time is high.
potential for regression is high.
Option B: spend many weeks on a solution, getting little exposure on it
before releasing it to the wild as an update. Potential for regression
is high.
Option C: take the new version wholesale. The flaws are guaranteed
fixed. API will break slightly, but with warning and possibly a little
help, people can adapt. Most applications were fine with little to no
changes. Eclipse needed some help, but I helped the team get around
that. Devhelp needed a little bit of help, but it didn't take long.
Naturally, we went with option C, after discussing the options, although
it became clear quickly that option C was the best choice. I see no
reason Fedora can't make informed, intelligent decisions if the need
arises. Expressly forbidding these decisions to be made is the wrong
thing to do.
Rex is correct. We should look to avoid these situations if at all
possible. But sometimes, there is no good alternative.
10:07 p.m.
On Tue, 2006-11-21 at 13:59 -0500, Christopher Aillon wrote:
Rex is correct. We should look to avoid these situations if at all
possible. But sometimes, there is no good alternative.
No disagreement ... if
"there is no good alternative" ... I am not
against breaking ABIs/APIs/etc.
But, from an FE background, the situation is conversely:
People break ABIs/APIs/etc., because they are not aware about doing so,
because they do not care about it, because they blindly follow upstream
(and upstream doesn't care about ABI/API/etc.) or because they think
"having feature XXX outweighs ABI/API/etc.".
Ralf
3:56 p.m.
Ralf Corsepius wrote:
But, from an FE background, the situation is conversely:
People break ABIs/APIs/etc.,
because they are not aware about doing so,
Unfortunate, but could potentially be caught with education and
updates-testing.
because they do not care about it,
sad also, break out clue-stick.
because they blindly follow upstream
(and upstream doesn't care about ABI/API/etc.)
I'd say maintainer's in a tough situation, if upstream neither cares,
nor supports the older version, what to do?
because they think "having feature XXX outweighs
ABI/API/etc.".
Already addressed. Judgement call.
-- Rex
9:12 a.m.
On Mon, 2006-11-20 at 09:13 -0500, Jesse Keating wrote:
On Monday 20 November 2006 08:41, Rahul Sundaram wrote:
> Are you talking about having a general policy on updates or having a
> release freeze like FC instead of rolling updates like FE?
No, he's asking about introducing new packages to a released product. Say
Fedora 7 goes out the door with a given package set. Three weeks later a
great new package gets added to the Fedora universe, what kind of policy
would there be in making this package available to the Fedora 7 users?
Its an interesting question, one that I'd like to hear opinions on.
Historically we haven't made new packages available in core unless they were
needed by something else already in. However having Extras around helped in
that new packages could get introduced there. Just adding the package in
sounds OK on the surface, but one needs to consider some of the guidelines
we're putting up as far as what can be spun and called Fedora. If a bunch of
new packages show up after Fedora 7 is cut, would somebody be able to make
use of those packages when spinning their cut of Fedora 7? I think it's
pretty safe to say that a lot of these packages wouldn't have a chance to go
through any kind of QA / Testing that Will is trying to put in place.
Here's a proposal to consider:
"Official" packages for Fedora release X would consist of those packages
that exist in the development repository at the time that release X is
branched, plus official packages that are updated to fix security issues
or bugs. Maintainers would be discouraged from performing non- security
or bugfix related updates to official packages, especially if the update
would require updates to other packages.
New packages (i.e. packages that were not in the development repository
when the release was branched) would be added officially to a Fedora X
release only if they were required to fix a security issue or bug with a
package already in the official release. Approval from whatever board
is in charge of Fedora would be required to give a new package official
status in a released version of Fedora.
However, builds for new packages could be requested for non-development
branches. The binary packages would go into the same yum repos as
official packages but would have "unofficial" status. No official
package could have a build- or run-time dependency on an unofficial
package, no conflicts between official and unofficial packages, etc.
etc. Also, no Fedora branded {server,desktop,yadda yadda} CD/DVD
release could include unofficial packages (you could make a release, you
just couldn't call it Fedora).
Use of the package database would be required to track the status of
packages, and hopefully scripts could be developed that would prevent
(or at least detect) violations of policy.
Allowing "unofficial" packages in the yum repos is so that people could
access new packages easily (as long as they have Internet access).
Requiring people to run development (or downloading the SRPM and
rebuilding it) just to access new packages just seems too cruel. I'm
sure that there are a lot of people out there like me that want to try
out that new game or word processor or whatever but need a stable enough
system that they can rely on it being in a working state.
Jeff
9:26 a.m.
On Mon, Nov 20, 2006 at 09:12:46AM -0600, Jeffrey C. Ollie wrote:
"Official" packages for Fedora release X would consist of those packages
that exist in the development repository at the time that release X is
branched, plus official packages that are updated to fix security issues
or bugs. Maintainers would be discouraged from performing non- security
or bugfix related updates to official packages, especially if the update
would require updates to other packages.
This is not what I'm looking for in Fedora.
Please don't do this. It will just turn Fedora into yet another one of
many "backport security fixes only and make our users die of boredom"
distributions.
Emmanuel
9:32 a.m.
On Mon, Nov 20, 2006 at 04:26:10PM +0100, Emmanuel Seyman wrote:
This is not what I'm looking for in Fedora.
Perhaps what you are looking for is in rawhide. (That's what I run on my
desktop.)
Please don't do this. It will just turn Fedora into yet another
one of
many "backport security fixes only and make our users die of boredom"
distributions.
There's a six month release cycle! Do you really die of boredom that
quickly?
There's something to be said for a _little_ boring.
--
Matthew Miller mattdm(a)mattdm.org <http://mattdm.org/>
Boston University Linux ------> <http://linux.bu.edu/>
10:36 a.m.
On Mon, Nov 20, 2006 at 10:32:56AM -0500, Matthew Miller wrote:
Perhaps what you are looking for is in rawhide. (That's what I run on my
desktop.)
That may be. I've never actually tried to run rawhide on a permanent basis
because I don't have the time necessary to report bugs for any extended
period.
> Please don't do this. It will just turn Fedora into yet
another one of
> many "backport security fixes only and make our users die of boredom"
> distributions.
There's a six month release cycle! Do you really die of boredom that
quickly?
In the case of waiting for new drivers that are needed for Fedora to work
correctly on my box, I probably would, indeed, die of boredom waiting for
the next release.
There's something to be said for a _little_ boring.
- Demanding that packages pass through updates-testing before going to
updates is a little boring.
- Asking for ABI compatibility is a little boring.
"Security fixes only" is far too restrictif to have that qualification.
Emmanuel
10:53 a.m.
Emmanuel Seyman wrote:
On Mon, Nov 20, 2006 at 10:32:56AM -0500, Matthew Miller wrote:
> Perhaps what you are looking for is in rawhide. (That's what I run on my
> desktop.)
That may be. I've never actually tried to run rawhide on a permanent basis
because I don't have the time necessary to report bugs for any extended
period.
>> Please don't do this. It will just turn Fedora into yet another one of
>> many "backport security fixes only and make our users die of boredom"
>> distributions.
> There's a six month release cycle! Do you really die of boredom that
> quickly?
In the case of waiting for new drivers that are needed for Fedora to work
correctly on my box, I probably would, indeed, die of boredom waiting for
the next release.
You are bored because you dont get the latest updates but you dont have
time to participate in testing of rawhide or updates-testing. Perhaps
when you are bored you can help out and contribute.
> There's something to be said for a _little_ boring.
- Demanding that packages pass through updates-testing before going to
updates is a little boring.
A blanket demand might be cumbersome but it generally is a good idea to
shoot for better robustness. Limited exceptions can be granted for high
priority security fixes and other very trivial changes.
- Asking for ABI compatibility is a little boring.
I dont think we can meet ABI compatibility requirements on all updates.
"Security fixes only" is far too restrictif to have that
qualification.
Agreed.
Rahul
11:11 a.m.
On Mon, 2006-11-20 at 22:23 +0530, Rahul Sundaram wrote:
> - Asking for ABI compatibility is a little boring.
I dont think we can meet ABI compatibility requirements on all updates.
You
can't avoid it. In fact, current Core strictly does or at least
tries hard to strive for it. FE is a bit sloppier about it.
Ralf
11:38 a.m.
Ralf Corsepius wrote:
On Mon, 2006-11-20 at 22:23 +0530, Rahul Sundaram wrote:
>> - Asking for ABI compatibility is a little boring.
> I dont think we can meet ABI compatibility requirements on all updates.
You can't avoid it. In fact, current Core strictly does or at least
tries hard to strive for it. FE is a bit sloppier about it.
Strictly maintaining ABI is very heavy amount of additional work. Since
many upstream projects dont care about it, this essentially means
backporting fixes, struggle on choiecs between security fixes and ABI
breakage, doing QA ack's on every individual patch, running it through a
series of tests etc that is being done on RHEL. We cant afford that
maintenance overhead currently in Fedora.
Rahul
12:49 p.m.
Le lundi 20 novembre 2006 à 17:36 +0100, Emmanuel Seyman a écrit :
On Mon, Nov 20, 2006 at 10:32:56AM -0500, Matthew Miller wrote:
>
> Perhaps what you are looking for is in rawhide. (That's what I run on my
> desktop.)
That may be. I've never actually tried to run rawhide on a permanent basis
because I don't have the time necessary to report bugs for any extended
period.
It's not like this. Running rawhide means you'll have some parts of the
system break at inconvenient time, so you learn workarounding a lot, but
no rawhide user has the energy to report every broken thing. You do it
when you're really annoyed and you have the time to write a good report.
The rest of the time you wait a few days for breakage to fix itself.
That's all there is to the eating babies part 99% of the time
(unglamorous, I know). Rawhide is only slightly less stable than some
Extras parts.
--
Nicolas Mailhot
9:28 a.m.
On Monday 20 November 2006 10:12, Jeffrey C. Ollie wrote:
Here's a proposal to consider:
I'd like to mull over your proposal, but on the service it seems very
confusing, and would be confusing to packagers trying to figure out where
their package goes, and composers trying to figure out what they could use
for a compose. I'd prefer very simplistic and easy to understand rules if
possible.
--
Jesse Keating
Release Engineer: Fedora
10:39 a.m.
Le lundi 20 novembre 2006 à 09:12 -0600, Jeffrey C. Ollie a écrit :
Here's a proposal to consider:
"Official" packages for Fedora release X would consist of those packages
that exist in the development repository at the time that release X is
branched, plus official packages that are updated to fix security issues
or bugs. Maintainers would be discouraged from performing non- security
or bugfix related updates to official packages, especially if the update
would require updates to other packages.
This is clearly against the definition of Fedora you can find on
http://fedoraproject.org/wiki/FAQ
"You should be using Fedora because it includes the best and latest
collection of robust free and open source software available."
The latest software ...
The latest software ...
The latest software ...
--
Thomas Canniot
http://fedoraproject.org/wiki/ThomasCanniot
10:50 a.m.
On Monday 20 November 2006 11:39, Thomas Canniot wrote:
"You should be using Fedora because it includes the best and
latest
collection of robust free and open source software available."
The latest software ...
The latest software ...
The latest software ...
But we can't possibly be all the latest all the time or else we'd never have a
stable release for people to use :/
--
Jesse Keating
Release Engineer: Fedora
11:09 a.m.
Dnia 20-11-2006, pon o godzinie 09:12 -0600, Jeffrey C. Ollie
napisał(a):
Here's a proposal to consider:
"Official" packages for Fedora release X would consist of those packages
that exist in the development repository at the time that release X is
branched, (...)
However, builds for new packages could be requested for
non-development
branches. The binary packages would go into the same yum repos as
official packages but would have "unofficial" status.
What you propose
would become the new Extras - there would be "official"
and "unofficial" where currently there's "Core" and
"Extras".
There's no reason to ban inclusion of e.g. a new game to the
repositories UNLESS it's not obsoleting something already in.
So I'm for a policy:
- update to new versions of existing packages if there are serious
reasons (severe bugs, security fixes),
- add new packages provided they don't get installed automatically on
users' computers.
Lam
11:13 a.m.
On Mon, 2006-11-20 at 18:09 +0100, Leszek Matok wrote:
Dnia 20-11-2006, pon o godzinie 09:12 -0600, Jeffrey C. Ollie
napisał(a):
> Here's a proposal to consider:
>
> "Official" packages for Fedora release X would consist of those packages
> that exist in the development repository at the time that release X is
> branched, (...)
> However, builds for new packages could be requested for non-development
> branches. The binary packages would go into the same yum repos as
> official packages but would have "unofficial" status.
What you propose would become the new Extras - there would be "official"
and "unofficial" where currently there's "Core" and
"Extras".
Kindof... it would mostly control what kind of updates could be applied
to a package in a release branch and which packages could be selected in
a CD/DVD compose and still be branded as "Fedora".
Jeff
6367
days inactive
6369
days old
45 comments
17 participants
participants (17)
-
Alan Cox -
Christopher Aillon -
Dmitry Butskoy -
Emmanuel Seyman -
Hans de Goede -
Jeffrey Ollie -
Jesse Keating -
Kevin Kofler -
Leszek Matok -
Matthew Miller -
Nicolas Mailhot -
Orion Poplawski -
Rahul Sundaram -
Ralf Corsepius -
Rex Dieter -
Thomas Canniot -
Thorsten Leemhuis