4:49 a.m.
Hi all.
KDE 4.3 will come to F11 and F10. It's a cool thing.
There aren't updates like this for Gnome. Why not?
F10 with Gnome 2.26 sounds fine to me.
--
Josephine "Fine" Tannhäuser
2.6.29.6-213.fc11.i586
5:02 a.m.
2009/8/5 Josephine Tannhäuser <josephine.tannhauser(a)googlemail.com>:
KDE 4.3 will come to F11 and F10. It's a cool thing.
There aren't updates like this for Gnome. Why not?
F10 with Gnome 2.26 sounds fine to me.
Because I don't want to _support_ the latest and greatest GNOME on old
versions. A lot of the GNOME stack would require updating core system
stuff like gtk+ and glib2, and when you've done that you might as well
be running F11. I don't mind merging small patches from upstream to
fix specific bugs, but new code brings new bugs, and that's not
something a typical F10 user wants to cope with. In my opinion, if you
want newer functionality, you should just upgrade to F11.
Richard.
5:23 a.m.
On 05.08.2009 12:02, Richard Hughes wrote:
2009/8/5 Josephine Tannhäuser
<josephine.tannhauser(a)googlemail.com>:
> KDE 4.3 will come to F11 and F10. It's a cool thing.
> There aren't updates like this for Gnome. Why not?
> F10 with Gnome 2.26 sounds fine to me.
Because I don't want to _support_ the latest and greatest GNOME on old
versions. A lot of the GNOME stack would require updating core system
stuff like gtk+ and glib2, and when you've done that you might as well
be running F11. I don't mind merging small patches from upstream to
fix specific bugs, but new code brings new bugs, and that's not
something a typical F10 user wants to cope with. In my opinion, if you
want newer functionality, you should just upgrade to F11.
I don't want to get between the lines here (there are good arguments and
against updating Gnome and KDE for older releases) and I hate buzz-words
like "Corporate identity", but I find it more and more odd that one
doesn't know what to expect from Fedora, because similar sized things
(KDE and Gnome) are handled quite differently.
Further: The behavior changes to much IMHO -- one reason why I use
Fedora at home and work and suggested it to others were the major new
kernel versions that got delivered as regular update. But that doesn't
really work anymore since half a year or something: F-10 is still on
2.6.27, 2.6.29 sits in Updates-testing for ages; 2.6.30 is out for
weeks, but no sign of a update for F-11 apart for a few commits in CVS. :-(
A more common look and feel to the outside world and a more reliable
update scheme IMHO would be good for Fedora, as people would know what
to expect. Ohh, and it would prevent discussions like this ;-)
CU
knurd
7:01 a.m.
On Wed, Aug 05, 2009 at 12:23:12PM +0200, Thorsten Leemhuis wrote:
On 05.08.2009 12:02, Richard Hughes wrote:
> 2009/8/5 Josephine Tannhäuser <josephine.tannhauser(a)googlemail.com>:
>> KDE 4.3 will come to F11 and F10. It's a cool thing.
>> There aren't updates like this for Gnome. Why not?
>> F10 with Gnome 2.26 sounds fine to me.
> Because I don't want to _support_ the latest and greatest GNOME on old
> versions. A lot of the GNOME stack would require updating core system
> stuff like gtk+ and glib2, and when you've done that you might as well
> be running F11. I don't mind merging small patches from upstream to
> fix specific bugs, but new code brings new bugs, and that's not
> something a typical F10 user wants to cope with. In my opinion, if you
> want newer functionality, you should just upgrade to F11.
I don't want to get between the lines here (there are good arguments and
against updating Gnome and KDE for older releases) and I hate buzz-words
like "Corporate identity", but I find it more and more odd that one
doesn't know what to expect from Fedora, because similar sized things
(KDE and Gnome) are handled quite differently.
Short of passing a policy that says no major desktop upgrades for stable
releases, I don't see this changing. If we did pass that, I have a feeling
it would piss off a lot of people. Passing the converse (always upgrade)
would piss off just as many.
I'm not that enthralled with starting a "who do you want to piss off
today?"
campaign for Fedora.
Further: The behavior changes to much IMHO -- one reason why I use
Fedora at home and work and suggested it to others were the major new
kernel versions that got delivered as regular update. But that doesn't
really work anymore since half a year or something: F-10 is still on
2.6.27, 2.6.29 sits in Updates-testing for ages; 2.6.30 is out for
weeks, but no sign of a update for F-11 apart for a few commits in CVS. :-(
I haven't followed it that closely days. However, being on the bleeding
edge kernel isn't what it used to be. Yes, 2.6.30 has been out for a while.
But I believe we currently wait until at least the .1 release (which was still
out a while ago). Right now, .4 was just released on Jul 30. Having a bit
of patience to see if the kernel is a lemon or not is pretty prudent IMHO.
A more common look and feel to the outside world and a more reliable
update scheme IMHO would be good for Fedora, as people would know what
to expect. Ohh, and it would prevent discussions like this ;-)
Some of us tried that. We got critcized for it pretty heavily.
josh
1:47 p.m.
On Wed, 2009-08-05 at 08:01 -0400, Josh Boyer wrote:
>I don't want to get between the lines here (there are good
arguments and
>against updating Gnome and KDE for older releases) and I hate buzz-words
>like "Corporate identity", but I find it more and more odd that one
>doesn't know what to expect from Fedora, because similar sized things
>(KDE and Gnome) are handled quite differently.
Short of passing a policy that says no major desktop upgrades for stable
releases, I don't see this changing. If we did pass that, I have a feeling
it would piss off a lot of people. Passing the converse (always upgrade)
would piss off just as many.
I'm not that enthralled with starting a "who do you want to piss off
today?"
campaign for Fedora.
We've had this discussion before, but to re-state my opinion: the only
sane way to handle this is multiple, discretionary update repositories.
A repository for security and stable bugfix updates, and a repository
for other updates - major version bumps whose purpose isn't solely to
fix a security issue or, with minimal changes, a clearly identified bug.
It's more work, but it's the only workable consistent system that
doesn't restrict some maintainer from being able to do what they want to
do. A distribution with much fewer resources than Fedora (Mandriva) has
been using this system successfully, to the satisfaction of developers
and users, for several releases now.
The system gives users the flexibility to choose whether they want a
'traditional' stable update system, or a more adventurous,
version-upgrading system. And maintainers can choose whether or not they
want to take on the work of shipping updates in the adventurous
repository. In all cases, users and maintainers both know what each
repository is for, and what they'll be getting depending on which they
choose to use.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
1:49 p.m.
On Wed, Aug 5, 2009 at 1:47 PM, Adam Williamson<awilliam(a)redhat.com> wrote:
<snip>
We've had this discussion before, but to re-state my opinion: the
only
sane way to handle this is multiple, discretionary update repositories.
A repository for security and stable bugfix updates, and a repository
for other updates - major version bumps whose purpose isn't solely to
fix a security issue or, with minimal changes, a clearly identified bug.
It's more work, but it's the only workable consistent system that
doesn't restrict some maintainer from being able to do what they want to
do. A distribution with much fewer resources than Fedora (Mandriva) has
been using this system successfully, to the satisfaction of developers
and users, for several releases now.
The system gives users the flexibility to choose whether they want a
'traditional' stable update system, or a more adventurous,
version-upgrading system. And maintainers can choose whether or not they
want to take on the work of shipping updates in the adventurous
repository. In all cases, users and maintainers both know what each
repository is for, and what they'll be getting depending on which they
choose to use.
<snip>
+1
Would definitely be one way to solve this sort of problem.
-Adam
--
http://maxamillion.googlepages.com
---------------------------------------------------------
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
1:51 p.m.
On Wed, Aug 5, 2009 at 2:49 PM, Adam Miller<maxamillion(a)gmail.com> wrote:
On Wed, Aug 5, 2009 at 1:47 PM, Adam
Williamson<awilliam(a)redhat.com> wrote:
<snip>
> We've had this discussion before, but to re-state my opinion: the only
> sane way to handle this is multiple, discretionary update repositories.
> A repository for security and stable bugfix updates, and a repository
> for other updates - major version bumps whose purpose isn't solely to
> fix a security issue or, with minimal changes, a clearly identified bug.
>
> It's more work, but it's the only workable consistent system that
> doesn't restrict some maintainer from being able to do what they want to
> do. A distribution with much fewer resources than Fedora (Mandriva) has
> been using this system successfully, to the satisfaction of developers
> and users, for several releases now.
>
> The system gives users the flexibility to choose whether they want a
> 'traditional' stable update system, or a more adventurous,
> version-upgrading system. And maintainers can choose whether or not they
> want to take on the work of shipping updates in the adventurous
> repository. In all cases, users and maintainers both know what each
> repository is for, and what they'll be getting depending on which they
> choose to use.
<snip>
+1
Would definitely be one way to solve this sort of problem.
-Adam
--
http://maxamillion.googlepages.com
---------------------------------------------------------
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
+1
OpenSUSE buildservice does this and it is nice to be able to pull
things like latest OpenOffice, etc.
--
Mark Bidewell
http://www.linkedin.com/in/markbidewell
1:58 p.m.
On Wed, Aug 5, 2009 at 1:51 PM, Mark
Bidewell<mark.bidewell(a)alumni.clemson.edu> wrote:
<snip>
+1
<snip>
Would we want to consider putting together a proposal for something
that is OpenSuSE Buildservice "styled" in order to satisfy this?
-Adam
--
http://maxamillion.googlepages.com
---------------------------------------------------------
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
2:06 p.m.
On Wed, 2009-08-05 at 13:58 -0500, Adam Miller wrote:
On Wed, Aug 5, 2009 at 1:51 PM, Mark
Bidewell<mark.bidewell(a)alumni.clemson.edu> wrote:
<snip>
>
> +1
>
<snip>
Would we want to consider putting together a proposal for something
that is OpenSuSE Buildservice "styled" in order to satisfy this?
It doesn't really need that (though it'd not be a bad thing to have,
necessarily; actually, I believe there's an ongoing project to open up
our current build system to public use through a PPA-style system). It's
more just a question of introducing extra repositories to be used (from
both the user and maintainer side) through the existing build system.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
1:58 p.m.
On 08/05/2009 11:47 AM, Adam Williamson wrote:
And maintainers can choose whether or not they
want to take on the work of shipping updates in the adventurous
repository.
How does this work? It would seem that the adventurous repository would
be mandatory as something that changes ABI would require other packages
to be rebuilt.
Also, having the expectation that the other repository is for security
updates doesn't address the problem of a security release breaking ABI.
-Toshio
2:11 p.m.
On Wed, 2009-08-05 at 11:58 -0700, Toshio Kuratomi wrote:
On 08/05/2009 11:47 AM, Adam Williamson wrote:
> And maintainers can choose whether or not they
> want to take on the work of shipping updates in the adventurous
> repository.
How does this work? It would seem that the adventurous repository would
be mandatory as something that changes ABI would require other packages
to be rebuilt.
In the Mandriva system, ABI-breaking updates in /backports are
discouraged by policy. When it happens, obviously you have to provide
updates for all dependencies in /backports, too.
Neither of the examples in question really breaks many public ABIs,
though, AFAIK. GTK+ version bumps don't break the ABI, we don't rebuild
seven thousand packages each time GTK+ gets updated (it's still on the
2.0 ABI). Most KDE / GNOME breakage with new releases is 'internal', I
think - so if you're updating all of KDE/GNOME anyway, the API/ABI
breakage isn't a problem.
Also, having the expectation that the other repository is for
security
updates doesn't address the problem of a security release breaking ABI.
That's rather unlikely (well, except in oddball cases like Firefox /
XULRunner), but sure it does - if a security update cannot be done in
any way other than by breaking API/ABI, you ship rebuilds of all
dependent packages as official updates in the stable update repository.
That's how we'd handle it at present anyway. The normal policy is you do
the minimum possible amount of changes to address vital problems, but
you do _have_ to fix them, even if the 'minimum possible amount of
changes' involves rebuilding a dozen packages. This is how all
conventionally updated distros work, AFAIK (including for e.g. RHEL -
they wouldn't just leave a security hole unpatched because they had to
break an API/ABI to fix it ...)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:44 p.m.
On 08/05/2009 12:11 PM, Adam Williamson wrote:
On Wed, 2009-08-05 at 11:58 -0700, Toshio Kuratomi wrote:
> Also, having the expectation that the other repository is for security
> updates doesn't address the problem of a security release breaking ABI.
That's rather unlikely (well, except in oddball cases like Firefox /
XULRunner),
heh, the exact case I was thinking of :-)
but sure it does - if a security update cannot be done in
any way other than by breaking API/ABI, you ship rebuilds of all
dependent packages as official updates in the stable update repository.
That's how we'd handle it at present anyway. The normal policy is you do
the minimum possible amount of changes to address vital problems, but
you do _have_ to fix them, even if the 'minimum possible amount of
changes' involves rebuilding a dozen packages. This is how all
conventionally updated distros work, AFAIK (including for e.g. RHEL -
they wouldn't just leave a security hole unpatched because they had to
break an API/ABI to fix it ...)
Sure, this is comparable to the present situation. But it doesn't seem
like it makes things much better.
* It doesn't solve the original poster's issue (that the GNOME stack
isn't going to be updated for F10 since the maintainers don't want to do
this and the policy wouldn't require it)
* It doesn't solve the follow-on issue of things being different between
major Fedora components (since gnome maintainers don't want to
participate but kde maintainers do)
* It makes things more complex (for instance, we would have to build
packages against multiple repository sets -- ie: [F12-release +
F12-updates-security] [F12-release + F12-updates-security +
F12-updates-adventurous] since there could be incompatibilities between
the packages in updates-security and updates-adventurous.).
* It makes more work for rel-eng to prepare and push the extra repos.
-Toshio
2:58 p.m.
On Wed, 2009-08-05 at 12:44 -0700, Toshio Kuratomi wrote:
Sure, this is comparable to the present situation. But it doesn't seem
like it makes things much better.
* It doesn't solve the original poster's issue (that the GNOME stack
isn't going to be updated for F10 since the maintainers don't want to do
this and the policy wouldn't require it)
* It doesn't solve the follow-on issue of things being different between
major Fedora components (since gnome maintainers don't want to
participate but kde maintainers do)
* It makes things more complex (for instance, we would have to build
packages against multiple repository sets -- ie: [F12-release +
F12-updates-security] [F12-release + F12-updates-security +
F12-updates-adventurous] since there could be incompatibilities between
the packages in updates-security and updates-adventurous.).
* It makes more work for rel-eng to prepare and push the extra repos.
It also would require multiple CVS branches, one for security, one for
adventurous, as well as different buildroots to go along with those,
since you wouldn't be able to build a security update for a gnome
package against the newer adventurous gtk and expect it to work on the
older GTK, likewise if you had to modify a gnome package to work with
newer gtk, you dont' want those modifications in the way if/when you
need to do a conservative security update for it later.
All this really does is create a pseudo rawhide for each release,
blurring the lines even more around why we even do releases. With a 6
month cycle, do we really want to take on all this extra headaches and
hassles just so that you can have some newer experimental software a bit
sooner, or without doing a wholesale update to the next release?
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:03 p.m.
On Wed, 2009-08-05 at 12:58 -0700, Jesse Keating wrote:
It also would require multiple CVS branches, one for security, one
for
adventurous, as well as different buildroots to go along with those,
since you wouldn't be able to build a security update for a gnome
package against the newer adventurous gtk and expect it to work on the
older GTK, likewise if you had to modify a gnome package to work with
newer gtk, you dont' want those modifications in the way if/when you
need to do a conservative security update for it later.
Oh I forgot, you also need -testing versions of each of those repos, so
for any release, you could have updates, updates-testing, experimental,
and experimental-testing repo options and build targets and buildroot
shuffling going on. WHAT FUN!
--
Jesse Keating RHCE (http://jkeating.livejournal.com)
Fedora Project (http://fedoraproject.org/wiki/JesseKeating)
GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub)
identi.ca (http://identi.ca/jkeating)
4:27 p.m.
On Wed, 2009-08-05 at 13:03 -0700, Jesse Keating wrote:
On Wed, 2009-08-05 at 12:58 -0700, Jesse Keating wrote:
> It also would require multiple CVS branches, one for security, one for
> adventurous, as well as different buildroots to go along with those,
> since you wouldn't be able to build a security update for a gnome
> package against the newer adventurous gtk and expect it to work on the
> older GTK, likewise if you had to modify a gnome package to work with
> newer gtk, you dont' want those modifications in the way if/when you
> need to do a conservative security update for it later.
Oh I forgot, you also need -testing versions of each of those repos, so
for any release, you could have updates, updates-testing, experimental,
and experimental-testing repo options and build targets and buildroot
shuffling going on. WHAT FUN!
Mandriva has a /testing repository for /updates, but not for /backports,
on the basis that /backports is fundamentally unstable so you may as
well just do your testing in the repo. This works fine, so far.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
10:30 p.m.
Adam Williamson wrote:
Mandriva has a /testing repository for /updates, but not for
/backports,
on the basis that /backports is fundamentally unstable so you may as
well just do your testing in the repo. This works fine, so far.
That's not going to work for KDE SIG. Updates like KDE 4.3.0 really need
testing. (Of course we could use kde-redhat testing for that, but at that
point I'd have to start wondering why we're bothering with Fedora's
infrastructure for updates entirely. I really don't think forcing us to go
back to kde-redhat as the primary delivery mechanism for our updates is
going to be helpful.)
Kevin Kofler
4:22 a.m.
Le mercredi 05 août 2009 à 14:27 -0700, Adam Williamson a écrit :
On Wed, 2009-08-05 at 13:03 -0700, Jesse Keating wrote:
> On Wed, 2009-08-05 at 12:58 -0700, Jesse Keating wrote:
> > It also would require multiple CVS branches, one for security, one for
> > adventurous, as well as different buildroots to go along with those,
> > since you wouldn't be able to build a security update for a gnome
> > package against the newer adventurous gtk and expect it to work on the
> > older GTK, likewise if you had to modify a gnome package to work with
> > newer gtk, you dont' want those modifications in the way if/when you
> > need to do a conservative security update for it later.
>
> Oh I forgot, you also need -testing versions of each of those repos, so
> for any release, you could have updates, updates-testing, experimental,
> and experimental-testing repo options and build targets and buildroot
> shuffling going on. WHAT FUN!
Mandriva has a /testing repository for /updates, but not for /backports,
on the basis that /backports is fundamentally unstable so you may as
well just do your testing in the repo. This works fine, so far.
Well, some people ( me to some extend ) are not really happy with this,
because some users tends to auto upgrade even with /backports and then
complaint when something is broken. Once you tell them "this is
backports, do not expect everything to be functionnal", they start to
recommend to others to not use this repository, thus giving /backports a
bad reputation because of a few bad apples.
But having /testing for /backports would have been maybe too complex,
indeed. We didn't found a good solution when we discussed last time.
( and this was also discussed to death on mandriva mailling list too )
--
Michael Scherer
4:20 a.m.
On Wed, 2009-08-05 at 12:58 -0700, Jesse Keating wrote:
All this really does is create a pseudo rawhide for each release,
blurring the lines even more around why we even do releases. With a 6
month cycle, do we really want to take on all this extra headaches and
hassles just so that you can have some newer experimental software a bit
sooner, or without doing a wholesale update to the next release?
For fedora-virt folks, we have a "virt-preview" repository, the general
idea being:
- a repo where you can pull f11 builds of the latest rawhide virt bits
- purely for people who want to help with testing f12 virt, but
aren't willing to run rawhide
- it's not about making new features available to f11 users, it's
about allowing f11 users to get involved with f12 development
- if it breaks, you get to keep both pieces - we'll do our best to
fix problems specific to this repo, but in reality we care more
about problems which affect stock f11 or rawhide/f12
- we're trying to keep the limit the packages in the repo to purely
virt related packages - e.g. right now we need something from f12
selinux-policy, but I'm hoping we can get added in an f11 update
rather than pulling in the f12 version and breaking non-virt stuff
It hasn't been around long, but it's working well and we're getting
valuable testing from it. The only thing we're missing is that we can't
add virt-preview packages to the buildroot. We're considering switching
from koji to mock for the builds because of this.
With a little automation, I think this model could work fairly well for
the likes of GNOME.
Cheers,
Mark.
4:59 a.m.
Mark McLoughlin wrote:
For fedora-virt folks, we have a "virt-preview" repository,
the general
idea being:
- a repo where you can pull f11 builds of the latest rawhide virt bits
- purely for people who want to help with testing f12 virt, but
aren't willing to run rawhide
- it's not about making new features available to f11 users, it's
about allowing f11 users to get involved with f12 development
- if it breaks, you get to keep both pieces - we'll do our best to
fix problems specific to this repo, but in reality we care more
about problems which affect stock f11 or rawhide/f12
- we're trying to keep the limit the packages in the repo to purely
virt related packages - e.g. right now we need something from f12
selinux-policy, but I'm hoping we can get added in an f11 update
rather than pulling in the f12 version and breaking non-virt stuff
We have that too for KDE, it's called kde-redhat unstable. But it's not a
replacement for stable, tested version upgrades.
Kevin Kofler
12:21 p.m.
On Thu, 2009-08-06 at 10:20 +0100, Mark McLoughlin wrote:
For fedora-virt folks, we have a "virt-preview" repository,
the general
idea being:
- a repo where you can pull f11 builds of the latest rawhide virt bits
- purely for people who want to help with testing f12 virt, but
aren't willing to run rawhide
- it's not about making new features available to f11 users, it's
about allowing f11 users to get involved with f12 development
- if it breaks, you get to keep both pieces - we'll do our best to
fix problems specific to this repo, but in reality we care more
about problems which affect stock f11 or rawhide/f12
- we're trying to keep the limit the packages in the repo to purely
virt related packages - e.g. right now we need something from f12
selinux-policy, but I'm hoping we can get added in an f11 update
rather than pulling in the f12 version and breaking non-virt stuff
It hasn't been around long, but it's working well and we're getting
valuable testing from it. The only thing we're missing is that we can't
add virt-preview packages to the buildroot. We're considering switching
from koji to mock for the builds because of this.
With a little automation, I think this model could work fairly well for
the likes of GNOME.
This is essentially what I wanted to create with KoPeRs.
https://fedoraproject.org/wiki/JesseKeating/KojiPersonalRepos
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:04 p.m.
On Wed, 2009-08-05 at 12:44 -0700, Toshio Kuratomi wrote:
Sure, this is comparable to the present situation. But it
doesn't seem
like it makes things much better.
* It doesn't solve the original poster's issue (that the GNOME stack
isn't going to be updated for F10 since the maintainers don't want to do
this and the policy wouldn't require it)
* It doesn't solve the follow-on issue of things being different between
major Fedora components (since gnome maintainers don't want to
participate but kde maintainers do)
* It makes things more complex (for instance, we would have to build
packages against multiple repository sets -- ie: [F12-release +
F12-updates-security] [F12-release + F12-updates-security +
F12-updates-adventurous] since there could be incompatibilities between
the packages in updates-security and updates-adventurous.).
* It makes more work for rel-eng to prepare and push the extra repos.
The major thing it solves is it makes it possible to reliably get only
'conventional' updates. At present, as traditional security / bugfix
updates are mixed up with more adventurous updates, you can't do this.
An alternative would be to tag updates within a single repo in a way
that yum and PackageKit understand and have appropriate configuration
options to enable certain types of update, which would really be much
the same situation, just organized slightly differently.
Either way it's going to be some level of extra work for someone
somewhere, I haven't denied that. Was just discussing the parameters of
addressing (or not addressing) this issue. It's not possible to make all
parties happy in the current framework, so either we change something,
or we take a specific decision to make some parties unhappy, and justify
that formally.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:07 p.m.
On Wed, 2009-08-05 at 13:04 -0700, Adam Williamson wrote:
An alternative would be to tag updates within a single repo in a way
that yum and PackageKit understand and have appropriate configuration
options to enable certain types of update, which would really be much
the same situation, just organized slightly differently.
bodhi and packagekit already work together to mark updates as bug-fix,
security or enhancement. Do you need anything else ? Of course, with
this setup, once you decide to not be adventurous and install the
enhancement update to KDE 4.3.0, you won't get bug fixes for the older
version you are stuck on, and more seriously, no security updates
either...
3:14 p.m.
On Wed, 2009-08-05 at 13:04 -0700, Adam Williamson wrote:
An alternative would be to tag updates within a single repo in a way
that yum and PackageKit understand and have appropriate configuration
options to enable certain types of update, which would really be much
the same situation, just organized slightly differently.
We already tag updates as either security, bugfix, or enhancement.
yum-security would only install the security ones. However what was
yesterday's security update can become today's enhancement update, so
you'd have to consume the enhancement in order to get the security fix.
Likewise tomorrow's security fix may be built against yesterday's
enhancement for something else, so in order to get the security for A
you have to get the enhancement for B.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
4:24 p.m.
On Wed, 2009-08-05 at 13:14 -0700, Jesse Keating wrote:
On Wed, 2009-08-05 at 13:04 -0700, Adam Williamson wrote:
>
> An alternative would be to tag updates within a single repo in a way
> that yum and PackageKit understand and have appropriate configuration
> options to enable certain types of update, which would really be much
> the same situation, just organized slightly differently.
We already tag updates as either security, bugfix, or enhancement.
yum-security would only install the security ones. However what was
yesterday's security update can become today's enhancement update, so
you'd have to consume the enhancement in order to get the security fix.
Likewise tomorrow's security fix may be built against yesterday's
enhancement for something else, so in order to get the security for A
you have to get the enhancement for B.
That was the problem I initially thought of with this method, but then I
thought - there's no actual reason we can't have different trains of
updates in a single repository, is there?
We could have:
foo-1.0-2 (conservative bug fix, tagged as such)
foo-2.0-1 (adventurous version upgrade, tagged as such)
within one updates repository, couldn't we? Is there anything that
unavoidably says we can't?
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
4:34 p.m.
On Wed, 2009-08-05 at 14:24 -0700, Adam Williamson wrote:
That was the problem I initially thought of with this method, but then
I
thought - there's no actual reason we can't have different trains of
updates in a single repository, is there?
We could have:
foo-1.0-2 (conservative bug fix, tagged as such)
foo-2.0-1 (adventurous version upgrade, tagged as such)
within one updates repository, couldn't we? Is there anything that
unavoidably says we can't?
How do you choose which to build against? How do you close deps?
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
6:59 p.m.
On Wed, 2009-08-05 at 14:34 -0700, Jesse Keating wrote:
On Wed, 2009-08-05 at 14:24 -0700, Adam Williamson wrote:
>
> That was the problem I initially thought of with this method, but then
> I
> thought - there's no actual reason we can't have different trains of
> updates in a single repository, is there?
>
> We could have:
>
> foo-1.0-2 (conservative bug fix, tagged as such)
> foo-2.0-1 (adventurous version upgrade, tagged as such)
>
> within one updates repository, couldn't we? Is there anything that
> unavoidably says we can't?
How do you choose which to build against? How do you close deps?
Hmm, yeah. Which again leaves us with separate repositories as the
solution. Unless the buildsystem can be tied in to the package tags,
somehow.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:25 p.m.
On 08/05/2009 01:04 PM, Adam Williamson wrote:
On Wed, 2009-08-05 at 12:44 -0700, Toshio Kuratomi wrote:
> Sure, this is comparable to the present situation. But it doesn't seem
> like it makes things much better.
>
> * It doesn't solve the original poster's issue (that the GNOME stack
> isn't going to be updated for F10 since the maintainers don't want to do
> this and the policy wouldn't require it)
> * It doesn't solve the follow-on issue of things being different between
> major Fedora components (since gnome maintainers don't want to
> participate but kde maintainers do)
> * It makes things more complex (for instance, we would have to build
> packages against multiple repository sets -- ie: [F12-release +
> F12-updates-security] [F12-release + F12-updates-security +
> F12-updates-adventurous] since there could be incompatibilities between
> the packages in updates-security and updates-adventurous.).
> * It makes more work for rel-eng to prepare and push the extra repos.
The major thing it solves is it makes it possible to reliably get only
'conventional' updates. At present, as traditional security / bugfix
updates are mixed up with more adventurous updates, you can't do this.
An alternative would be to tag updates within a single repo in a way
that yum and PackageKit understand and have appropriate configuration
options to enable certain types of update, which would really be much
the same situation, just organized slightly differently.
For this:
$ repoquery -qi yum-plugin-security
Name : yum-plugin-security
Version : 1.1.22
Release : 1.fc11
Architecture: noarch
Size : 23792
Packager : Fedora Project
Group : System Environment/Base
URL : http://yum.baseurl.org/download/yum-utils/
Repository : updates
Summary : Yum plugin to enable security filters
Description :
This plugin adds the options --security, --cve, --bz and --advisory flags
to yum and the list-security and info-security commands.
The options make it possible to limit list/upgrade of packages to specific
security relevant ones. The commands give you the security information.
Either way it's going to be some level of extra work for someone
somewhere, I haven't denied that. Was just discussing the parameters of
addressing (or not addressing) this issue. It's not possible to make all
parties happy in the current framework, so either we change something,
or we take a specific decision to make some parties unhappy, and justify
that formally.
Sure. I'm just pointing out that you're trying to solve a different
problem than either the original poster or Thorsten. (And now that I
understand your problem better, perhaps yours is already solved :-)
-Toshio
4:26 p.m.
On Wed, 2009-08-05 at 13:25 -0700, Toshio Kuratomi wrote:
> Either way it's going to be some level of extra work for
someone
> somewhere, I haven't denied that. Was just discussing the parameters of
> addressing (or not addressing) this issue. It's not possible to make all
> parties happy in the current framework, so either we change something,
> or we take a specific decision to make some parties unhappy, and justify
> that formally.
>
Sure. I'm just pointing out that you're trying to solve a different
problem than either the original poster or Thorsten. (And now that I
understand your problem better, perhaps yours is already solved :-)
Well, I think it's really the same issue. The problem is one of
expectation: we have two similar components, GNOME and KDE, in the same
distribution, following different update polices - GNOME favours stable,
KDE favours adventurous. This confounds expectation.
Yes, my problem is potentially almost solved with the tools at our
disposal and some little tweaks to interfaces, except for the problem
raised by Jesse, see my reply to his post. :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
4:36 p.m.
On Wed, 2009-08-05 at 14:26 -0700, Adam Williamson wrote:
Well, I think it's really the same issue. The problem is one of
expectation: we have two similar components, GNOME and KDE, in the same
distribution, following different update polices - GNOME favours stable,
KDE favours adventurous. This confounds expectation.
I don't know that this is really the case. KDE is rolling up a bugfix
release. Gnome does bugfix releases. Other than a difference in how
they number them, is there really that big of a difference in what they
are doing?
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
6:59 p.m.
On Wed, 2009-08-05 at 14:36 -0700, Jesse Keating wrote:
On Wed, 2009-08-05 at 14:26 -0700, Adam Williamson wrote:
>
> Well, I think it's really the same issue. The problem is one of
> expectation: we have two similar components, GNOME and KDE, in the same
> distribution, following different update polices - GNOME favours stable,
> KDE favours adventurous. This confounds expectation.
I don't know that this is really the case. KDE is rolling up a bugfix
release. Gnome does bugfix releases. Other than a difference in how
they number them, is there really that big of a difference in what they
are doing?
It's not a bugfix release, it's a bit ingenuous to describe it as one.
KDE make major changes between 4.x and 4.y. The bugfix releases are one
level down. 4.2.1 vs. 4.2 is a bugfix release, but 4.3 vs. 4.2.1 is not.
It's exactly the same as the GNOME situation - 2.24.1 vs. 2.24.0 is a
bugfix update, 2.26.0 vs. 2.24.1 is not. Most distributions would not
bump KDE from 4.2 to 4.3 in their stable update repositories.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
7:23 p.m.
On Wed, Aug 5, 2009 at 4:59 PM, Adam Williamson<awilliam(a)redhat.com> wrote:
On Wed, 2009-08-05 at 14:36 -0700, Jesse Keating wrote:
> On Wed, 2009-08-05 at 14:26 -0700, Adam Williamson wrote:
> >
> > Well, I think it's really the same issue. The problem is one of
> > expectation: we have two similar components, GNOME and KDE, in the same
> > distribution, following different update polices - GNOME favours stable,
> > KDE favours adventurous. This confounds expectation.
>
> I don't know that this is really the case. KDE is rolling up a bugfix
> release. Gnome does bugfix releases. Other than a difference in how
> they number them, is there really that big of a difference in what they
> are doing?
It's not a bugfix release, it's a bit ingenuous to describe it as one.
Except for the fact that it fixes *over 10,000 bugs*. [1]
And I believe the word you are looking for is *dis*ingenuous.
It's hard to believe KDE 4.2 had that many bugs...
[1] http://kde.org/announcements/4.3/index.php
8:18 p.m.
On Wed, 2009-08-05 at 17:23 -0700, Christopher Stone wrote:
On Wed, Aug 5, 2009 at 4:59 PM, Adam
Williamson<awilliam(a)redhat.com> wrote:
> On Wed, 2009-08-05 at 14:36 -0700, Jesse Keating wrote:
>> On Wed, 2009-08-05 at 14:26 -0700, Adam Williamson wrote:
>> >
>> > Well, I think it's really the same issue. The problem is one of
>> > expectation: we have two similar components, GNOME and KDE, in the same
>> > distribution, following different update polices - GNOME favours stable,
>> > KDE favours adventurous. This confounds expectation.
>>
>> I don't know that this is really the case. KDE is rolling up a bugfix
>> release. Gnome does bugfix releases. Other than a difference in how
>> they number them, is there really that big of a difference in what they
>> are doing?
>
> It's not a bugfix release, it's a bit ingenuous to describe it as one.
Except for the fact that it fixes *over 10,000 bugs*. [1]
And I believe the word you are looking for is *dis*ingenuous.
It's hard to believe KDE 4.2 had that many bugs...
[1] http://kde.org/announcements/4.3/index.php
I was actually reaching for another word entirely, but you're right that
ingenuous makes no sense. :)
A release that fixes bugs is not necessarily a bug fix release. A bug
fix release is a release that _exclusively_ fixes bugs. So any bug fix
release must fix bugs, but not any release that fixes bugs must be a bug
fix release.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
9:34 p.m.
2009/8/6 Adam Williamson <awilliam(a)redhat.com>
On Wed, 2009-08-05 at 17:23 -0700, Christopher Stone wrote:
> On Wed, Aug 5, 2009 at 4:59 PM, Adam Williamson<awilliam(a)redhat.com>
wrote:
> > On Wed, 2009-08-05 at 14:36 -0700, Jesse Keating wrote:
> >> On Wed, 2009-08-05 at 14:26 -0700, Adam Williamson wrote:
> >> >
> >> > Well, I think it's really the same issue. The problem is one of
> >> > expectation: we have two similar components, GNOME and KDE, in the
same
> >> > distribution, following different update polices - GNOME favours
stable,
> >> > KDE favours adventurous. This confounds expectation.
> >>
> >> I don't know that this is really the case. KDE is rolling up a bugfix
> >> release. Gnome does bugfix releases. Other than a difference in how
> >> they number them, is there really that big of a difference in what
they
> >> are doing?
> >
> > It's not a bugfix release, it's a bit ingenuous to describe it as one.
>
> Except for the fact that it fixes *over 10,000 bugs*. [1]
>
> And I believe the word you are looking for is *dis*ingenuous.
>
> It's hard to believe KDE 4.2 had that many bugs...
>
> [1] http://kde.org/announcements/4.3/index.php
I was actually reaching for another word entirely, but you're right that
ingenuous makes no sense. :)
A release that fixes bugs is not necessarily a bug fix release. A bug
fix release is a release that _exclusively_ fixes bugs. So any bug fix
release must fix bugs, but not any release that fixes bugs must be a bug
fix release.
It's unlikely a project has no open bugs, so any update should fix a bunch
of
them; on the other hand it's rare to have software enhancement stopped just
to close bugs, in particular in big projects, if you want that you want
backporting.
By the way, i dont even think its safe to measure stability or completness
counting
bugfix releases or with release numbers, as you will find projects which get
released with major versions X.0 in an incomplete and unstable state, while
others
trying to accomplish the opposite.
That said, in this scenery:
F-x
- bugfix rel
- enhance rel
F-x+1 released
- bugfix rel
with no backporting and the aim to be leading edge, what's the point to skip
update 2? In the worst case, your Frel will hit (Flatest - 2) in about 12
months
and you will need to upgrade nonetheless
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
--
fedora-devel-list mailing list
fedora-devel-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
--
Guido Grazioli <guido.grazioli(a)gmail.com>
Via Parri 11 48011 - Alfonsine (RA)
Mobile: +39 347 1017202 (10-18)
Key FP = 7040 F398 0DED A737 7337 DAE1 12DC A698 5E81 2278
Linked in: http://www.linkedin.com/in/guidograzioli
7:46 p.m.
On 08/05/2009 02:26 PM, Adam Williamson wrote:
On Wed, 2009-08-05 at 13:25 -0700, Toshio Kuratomi wrote:
> Sure. I'm just pointing out that you're trying to solve a different
> problem than either the original poster or Thorsten. (And now that I
> understand your problem better, perhaps yours is already solved :-)
Well, I think it's really the same issue. The problem is one of
expectation: we have two similar components, GNOME and KDE, in the same
distribution, following different update polices - GNOME favours stable,
KDE favours adventurous. This confounds expectation.
This isn't solved by having two repositories. We'd still have a post on
this list asking for the new GNOME release to be built for F-10 and we'd
still have the GNOME maintainers say that they're not going to do that.
Yes, my problem is potentially almost solved with the tools at our
disposal and some little tweaks to interfaces, except for the problem
raised by Jesse, see my reply to his post. :)
Heh. I thought you were willing to accept that change when you talked
about using tags rather than a separate repo :-)
-Toshio
7:46 a.m.
Adam Williamson, Wed, 05 Aug 2009 14:26:53 -0700:
Well, I think it's really the same issue. The problem is one of
expectation: we have two similar components, GNOME and KDE, in the same
distribution, following different update polices - GNOME favours stable,
KDE favours adventurous. This confounds expectation.
Yes, my problem is potentially almost solved with the tools at our
disposal and some little tweaks to interfaces, except for the problem
raised by Jesse, see my reply to his post. :)
Adam, I see where you are coming from, but aside from the unclear
definition of the Fedora's target audience (which is IMHO clearly defined
as developers needing bleeding-edge distro with huge engineering support;
we just live in denial for not saying so clearly) you are getting into
much deeper organizational problem ... how manages Fedora. Actually, it
seems to me the answer is no-one really ... this is really a community of
packagers held together by very rough consensus and necessity to support
each other.
As such there is no such thing as "corporate brand" and "expected
behavior" ... if KDE folks decide they want to package their packages
(and they are their packages, not of the folks in the RH Desktop team) as
they do and have multiple upgrades even for N-1 distros, it is only their
business -- they will have to hold all pieces together if it blows up in
their face. If Gnome folks decide to be more conservative (or conserving
effort for Gnome 3.* and bigger stability of Gnome before Fedora 12 aka
RHEL 6 Alpha) it is their business and nobody could them anything.
I am not sure about Mandriva, I have never had it installed ever (even
though I got kindly LiveUSB disk at Guadec 2007 -- it was wonderful free
3GB USB drive before I lost it ;-)), but if it is smaller distro, it
could be true it was smaller community with more centrally controlled
strategy?
Or in other words ... read “Nature of the firm” (Coase, 1937) and “The
Problem of Social Cost” (Coase, 1960) ... to understand one way how to
get grasp of this community. In the situation where opportunity cost of
cooperation is quite low, transaction cost is perceived as quite high,
and cost of leaving the community quite low, there is no way how to
centralize management of the community. There are some communities where
it is possible to achieve *slightly* higher degree of centralization
(Ubuntu, and possibly Mandriva), but certainly it is not the case of
Fedora which is probably quite close to the extreme of market-driven
organization (to use Coase's terminology).
Matěj
11:38 a.m.
On Thu, 2009-08-06 at 12:46 +0000, Matej Cepl wrote:
Adam Williamson, Wed, 05 Aug 2009 14:26:53 -0700:
> Well, I think it's really the same issue. The problem is one of
> expectation: we have two similar components, GNOME and KDE, in the same
> distribution, following different update polices - GNOME favours stable,
> KDE favours adventurous. This confounds expectation.
>
> Yes, my problem is potentially almost solved with the tools at our
> disposal and some little tweaks to interfaces, except for the problem
> raised by Jesse, see my reply to his post. :)
Adam, I see where you are coming from, but aside from the unclear
definition of the Fedora's target audience (which is IMHO clearly defined
as developers needing bleeding-edge distro with huge engineering support;
we just live in denial for not saying so clearly) you are getting into
much deeper organizational problem ... how manages Fedora. Actually, it
seems to me the answer is no-one really ... this is really a community of
packagers held together by very rough consensus and necessity to support
each other.
Actually I agree with you, I'd just really like this to be more out in
the open and generally agreed-upon, so we can make saner decisions in
certain cases and not have to worry about things we shouldn't need to
worry about in the first place. It seems like we're happy to be that
kind of distro _in effect_, but not to just come out and say it :) Don't
be ashamed, people! We can come out of the closet! We're not your
sysadmin's distro! ;)
I am not sure about Mandriva, I have never had it installed ever
(even
though I got kindly LiveUSB disk at Guadec 2007 -- it was wonderful free
3GB USB drive before I lost it ;-)), but if it is smaller distro, it
could be true it was smaller community with more centrally controlled
strategy?
There is slightly more central control possible in MDV's structure, but
really I think the difference is just that MDV started off with a
traditional update policy, properly enforced (there's a gatekeeper at
MDV; official updates go through the security team, maintainers can't
push them directly). So at MDV the process was to add a /backports
repository to satisfy the adventurous tendency (which, by the way, took
me a year and half to get done...). Fedora is the other way around.
Or in other words ... read “Nature of the firm” (Coase, 1937) and
“The
Problem of Social Cost” (Coase, 1960) ... to understand one way how to
get grasp of this community. In the situation where opportunity cost of
cooperation is quite low, transaction cost is perceived as quite high,
and cost of leaving the community quite low, there is no way how to
centralize management of the community.
This is rather a simplification. There is a degree of central control
over Fedora. If you wanted to be cynical you could say it was based in
Raleigh, but I'd never do such a thing ;). Otherwise we wouldn't be able
to have packaging policies, release freezes...or releases, really. But I
agree with the thrust of your argument, yeah. Oh, and the only
non-fiction I read is the newspaper :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:44 a.m.
On 08/05/2009 12:11 PM, Adam Williamson wrote:
On Wed, 2009-08-05 at 11:58 -0700, Toshio Kuratomi wrote:
> Also, having the expectation that the other repository is for security
> updates doesn't address the problem of a security release breaking ABI.
That's rather unlikely (well, except in oddball cases like Firefox /
XULRunner),
Sure, you can blame Gecko for having it's unstable ABI be, well,
unstable. But blame also goes to the apps for not using the stable ABI.
4:56 a.m.
Christopher Aillon wrote:
Sure, you can blame Gecko for having it's unstable ABI be, well,
unstable. But blame also goes to the apps for not using the stable ABI.
Why does Mozilla expect apps to use an ABI:
* which didn't exist when the apps were written and
* which they aren't even using for their own apps?
Everyone complains about M$ using internal W32 APIs in IE, why does Mozilla
do the same with internal xulrunner APIs? If you think everyone should use
the stable ABI, why is Firefox not using it?
Kevin Kofler
5:22 a.m.
On Thu, Aug 6, 2009 at 11:56 AM, Kevin Kofler<kevin.kofler(a)chello.at> wrote:
Christopher Aillon wrote:
> Sure, you can blame Gecko for having it's unstable ABI be, well,
> unstable. But blame also goes to the apps for not using the stable ABI.
Why does Mozilla expect apps to use an ABI:
* which didn't exist when the apps were written and
* which they aren't even using for their own apps?
Everyone complains about M$ using internal W32 APIs in IE,
who does that?
why does Mozilla
do the same with internal xulrunner APIs? If you think everyone should use
the stable ABI, why is Firefox not using it?
I don't see whats wrong with providing a an ABI that you can/want to
support (i.e no ABI breaks for minor updates) and one for your
internal use (i.e you know when it breaks and therefore fix your own
app).
2:28 p.m.
On Wed, Aug 05, 2009 at 11:47:24AM -0700, Adam Williamson wrote:
On Wed, 2009-08-05 at 08:01 -0400, Josh Boyer wrote:
> >I don't want to get between the lines here (there are good arguments and
> >against updating Gnome and KDE for older releases) and I hate buzz-words
> >like "Corporate identity", but I find it more and more odd that one
> >doesn't know what to expect from Fedora, because similar sized things
> >(KDE and Gnome) are handled quite differently.
>
> Short of passing a policy that says no major desktop upgrades for stable
> releases, I don't see this changing. If we did pass that, I have a feeling
> it would piss off a lot of people. Passing the converse (always upgrade)
> would piss off just as many.
>
> I'm not that enthralled with starting a "who do you want to piss off
today?"
> campaign for Fedora.
We've had this discussion before, but to re-state my opinion: the only
sane way to handle this is multiple, discretionary update repositories.
A repository for security and stable bugfix updates, and a repository
for other updates - major version bumps whose purpose isn't solely to
fix a security issue or, with minimal changes, a clearly identified bug.
It's more work, but it's the only workable consistent system that
doesn't restrict some maintainer from being able to do what they want to
do. A distribution with much fewer resources than Fedora (Mandriva) has
been using this system successfully, to the satisfaction of developers
and users, for several releases now.
Care to write up a proposal on how this work-flow would look like? Without
some of the details, I'm confused how one would avoid all kinds of weirdness
from repo conflicts if you have multiple of these repos enabled. That, and the
fact that everything is built from a single buildroot at the moment.
josh
2:41 p.m.
On Wed, 2009-08-05 at 15:28 -0400, Josh Boyer wrote:
Care to write up a proposal on how this work-flow would look like?
Without
some of the details, I'm confused how one would avoid all kinds of weirdness
from repo conflicts if you have multiple of these repos enabled. That, and the
fact that everything is built from a single buildroot at the moment.
I probably couldn't do much justice to a comprehensive plan as I have
insufficient knowledge of how the buildsystem works. I was acting at a
higher level - just trying to point out that it's essentially doomed to
try and please everyone with a single update repository, that's not an
argument anyone can win. Either the 'we want stable updates' camp or the
'we want shiny new stuff' camp is going to be disappointed.
I'm not sure what kind of weirdness you mean, but I have to emphasize
this isn't some kind of theoretical system, it really exists in the
really real world :). I have three Mandriva machines (not worth the
bother converting them to Fedora), some using /backports and /updates
repositories, some just /updates, and there's no 'weirdness' involved.
Probably the major issue I can think of is that maintainers
pushing /backports packages should be careful to forward port changes
done on the /updates branch to /backports, so that those using the more
adventurous updates don't miss out on any security / bug fixes done in
the stabler updates. But since the person doing /backports packages and
the person doing /updates packages are usually exactly the same person,
this doesn't present much of a problem.
Oh, I just realized, in case it's not clear - in the MDV system, the
adventurous repo (/backports) is complementary to the stable repo
(/updates), it doesn't replace it. You either use /updates
and /backports, or just /updates; using /backports but not /updates is
not intended or supported.
Yes, there would have to be some kind of accommodation in the build bots
for this. Packages intended for the adventurous updates branch would
have to be built in an environment which used that repository *and* the
stable updates repository as a source, and packages intended for the
stable updates branch would have to be built in an environment which
only used the stable repository as a source. It's more work, yes, as I
said in my initial mail :)
The missing bit of the argument from before is whether we actually want
to care about people who only want 'stable' updates, and that tracks
back to the question of what Fedora actually is, which I don't believe
the Board has settled yet. If we don't care about providing a stable
update set, then implementing this system would be unnecessary work, and
it's fine to continue simply to have a single repo and allow adventurous
updates to be sent there.
Of course, packages sent to /backports can break sometimes, but that's
not unexpected, and no different to shipping updates of the same level
of potential brokenness in a single update repository, as we currently
do.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:49 p.m.
On 08/05/2009 03:41 PM, Adam Williamson wrote:
The missing bit of the argument from before is whether we actually
want
to care about people who only want 'stable' updates, and that tracks
back to the question of what Fedora actually is, which I don't believe
the Board has settled yet. If we don't care about providing a stable
update set, then implementing this system would be unnecessary work, and
it's fine to continue simply to have a single repo and allow adventurous
updates to be sent there.
See, this is different. If you're waiting for the board to define "what
Fedora actually is", you're going to die waiting. I'm of the opinion
that such a question is too broad and vague.
Now, if you wanted to know how the board feels about providing "a stable
updates set", and you can elaborate on what that means and how it works,
with less handwaving and miracles, I think we could give a more
productive and useful answer. *
~spot, Fedora Board member, speaking for himself only
* Although, strictly speaking, that sort of thing is in FESCo's domain.
3:11 p.m.
On Wed, 2009-08-05 at 15:49 -0400, Tom "spot" Callaway wrote:
On 08/05/2009 03:41 PM, Adam Williamson wrote:
> The missing bit of the argument from before is whether we actually want
> to care about people who only want 'stable' updates, and that tracks
> back to the question of what Fedora actually is, which I don't believe
> the Board has settled yet. If we don't care about providing a stable
> update set, then implementing this system would be unnecessary work, and
> it's fine to continue simply to have a single repo and allow adventurous
> updates to be sent there.
See, this is different. If you're waiting for the board to define "what
Fedora actually is", you're going to die waiting. I'm of the opinion
that such a question is too broad and vague.
Now, if you wanted to know how the board feels about providing
"a stable
updates set", and you can elaborate on what that means and how it works,
with less handwaving and miracles, I think we could give a more
productive and useful answer. *
I think they're the same question. I've explained why before, but here
we go again.
The question is whether Fedora intends to be a distribution suitable for
day-to-day general purpose use by people who are not necessarily that
interested in Fedora per se - whether it's got an aim to be a
general-purpose operating system like other distributions do - or not.
That's the only framework in which you can sensibly answer whether we
want a stable update set or not, to my mind.
If we are - or _want to be_ - that kind of a distribution, we have to
provide a stable update set so we can stop telling people who just want
a distro to run Aunt Flo's desktop or their webserver or whatever on to
run CentOS or Ubuntu instead. If, however, we really don't care about
that kind of usage scenario and instead we want to focus only on being a
kind of project for the prototyping of systems that will eventually
_become_ components of that kind of generally usable operating system -
which to my mind is more or less the status at the moment - it doesn't
make any sense to provide a stable update set, it's not serving any real
purpose, and it'd just be a waste of effort.
I really can't see any more 'specialized' framework in which to address
the question. Whether it makes sense to provide a solely stable update
set or not is inevitably tied to who would use such a set, and that in
turn inevitably ties back to exactly what kind of Fedora user we want,
and that in turn is inextricably linked to the identity of Fedora as a
project.
If you can break that chain at any point, please do, otherwise I'm
struggling to divorce the issues :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:18 p.m.
On 08/05/2009 04:11 PM, Adam Williamson wrote:
The question is whether Fedora intends to be a distribution suitable
for
day-to-day general purpose use by people who are not necessarily that
interested in Fedora per se - whether it's got an aim to be a
general-purpose operating system like other distributions do - or not.
That's the only framework in which you can sensibly answer whether we
want a stable update set or not, to my mind.
What does a "stable update set" mean? Does it mean updates which don't
break ABI/API? Does it mean backporting patches and not permitting new
versions as updates?
I seriously doubt that anyone is pushing updates simply to push them in
the current Fedora model. Maintainers are pushing updates because they
feel there is a reason, a bug fixed, a security hole closed, a
significant feature enhancement that users want (or that they think
users want).
Without a finer definition here, it's all just hand-waving.
~spot
3:24 p.m.
On Wed, Aug 5, 2009 at 10:18 PM, Tom "spot" Callaway<tcallawa(a)redhat.com>
wrote:
On 08/05/2009 04:11 PM, Adam Williamson wrote:
>
> The question is whether Fedora intends to be a distribution suitable for
> day-to-day general purpose use by people who are not necessarily that
> interested in Fedora per se - whether it's got an aim to be a
> general-purpose operating system like other distributions do - or not.
> That's the only framework in which you can sensibly answer whether we
> want a stable update set or not, to my mind.
What does a "stable update set" mean? Does it mean updates which don't
break
ABI/API? Does it mean backporting patches and not permitting new versions as
updates?
I seriously doubt that anyone is pushing updates simply to push them in the
current Fedora model. Maintainers are pushing updates because they feel
there is a reason, a bug fixed, a security hole closed, a significant
feature enhancement that users want (or that they think users want).
Without a finer definition here, it's all just hand-waving.
The whole thing is useless, maintainers should decide whether the risk
of pushing foo-x.y.z is worth the gain or not.
Threads like this are IMHO useless "why can't you update bar, foo has
been updated to foo+1" ... well each maintainer has a reason why he
does a update or not, while asking for the reasons is not wrong
demanding a policy (bureaucracy) on when to update what an for which
reasons will as Josh already said "just piss people off".
3:33 p.m.
On Wed, 2009-08-05 at 16:18 -0400, Tom "spot" Callaway wrote:
Maintainers are pushing updates because they
feel there is a reason, a bug fixed, a security hole closed, a
significant feature enhancement that users want (or that they think
users want).
A bug filed by FEVEr or it's replacement saying there is a bigger number
released somewhere.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:49 p.m.
* Jesse Keating [05/08/2009 22:38] :
A bug filed by FEVEr or it's replacement saying there is a bigger number
released somewhere.
Do maintainers really push out updates for this? I've always considered
a reason to push out a build for rawhide but not to issue updates for
the stable releases.
Emmanuel
4:14 p.m.
On Wed, 2009-08-05 at 22:49 +0200, Emmanuel Seyman wrote:
Do maintainers really push out updates for this? I've always
considered
a reason to push out a build for rawhide but not to issue updates for
the stable releases.
It's really hard to tell when so many updates pushers put 0 information
in their updates about /why/ they are pushing the update.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
3:51 p.m.
On Wed, August 5, 2009 2:33 pm, Jesse Keating wrote:
On Wed, 2009-08-05 at 16:18 -0400, Tom "spot" Callaway
wrote:
> Maintainers are pushing updates because they
> feel there is a reason, a bug fixed, a security hole closed, a
> significant feature enhancement that users want (or that they think
> users want).
A bug filed by FEVEr or it's replacement saying there is a bigger number
released somewhere.
FEVER reports against rawhide, it doesn't by itself suggest an update.
Sometimes I only update rawhide, sometime I also update the current
release if it seems appropriate. It's a useful tool when you have a
couple dozen packages or more.
--
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
10:42 p.m.
Adam Williamson wrote:
If we are - or _want to be_ - that kind of a distribution, we have
to
provide a stable update set so we can stop telling people who just want
a distro to run Aunt Flo's desktop or their webserver or whatever on to
run CentOS or Ubuntu instead. If, however, we really don't care about
that kind of usage scenario and instead we want to focus only on being a
kind of project for the prototyping of systems that will eventually
_become_ components of that kind of generally usable operating system -
which to my mind is more or less the status at the moment - it doesn't
make any sense to provide a stable update set, it's not serving any real
purpose, and it'd just be a waste of effort.
Actually, I think our KDE updates are very much beneficial even to "Aunt
Flo" type users. We wouldn't push them out if we thought otherwise.
In the current state of KDE, users are thanking us at each 4.n release for
the usability improvements. And while that effect diminishes as KDE gets to
a more mature state, the changes between releases also get less invasive and
thus the risk also goes down (e.g. KDE 3.5 wasn't quite as major as KDE 4.1
was, we're even seeing this progression with 4.x now).
Kevin Kofler
1:05 a.m.
On Thu, 2009-08-06 at 05:42 +0200, Kevin Kofler wrote:
Adam Williamson wrote:
> If we are - or _want to be_ - that kind of a distribution, we have to
> provide a stable update set so we can stop telling people who just want
> a distro to run Aunt Flo's desktop or their webserver or whatever on to
> run CentOS or Ubuntu instead. If, however, we really don't care about
> that kind of usage scenario and instead we want to focus only on being a
> kind of project for the prototyping of systems that will eventually
> _become_ components of that kind of generally usable operating system -
> which to my mind is more or less the status at the moment - it doesn't
> make any sense to provide a stable update set, it's not serving any real
> purpose, and it'd just be a waste of effort.
Actually, I think our KDE updates are very much beneficial even to "Aunt
Flo" type users. We wouldn't push them out if we thought otherwise.
At this point you're getting down to update theory, which is a deeply
unexciting area to most people, I suspect ;)
The problem with that approach is that, in the conventional approach to
updates, the key factor is _continuity_. You don't change behaviour or
risk regressions. If an update fixes ten bugs but changes the behaviour
of some component people see every day - which is a fairly accurate
description of both KDE and GNOME point releases - it's not appropriate
to be an update, in this theory, because it means the updated product is
breaking the expectations of the the initial release. What your frazzled
sysadmin cares about most is that things work on Tuesday the same way
they did on Monday - even if that just means they're broken in the same
way. If you can fix something without changing the fundamental behaviour
of the system, great, but that's all.
As I said, I'm not arguing in favour of or against any particular
position. I'm just pointing out the angles here. There is a conventional
approach to updates that many distributions use, and that some types of
user expect and would like in any distribution they use. We can choose
not to do this, and it's fine, I just want it to be clear where the
'edges' are.
Right now, if you ask around in the conventional places - Fedora forums,
Linuxquestions, distrowatch, IRC, places like that - people will tell
you that, if what you want is a conventional stable operating system to
run your servers or whatever on, that doesn't change from day to day,
don't run Fedora, run CentOS (or Ubuntu or Debian or SUSE or...whatever
they like). If we're happy with that, that's great. But it is worth
being aware exactly what the status quo is. It seems like our current
policy is more de facto than the result of any reasoned decision.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
1:51 a.m.
On Wed, 2009-08-05 at 23:05 -0700, Adam Williamson wrote:
The problem with that approach is that, in the conventional approach
to
updates, the key factor is _continuity_. You don't change behaviour or
risk regressions. If an update fixes ten bugs but changes the behaviour
of some component people see every day - which is a fairly accurate
description of both KDE and GNOME point releases - it's not appropriate
to be an update, in this theory, because it means the updated product is
breaking the expectations of the the initial release. What your frazzled
The kernel's a great example here, BTW. If we update F10 to kernel
2.6.29, the ATI proprietary driver will stop working. We don't care
about proprietary software and yadda yadda yadda, but it's exactly the
kind of behaviour change in a supposedly 'final' product that certain
groups of users just don't want to have to deal with. It doesn't really
matter that the driver's proprietary, even. The point is that an
interface that could reasonably be expected not to change in a 'stable'
operating system release, by conventional definitions, does change in
Fedora.
Similar with the changes from 2.6.29 to 2.6.31. If we were to bump F11
from 2.6.29 to 2.6.31, the NVIDIA proprietary driver and the rt2860sta
wireless driver (and possibly other out-of-kernel network drivers,
too...) would break. The kernel guys consider it fine to do this sort of
breakage between point releases, and Fedora considers it fine to ship
kernel point releases as updates for 'stable' releases (we've done this
in the past, 2.6.29 is still planned for F10 - just stuck due to
problems - and I don't see any indication we won't be doing the same for
F11).
Certain groups of users just don't want this hassle. They have enough
pain getting their graphics card / wireless card / whatever bit of
hardware working right _once_, they don't want to have to do it again
every two months (or whenever the next kernel point release happens to
come out). They figure, since it's a stable release, once they get
something working it ought to _keep_ working.
This is the scenario that's problematic as long as we don't have a
reliable conservative update path available. Again, if we decide that's
a hit we're willing to take, that's fine.
To bring it back to where we came in, we have a problem in that the KDE
team are following one policy (update to the latest KDE release on the
basis that it brings in new shiny goodness and fixes more stuff than it
breaks) while the GNOME team are following the other (don't go to the
latest point release in the interest of consistency). This doesn't make
sense - if some parts of the distro are going with the adventurous
policy, it renders the caution of other parts essentially null and void.
The caution of the GNOME team doesn't really work, overall, if the
kernel is following the adventurous policy. Conservative users still
aren't going to go with Fedora.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
4:52 a.m.
Adam Williamson wrote:
the rt2860sta wireless driver
Aren't there patches for that one already? As the driver is Free Software,
it can be fixed. By the time 2.6.31 gets even to updates-testing, RPM Fusion
will already have the patches.
And, by the way, Fedora intentionally refuses to support out-of-tree kernel
drivers, see also the FESCo decision some time ago to ban standalone kmod
packages in Fedora and the rationale that was given (paraphrasing: we don't
want kmods as we think out-of-tree kernel modules should not exist). (My
personal opinion is that Free out-of-tree modules can be supported because
they can be fixed if they're broken, proprietary ones are a wholely
different issue though.)
To bring it back to where we came in, we have a problem in that the
KDE
team are following one policy (update to the latest KDE release on the
basis that it brings in new shiny goodness and fixes more stuff than it
breaks) while the GNOME team are following the other (don't go to the
latest point release in the interest of consistency). This doesn't make
sense - if some parts of the distro are going with the adventurous
policy, it renders the caution of other parts essentially null and void.
The caution of the GNOME team doesn't really work, overall, if the
kernel is following the adventurous policy. Conservative users still
aren't going to go with Fedora.
I think upgrading GNOME too should really be considered. But according to
what our GNOME maintainers replied, it seems to be much more reliant on the
very latest version of core system components than KDE is, so there appear
to be good reasons for the current "inconsistency".
Kevin Kofler
11:46 a.m.
On Thu, 2009-08-06 at 11:52 +0200, Kevin Kofler wrote:
Adam Williamson wrote:
> the rt2860sta wireless driver
Aren't there patches for that one already?
There's a hack, because I reported the problem to Orcan and he wrote a
hack. If I hadn't done that there probably wouldn't be; Orcan wasn't
aware of the issue until then.
As the driver is Free Software,
it can be fixed. By the time 2.6.31 gets even to updates-testing, RPM Fusion
will already have the patches.
And, by the way, Fedora intentionally refuses to support out-of-tree kernel
drivers, see also the FESCo decision some time ago to ban standalone kmod
packages in Fedora and the rationale that was given (paraphrasing: we don't
want kmods as we think out-of-tree kernel modules should not exist). (My
personal opinion is that Free out-of-tree modules can be supported because
they can be fixed if they're broken, proprietary ones are a wholely
different issue though.)
As I said, the particular code isn't the issue. We ship a kernel API. At
present, we consider it fine to break that API in stable releases. This
is not something that would be considered 'stable' in a traditional
definition. The kernel's just an example, we do the same kind of
non-stable updates all over the place. That's the issue I'm trying to
talk about, not just the specific example I happened to mention. Please
don't bog down in specifics.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
1 p.m.
Adam Williamson wrote:
As I said, the particular code isn't the issue. We ship a kernel
API. At
present, we consider it fine to break that API in stable releases. This
is not something that would be considered 'stable' in a traditional
definition. The kernel's just an example, we do the same kind of
non-stable updates all over the place. That's the issue I'm trying to
talk about, not just the specific example I happened to mention. Please
don't bog down in specifics.
Well, the specifics are that packages both within Fedora and in third-party
repositories which depend on the bumped API usually get rebuilt (and patched
if needed) fairly quickly, normally before the update even goes stable. Of
course that's only possible for software which can be patched, which is just
another example of how binary-only software is broken by design.
Kevin Kofler
1:39 p.m.
On Thu, 2009-08-06 at 20:00 +0200, Kevin Kofler wrote:
Adam Williamson wrote:
> As I said, the particular code isn't the issue. We ship a kernel API. At
> present, we consider it fine to break that API in stable releases. This
> is not something that would be considered 'stable' in a traditional
> definition. The kernel's just an example, we do the same kind of
> non-stable updates all over the place. That's the issue I'm trying to
> talk about, not just the specific example I happened to mention. Please
> don't bog down in specifics.
Well, the specifics are that packages both within Fedora and in third-party
repositories which depend on the bumped API usually get rebuilt (and patched
if needed) fairly quickly, normally before the update even goes stable. Of
course that's only possible for software which can be patched, which is just
another example of how binary-only software is broken by design.
But we're providing an operating system, not just a bunch of packages.
What if some group's written their own kernel module for their own
purposes, rolled it out to all their systems, and doesn't expect an
official update to make them re-write it? Same question for KDE -
someone writes a tool for their group based on some KDE libraries,
doesn't expect an update to come along and do a major KDE version bump
and break some interface the tool relied on...reducing the question to
'are all the packages we care about okay' is, again, excluding some use
cases, i.e. defining an identity for Fedora.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:26 p.m.
On Thu, 2009-08-06 at 11:39 -0700, Adam Williamson wrote:
But we're providing an operating system, not just a bunch of
packages.
What if some group's written their own kernel module for their own
purposes, rolled it out to all their systems, and doesn't expect an
official update to make them re-write it? Same question for KDE -
someone writes a tool for their group based on some KDE libraries,
doesn't expect an update to come along and do a major KDE version bump
and break some interface the tool relied on...reducing the question to
'are all the packages we care about okay' is, again, excluding some use
cases, i.e. defining an identity for Fedora.
We're providing a bunch of packages, that certain groups use to make a
variety of operating systems. If you want to develop a tool and expect
that it'll keep working on any given release without aggressive changes
underneath, pick the Fedora Desktop operating system. If you want to
run with the latest and greatest regardless of change risk, try the
Fedora KDE operating system.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
2:35 p.m.
On Thu, 2009-08-06 at 12:26 -0700, Jesse Keating wrote:
We're providing a bunch of packages, that certain groups use to
make a
variety of operating systems. If you want to develop a tool and expect
that it'll keep working on any given release without aggressive changes
underneath, pick the Fedora Desktop operating system.
Except that doesn't work, because we still change stuff out from under
you on Desktop. See the kernel example. There's others.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
11:52 p.m.
Jesse Keating wrote:
We're providing a bunch of packages, that certain groups use to
make a
variety of operating systems. If you want to develop a tool and expect
that it'll keep working on any given release without aggressive changes
underneath, pick the Fedora Desktop operating system. If you want to
run with the latest and greatest regardless of change risk, try the
Fedora KDE operating system.
The KDE libraries are backwards compatible, applications built against 4.2
(or even 4.1 or 4.0) will still work with 4.3.
Kevin Kofler
2:30 p.m.
On Thu, Aug 06, 2009 at 11:39:16AM -0700, Adam Williamson wrote:
On Thu, 2009-08-06 at 20:00 +0200, Kevin Kofler wrote:
> Adam Williamson wrote:
> > As I said, the particular code isn't the issue. We ship a kernel API. At
> > present, we consider it fine to break that API in stable releases. This
> > is not something that would be considered 'stable' in a traditional
> > definition. The kernel's just an example, we do the same kind of
> > non-stable updates all over the place. That's the issue I'm trying to
> > talk about, not just the specific example I happened to mention. Please
> > don't bog down in specifics.
>
> Well, the specifics are that packages both within Fedora and in third-party
> repositories which depend on the bumped API usually get rebuilt (and patched
> if needed) fairly quickly, normally before the update even goes stable. Of
> course that's only possible for software which can be patched, which is just
> another example of how binary-only software is broken by design.
But we're providing an operating system, not just a bunch of packages.
What if some group's written their own kernel module for their own
purposes, rolled it out to all their systems, and doesn't expect an
official update to make them re-write it? Same question for KDE -
If they don't expect that, they have no idea what Fedora is or how it works.
We don't care about out of tree drivers.
someone writes a tool for their group based on some KDE libraries,
doesn't expect an update to come along and do a major KDE version bump
and break some interface the tool relied on...reducing the question to
'are all the packages we care about okay' is, again, excluding some use
cases, i.e. defining an identity for Fedora.
You keep making strawman arguments that liken Fedora to something more akin
to RHEL or Ubuntu LTS. We aren't either of those.
josh
3:53 p.m.
Adam Williamson wrote:
Same question for KDE - someone writes a tool for their group based
on some KDE libraries, doesn't expect an update to come along and do
a major KDE version bump and break some interface the tool relied
on...
KDE would generally consider it a bug if that happened (API compat
broken by a non-major* update), unless it was an interface that already
had a big "BC/SC not guaranteed" warning label.
(* major = e.g. KDE3 -> KDE4)
There may be situations in which such a break would be done anyway, but
there would have to be a strong argument why such change is so critical
as to warrant a compatibility break.
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Thank you for reading all the way to this .sig. You may stop reading
now. Really. It is safe to stop. There is no more content. Why are you
still reading?
9:20 p.m.
On Thu, 2009-08-06 at 15:53 -0500, Matthew Woehlke wrote:
Adam Williamson wrote:
> Same question for KDE - someone writes a tool for their group based
> on some KDE libraries, doesn't expect an update to come along and do
> a major KDE version bump and break some interface the tool relied
> on...
KDE would generally consider it a bug if that happened (API compat
broken by a non-major* update), unless it was an interface that already
had a big "BC/SC not guaranteed" warning label.
(* major = e.g. KDE3 -> KDE4)
There may be situations in which such a break would be done anyway, but
there would have to be a strong argument why such change is so critical
as to warrant a compatibility break.
It seems to happen rather a lot for that to be the case, though maybe
the situation I'm most familiar with (KDE 4.0 -> 4.1 -> 4.2) is an
unusual situation. I was watching KDE quite closely in MDV at that
point, as quite a lot of features that people expected from 3.x were
missing, and I remember, for instance, that someone was trying to get
kmilo (for multimedia keys) working on 4.x, they had to port it to 4.0,
then port it to 4.1, then to 4.2...
as I said, I suppose this could just be because 4.0 didn't quite have
everything settled down yet so some major changes still had to be made
for 4.1 / 4.2. I'm not enough of an expert on KDE to be sure. But we're
getting bogged down in specifics again :)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
11:55 p.m.
Adam Williamson wrote:
It seems to happen rather a lot for that to be the case, though
maybe
the situation I'm most familiar with (KDE 4.0 -> 4.1 -> 4.2) is an
unusual situation. I was watching KDE quite closely in MDV at that
point, as quite a lot of features that people expected from 3.x were
missing, and I remember, for instance, that someone was trying to get
kmilo (for multimedia keys) working on 4.x, they had to port it to 4.0,
then port it to 4.1, then to 4.2...
That's a plasmoid, the ABI for libplasma wasn't stable until 4.2. (It is
now, so plasmoids built for 4.2 still work with 4.3.)
as I said, I suppose this could just be because 4.0 didn't quite
have
everything settled down yet so some major changes still had to be made
for 4.1 / 4.2. I'm not enough of an expert on KDE to be sure.
Right, Plasma still needed major changes there. The libraries used by
regular applications kept binary compatibility though, an application built
against 4.0 will still work with 4.3.
Kevin Kofler
5:53 p.m.
On Sat, Aug 8, 2009 at 6:55 AM, Kevin Kofler<kevin.kofler(a)chello.at> wrote:
Adam Williamson wrote:
> It seems to happen rather a lot for that to be the case, though maybe
> the situation I'm most familiar with (KDE 4.0 -> 4.1 -> 4.2) is an
> unusual situation. I was watching KDE quite closely in MDV at that
> point, as quite a lot of features that people expected from 3.x were
> missing, and I remember, for instance, that someone was trying to get
> kmilo (for multimedia keys) working on 4.x, they had to port it to 4.0,
> then port it to 4.1, then to 4.2...
That's a plasmoid, the ABI for libplasma wasn't stable until 4.2. (It is
now, so plasmoids built for 4.2 still work with 4.3.)
OK, good to hear that, means that this time no patches to compiz-kde are needed.
6:52 a.m.
Adam Williamson <awilliam(a)redhat.com> writes:
To bring it back to where we came in, we have a problem in that the
KDE
team are following one policy (update to the latest KDE release on the
basis that it brings in new shiny goodness and fixes more stuff than it
breaks) while the GNOME team are following the other (don't go to the
latest point release in the interest of consistency). This doesn't make
sense
The KDE packagers have decided that KDE is good enough at avoiding
regressions that upgrading from 4.2 to 4.3 is reasonably safe. (Or
alternatively, that KDE 4.2 was so bad that 4.3 could only be an
improvement.) The Gnome packagers have the opposite views of Gnome.
Those 2 views do not conflict, and even if the teams were using the
exact same criteria, they could still come to those conclusions. You can
only call it inconsistent if KDE and Gnome have exactly the same release
policy and exactly the same history of bugs (or the absence of bugs).
This is clearly not the case.
/Benny
12:27 p.m.
On Wed, 2009-08-05 at 23:51 -0700, Adam Williamson wrote:
To bring it back to where we came in, we have a problem in that the KDE
team are following one policy (update to the latest KDE release on the
basis that it brings in new shiny goodness and fixes more stuff than it
breaks) while the GNOME team are following the other (don't go to the
latest point release in the interest of consistency). This doesn't make
sense - if some parts of the distro are going with the adventurous
policy, it renders the caution of other parts essentially null and void.
The caution of the GNOME team doesn't really work, overall, if the
kernel is following the adventurous policy. Conservative users still
aren't going to go with Fedora.
If you stop looking at Fedora the repo of packages as a whole, and start
looking at our discrete offerings, such as the Desktop spin and the KDE
spin, you can start to find consistency within each of those spins. In
the Desktop spin, you're going to see more conservative updates, mostly
focused on pure bugfix releases with some notable exceptions like the
kernel, but even that is fairly conservative. In the KDE spin you'll
find more aggressive updates. This does actually match the environments
quite well. Gnome targets the conservative, the ease of use, the
minimal knobs to twist, the get out of my way and just let me work,
where as KDE is really more about fine tuning and tweaking and turning
one of the 4000 knobs 8° to the left and being more eager to get latest
and greatest stuff.
Perhaps we're failing to define a update policy because we have wildly
divergent audiences, and we should be allowing SIGs that cater to these
audiences define the policy that best suites their respective
constituents. Defining "Fedora" is so darned hard because it's
different things to so many different people. Diving down a bit deeper
and defining Fedora Desktop vs Fedora KDE gets a bit easier to do.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
1:31 p.m.
On Thu, 2009-08-06 at 10:27 -0700, Jesse Keating wrote:
Perhaps we're failing to define a update policy because we have
wildly
divergent audiences, and we should be allowing SIGs that cater to these
audiences define the policy that best suites their respective
constituents. Defining "Fedora" is so darned hard because it's
different things to so many different people. Diving down a bit deeper
and defining Fedora Desktop vs Fedora KDE gets a bit easier to do.
I definitely see what you're saying, and yeah, perhaps an issue is that
we don't have enough of a separate identity for the separate spins. We
don't have Kedora and Gedora (or Dedora, if you like ;>), we have
Fedora...but still, there's enough updates pushed even in packages in
the Desktop spin which wouldn't go through in a more conventionally
defined update process (ask yourself if RHEL would ship 'em :>).
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
1:35 p.m.
On Thu, 2009-08-06 at 11:31 -0700, Adam Williamson wrote:
I definitely see what you're saying, and yeah, perhaps an issue is
that
we don't have enough of a separate identity for the separate spins. We
don't have Kedora and Gedora (or Dedora, if you like ;>), we have
Fedora...but still, there's enough updates pushed even in packages in
the Desktop spin which wouldn't go through in a more conventionally
defined update process (ask yourself if RHEL would ship 'em :>).
That's not a useful argument. There is a huge difference between what
RHEL would ship, and a conservative bugfix update. RHEL typically
requires a paying customer contacting support about an issue, escalation
from there, 3 levels of ACK/NACK decisions, and finally gobs of QA on a
package before it ever goes out. Vastly different than what we do in
Fedora, even for conservative updates.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
2:06 p.m.
On Thu, 2009-08-06 at 11:35 -0700, Jesse Keating wrote:
> I definitely see what you're saying, and yeah, perhaps an
issue is
> that
> we don't have enough of a separate identity for the separate spins. We
> don't have Kedora and Gedora (or Dedora, if you like ;>), we have
> Fedora...but still, there's enough updates pushed even in packages in
> the Desktop spin which wouldn't go through in a more conventionally
> defined update process (ask yourself if RHEL would ship 'em :>).
That's not a useful argument. There is a huge difference between what
RHEL would ship, and a conservative bugfix update. RHEL typically
requires a paying customer contacting support about an issue, escalation
from there, 3 levels of ACK/NACK decisions, and finally gobs of QA on a
package before it ever goes out. Vastly different than what we do in
Fedora, even for conservative updates.
OK, bad example, but you know what I mean.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:30 p.m.
On Thu, 2009-08-06 at 12:06 -0700, Adam Williamson wrote:
OK, bad example, but you know what I mean.
Yes, I do, and I think there is room for a Fedora offering that is
released frequently (every 6 months), supported for about a year, with
conservative updates to the platform. That's nearly exactly what we
have in Fedora Desktop. There is also room for a Fedora offering that
is released frequently (every 6 months), supported for about a year,
with aggressive updates to the latest and greatest for the platform.
That's nearly exactly what we have in Fedora KDE.
The real problem is going to be when somebody wants to make an offering
that features GNOME but has aggressive updates to latest and greatest
GNOME on every update stream, as that cannot coexist with the
conservative Fedora Desktop.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
6:07 p.m.
On Thu, 2009-08-06 at 12:30 -0700, Jesse Keating wrote:
On Thu, 2009-08-06 at 12:06 -0700, Adam Williamson wrote:
> OK, bad example, but you know what I mean.
Yes, I do, and I think there is room for a Fedora offering that is
released frequently (every 6 months), supported for about a year, with
conservative updates to the platform. That's nearly exactly what we
have in Fedora Desktop. There is also room for a Fedora offering that
is released frequently (every 6 months), supported for about a year,
with aggressive updates to the latest and greatest for the platform.
That's nearly exactly what we have in Fedora KDE.
Its kinda funny how the GNOME side is ending up on the 'conservative'
side here. We are pretty agressive in pushing new stuff into each
release. But we believe it is better to do that _before_ the release,
not after.
7:10 p.m.
On Thu, 2009-08-06 at 19:07 -0400, Matthias Clasen wrote:
Its kinda funny how the GNOME side is ending up on the 'conservative'
side here. We are pretty agressive in pushing new stuff into each
release. But we believe it is better to do that _before_ the release,
not after.
Right, aggressive between Fedora releases, conservative within a Fedora
release. I kind of wish everybody did that, and actually treated our
stable releases as, you know, stable releases, otherwise what's the
point of even making releases, and going through freezes and feature
processes and...
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
7:47 p.m.
On Thu, Aug 6, 2009 at 5:10 PM, Jesse Keating<jkeating(a)redhat.com> wrote:
On Thu, 2009-08-06 at 19:07 -0400, Matthias Clasen wrote:
>
> Its kinda funny how the GNOME side is ending up on the 'conservative'
> side here. We are pretty agressive in pushing new stuff into each
> release. But we believe it is better to do that _before_ the release,
> not after.
Right, aggressive between Fedora releases, conservative within a Fedora
release. I kind of wish everybody did that, and actually treated our
stable releases as, you know, stable releases, otherwise what's the
point of even making releases, and going through freezes and feature
processes and...
Yea well, I dunno about you guys who run rawhide. But as an F-11 user,
I am *very* glad I use KDE and the KDE SIG is giving me the latest and
greatest to use. I am so glad I don't have to wait for F-12 to be
released just to run the latest version of my desktop. Thank you once
again KDE SIG for your awesome support and maintainership, it is
second to none.
8:33 p.m.
On Thu, 2009-08-06 at 17:47 -0700, Christopher Stone wrote:
Yea well, I dunno about you guys who run rawhide. But as an F-11
user,
I am *very* glad I use KDE and the KDE SIG is giving me the latest and
greatest to use. I am so glad I don't have to wait for F-12 to be
released just to run the latest version of my desktop. Thank you once
again KDE SIG for your awesome support and maintainership, it is
second to none.
So you want rawhide-like treatment for some of your packages, but not
all of them? Where is the line?
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
9:38 a.m.
On Thu, Aug 6, 2009 at 6:33 PM, Jesse Keating<jkeating(a)redhat.com> wrote:
On Thu, 2009-08-06 at 17:47 -0700, Christopher Stone wrote:
> Yea well, I dunno about you guys who run rawhide. But as an F-11 user,
> I am *very* glad I use KDE and the KDE SIG is giving me the latest and
> greatest to use. I am so glad I don't have to wait for F-12 to be
> released just to run the latest version of my desktop. Thank you once
> again KDE SIG for your awesome support and maintainership, it is
> second to none.
So you want rawhide-like treatment for some of your packages, but not
all of them? Where is the line?
I don't draw the line, the maintainers of each package draw their own
line. I just sit back and comfortably sip on my mai tai while the
people who know best make the proper decisions.
10:38 a.m.
On Fri, 2009-08-07 at 07:38 -0700, Christopher Stone wrote:
On Thu, Aug 6, 2009 at 6:33 PM, Jesse
Keating<jkeating(a)redhat.com> wrote:
> On Thu, 2009-08-06 at 17:47 -0700, Christopher Stone wrote:
>> Yea well, I dunno about you guys who run rawhide. But as an F-11 user,
>> I am *very* glad I use KDE and the KDE SIG is giving me the latest and
>> greatest to use. I am so glad I don't have to wait for F-12 to be
>> released just to run the latest version of my desktop. Thank you once
>> again KDE SIG for your awesome support and maintainership, it is
>> second to none.
>
> So you want rawhide-like treatment for some of your packages, but not
> all of them? Where is the line?
I don't draw the line, the maintainers of each package draw their own
line. I just sit back and comfortably sip on my mai tai while the
people who know best make the proper decisions.
Hmm, you sound like a GNOME user ;)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
10:40 a.m.
On Fri, 2009-08-07 at 07:38 -0700, Christopher Stone wrote:
I don't draw the line, the maintainers of each package draw their
own
line. I just sit back and comfortably sip on my mai tai while the
people who know best make the proper decisions.
But you obviously have a personal line somewhere. Where is your line
that you're willing to take latest upstream builds, but won't move to
rawhide?
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
11:05 a.m.
Jesse Keating wrote:
On Fri, 2009-08-07 at 07:38 -0700, Christopher Stone wrote:
> I don't draw the line, the maintainers of each package draw their own
> line. I just sit back and comfortably sip on my mai tai while the
> people who know best make the proper decisions.
>
But you obviously have a personal line somewhere. Where is your line
that you're willing to take latest upstream builds, but won't move to
rawhide?
For me, that's easy. I don't want updates that the packagers don't
consider "stable". It sure sounds to me like Christopher feels the same way.
I am willing to take the latest upstream builds because the maintainer
considers them "safe". I am not willing to use rawhide because it's
considered a free-for-all. (I don't use updates-testing either, which
IMO if I slurped everything relevant from updates-testing, would be
about the same thing as using rawhide.)
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Thank you for reading all the way to this .sig. You may stop reading
now. Really. It is safe to stop. There is no more content. Why are you
still reading?
11:35 a.m.
On Fri, 2009-08-07 at 11:05 -0500, Matthew Woehlke wrote:
For me, that's easy. I don't want updates that the packagers
don't
consider "stable". It sure sounds to me like Christopher feels the same way.
I am willing to take the latest upstream builds because the maintainer
considers them "safe". I am not willing to use rawhide because it's
considered a free-for-all. (I don't use updates-testing either, which
IMO if I slurped everything relevant from updates-testing, would be
about the same thing as using rawhide.)
So if rawhide had an updates-testing like repo, you wouldn't mind using
it?
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
12:21 p.m.
Jesse Keating wrote:
On Fri, 2009-08-07 at 11:05 -0500, Matthew Woehlke wrote:
> For me, that's easy. I don't want updates that the packagers don't
> consider "stable". It sure sounds to me like Christopher feels the same
way.
>
> I am willing to take the latest upstream builds because the maintainer
> considers them "safe". I am not willing to use rawhide because it's
> considered a free-for-all. (I don't use updates-testing either, which
> IMO if I slurped everything relevant from updates-testing, would be
> about the same thing as using rawhide.)
So if rawhide had an updates-testing like repo, you wouldn't mind using
it?
If that put an end to stuff like 'sorry, that last glibc rpm bricks your
system if you have the misfortune of installing it'... maybe. As I said,
right now my "line" is "packages that the maintainers consider
stable".
If "rawhide" became that (and some new "rawhide-testing" or such for
the
current free-for-all), then I suppose I might use it. I'd also ask how
that differs in any significant way from a rolling release.
To be clear, 1. I would be in favor of a rolling release system, and 2.
development /needs/ a "free for all" environment. So please don't take
the above as being in any way opposed to such an environment existing...
just so long as I can opt out of it ;-).
Oh, and on a related note, it would be really helpful if it was possible
to enable updates-testing only for certain packages (and when needed,
dependencies thereof) on a permanent whitelist basis.
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Thank you for reading all the way to this .sig. You may stop reading
now. Really. It is safe to stop. There is no more content. Why are you
still reading?
12:43 p.m.
On Fri, 2009-08-07 at 12:21 -0500, Matthew Woehlke wrote:
If that put an end to stuff like 'sorry, that last glibc rpm
bricks your
system if you have the misfortune of installing it'... maybe. As I said,
right now my "line" is "packages that the maintainers consider
stable".
If "rawhide" became that (and some new "rawhide-testing" or such for
the
current free-for-all), then I suppose I might use it. I'd also ask how
that differs in any significant way from a rolling release.
To be clear, 1. I would be in favor of a rolling release system, and 2.
development /needs/ a "free for all" environment. So please don't take
the above as being in any way opposed to such an environment existing...
just so long as I can opt out of it ;-).
Well with the no frozen rawhide proposal, from the Alpha freeze point on
there would be such an updates-testing for the pending release, while
rawhide remains the wild west. You could say install F12, then at F13
Alpha jump onto F13 and have the much newer more often content that has
had some testing. Just keep jumping to the next Alpha and you have your
"rolling release" as it were.
Oh, and on a related note, it would be really helpful if it was possible
to enable updates-testing only for certain packages (and when needed,
dependencies thereof) on a permanent whitelist basis.
include=<package> in the yum conf for updates-testing.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
1:06 p.m.
On Fri, 2009-08-07 at 10:43 -0700, Jesse Keating wrote:
Well with the no frozen rawhide proposal, from the Alpha freeze point on
there would be such an updates-testing for the pending release, while
rawhide remains the wild west. You could say install F12, then at F13
Alpha jump onto F13 and have the much newer more often content that has
had some testing. Just keep jumping to the next Alpha and you have your
"rolling release" as it were.
Of course, that assumes that the 'jumping', ie preupgrade / upgrade are
well supported and work smoothly...
1:16 p.m.
Jesse Keating wrote:
Well with the no frozen rawhide proposal, from the Alpha freeze point
on
there would be such an updates-testing for the pending release, while
rawhide remains the wild west. You could say install F12, then at F13
Alpha jump onto F13 and have the much newer more often content that has
had some testing. Just keep jumping to the next Alpha and you have your
"rolling release" as it were.
How does that differ from the current situation (except for being a
little more bleeding)?
A true rolling release is install-once, update-forever. Yes you can more
or less do this with upgrade-via-yum, but it is still a large chunk of
effort at 6- or 12-month intervals.
> Oh, and on a related note, it would be really helpful if it was
possible
> to enable updates-testing only for certain packages (and when needed,
> dependencies thereof) on a permanent whitelist basis.
include=<package> in the yum conf for updates-testing.
Will that also use packages from -testing when needed to resolve
dependencies for something in the include list? Or will it just break?
('man yum.conf' makes it sound like the latter...)
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Thank you for reading all the way to this .sig. You may stop reading
now. Really. It is safe to stop. There is no more content. Why are you
still reading?
5:44 p.m.
On Fri, Aug 7, 2009 at 8:40 AM, Jesse Keating<jkeating(a)redhat.com> wrote:
On Fri, 2009-08-07 at 07:38 -0700, Christopher Stone wrote:
> I don't draw the line, the maintainers of each package draw their own
> line. I just sit back and comfortably sip on my mai tai while the
> people who know best make the proper decisions.
>
But you obviously have a personal line somewhere. Where is your line
that you're willing to take latest upstream builds, but won't move to
rawhide?
For me, as I explained earlier, I take each package I maintain on a
case by case basis. However it's basically one simple rule: If it is
going to cause a bunch of new bugs to be reported which I have to deal
with then I wont release for non-rawhide or "stable" Fedoras.
Otherwise, I generally try to keep all supported Fedora versions up to
date with the packages I maintain. Although I have to admit I've been
slacking off in the past few months...
8:26 p.m.
On Thu, Aug 6, 2009 at 8:10 PM, Jesse Keating wrote:
On Thu, 2009-08-06 at 19:07 -0400, Matthias Clasen wrote:
>
> Its kinda funny how the GNOME side is ending up on the 'conservative'
> side here. We are pretty agressive in pushing new stuff into each
> release. But we believe it is better to do that _before_ the release,
> not after.
Right, aggressive between Fedora releases, conservative within a Fedora
release. I kind of wish everybody did that, and actually treated our
stable releases as, you know, stable releases, otherwise what's the
point of even making releases, and going through freezes and feature
processes and...
I believe that is the way it should be. The releases must be there
every once in a while when the installer is updated, e.g.. when the
default file system is changed, or when gnome is finally obsoleted
etc. Otherwise F10=F11 until the last day of F-10's lifetime, in my
perspective. It's just my opinion, as I don't maintain any core
components and there might be things that I'm not considering.
Orcan
10:45 p.m.
On Thu, Aug 6, 2009 at 7:10 PM, Jesse Keating<jkeating(a)redhat.com> wrote:
<snip>
Right, aggressive between Fedora releases, conservative within a
Fedora
release. I kind of wish everybody did that, and actually treated our
stable releases as, you know, stable releases, otherwise what's the
point of even making releases, and going through freezes and feature
processes and...
<snip>
We could always just go the direction of Arch Linux, have a rolling
release and just push out new install images every 6 months (or so).
:)
..... only kidding, but it does seem like some of the arguing points
are going that direction.
-Adam
--
http://maxamillion.googlepages.com
---------------------------------------------------------
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments
9:21 p.m.
On Thu, 2009-08-06 at 12:30 -0700, Jesse Keating wrote:
On Thu, 2009-08-06 at 12:06 -0700, Adam Williamson wrote:
> OK, bad example, but you know what I mean.
Yes, I do, and I think there is room for a Fedora offering that is
released frequently (every 6 months), supported for about a year, with
conservative updates to the platform. That's nearly exactly what we
have in Fedora Desktop. There is also room for a Fedora offering that
is released frequently (every 6 months), supported for about a year,
with aggressive updates to the latest and greatest for the platform.
That's nearly exactly what we have in Fedora KDE.
The real problem is going to be when somebody wants to make an offering
that features GNOME but has aggressive updates to latest and greatest
GNOME on every update stream, as that cannot coexist with the
conservative Fedora Desktop.
The other problem is if you'd like stable updates but you prefer KDE, or
vice versa =)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:05 a.m.
On Friday 07 August 2009 04:21:56 Adam Williamson wrote:
On Thu, 2009-08-06 at 12:30 -0700, Jesse Keating wrote:
> On Thu, 2009-08-06 at 12:06 -0700, Adam Williamson wrote:
> > OK, bad example, but you know what I mean.
>
> Yes, I do, and I think there is room for a Fedora offering that is
> released frequently (every 6 months), supported for about a year, with
> conservative updates to the platform. That's nearly exactly what we
> have in Fedora Desktop. There is also room for a Fedora offering that
> is released frequently (every 6 months), supported for about a year,
> with aggressive updates to the latest and greatest for the platform.
> That's nearly exactly what we have in Fedora KDE.
>
> The real problem is going to be when somebody wants to make an offering
> that features GNOME but has aggressive updates to latest and greatest
> GNOME on every update stream, as that cannot coexist with the
> conservative Fedora Desktop.
The other problem is if you'd like stable updates but you prefer KDE, or
vice versa =)
Why do you expect that updating to the latest KDE means unstable system? ;-)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
--
Jaroslav Řezník <jreznik(a)redhat.com>
Associate Software Engineer - Base Operating Systems Brno
Office: +420 532 294 275
Mobile: +420 731 455 332
Red Hat, Inc. http://cz.redhat.com/
3:42 a.m.
On 08/07/2009 01:35 PM, Jaroslav Reznik wrote:
> The other problem is if you'd like stable updates but you
prefer KDE, or
> vice versa =)
Why do you expect that updating to the latest KDE means unstable system? ;-)
As already explained, stable in the sense of things that work the same
(No big UI changes etc). We are not talking about robustness here
although new updates has the potential to cause issues there as well.
Rahul
6:18 a.m.
On Friday 07 August 2009 10:42:35 Rahul Sundaram wrote:
On 08/07/2009 01:35 PM, Jaroslav Reznik wrote:
>> The other problem is if you'd like stable updates but you prefer KDE, or
>> vice versa =)
>
> Why do you expect that updating to the latest KDE means unstable system?
> ;-)
As already explained, stable in the sense of things that work the same
(No big UI changes etc). We are not talking about robustness here
although new updates has the potential to cause issues there as well.
But that means Fedora is totally unstable - as we're forcing users every year
to survive much more bigger changes. Fedora is really very inconsistent
between releases. This is case where continual updates can avoid it.
Maybe we're lacking some vision farther then +1 release, not only in Fedora,
but in all OSS projects...
Jaroslav
Rahul
--
Jaroslav Řezník <jreznik(a)redhat.com>
Associate Software Engineer - Base Operating Systems Brno
Office: +420 532 294 275
Mobile: +420 731 455 332
Red Hat, Inc. http://cz.redhat.com/
6:45 a.m.
On 08/07/2009 04:48 PM, Jaroslav Reznik wrote:
On Friday 07 August 2009 10:42:35 Rahul Sundaram wrote:
> On 08/07/2009 01:35 PM, Jaroslav Reznik wrote:
>>> The other problem is if you'd like stable updates but you prefer KDE, or
>>> vice versa =)
>>
>> Why do you expect that updating to the latest KDE means unstable system?
>> ;-)
>
> As already explained, stable in the sense of things that work the same
> (No big UI changes etc). We are not talking about robustness here
> although new updates has the potential to cause issues there as well.
But that means Fedora is totally unstable - as we're forcing users every year
to survive much more bigger changes.
No it does not. New releases bringing in changes is expected. Updates
changing behaviour, much less so.
Rahul
12:04 a.m.
Rahul Sundaram wrote:
As already explained, stable in the sense of things that work the
same
(No big UI changes etc).
When did we push *big* UI changes in a KDE update? We're even making sure
the default Plasma theme in F10 and F11 stays Oxygen rather than switching
to Air which is the new upstream default in 4.3 for this very reason. We
also don't push major updates like Amarok 1->2 to stable releases (F9 stayed
with 1.4 until EOL, F10 shipped with a beta of Amarok 2 and got updated to
newer Amarok 2 builds).
Kevin Kofler
3:58 a.m.
On 08/08/2009 10:34 AM, Kevin Kofler wrote:
Rahul Sundaram wrote:
> As already explained, stable in the sense of things that work the same
> (No big UI changes etc).
When did we push *big* UI changes in a KDE update?
Big UI changes is an *example* but if you are going to argue that none
of the KDE updates ever changed the user experience including the
interface significantly then I guess we got to disagree on that.
Rahul
10:37 p.m.
Adam Williamson wrote:
I probably couldn't do much justice to a comprehensive plan as I
have
insufficient knowledge of how the buildsystem works. I was acting at a
higher level - just trying to point out that it's essentially doomed to
try and please everyone with a single update repository, that's not an
argument anyone can win. Either the 'we want stable updates' camp or the
'we want shiny new stuff' camp is going to be disappointed.
The problem is that your solution doubles maintainer and rel-eng workload. I
think we really don't have the resources for that.
Kevin Kofler
12:59 a.m.
On Thu, 2009-08-06 at 05:37 +0200, Kevin Kofler wrote:
Adam Williamson wrote:
> I probably couldn't do much justice to a comprehensive plan as I have
> insufficient knowledge of how the buildsystem works. I was acting at a
> higher level - just trying to point out that it's essentially doomed to
> try and please everyone with a single update repository, that's not an
> argument anyone can win. Either the 'we want stable updates' camp or the
> 'we want shiny new stuff' camp is going to be disappointed.
The problem is that your solution doubles maintainer and rel-eng workload. I
think we really don't have the resources for that.
Please don't personalize things. It's not 'mine', and it's not really
a
solution. I'm simply pointing out that it's literally impossible to
satisfy both possible update policies with a single unitary repository.
We either have to make it clear which policy we use and which policy we
don't, and hence which theoretical user base we are not targeting, or
take on extra work and try to satisfy both. I am not declaring myself in
favor of, or against, any particular option. I'm just pointing out the
parameters of the question.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
8:24 a.m.
On Wed, Aug 05, 2009 at 10:59:25PM -0700, Adam Williamson wrote:
On Thu, 2009-08-06 at 05:37 +0200, Kevin Kofler wrote:
> Adam Williamson wrote:
> > I probably couldn't do much justice to a comprehensive plan as I have
> > insufficient knowledge of how the buildsystem works. I was acting at a
> > higher level - just trying to point out that it's essentially doomed to
> > try and please everyone with a single update repository, that's not an
> > argument anyone can win. Either the 'we want stable updates' camp or
the
> > 'we want shiny new stuff' camp is going to be disappointed.
>
> The problem is that your solution doubles maintainer and rel-eng workload. I
> think we really don't have the resources for that.
Please don't personalize things. It's not 'mine', and it's not really
a
solution. I'm simply pointing out that it's literally impossible to
satisfy both possible update policies with a single unitary repository.
You are under the impression that we have an update policy at all. We don't.
So we have nothing to satisfy, which makes it very possible.
We either have to make it clear which policy we use and which policy
we
don't, and hence which theoretical user base we are not targeting, or
take on extra work and try to satisfy both. I am not declaring myself in
Actually, we could do nothing and be just fine. Let the users decide if and
when and what they want to update.
josh
11:43 a.m.
On Thu, 2009-08-06 at 09:24 -0400, Josh Boyer wrote:
>We either have to make it clear which policy we use and which
policy we
>don't, and hence which theoretical user base we are not targeting, or
>take on extra work and try to satisfy both. I am not declaring myself in
Actually, we could do nothing and be just fine. Let the users decide if and
when and what they want to update.
Doing nothing is an implicit choice in favour of the adventurous option,
with the disadvantage that we don't come out clearly and say it.
It's rather hard to choose 'if and when and what' you want to update on
a system that you only really talk to once a week that otherwise just
sits there and does its job. For instance - a server, or a home theater
box. I have both of these types of system. They're set to auto-update
once a day, I don't spend my life logging into them by SSH, poring over
the update list and deciding what to install. I can do this because the
conservative update policy of the distribution they run gives me
confidence that the updates won't break the things. I couldn't do that
with Fedora, as there's no policy to give me the confidence that
automatically updating such systems won't break them. As I've said, this
isn't a _problem_ per se, but it means Fedora has a particular identity
that we don't seem comfortable talking about - 'let's pretend not to
make a choice' - for some reason.
See what I mean? No choice is a choice.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
12:05 p.m.
On Thu, Aug 06, 2009 at 09:43:03AM -0700, Adam Williamson wrote:
On Thu, 2009-08-06 at 09:24 -0400, Josh Boyer wrote:
> >We either have to make it clear which policy we use and which policy we
> >don't, and hence which theoretical user base we are not targeting, or
> >take on extra work and try to satisfy both. I am not declaring myself in
>
> Actually, we could do nothing and be just fine. Let the users decide if and
> when and what they want to update.
Doing nothing is an implicit choice in favour of the adventurous option,
with the disadvantage that we don't come out clearly and say it.
Um, ok. I disagree, but hey we'll just go in circles.
It's rather hard to choose 'if and when and what' you want
to update on
a system that you only really talk to once a week that otherwise just
sits there and does its job. For instance - a server, or a home theater
box. I have both of these types of system. They're set to auto-update
once a day, I don't spend my life logging into them by SSH, poring over
Personally, I don't care about meeting the needs of someone that wants to
set their machine to auto-update so they can have warm fuzzies about it. We
don't guarantee anything, we don't have official support contracts for Fedora,
and as of right now we don't have the maintainer/QA/rel-eng manpower to even
come close to making it safe to auto-update 100% of the time.
See what I mean? No choice is a choice.
Sure. It's called 'sticking with the status quo'. Which isn't all or
nothing
as you seem to want to paint it. It's left in the hands of the maintainers.
josh
12:31 p.m.
On 08/06/2009 09:43 AM, Adam Williamson wrote:
On Thu, 2009-08-06 at 09:24 -0400, Josh Boyer wrote:
>> We either have to make it clear which policy we use and which policy we
>> don't, and hence which theoretical user base we are not targeting, or
>> take on extra work and try to satisfy both. I am not declaring myself in
>
> Actually, we could do nothing and be just fine. Let the users decide if and
> when and what they want to update.
Doing nothing is an implicit choice in favour of the adventurous option,
with the disadvantage that we don't come out clearly and say it.
It's rather hard to choose 'if and when and what' you want to update on
a system that you only really talk to once a week that otherwise just
sits there and does its job. For instance - a server, or a home theater
box. I have both of these types of system. They're set to auto-update
once a day, I don't spend my life logging into them by SSH, poring over
the update list and deciding what to install. I can do this because the
conservative update policy of the distribution they run gives me
confidence that the updates won't break the things. I couldn't do that
with Fedora, as there's no policy to give me the confidence that
automatically updating such systems won't break them. As I've said, this
isn't a _problem_ per se, but it means Fedora has a particular identity
that we don't seem comfortable talking about - 'let's pretend not to
make a choice' - for some reason.
See what I mean? No choice is a choice.
In writing my reply, I figured out where the disconnect is between what
you're seeing and what I'm seeing. You're looking at this from the
user's point of view. In that case, a hands off policy does make it
more likely that the user will have an adventurous experience rather
than a conservative experience even if one segment of the maintainer
community (the desktop team) is doing its best to play a conservative role.
I think we'd be happy to admit to the end users that that's the kind of
distro we are and that CentOS/RHEL may be a better venue for the
machines that they want to take a hands-off, everything works today and
so everything will work tomorrow and the next day approach. We
currently tell people to run CentOS or RHEL for the machines in that use
case because of the 13 month EOL period anyway.
The viewpoint that you also have to see, though, is the packager
viewpoint. From within we don't all agree on whether we should have a
conservative or an adventurous update policy. As the specifics of
whether to update KDE and whether to update GNOME demonstrate, different
sets of maintainers want the opposite strategies. Mandating that
maintainers will either follow the conservative or the adventurous or
follow both the conservative and the adventurous update path may satisfy
the most users but leaves the maintainers disgruntled.
Being clear that how we're messaging this to the users isn't affecting
how the maintainers get to handle their individual packages in this case
makes sense.
I'm going to note, though, that this still doesn't address the original
poster's question or thorsten's followup -- some areas of our
distribution will still follow a conservative update policy as long as
we give individual maintainers the leeway to use their best judgement.
-Toshio
1:36 p.m.
On Thu, 2009-08-06 at 10:31 -0700, Toshio Kuratomi wrote:
> See what I mean? No choice is a choice.
>
In writing my reply, I figured out where the disconnect is between what
you're seeing and what I'm seeing. You're looking at this from the
user's point of view.
Yes, you could say I have a nasty habit of doing that. ;) Actually I try
and look at things from many points of view, but the user's point of
view is a rather important one. We're _all_ users, even those of us who
are also maintainers. Each maintainer only maintains a little bit of the
distro. With regard to all the other packages we don't maintain, we're
users.
Imagine two staff members in a store discussing an issue, then one
turning to the other and saying "ohhh, I get it. You're thinking about
the CUSTOMER'S point of view!" :D
In that case, a hands off policy does make it
more likely that the user will have an adventurous experience rather
than a conservative experience even if one segment of the maintainer
community (the desktop team) is doing its best to play a conservative role.
I think we'd be happy to admit to the end users that that's the kind of
distro we are and that CentOS/RHEL may be a better venue for the
machines that they want to take a hands-off, everything works today and
so everything will work tomorrow and the next day approach. We
currently tell people to run CentOS or RHEL for the machines in that use
case because of the 13 month EOL period anyway.
Well, I'd be happy if we did that, yes. I guess the best thing would be
to take some kind of proposal to the appropriate committee that we just
write up a document, for the wiki or fedoraproject.org or wherever's
appropriate, to make it clear that we don't have a conservative update
policy, and that we don't expect users to be able to treat Fedora like a
CentOS/RHEL/Debian stable/whatever-style operating system, from an
update point of view.
The viewpoint that you also have to see, though, is the packager
viewpoint. From within we don't all agree on whether we should have a
conservative or an adventurous update policy. As the specifics of
whether to update KDE and whether to update GNOME demonstrate, different
sets of maintainers want the opposite strategies. Mandating that
maintainers will either follow the conservative or the adventurous or
follow both the conservative and the adventurous update path may satisfy
the most users but leaves the maintainers disgruntled.
Yes, I agree, it wasn't my intent to suggest that. Even in the combined
case, maintainers always have the choice to not bother to ship
adventurous updates, and even if we specify that we don't guarantee
conservative updates, maintainers who don't want to do adventurous
updates aren't compelled to. I just want to be clear about how the big
picture looks to users in each of these cases, and try for consistent
messaging on whichever path we end up on, so users know what they can
expect from Fedora.
I'm going to note, though, that this still doesn't address
the original
poster's question or thorsten's followup -- some areas of our
distribution will still follow a conservative update policy as long as
we give individual maintainers the leeway to use their best judgement.
Yes, you're right there.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
6:56 p.m.
Great thread.
On 08/06/2009 01:59 AM, Adam Williamson wrote:
I'm simply pointing out that it's literally impossible to
satisfy both possible update policies with a single unitary repository.
There was some talk about additional tagging in RPM being available in
Fedora 13, wasn't there? Perhaps if that could propagate through the
build, repo, and yum tools there would be a way to solve for various
branches.
MythDora is a spin that's worth studying here. It provides a specific
purpose, is pretty well-tuned to that purpose, and doesn't necessarily
update for every Fedora release.
One can imagine a 'Fedora Solid' spin that pays special attention to QA,
maybe only plans on every-other release, sometimes back-porting
release+1 things that make a huge win, maybe takes longer to compose
than a regular Fedora release. There was some talk about extending
updates to 18 months, which would make such a spin feasible.
CentOS tends to be crufty, Fedora tends to be broken. Average users
usually want to be somewhere in the middle. Having a user-focused SIG
as an additional check on packagers' decisions to update packages could
have quality benefits.
I like the idea that Fedora is whatever there's a SIG for, not just for
avoiding the question, but for the idea that Fedora is a process, not a
product.
-Bill
--
Bill McGonigle, Owner Work: 603.448.4440
BFC Computing, LLC Home: 603.448.1668
http://www.bfccomputing.com/ Cell: 603.252.2606
Twitter, etc.: bill_mcgonigle Page: 603.442.1833
Email, IM, VOIP: bill(a)bfccomputing.com
Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf
7:57 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bill McGonigle wrote:
CentOS tends to be crufty, Fedora tends to be broken. Average
users
usually want to be somewhere in the middle. Having a user-
focused SIG
as an additional check on packagers' decisions to update
packages could
have quality benefits.
I like the idea that Fedora is whatever there's a SIG for, not
just for
avoiding the question, but for the idea that Fedora is a
process, not a
product.
-Bill
Just a thought, but could that SIG just enforce a critical path-
like workflow (with overrides from the security team) on FN-2?
They would have to be willing to do the QA, talk with SIGs and
maintainers, and be large enough to be able to do so. Thoughts?
As a bridge, have critical path grab more packages in FN-1
(maybe have it happen at a milestone such as FN+1 the-release-
formerly-known-as-beta?).
- --Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkp7fAkACgkQiPi+MRHG3qQa0wCeOkR/xSGvXlJcsYMWuLdTg4TO
OfoAnAyF8a1V8D2BwS7lvYE6JpLyci1z
=xO/E
-----END PGP SIGNATURE-----
10:28 a.m.
On 08/06/2009 08:57 PM, Ben Boeckel wrote:
Just a thought, but could that SIG just enforce a critical path-
like workflow (with overrides from the security team) on FN-2?
They would have to be willing to do the QA, talk with SIGs and
maintainers, and be large enough to be able to do so. Thoughts?
I'm not sure FN-2 always qualifies as stable. For instance, I've seen
major sound and video breakage in F11 - that wouldn't make a good base
for a stable distro when F13 is branching _just_ because it's two back.
On the other hand, one can juggle kernel versions/options, drivers,
disable PulseAudio, etc. as required to achieve stable - though work
better suited for a project than random thoughts in this e-mail. ;)
-Bill
--
Bill McGonigle, Owner Work: 603.448.4440
BFC Computing, LLC Home: 603.448.1668
http://www.bfccomputing.com/ Cell: 603.252.2606
Twitter, etc.: bill_mcgonigle Page: 603.442.1833
Email, IM, VOIP: bill(a)bfccomputing.com
Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf
9:24 p.m.
On Thu, 2009-08-06 at 19:56 -0400, Bill McGonigle wrote:
Great thread.
Glad someone appreciates it :)
On 08/06/2009 01:59 AM, Adam Williamson wrote:
> I'm simply pointing out that it's literally impossible to
> satisfy both possible update policies with a single unitary repository.
There was some talk about additional tagging in RPM being available in
Fedora 13, wasn't there? Perhaps if that could propagate through the
build, repo, and yum tools there would be a way to solve for various
branches.
We discussed that a few branches of the thread back ;). The principal
problem with that is that it's tricky to have multiple 'tracks' within
one update repository - so if a package does get an 'adventurous' update
then hits a security bug, there's no way to have a separate update
without the adventurous change but with the security bug fixed. You then
don't have the ability to choose the 'stable but secure' path - you're
stuck with either the release package (stable but insecure) or the
updated package that includes the adventurous change (secure but
potentially unstable).
MythDora is a spin that's worth studying here. It provides a
specific
purpose, is pretty well-tuned to that purpose, and doesn't necessarily
update for every Fedora release.
One can imagine a 'Fedora Solid' spin that pays special attention to QA,
maybe only plans on every-other release, sometimes back-porting
release+1 things that make a huge win, maybe takes longer to compose
than a regular Fedora release. There was some talk about extending
updates to 18 months, which would make such a spin feasible.
I'm not sure you could _make_ a 'Solid' spin unless there was a Solid
update path to work off.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
10:24 a.m.
On 08/06/2009 10:24 PM, Adam Williamson wrote:
so if a package does get an 'adventurous' update
then hits a security bug, there's no way to have a separate update
without the adventurous change but with the security bug fixed
so, two separate issues: one is making the updates, the other is solving
for them. I only meant that with tags you could potentially solve for
available updates within a single repo.
I'm not sure you could _make_ a 'Solid' spin unless there
was a Solid
update path to work off.
Right, to do that we'd need a SIG interested in making sure there was
one. Some package developers/maintainers would probably join, others
wouldn't be interested. It's probably not necessary to have all of
Fedora in such a spin, but where there are users there tends to be interest.
-Bill
--
Bill McGonigle, Owner Work: 603.448.4440
BFC Computing, LLC Home: 603.448.1668
http://www.bfccomputing.com/ Cell: 603.252.2606
Twitter, etc.: bill_mcgonigle Page: 603.442.1833
Email, IM, VOIP: bill(a)bfccomputing.com
Blog: http://blog.bfccomputing.com/
VCard: http://bfccomputing.com/vcard/bill.vcf
9:55 a.m.
On Wed, Aug 5, 2009 at 12:23 PM, Thorsten Leemhuis<fedora(a)leemhuis.info> wrote:
Further: The behavior changes to much IMHO -- one reason why I use
Fedora at home and work and suggested it to others were the major new
kernel versions that got delivered as regular update. But that doesn't
really work anymore since half a year or something: F-10 is still on
2.6.27, 2.6.29 sits in Updates-testing for ages; 2.6.30 is out for
weeks, but no sign of a update for F-11 apart for a few commits in CVS. :-(
If I got this correctly the main reason are the out of tree drm
patches (modestetting) needs to be ported, just rebasing to newer
upstream bits does not always work because it would require updated X
drivers.
So it ended up like the old xen days (delays due to back/forwardporting effort).
5:08 a.m.
On Wed, Aug 5, 2009 at 9:49 AM, Josephine
Tannhäuser<josephine.tannhauser(a)googlemail.com> wrote:
Hi all.
KDE 4.3 will come to F11 and F10. It's a cool thing.
There aren't updates like this for Gnome. Why not?
F10 with Gnome 2.26 sounds fine to me.
Because a lot of GNOME works directly with (and depends on) the core
OS., and we want a stable system.
And really because we should rather invest effort in making sure that
upgrades between major releases for the core OS and default desktop
packages are nearly bulletproof, and in addition try to maintain a
parallel-installable stable set of library packages for a set period
of time. This would make it so that things outside the core are less
likely to break due to core upgrades. I'm thinking concretely here
of say a package like clutter which has switched 0.6 -> 0.8 -> 1.0 in
the same "clutter" package is a bad idea once the core desktop depends
on it, we'll need to parallel install.
5:46 a.m.
On Wednesday 05 August 2009 13:08:28 Colin Walters wrote:
Because a lot of GNOME works directly with (and depends on) the core
OS., and we want a stable system.
Does this mean, that every time I've installed my system and left
GNOME out, I made a broken system?
Is there a list of those 'direct dependencies' somewhere?
Tuju
--
Better to have one, and not need it, than to need one and not have it.
6:06 a.m.
On Wed, 2009-08-05 at 13:46 +0300, Juha Tuomala wrote:
On Wednesday 05 August 2009 13:08:28 Colin Walters wrote:
> Because a lot of GNOME works directly with (and depends on) the core
> OS., and we want a stable system.
Does this mean, that every time I've installed my system and left
GNOME out, I made a broken system?
Is there a list of those 'direct dependencies' somewhere?
No, it means that updating gnome would mean updating a bunch of
libraries that are used by other apps. This would require a lot of
rebuilds, and they might fail due to a number of reasons.
Upgrading the desktop is potentially a big operation. I am very happy
with the release scheme that is used with Gnome, OpenOffice, GCC and so
on. If you want the newest and shiniest, use the newest release of
Fedora.
--
Jussi Lehtola
Fedora Project Contributor
jussilehtola(a)fedoraproject.org
9:21 a.m.
On Wednesday 05 August 2009 14:06:43 Jussi Lehtola wrote:
On Wed, 2009-08-05 at 13:46 +0300, Juha Tuomala wrote:
> On Wednesday 05 August 2009 13:08:28 Colin Walters wrote:
> > Because a lot of GNOME works directly with (and depends on) the core
> > OS., and we want a stable system.
>
> Does this mean, that every time I've installed my system and left
> GNOME out, I made a broken system?
>
> Is there a list of those 'direct dependencies' somewhere?
No, it means that updating gnome would mean updating a bunch of
libraries that are used by other apps.
Which sounds like, it would break 'other apps', not 'the core OS'.
Upgrading the desktop is potentially a big operation. I am very
happy
with the release scheme that is used with Gnome, OpenOffice, GCC and so
on.
Likewise. I'm also very happy that KDE SIG goes through the effort
and brings the 4.3 to us and we can enjoy the whole lifespan of already
installed OS. That is a huge saving in manhours, bandwidth, electricity,
hard disk ballbearings, whatever - world wide. Certainly worth of effort.
Tuju
--
Better to have one, and not need it, than to need one and not have it.
1:53 p.m.
On Wed, 2009-08-05 at 17:21 +0300, Juha Tuomala wrote:
On Wednesday 05 August 2009 14:06:43 Jussi Lehtola wrote:
> On Wed, 2009-08-05 at 13:46 +0300, Juha Tuomala wrote:
> > On Wednesday 05 August 2009 13:08:28 Colin Walters wrote:
> > > Because a lot of GNOME works directly with (and depends on) the core
> > > OS., and we want a stable system.
> >
> > Does this mean, that every time I've installed my system and left
> > GNOME out, I made a broken system?
> >
> > Is there a list of those 'direct dependencies' somewhere?
>
> No, it means that updating gnome would mean updating a bunch of
> libraries that are used by other apps.
Which sounds like, it would break 'other apps', not 'the core OS'.
What's being talked about, specifically, is libraries like GTK+
(especially GTK+ itself). That's part of the 'core system' by any
reasonable definition, as many many applications depend on it
(including, say, our default browser, and all our system configuration
tools). There are several other components down in the stack that GNOME
depends on which are in the same situation.
Things aren't quite the same on the KDE side, as relatively few really
mission-critical apps in Fedora are built on Qt and the rest of the KDE
stack.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
8:06 a.m.
On Wed, 2009-08-05 at 11:49 +0200, Josephine Tannhäuser wrote:
Hi all.
KDE 4.3 will come to F11 and F10. It's a cool thing.
There aren't updates like this for Gnome. Why not?
F10 with Gnome 2.26 sounds fine to me.
GNOME has stable bugfix updates, and we do bring all of those into
released Fedoras.
Backporting entirely new desktop versions to old Fedora releases is a
bad idea for a number of reasons:
- It would pull along a good-sized portion of the 'plumbing' layer: new
udev, kernel, pulseaudio, X...
- We don't have the man power to do a good job on this. This may be
different on the KDE side. While we do a good chunk of the development
work for each GNOME release, the KDE sig is more of a packaging effort,
as far as I understand. Correct me if I'm wrong here...
- It is not compatible with the concept of a finished, stable release.
If we just want to dump all the latest stuff in there, why bother with
freezes and releases at all ? We could all just use rawhide...
Matthias
11:08 p.m.
Matthias Clasen wrote:
- It would pull along a good-sized portion of the 'plumbing'
layer: new
udev, kernel, pulseaudio, X...
Hmmm, that's interesting. KDE seems to be a lot more flexible there, you
sure don't need to run the latest kernel to use the latest KDE.
That said, some stuff like the kernel has traditionally been updated
frequently anyway (though lately there have been issues), other stuff like
PulseAudio could probably use getting updates too (as they fix bugs, though
AIUI most bugfixes are in ALSA, which brings us back to the kernel).
- We don't have the man power to do a good job on this. This may
be
different on the KDE side.
:-)
I'll remember this in case you argue about KDE SIG's supposed lack of
manpower in the future. :-p
That said, …
While we do a good chunk of the development work for each GNOME
release,
the KDE sig is more of a packaging effort, as far as I understand. Correct
me if I'm wrong here...
… you have a point here.
Another factor is that KDE's big modules are a lot less work to package than
the many small modules GNOME ships.
- It is not compatible with the concept of a finished, stable
release.
If we just want to dump all the latest stuff in there, why bother with
freezes and releases at all ? We could all just use rawhide...
In KDE SIG, we don't dump "all the latest stuff" in there. First of all,
version upgrades always go to updates-testing first, we don't just dump them
to updates. They'll stay in updates-testing as long as needed to hunt down
any regressions, for example Qt 4.5 stayed there for quite a long time.
We'll only push something to stable when we're convinced it actually IS
stable. And we also don't push out everything as updates. We do NOT push:
* prereleases of core KDE or of most applications (only few exceptions), we
push only releases upstream deems stable,
* major (first digit) updates like KDE 3->4, Amarok 1->2 and other KDE 3->4
ports of applications with major changes and known regressions,
* any other stuff we do not consider ready for the average user's
consumption.
Just look at the contents of kde-redhat unstable (http://apt.kde-
redhat.org/apt/kde-redhat/fedora/11/i386/RPMS.unstable/) for examples of
stuff we do NOT push as updates to stable releases (whereas Rawhide has it).
Currently, kde-redhat unstable for F11 contains Digikam 1.0 Beta 3 (unstable
prerelease), Eigen2 2.0.3 (already in stable updates, can be removed now),
K3b 1.66 (unstable prerelease, and a KDE 4 port with major changes),
Kaffeine 1.0-pre1 (likewise), a new kde-plasma-stasks build (fixes for KDE
4.3, will be pushed with our 4.3 updates most likely), KOffice 2.0.1 (KDE 4
port with major changes), Konversation 1.2 alpha4 (unstable prerelease, and
a KDE 4 port with major changes) and builds of Qt and Phonon which enable
Qt's own copy of Phonon (still shipped as a system library, of course, just
built from the Qt SRPM now as that's actually more up to date than the
tarball and as building it together with Qt has other benefits, in
particular, it avoids a circular dependency when building QtWebKit; this is
in kde-redhat unstable because it also makes Phonon-GStreamer the default
rather than Phonon-Xine). All that stuff is already in Rawhide (also hoping
that the prereleases will be sufficiently stable by the time F12 releases).
Kevin Kofler
7:35 a.m.
Kevin Kofler, Thu, 06 Aug 2009 06:08:50 +0200:
Hmmm, that's interesting. KDE seems to be a lot more flexible
there, you
sure don't need to run the latest kernel to use the latest KDE.
Yes, it is ... because it is much more self-contained (you have just one
huge dependency containing everything -- libqt; that's hyperbole, but not
that much). Gnome is that maze of zillion interdependent libraries which
need to work together. Sometimes one model has advantage over another
sometimes not. C'est la vie.
Matěj
7:41 a.m.
2009/8/5 Matthias Clasen <mclasen(a)redhat.com>:
If we just want to dump all the latest stuff in there, why bother
with
freezes and releases at all ? We could all just use rawhide...
While often repeated, I don't think that argument is true.
Some people (including me) like the idea of having a 'rolling
release', but that's *not* the same as running rawhide. Even in a
'rolling release' scenario, packages would be in a 'staging area first
for a while for testing, before being moved to the main repo.
And back to the topic, afaik the KDE 4.3 packages have indeed been
tested (via kde-redhat/testing etc) before being thrown on the f10 &
f11 users.
- Thomas
8:05 a.m.
2009/8/7 Thomas Moschny <thomas.moschny(a)gmail.com>:
2009/8/5 Matthias Clasen <mclasen(a)redhat.com>:
> If we just want to dump all the latest stuff in there, why bother with
> freezes and releases at all ? We could all just use rawhide...
While often repeated, I don't think that argument is true.
Some people (including me) like the idea of having a 'rolling
release', but that's *not* the same as running rawhide. Even in a
'rolling release' scenario, packages would be in a 'staging area first
for a while for testing, before being moved to the main repo.
And back to the topic, afaik the KDE 4.3 packages have indeed been
tested (via kde-redhat/testing etc) before being thrown on the f10 &
f11 users.
Indeed. Even the RCs up to 4.2.98 have been tested via the kde-redhat
repo, bugs filed and fixed. I'm one of them who run always the latest
and greatest from kde-redhat.
--
LG Thomas
Dubium sapientiae initium
9:58 a.m.
On Friday 07 August 2009 14:05:25 Thomas Janssen wrote:
> And back to the topic, afaik the KDE 4.3 packages have indeed
been
> tested (via kde-redhat/testing etc) before being thrown on the f10 &
> f11 users.
Indeed. Even the RCs up to 4.2.98 have been tested via the kde-redhat
repo, bugs filed and fixed. I'm one of them who run always the latest
and greatest from kde-redhat.
I am one of those who test kde packages both from kde-redhat and from rawhide.
In every case the packages appeared first in rawhide, later in unstable of
kde-redhat and only later on updates-testing, by the time the packages are
submitted to updates they have passed all those different levels of testing.
Do not forget also the update to emacs 23.1 made recently. Before that I
always tried the repos who had emacs compiled for the latest Fedora stable
version. I was glad when I saw the latest emacs available for F-11.
--
José Abílio
5398
days inactive
5401
days old
119 comments
36 participants
participants (36)
-
Adam Miller -
Adam Williamson -
Ben Boeckel -
Benny Amorsen -
Bill McGonigle -
Christopher Aillon -
Christopher Stone -
Colin Walters -
drago01 -
Emmanuel Seyman -
Guido Grazioli -
Jaroslav Reznik -
Jesse Keating -
Jesse Keating -
Josephine Tannhäuser -
Josh Boyer -
José Abílio Matos -
Juha Tuomala -
Kevin Kofler -
Mark Bidewell -
Mark McLoughlin -
Matej Cepl -
Matthew Woehlke -
Matthias Clasen -
Michael Scherer -
Orcan Ogetbil -
Orion Poplawski -
Rahul Sundaram -
Rex Dieter -
Richard Hughes -
Susi Lehtola -
Thomas Janssen -
Thomas Moschny -
Thorsten Leemhuis -
Tom Callaway -
Toshio Kuratomi