Are we ready to consider a brand new RPM version for F11, amidst all this mass-rebuild-for-strong-hash chaos and just days to go to development freeze?
We just put out first rpm 4.7.0 beta: http://lists.rpm.org/pipermail/rpm-announce/2009-February/000016.html. This is nothing like the 4.4.2.x -> 4.6.0 leap-of-faith upgrade last year but it's still non-trivial amount of changes to get the kind of memory use and performance improvements that 4.7.0 has, which is why it's not just 4.6.1.
The wording of Fedora Feature policy pretty explicitly singles out each RPM upgrade to be a Feature... I would like to hear a preliminary opinion on it: if everybody is going to be an outright "NO!" then I'm not going to waste my time with writing up a Feature page. If it's "maybe" or "it depends" then ok, will submit as a feature in time for tomorrows FESCo meeting.
So, should I bother with a RPM 4.7 feature page or not?
- Panu -
Panu Matilainen wrote:
Are we ready to consider a brand new RPM version for F11, amidst all this mass-rebuild-for-strong-hash chaos and just days to go to development freeze?
We just put out first rpm 4.7.0 beta: http://lists.rpm.org/pipermail/rpm-announce/2009-February/000016.html. This is nothing like the 4.4.2.x -> 4.6.0 leap-of-faith upgrade last year but it's still non-trivial amount of changes to get the kind of memory use and performance improvements that 4.7.0 has, which is why it's not just 4.6.1.
The wording of Fedora Feature policy pretty explicitly singles out each RPM upgrade to be a Feature... I would like to hear a preliminary opinion on it: if everybody is going to be an outright "NO!" then I'm not going to waste my time with writing up a Feature page. If it's "maybe" or "it depends" then ok, will submit as a feature in time for tomorrows FESCo meeting.
So, should I bother with a RPM 4.7 feature page or not?
- Panu -
F12 maybe?
On Thu, Feb 26, 2009 at 12:45 PM, Jon Ciesla limb@jcomserv.net wrote:
Panu Matilainen wrote:
Are we ready to consider a brand new RPM version for F11, amidst all this mass-rebuild-for-strong-hash chaos and just days to go to development freeze?
We just put out first rpm 4.7.0 beta: http://lists.rpm.org/pipermail/rpm-announce/2009-February/000016.html. This is nothing like the 4.4.2.x -> 4.6.0 leap-of-faith upgrade last year but it's still non-trivial amount of changes to get the kind of memory use and performance improvements that 4.7.0 has, which is why it's not just 4.6.1.
The wording of Fedora Feature policy pretty explicitly singles out each RPM upgrade to be a Feature... I would like to hear a preliminary opinion on it: if everybody is going to be an outright "NO!" then I'm not going to waste my time with writing up a Feature page. If it's "maybe" or "it depends" then ok, will submit as a feature in time for tomorrows FESCo meeting.
So, should I bother with a RPM 4.7 feature page or not?
- Panu -
F12 maybe?
It sure does offer some noticeable improvements, can't let F12 have everything!
I think end users will really appreciate the advertised lower memory footprint/speed improvements.
(They will also complain if it introduces instability, but lets assume that that will not be the case.)
Jon Ciesla limb@jcomserv.net writes:
Panu Matilainen wrote:
Are we ready to consider a brand new RPM version for F11, amidst all this mass-rebuild-for-strong-hash chaos and just days to go to development freeze?
F12 maybe?
Yeah, it seems like F12 material. Going with a beta version of critical infrastructure like RPM strikes me as sheer insanity. Or have we learned nothing from how badly the still-in-progress RPM update was mismanaged? These things need to be taken *slowly*.
regards, tom lane
On Thu, 2009-02-26 at 13:24 -0500, Tom Lane wrote:
Jon Ciesla limb@jcomserv.net writes:
Panu Matilainen wrote:
Are we ready to consider a brand new RPM version for F11, amidst all this mass-rebuild-for-strong-hash chaos and just days to go to development freeze?
F12 maybe?
Yeah, it seems like F12 material. Going with a beta version of critical infrastructure like RPM strikes me as sheer insanity. Or have we learned nothing from how badly the still-in-progress RPM update was mismanaged? These things need to be taken *slowly*.
I do not think the still-in-progress rpm update was mismanaged at all.
Back that claim up or don't make it.
-sv
seth vidal (skvidal@fedoraproject.org) said:
Yeah, it seems like F12 material. Going with a beta version of critical infrastructure like RPM strikes me as sheer insanity. Or have we learned nothing from how badly the still-in-progress RPM update was mismanaged? These things need to be taken *slowly*.
I do not think the still-in-progress rpm update was mismanaged at all.
Back that claim up or don't make it.
1) RC version shipped in Fedora 10 is incompatible with packages produced by the final version. Bad. 2) No solution for handling packages natively on F9. 3) Breaks handling of %config across upgrades
'Mismanaged' may be strong, but... it could have gone better.
Bill
seth vidal skvidal@fedoraproject.org writes:
On Thu, 2009-02-26 at 13:24 -0500, Tom Lane wrote:
Yeah, it seems like F12 material. Going with a beta version of critical infrastructure like RPM strikes me as sheer insanity. Or have we learned nothing from how badly the still-in-progress RPM update was mismanaged? These things need to be taken *slowly*.
I do not think the still-in-progress rpm update was mismanaged at all.
Back that claim up or don't make it.
The large number of complaints seen in this mailing list over the past week seem to me to be more than sufficient evidence that it was done without adequate preparation or lead time.
I'm personally still ticked off that I'm being forced to update my development workstation to F-10 immediately in order to continue doing useful work on rawhide packages. I don't have time for that right now. Since F-9 is still supported, isn't it a management failing to have allowed this to happen without a plan to make mock on F-9 work?
regards, tom lane
On Thu, 2009-02-26 at 13:57 -0500, Tom Lane wrote:
seth vidal skvidal@fedoraproject.org writes:
On Thu, 2009-02-26 at 13:24 -0500, Tom Lane wrote:
Yeah, it seems like F12 material. Going with a beta version of critical infrastructure like RPM strikes me as sheer insanity. Or have we learned nothing from how badly the still-in-progress RPM update was mismanaged? These things need to be taken *slowly*.
I do not think the still-in-progress rpm update was mismanaged at all.
Back that claim up or don't make it.
The large number of complaints seen in this mailing list over the past week seem to me to be more than sufficient evidence that it was done without adequate preparation or lead time.
I'm personally still ticked off that I'm being forced to update my development workstation to F-10 immediately in order to continue doing useful work on rawhide packages. I don't have time for that right now. Since F-9 is still supported, isn't it a management failing to have allowed this to happen without a plan to make mock on F-9 work?
Then you're wrong:
yum update rpm* yum*
that should be about it.
-sv
seth vidal skvidal@fedoraproject.org writes:
On Thu, 2009-02-26 at 13:57 -0500, Tom Lane wrote:
Since F-9 is still supported, isn't it a management failing to have allowed this to happen without a plan to make mock on F-9 work?
Then you're wrong: yum update rpm* yum* that should be about it.
Oh?
[tgl@rh2 ~]$ sudo yum update rpm* yum* ... Setting up Update Process No Packages marked for Update [tgl@rh2 ~]$
What was stated a couple days ago was that back-porting the hash changes into pre-F10 RPM versions was completely impractical. Has that been rethought?
regards, tom lane
On Thu, 2009-02-26 at 14:28 -0500, Tom Lane wrote:
seth vidal skvidal@fedoraproject.org writes:
On Thu, 2009-02-26 at 13:57 -0500, Tom Lane wrote:
Since F-9 is still supported, isn't it a management failing to have allowed this to happen without a plan to make mock on F-9 work?
Then you're wrong: yum update rpm* yum* that should be about it.
Oh?
[tgl@rh2 ~]$ sudo yum update rpm* yum* ... Setting up Update Process No Packages marked for Update [tgl@rh2 ~]$
What was stated a couple days ago was that back-porting the hash changes into pre-F10 RPM versions was completely impractical. Has that been rethought?
I'm sorry, I thought you had said F10. Not F9.
In F10 it's available.
And no - I don't think it is unreasonable to ask our developers and maintainers to be on something vaguely recent. And if they can't be for whatever reason it's not crazy for them to run it in a xen or kvm instance.
-sv
On Thursday 26 February 2009, seth vidal wrote:
On Thu, 2009-02-26 at 14:28 -0500, Tom Lane wrote:
seth vidal skvidal@fedoraproject.org writes:
On Thu, 2009-02-26 at 13:57 -0500, Tom Lane wrote:
Since F-9 is still supported, isn't it a management failing to have allowed this to happen without a plan to make mock on F-9 work?
Then you're wrong: yum update rpm* yum* that should be about it.
Oh?
[tgl@rh2 ~]$ sudo yum update rpm* yum* ... Setting up Update Process No Packages marked for Update [tgl@rh2 ~]$
What was stated a couple days ago was that back-porting the hash changes into pre-F10 RPM versions was completely impractical. Has that been rethought?
I'm sorry, I thought you had said F10. Not F9.
In F10 it's available.
FWIW, I just added F-10 and its updates repos temporarily to my yum config and imported the F-10 GPG key on F-9 and updated rpm* and yum*. mock is able to build for Rawhide again, dunno what kind of issues I'll run into when the next round of F-9 updates appears.
On Thursday, 26 February 2009 at 20:38, seth vidal wrote:
On Thu, 2009-02-26 at 14:28 -0500, Tom Lane wrote:
seth vidal skvidal@fedoraproject.org writes:
On Thu, 2009-02-26 at 13:57 -0500, Tom Lane wrote:
Since F-9 is still supported, isn't it a management failing to have allowed this to happen without a plan to make mock on F-9 work?
Then you're wrong: yum update rpm* yum* that should be about it.
Oh?
[tgl@rh2 ~]$ sudo yum update rpm* yum* ... Setting up Update Process No Packages marked for Update [tgl@rh2 ~]$
What was stated a couple days ago was that back-porting the hash changes into pre-F10 RPM versions was completely impractical. Has that been rethought?
I'm sorry, I thought you had said F10. Not F9.
In F10 it's available.
And no - I don't think it is unreasonable to ask our developers and maintainers to be on something vaguely recent.
I have F-10 on my netbook, but obviously it's too underpowered to build packages on comfortably. My main desktop is F-9, because I don't have time to upgrade it.
And if they can't be for whatever reason it's not crazy for them to run it in a xen
There's no Xen dom0 for F-9.
or kvm instance.
And KVM requires hardware support for virtualization. Any other suggestions?
Regards, R.
On Thu, 2009-02-26 at 22:18 +0100, Dominik 'Rathann' Mierzejewski wrote:
And KVM requires hardware support for virtualization. Any other suggestions?
Hate to be all populist, but - VirtualBox?
On Friday, 27 February 2009 at 03:23, Adam Williamson wrote:
On Thu, 2009-02-26 at 22:18 +0100, Dominik 'Rathann' Mierzejewski wrote:
And KVM requires hardware support for virtualization. Any other suggestions?
Hate to be all populist, but - VirtualBox?
VirtualBox is not in Fedora. ;)
RPMFusion package hasn't been reviewed yet. You (or anyone else) are welcome to step in and review it: https://bugzilla.rpmfusion.org/show_bug.cgi?id=285
Regards, R.
On Fri, 2009-02-27 at 16:24 +0100, Dominik 'Rathann' Mierzejewski wrote:
On Friday, 27 February 2009 at 03:23, Adam Williamson wrote:
On Thu, 2009-02-26 at 22:18 +0100, Dominik 'Rathann' Mierzejewski wrote:
And KVM requires hardware support for virtualization. Any other suggestions?
Hate to be all populist, but - VirtualBox?
VirtualBox is not in Fedora. ;)
RPMFusion package hasn't been reviewed yet. You (or anyone else) are welcome to step in and review it: https://bugzilla.rpmfusion.org/show_bug.cgi?id=285
Upstream package works, though.
I don't think I'm allowed to review packages, as I'm not yet a maintainer...
On Thu, 2009-02-26 at 14:38 -0500, seth vidal wrote:
I'm sorry, I thought you had said F10. Not F9.
In F10 it's available.
And no - I don't think it is unreasonable to ask our developers and maintainers to be on something vaguely recent. And if they can't be for whatever reason it's not crazy for them to run it in a xen or kvm instance.
It would be nice to have everyone who works on Rawhide, work *from* Rawhide. I suspect this would make people generally less keen to break stuff. =)
On Fr Februar 27 2009, Adam Williamson wrote:
It would be nice to have everyone who works on Rawhide, work *from* Rawhide. I suspect this would make people generally less keen to break stuff. =)
I hope that nobody does this, because the rpm packages for Rawhide are not signed and therefore should not be trusted.
Regards, Till
On Fri, 2009-02-27 at 13:24 +0100, Till Maas wrote:
On Fr Februar 27 2009, Adam Williamson wrote:
It would be nice to have everyone who works on Rawhide, work *from* Rawhide. I suspect this would make people generally less keen to break stuff. =)
I hope that nobody does this, because the rpm packages for Rawhide are not signed and therefore should not be trusted.
Huh. I didn't know that. Is there some reason why not? Is it the manual signing thing?
On Fri, 2009-02-27 at 12:14 -0800, Adam Williamson wrote:
On Fri, 2009-02-27 at 13:24 +0100, Till Maas wrote:
On Fr Februar 27 2009, Adam Williamson wrote:
It would be nice to have everyone who works on Rawhide, work *from* Rawhide. I suspect this would make people generally less keen to break stuff. =)
I hope that nobody does this, because the rpm packages for Rawhide are not signed and therefore should not be trusted.
Huh. I didn't know that. Is there some reason why not? Is it the manual signing thing?
It's not actually just that though, due to the amount of churn, open ACL lists, and so forth, I think you'd need to do a lot more before you could go using rawhide for day-to-day stuff. Of course people more trusting than myself will happily argue otherwise :)
Jon.
On Fri, 2009-02-27 at 16:01 -0500, Jon Masters wrote:
On Fri, 2009-02-27 at 12:14 -0800, Adam Williamson wrote:
On Fri, 2009-02-27 at 13:24 +0100, Till Maas wrote:
On Fr Februar 27 2009, Adam Williamson wrote:
It would be nice to have everyone who works on Rawhide, work *from* Rawhide. I suspect this would make people generally less keen to break stuff. =)
I hope that nobody does this, because the rpm packages for Rawhide are not signed and therefore should not be trusted.
Huh. I didn't know that. Is there some reason why not? Is it the manual signing thing?
It's not actually just that though, due to the amount of churn, open ACL lists, and so forth, I think you'd need to do a lot more before you could go using rawhide for day-to-day stuff. Of course people more trusting than myself will happily argue otherwise :)
Hmm. As far as I can see, signing Rawhide packages would still have value, in that it would prove that the package was created either by an approved maintainer of that package or by a Proven Packager, and was properly built through the official build system (it should, anyway, if the signing process is properly situated at the end of the above process and can't be accessed in any other way).
That would be a useful thing to provide, I'd think.
On Fri, 2009-02-27 at 13:21 -0800, Adam Williamson wrote:
On Fri, 2009-02-27 at 16:01 -0500, Jon Masters wrote:
On Fri, 2009-02-27 at 12:14 -0800, Adam Williamson wrote:
On Fri, 2009-02-27 at 13:24 +0100, Till Maas wrote:
On Fr Februar 27 2009, Adam Williamson wrote:
It would be nice to have everyone who works on Rawhide, work *from* Rawhide. I suspect this would make people generally less keen to break stuff. =)
I hope that nobody does this, because the rpm packages for Rawhide are not signed and therefore should not be trusted.
Huh. I didn't know that. Is there some reason why not? Is it the manual signing thing?
It's not actually just that though, due to the amount of churn, open ACL lists, and so forth, I think you'd need to do a lot more before you could go using rawhide for day-to-day stuff. Of course people more trusting than myself will happily argue otherwise :)
Hmm. As far as I can see, signing Rawhide packages would still have value, in that it would prove that the package was created either by an approved maintainer of that package or by a Proven Packager, and was properly built through the official build system (it should, anyway, if the signing process is properly situated at the end of the above process and can't be accessed in any other way).
Yeah, still doesn't protect against the guy who introduces a new package today that includes an updated configuration for my VPN client, or my email client, or a host of other stuff I might be using and rely upon.
IMHO it's not the place of the development branch of a distribution to provide the level of protection from such things. This is why I run my tests mostly on old hardware or on virtual machines - I copy stuff into the virtual machine, have only toy passwords on it, etc. It's not a perfect protection, but I view it as a reasonable precaution against "kitten consumption" or even malicious attempts to harm Fedora.
Jon.
On Fri, 2009-02-27 at 16:30 -0500, Jon Masters wrote:
Hmm. As far as I can see, signing Rawhide packages would still have value, in that it would prove that the package was created either by an approved maintainer of that package or by a Proven Packager, and was properly built through the official build system (it should, anyway, if the signing process is properly situated at the end of the above process and can't be accessed in any other way).
Yeah, still doesn't protect against the guy who introduces a new package today that includes an updated configuration for my VPN client, or my email client, or a host of other stuff I might be using and rely upon.
Sure. I didn't say it does. That doesn't make it useless. :)
(On a practical level, neither do F9 or F10, since maintainers can at present push packages directly to the official updates repository with no oversight, AFAIK).
On Fri, Feb 27, 2009 at 01:47:10PM -0800, Adam Williamson wrote:
On Fri, 2009-02-27 at 16:30 -0500, Jon Masters wrote:
Hmm. As far as I can see, signing Rawhide packages would still have value, in that it would prove that the package was created either by an approved maintainer of that package or by a Proven Packager, and was properly built through the official build system (it should, anyway, if the signing process is properly situated at the end of the above process and can't be accessed in any other way).
Yeah, still doesn't protect against the guy who introduces a new package today that includes an updated configuration for my VPN client, or my email client, or a host of other stuff I might be using and rely upon.
Sure. I didn't say it does. That doesn't make it useless. :)
(On a practical level, neither do F9 or F10, since maintainers can at present push packages directly to the official updates repository with no oversight, AFAIK).
I could just stop pushing updates if it would make everyone feel safer.
josh
On Fri, 2009-02-27 at 13:47 -0800, Adam Williamson wrote:
On Fri, 2009-02-27 at 16:30 -0500, Jon Masters wrote:
Yeah, still doesn't protect against the guy who introduces a new package today that includes an updated configuration for my VPN client, or my email client, or a host of other stuff I might be using and rely upon.
Sure. I didn't say it does. That doesn't make it useless. :)
(On a practical level, neither do F9 or F10, since maintainers can at present push packages directly to the official updates repository with no oversight, AFAIK).
But the stigma caused by destabilizing a stable release is just that much worse.
On Fri, 2009-02-27 at 17:01 -0500, Ignacio Vazquez-Abrams wrote:
On Fri, 2009-02-27 at 13:47 -0800, Adam Williamson wrote:
On Fri, 2009-02-27 at 16:30 -0500, Jon Masters wrote:
Yeah, still doesn't protect against the guy who introduces a new package today that includes an updated configuration for my VPN client, or my email client, or a host of other stuff I might be using and rely upon.
Sure. I didn't say it does. That doesn't make it useless. :)
(On a practical level, neither do F9 or F10, since maintainers can at present push packages directly to the official updates repository with no oversight, AFAIK).
But the stigma caused by destabilizing a stable release is just that much worse.
That's what I'm trying to fix. ;)
Adam Williamson wrote:
On Fri, 2009-02-27 at 17:01 -0500, Ignacio Vazquez-Abrams wrote:
But the stigma caused by destabilizing a stable release is just that much worse.
That's what I'm trying to fix. ;)
Well, I can easily push out a broken kdelibs to F-9 if you want that. ^^ Oh, is that not what you mean? ;-)
Kevin Kofler
On Thu, 2009-02-26 at 18:20 -0800, Adam Williamson wrote:
On Thu, 2009-02-26 at 14:38 -0500, seth vidal wrote:
I'm sorry, I thought you had said F10. Not F9.
In F10 it's available.
And no - I don't think it is unreasonable to ask our developers and maintainers to be on something vaguely recent. And if they can't be for whatever reason it's not crazy for them to run it in a xen or kvm instance.
It would be nice to have everyone who works on Rawhide, work *from* Rawhide. I suspect this would make people generally less keen to break stuff. =)
That's precisely why it's not practical to use Rawhide as a day-to-day platform. I know others will disagree and that's fine, but I long since switched back to a stable Fedora 9/10 setup. It's tough enough ever getting a rawhide that will install, let alone not break randomly.
KVM is great at letting one poke safely at stuff.
Jon.
On Fri, 2009-02-27 at 09:54 -0500, Jon Masters wrote:
It would be nice to have everyone who works on Rawhide, work *from* Rawhide. I suspect this would make people generally less keen to break stuff. =)
That's precisely why it's not practical to use Rawhide as a day-to-day platform. I know others will disagree and that's fine, but I long since switched back to a stable Fedora 9/10 setup. It's tough enough ever getting a rawhide that will install, let alone not break randomly.
Chicken and egg situation. Someone has to take the leap. Eventually, once enough developers are on Rawhide, there'll be a culture where people generally don't break things too egregiously, and are immediately complained-at if they do, workarounds become known, fixes are made quickly. But anyhoo, I have more developed thoughts along these lines coming in future.
KVM is great at letting one poke safely at stuff.
Sure, but nothing beats hardware. =)
On Fri, 2009-02-27 at 12:09 -0800, Adam Williamson wrote:
On Fri, 2009-02-27 at 09:54 -0500, Jon Masters wrote:
It would be nice to have everyone who works on Rawhide, work *from* Rawhide. I suspect this would make people generally less keen to break stuff. =)
That's precisely why it's not practical to use Rawhide as a day-to-day platform. I know others will disagree and that's fine, but I long since switched back to a stable Fedora 9/10 setup. It's tough enough ever getting a rawhide that will install, let alone not break randomly.
Chicken and egg situation. Someone has to take the leap.
Sure. I'll let someone who's not using a VPN, email, or anything involving passwords and tokens they care about do that. Meanwhile, I'll use something that's got signed packages for my daily stuff.
Eventually, once enough developers are on Rawhide, there'll be a culture where people generally don't break things too egregiously, and are immediately complained-at if they do, workarounds become known, fixes are made quickly. But anyhoo, I have more developed thoughts along these lines coming in future.
I go through phases of thinking this, but then I wonder how that gels with having the ability to be the playground of the latest and greatest technology, which is when I realize that the two are incompatible.
KVM is great at letting one poke safely at stuff.
Sure, but nothing beats hardware. =)
I disagree. Only time that even makes a difference is if you're using some specific gadget you can't pass through, or actually have some specific hardware you need to test - granted, actual testing should happen outside of VMs, but for much of userland stuff, it makes absolutely no difference. Even sound passthrough works now :P
Jon.
On Fri, 2009-02-27 at 15:57 -0500, Jon Masters wrote:
Chicken and egg situation. Someone has to take the leap.
Sure. I'll let someone who's not using a VPN, email, or anything involving passwords and tokens they care about do that. Meanwhile, I'll use something that's got signed packages for my daily stuff.
I replied about the signed packages thing in the other thread fork, please don't cross-pollute. :)
Eventually, once enough developers are on Rawhide, there'll be a culture where people generally don't break things too egregiously, and are immediately complained-at if they do, workarounds become known, fixes are made quickly. But anyhoo, I have more developed thoughts along these lines coming in future.
I go through phases of thinking this, but then I wonder how that gels with having the ability to be the playground of the latest and greatest technology, which is when I realize that the two are incompatible.
It's not, really. Fedora's is the only development branch which is so neglected, no other distro's is. To give the example I'm most familiar with, Mandriva's development branch has, this cycle, gone through a complete rebuild, Python 2.5 -> 2.6 migration, Tcl 8.5 -> 8.6 migration, X server 1.4 -> 1.6 (git snapshot then final release) migration, and a few other major changes. Most developers run it, as do quite a lot of testers, and it generally works. (While the Python 2.6 rebuild was going on, if you tried to upgrade, you'd see about four hundred errors. This was a fairly good clue that you should wait until the rebuild was complete before updating. Most people are able to handle this level of cogitation.)
I ran it on my production system for four years without it causing me any unavoidable problems.
So far I've been running Rawhide for a few weeks, similarly without any unavoidable problems. Early days, but I suspect Rawhide's reputation for kitten consumption to be somewhat inflated. I certainly don't think it's impossible to have a situation where we can work on Exciting New Stuff but still have a development branch which mostly works for most of the people most of the time.
KVM is great at letting one poke safely at stuff.
Sure, but nothing beats hardware. =)
I disagree. Only time that even makes a difference is if you're using some specific gadget you can't pass through, or actually have some specific hardware you need to test - granted, actual testing should happen outside of VMs, but for much of userland stuff, it makes absolutely no difference. Even sound passthrough works now :P
Sure, works, but you're not really testing the underlying hardware. We need to know if Rawhide changes are causing problems for video cards, sound cards, network adapters and so on.
On Fri, 2009-02-27 at 13:18 -0800, Adam Williamson wrote:
It's not, really. Fedora's is the only development branch which is so neglected, no other distro's is. To give the example I'm most familiar with, Mandriva's development branch has, this cycle, gone through a complete rebuild, Python 2.5 -> 2.6 migration, Tcl 8.5 -> 8.6 migration, X server 1.4 -> 1.6 (git snapshot then final release) migration, and a few other major changes. Most developers run it, as do quite a lot of testers, and it generally works. (While the Python 2.6 rebuild was going on, if you tried to upgrade, you'd see about four hundred errors. This was a fairly good clue that you should wait until the rebuild was complete before updating. Most people are able to handle this level of cogitation.)
To be fair - no other distro revs as quickly or as much as fedora does, either. We tend to get new things first. That's one of Fedora's goals.
So, saying that other distros have an easier development branch is really just evidence that fedora is doing what fedora does, move quickly.
-sv
On Fri, 2009-02-27 at 16:22 -0500, seth vidal wrote:
To be fair - no other distro revs as quickly or as much as fedora does, either. We tend to get new things first. That's one of Fedora's goals.
Well, not always, there are counter-examples. OK, those are broadly exceptions and Fedora probably does, overall, do more newer stuff faster (e.g. it went to X server 1.5 a lot faster than MDV, for one), but I don't think it's such a huge difference that it makes it impossible to have a basically usable dev branch. Hell, X is *usable* as long as vesa works. I'm talking about 'usable', not 'perfect', here. Stuff still *breaks*, in other dev branches. The point is they have a base of users who seem perfectly able to keep using them despite the breakages, and a wide base of developers running the dev branches.
So, saying that other distros have an easier development branch is really just evidence that fedora is doing what fedora does, move quickly.
I'm not sure that's actually the case. :) I think it's mostly a case of vicious and virtuous circles: Fedora has a dev branch that everyone believes is hard, so no-one uses it, so it tends to get broken a bit more often, so everyone believes it's hard, so...
By comparison, if you have a dev branch with a somewhat lower barrier of entry, more people use it, the developers who use it tend to fix stuff quickly when it gets broken (dog food principle), the wider user base means the word gets out quickly when something's broken and you can avoid or work around the breakage, so the dev branch gets a reputation for being usable, so more people use it, so...
I've been running Rawhide for a few weeks now, and haven't had any major problems. Granted, small sample size and restricted duration, but still.
Adam Williamson awilliam@redhat.com wrote:
[...]
I've been running Rawhide for a few weeks now, and haven't had any major problems. Granted, small sample size and restricted duration, but still.
I'm running rawhide on this machine since July (and a year or so on its predecessor). Yes, there has been breakage, even serious ones (keyboard only English, which is somewhat unconfortable if the keys are labeled for Spanish; OOo crash when trying to "Save as..." or "Export"; currently xemacs segfaults due to not finding fonts; ...). All can be worked around, and it is not too bad for day-to-day use.
So add me to the sample.
On Friday, February 27 2009, seth vidal said:
On Fri, 2009-02-27 at 13:18 -0800, Adam Williamson wrote:
It's not, really. Fedora's is the only development branch which is so neglected, no other distro's is. To give the example I'm most familiar with, Mandriva's development branch has, this cycle, gone through a complete rebuild, Python 2.5 -> 2.6 migration, Tcl 8.5 -> 8.6 migration, X server 1.4 -> 1.6 (git snapshot then final release) migration, and a few other major changes. Most developers run it, as do quite a lot of testers, and it generally works. (While the Python 2.6 rebuild was going on, if you tried to upgrade, you'd see about four hundred errors. This was a fairly good clue that you should wait until the rebuild was complete before updating. Most people are able to handle this level of cogitation.)
To be fair - no other distro revs as quickly or as much as fedora does, either. We tend to get new things first. That's one of Fedora's goals.
So, saying that other distros have an easier development branch is really just evidence that fedora is doing what fedora does, move quickly.
That said, I've been running rawhide on basically all of my boxes all the time without a need for a reinstall[1] for a decade later this year! :-)
Jeremy
[1] I tend to do fresh installs when I get new hardware but that's about the only time
On Fri, 2009-02-27 at 16:39 -0500, Jeremy Katz wrote:
That said, I've been running rawhide on basically all of my boxes all the time without a need for a reinstall[1] for a decade later this year! :-)
and the counter example is trying to run rawhide, have a day without email working. Have a day without the system booting, have a day without the wireless working, so on and so forth. Those days add up quickly when it's your critical functionality that breaks.
Making it harder to make those things break just means we wind up with rawhide, and rawerhide where the real changes are made, and the whole process repeats itself.
Sure, I'd love more people to use rawhide, and I'd love rawhide to break less often, but you're not going to win any favors by convincing developers to use rawhide and then not hear from them for a few days because all their communication software just broke.
On Fri, 2009-02-27 at 14:19 -0800, Jesse Keating wrote:
Making it harder to make those things break just means we wind up with rawhide, and rawerhide where the real changes are made, and the whole process repeats itself.
I think what could help a lot in making rawhide more usable day-to-day, would be if we had some way to publish 'raw stuff' in easily installable, packaged form for others to try out without forcing it immediately onto the wider rawhide community. Like PPAs...
That would allow us to develop and test new features with rawhide, but only merge them into rawhide when they are stable enough.
Matthias
On Fri, 2009-02-27 at 17:31 -0500, Matthias Clasen wrote:
On Fri, 2009-02-27 at 14:19 -0800, Jesse Keating wrote:
Making it harder to make those things break just means we wind up with rawhide, and rawerhide where the real changes are made, and the whole process repeats itself.
I think what could help a lot in making rawhide more usable day-to-day, would be if we had some way to publish 'raw stuff' in easily installable, packaged form for others to try out without forcing it immediately onto the wider rawhide community. Like PPAs...
That would allow us to develop and test new features with rawhide, but only merge them into rawhide when they are stable enough.
For the record I wouldn't like that. I hate PPAs. They're a hideous idea. So, that's not what I'm proposing =) I think in general you can push Exciting Stuff into the real development repository in a workable way.
Still - can't you send a build to Koji in a way which stops it actually being published to any repository? And doesn't that achieve what you're proposing?
Adam Williamson wrote:
Still - can't you send a build to Koji in a way which stops it actually being published to any repository? And doesn't that achieve what you're proposing?
Not really, because you can't use the packages to build other dependencies. Nor does it provide a repository for you, you have to find some webspace (or use fedorapeople.org, but the quota are pretty stringent there) and run createrepo by hand.
Kevin Kofler
On Fri, 2009-02-27 at 14:19 -0800, Jesse Keating wrote:
On Fri, 2009-02-27 at 16:39 -0500, Jeremy Katz wrote:
That said, I've been running rawhide on basically all of my boxes all the time without a need for a reinstall[1] for a decade later this year! :-)
and the counter example is trying to run rawhide, have a day without email working. Have a day without the system booting, have a day without the wireless working, so on and so forth. Those days add up quickly when it's your critical functionality that breaks.
Making it harder to make those things break just means we wind up with rawhide, and rawerhide where the real changes are made, and the whole process repeats itself.
Sure, I'd love more people to use rawhide, and I'd love rawhide to break less often, but you're not going to win any favors by convincing developers to use rawhide and then not hear from them for a few days because all their communication software just broke.
Email breaking is rather unlikely. I don't think there's many people left who keep all their actual email in a single client and cross their fingers that it won't break. Everyone uses some kind of remote server - mostly, let's face it, GMail these days (though die-hards like me are still running their own IMAP server, or using their ISP's, or something). In that case you can usually use any one of several dozen client apps to access your email, or the web interface.
How often does Rawhide really fail to boot? I mean, really? So bad that you can't fix it with a single kernel parameter or booting last week's kernel or something? This is part of the reputation inflation thing I'm wondering about. It just doesn't match my experience of dev branches.
This system's wireless. Been through a dozen kernel updates and it hasn't broken yet. Didn't break on Mandriva the whole time I was running that. And, hey, if the native driver breaks - you've always got ndiswrapper. Flexibility.
Look, obviously dev branches are always going to be less stable and break more often than stable releases, so obviously there's consequently people who really need to run stable releases. Some of these people are developers. I just remain unconvinced that it's really the case that everyone who could sensibly run Rawhide, already is. I continue to believe that we could have a lot more people - both developers and testers - running Rawhide on *some* system at least, and this would improve the quality of Rawhide and hence of releases.
On Fri, 2009-02-27 at 14:32 -0800, Adam Williamson wrote:
Email breaking is rather unlikely. I don't think there's many people left who keep all their actual email in a single client and cross their fingers that it won't break. Everyone uses some kind of remote server - mostly, let's face it, GMail these days (though die-hards like me are still running their own IMAP server, or using their ISP's, or something). In that case you can usually use any one of several dozen client apps to access your email, or the web interface.
The mail may still be accessible, but all the flagged mail and the search folders and such that help me do my job are lost when Evolution stops working (which is often). That makes a serious dent in my ability to get stuff done. Same when my calendar can't be brought up. I miss appointments etc...
How often does Rawhide really fail to boot? I mean, really? So bad that you can't fix it with a single kernel parameter or booting last week's kernel or something? This is part of the reputation inflation thing I'm wondering about. It just doesn't match my experience of dev branches.
Multiple times a release cycle. Particularly if we're going to be working on things like new initrd creation systems and new init systems.
This system's wireless. Been through a dozen kernel updates and it hasn't broken yet. Didn't break on Mandriva the whole time I was running that. And, hey, if the native driver breaks - you've always got ndiswrapper. Flexibility.
In previous rawhide cycles wireless has frequently broken, both driver and software to manage it. There were also days when the vpn software didn't work for various reasons.
Look, obviously dev branches are always going to be less stable and break more often than stable releases, so obviously there's consequently people who really need to run stable releases. Some of these people are developers. I just remain unconvinced that it's really the case that everyone who could sensibly run Rawhide, already is. I continue to believe that we could have a lot more people - both developers and testers - running Rawhide on *some* system at least, and this would improve the quality of Rawhide and hence of releases.
I don't disagree with that. I'm just not going to paint a picture where using rawhide as your main system won't lead to downtime and lost productivity. And as many people state, we're not going to find those important bugs until somebody does use it as their main system, either rawhide, a snapshot, or the final release.
I'm more convinced that we'll get far faster/better results by investing more time/effort/code into the automated testing system.
On Fri, 2009-02-27 at 15:28 -0800, Jesse Keating wrote:
On Fri, 2009-02-27 at 14:32 -0800, Adam Williamson wrote:
Email breaking is rather unlikely. I don't think there's many people left who keep all their actual email in a single client and cross their fingers that it won't break. Everyone uses some kind of remote server - mostly, let's face it, GMail these days (though die-hards like me are still running their own IMAP server, or using their ISP's, or something). In that case you can usually use any one of several dozen client apps to access your email, or the web interface.
The mail may still be accessible, but all the flagged mail and the search folders and such that help me do my job are lost when Evolution stops working (which is often). That makes a serious dent in my ability to get stuff done. Same when my calendar can't be brought up. I miss appointments etc...
Flags should be stored by IMAP, but OK for the other stuff. I'd like an easy personal calendaring server system. That'd be nice. You can sorta use Google Calendar, but then you're back to relying on Google to stay up and not be evil, which I don't rely on at all...le sigh.
How often does Rawhide really fail to boot? I mean, really? So bad that you can't fix it with a single kernel parameter or booting last week's kernel or something? This is part of the reputation inflation thing I'm wondering about. It just doesn't match my experience of dev branches.
Multiple times a release cycle. Particularly if we're going to be working on things like new initrd creation systems and new init systems.
See above - you can always boot last week's kernel. Breaking the initrd generation can only screw up kernels that get installed *after* the breakage. So just boot a kernel from before stuff got broken, then generate a working initrd for the newer kernel manually.
In previous rawhide cycles wireless has frequently broken, both driver and software to manage it. There were also days when the vpn software didn't work for various reasons.
Ok, then. But then, that's the sort of thing that having more people using Rawhide should lead to happening less often. I don't think there's really any intrinsic reason wireless drivers have to break very often in a dev branch.
(And again, you usually have the option of booting a known-good kernel in this case).
I don't disagree with that. I'm just not going to paint a picture where using rawhide as your main system won't lead to downtime and lost productivity. And as many people state, we're not going to find those important bugs until somebody does use it as their main system, either rawhide, a snapshot, or the final release.
I'm more convinced that we'll get far faster/better results by investing more time/effort/code into the automated testing system.
I think they're complementary. Automated testing is great, but it can never catch everything, it's probably not really going to get close. And automated testing should make Rawhide more reliable and hence help out with this side of things (having more real fleshy people use it and yell when stuff breaks). And there are people who can get involved in one side but not the other (as you can see I have a great talent for poking at difficult areas, but I couldn't write an automated test for *anything*...)
I don't see why there needs to be an opposition, really. And this whole idea about having more people run Rawhide doesn't involve any 'extra' coding.
Keep in mind there are plenty of non-IMAP users nowadays too... Gmail isn't very useful when you get 200+ emails a day, and not everyone is using some sort of IMAP server. In the end I don't think most Fedora developers will want to run on their personal computers (unless they have an extra lying around).
Regards,
On Friday 27 February 2009 04:00:33 pm Conrad Meyer wrote:
Keep in mind there are plenty of non-IMAP users nowadays too... Gmail isn't very useful when you get 200+ emails a day, and not everyone is using some sort of IMAP server. In the end I don't think most Fedora developers will want to run on their personal computers (unless they have an extra lying around).
Oops.
s/to run on/to run Rawhide on/
On Fri, 2009-02-27 at 16:10 -0800, Conrad Meyer wrote:
On Friday 27 February 2009 04:00:33 pm Conrad Meyer wrote:
Keep in mind there are plenty of non-IMAP users nowadays too... Gmail isn't very useful when you get 200+ emails a day, and not everyone is using some sort of IMAP server. In the end I don't think most Fedora developers will want to run on their personal computers (unless they have an extra lying around).
Oops.
s/to run on/to run Rawhide on/
Then why do you think other distributions don't have a problem with this?
I mean, that's a genuine, not a rhetorical question. What I'm proposing is not crazy pie-in-the-sky, there are other real distributions that have been around for a long time that *do* this. Most if not all developers run the development version of the distro. No-one seems particularly unhappy with this. I don't see many "oops, I can't help you because my email is broken" complaints. It just doesn't seem to be a problem.
(On the flipping email issue - I use Evolution. With an IMAP server. I think it's been broken, oh, maybe twice in the last five years. I had to use Thunderbird for a couple of days. I survived. And yes, Mandriva development branch goes through GNOME's unstable releases, so I ran Evo 2.19, 2.21, 2.23, 2.25 etc etc etc. It just doesn't totally break as much as people seem to be claiming, in my experience.)
On Friday 27 February 2009 05:25:25 pm Adam Williamson wrote:
On Fri, 2009-02-27 at 16:10 -0800, Conrad Meyer wrote:
On Friday 27 February 2009 04:00:33 pm Conrad Meyer wrote:
Keep in mind there are plenty of non-IMAP users nowadays too... Gmail isn't very useful when you get 200+ emails a day, and not everyone is using some sort of IMAP server. In the end I don't think most Fedora developers will want to run on their personal computers (unless they have an extra lying around).
Oops.
s/to run on/to run Rawhide on/
Then why do you think other distributions don't have a problem with this?
Other distributions don't treat their development branch as as much of a bleeding edge testing ground. As Jesse pointed out, if we tried to make rawhide usable, we'd end up creating a 'Rawerhide' that serves the same purpose as rawhide today. So how about you just pretend F-10 is 'less-raw hide' and work with that? I bet most Fedora devs do.
Regards,
On Fri, 2009-02-27 at 17:33 -0800, Conrad Meyer wrote:
Other distributions don't treat their development branch as as much of a bleeding edge testing ground. As Jesse pointed out, if we tried to make rawhide usable, we'd end up creating a 'Rawerhide' that serves the same purpose as rawhide today. So how about you just pretend F-10 is 'less-raw hide' and work with that? I bet most Fedora devs do.
Because it has a knock-on effect on quality. This is the ultimate point here.
If everyone just figures, hey, it's Rawhide, what the hell, we end up with a broken Rawhide. Then when we hit alpha stage we're scrambling just to fix Rawhide and make it vaguely work. We're playing catch-up throughout the entire pre-release cycle, fixing stuff that could have been caught much earlier if more people were actually using the code.
Look - lots of Fedora people are developers, yes? Do the X.org developers run X.org 7.4, do you think? Do you run the last stable release of any application you write, or do you use the latest code you just pushed into git? In most cases, the answer is that you use the latest code. Why? So you know when you *broke* something, and you can fix it. You wouldn't run an app by writing the code, throwing it at a compiler, seeing that the build worked and throwing it into git, then never running it but just running the last stable release, and hoping the code you just threw at the development branch worked. At least, I'd really *hope* you don't.
Why should the distro be any different? Why do you think it's a good idea to develop something without using it?
On Friday 27 February 2009 05:51:24 pm Adam Williamson wrote:
On Fri, 2009-02-27 at 17:33 -0800, Conrad Meyer wrote:
Other distributions don't treat their development branch as as much of a bleeding edge testing ground. As Jesse pointed out, if we tried to make rawhide usable, we'd end up creating a 'Rawerhide' that serves the same purpose as rawhide today. So how about you just pretend F-10 is 'less-raw hide' and work with that? I bet most Fedora devs do.
Because it has a knock-on effect on quality. This is the ultimate point here.
If everyone just figures, hey, it's Rawhide, what the hell, we end up with a broken Rawhide. Then when we hit alpha stage we're scrambling just to fix Rawhide and make it vaguely work. We're playing catch-up throughout the entire pre-release cycle, fixing stuff that could have been caught much earlier if more people were actually using the code.
Look - lots of Fedora people are developers, yes? Do the X.org developers run X.org 7.4, do you think? Do you run the last stable release of any application you write, or do you use the latest code you just pushed into git? In most cases, the answer is that you use the latest code. Why? So you know when you *broke* something, and you can fix it. You wouldn't run an app by writing the code, throwing it at a compiler, seeing that the build worked and throwing it into git, then never running it but just running the last stable release, and hoping the code you just threw at the development branch worked. At least, I'd really *hope* you don't.
Why should the distro be any different? Why do you think it's a good idea to develop something without using it?
You go ahead and run Rawhide, then. You can be our early warning system. I run Rawhide versions of my own packages when I need them, sure -- but I when I don't need the rawhide version of something, I don't run it. You can promote rawhide usage all you like, but the best you'll get is a "developers *should* use rawhide" -- and developers will continue doing whatever they like, just as they did before you tried to promote running rawhide.
Please don't hijack threads like this in the future. (Also: please excuse any typing errors in my emails lately, I'm on a laptop temporarily and its right shift key is broken.)
Regards,
On Fri, 2009-02-27 at 18:05 -0800, Conrad Meyer wrote:
Why should the distro be any different? Why do you think it's a good idea to develop something without using it?
You go ahead and run Rawhide, then. You can be our early warning system. I run Rawhide versions of my own packages when I need them, sure -- but I when I don't need the rawhide version of something, I don't run it. You can promote rawhide usage all you like, but the best you'll get is a "developers *should* use rawhide" -- and developers will continue doing whatever they like, just as they did before you tried to promote running rawhide.
Running Rawhide versions of specific packages isn't the same, because you don't get the whole environment. There may be some other change elsewhere in Rawhide which interacts with your package, which you'd only notice if you ran Rawhide.
The point is that Rawhide is the current development version of the product we're all working to provide. We need to know what the hell is actually going on in the current state-of-the-art.
I like your massively negative attitude - "sure, you can TRY and change things, but it'll never work!" - but I'm afraid I'm going to ignore it. Having more people run Rawhide would, IMO, contribute to the quality of the distribution, which is what I'm here to try and improve, so I damn well will keep evangelizing it.
Please don't hijack threads like this in the future. (Also: please excuse any typing errors in my emails lately, I'm on a laptop temporarily and its right shift key is broken.)
I posted a short aside, and it mushroomed from there. If people hadn't taken me up on it, it wouldn't have sprawled into this giant discussion. I wanted to bring this to the list at a slightly later point and in its own thread, which I tried to explain earlier, but people kept discussing, so I kept replying.
Adam Williamson wrote:
Look - lots of Fedora people are developers, yes? Do the X.org Do you run the last stable release of any application you write, or do you use the latest code you just pushed into git? In most cases, the answer is that you use the latest code.
Well, I commonly run the stable versions of applications I maintain, sometimes not even the latest. Call me crazy if you wish, but I'd rather spend my time on fixing things than on working around the breakages to do what I need to do.
Kevin Kofler
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Kevin Kofler wrote:
Adam Williamson wrote:
Look - lots of Fedora people are developers, yes? Do the X.org Do you run the last stable release of any application you write, or do you use the latest code you just pushed into git? In most cases, the answer is that you use the latest code.
Well, I commonly run the stable versions of applications I maintain, sometimes not even the latest. Call me crazy if you wish, but I'd rather spend my time on fixing things than on working around the breakages to do what I need to do.
Kevin Kofler
Running rawhide would encourage maintainers to fix the breakage instead of encouraging users to "work around it". We have to fix it at some point, why not earlier rather than later?
- --Ben
Ben Boeckel wrote:
Running rawhide would encourage maintainers to fix the breakage instead of encouraging users to "work around it". We have to fix it at some point, why not earlier rather than later?
Because I can only really fix one bug at a time and I really don't want to be fighting to work around all the other ones while I'm trying to produce a build fixing that one bug.
Plus, I'd also have to work around bugs in packages I don't maintain, surely you don't expect me to fix kernel bugs, for example... (I don't even have commit access to the kernel.)
Kevin Kofler
On Fri, 2009-02-27 at 17:51 -0800, Adam Williamson wrote:
Look - lots of Fedora people are developers, yes? Do the X.org developers run X.org 7.4, do you think? Do you run the last stable release of any application you write, or do you use the latest code you just pushed into git? In most cases, the answer is that you use the latest code. Why? So you know when you *broke* something, and you can fix it. You wouldn't run an app by writing the code, throwing it at a compiler, seeing that the build worked and throwing it into git, then never running it but just running the last stable release, and hoping the code you just threw at the development branch worked. At least, I'd really *hope* you don't.
Why should the distro be any different? Why do you think it's a good idea to develop something without using it?
Small point here. X developers may run their upstream latest X, but that's because they want just the unstable X, nothing else unstable. If they were doing it on rawhide and things crashed, is it because of the new X code, or some other breakage in rawhide? What if they can't even test X bring up because glibc is busted? It's quite easy to say you're going to run the latest and greatest for your little world of influence and your package set, but to properly develop it you have to have a stable platform to start with, to know if the changes you're making and the effects you're seeing are from your software vs something else entirely.
On Fri, 2009-02-27 at 18:17 -0800, Jesse Keating wrote:
Small point here. X developers may run their upstream latest X, but that's because they want just the unstable X, nothing else unstable. If they were doing it on rawhide and things crashed, is it because of the new X code, or some other breakage in rawhide? What if they can't even test X bring up because glibc is busted? It's quite easy to say you're going to run the latest and greatest for your little world of influence and your package set, but to properly develop it you have to have a stable platform to start with, to know if the changes you're making and the effects you're seeing are from your software vs something else entirely.
We're developing a distribution - Fedora. Fedora is our product, like X is the X developers' product. Fedora is "our little world of influence and our package set". Yes, that's a big task, but it's what we're here for. :)
I'm getting the sense a lot of people are thinking in terms of "well, I just work on this little piece, so I want to work on this little piece and not be bothered when some other piece breaks". But we're really all working on one *big* piece, here.
Adam Williamson awilliam@redhat.com writes:
We're developing a distribution - Fedora. Fedora is our product, like X is the X developers' product. Fedora is "our little world of influence and our package set". Yes, that's a big task, but it's what we're here for. :)
Are we? Personally I'm much nearer to being an X-developer; I spend some cycles on packaging stuff for Fedora, but that isn't, and won't become, my main occupation. I think you might find that most of the pool of people you're hoping to draw from likewise have expertise mostly in some particular area, and don't want to be bothered dealing with breakage in other areas.
Also, one doesn't necessarily want to be bothered with breakage that *is* connected to one's expertise. One of the reasons I was somewhat appalled to hear about KDE components starting to depend on mysql is that that destroys any prospect of using KDE (or at least those components of it) on my development workstation. mysql spends too much time broken or getting uninstalled/reinstalled/temporarily installed in some incompatible version. I can't afford to spend extra cycles babysitting some GUI components that are teetering atop it. I'm not much of a a KDE fan anyway, but there is now 0 chance that I'll ever become one, at least as long as I package mysql for Fedora.
regards, tom lane
On Fri, 2009-02-27 at 22:04 -0500, Tom Lane wrote:
Adam Williamson awilliam@redhat.com writes:
We're developing a distribution - Fedora. Fedora is our product, like X is the X developers' product. Fedora is "our little world of influence and our package set". Yes, that's a big task, but it's what we're here for. :)
Are we?
This being fedora-devel-list, I was sort of working on that assumption, yes.
Anyway, this is winding down, so I will leave it for a bit. Just a final thought - what I'm trying to do here is challenge the 'Rawhide is evil and you'd be crazy ever to touch it' perception, for a few reasons that I've touched upon. I expected considerable resistance to this at first, that's fine. But it's never going to change a bit unless it gets challenged.
Conrad Meyer wrote:
Keep in mind there are plenty of non-IMAP users nowadays too... Gmail isn't very useful when you get 200+ emails a day, and not everyone is using some sort of IMAP server. In the end I don't think most Fedora developers will want to run [Rawhide] on their personal computers (unless they have an extra lying around).
Heck, I'm still running F9 on this computer. ;-) My "extra" ("laptop64", a Core 2 Duo laptop) is running F10 (x86_64, thus the name, my main PC is an old 32-bit-only P4)...
I'm not too worried about the RPM/mock issues though, I can just send the builds to laptop64 or (if I don't need any non-Fedora deps) to Koji.
Kevin Kofler
On Fri, 2009-02-27 at 15:43 -0800, Adam Williamson wrote:
Multiple times a release cycle. Particularly if we're going to be working on things like new initrd creation systems and new init systems.
See above - you can always boot last week's kernel. Breaking the initrd generation can only screw up kernels that get installed *after* the breakage. So just boot a kernel from before stuff got broken, then generate a working initrd for the newer kernel manually.
that doesn't help when its the init system itself breaking, or anything else in the bootpath that is outside of the initrd.
In previous rawhide cycles wireless has frequently broken, both driver and software to manage it. There were also days when the vpn software didn't work for various reasons.
Ok, then. But then, that's the sort of thing that having more people using Rawhide should lead to happening less often. I don't think there's really any intrinsic reason wireless drivers have to break very often in a dev branch.
(And again, you usually have the option of booting a known-good kernel in this case).
No, it means that somebody will notice and complain a tad bit earlier, but they are still going to be broken. You're still relying on your userbase as the early warning detection system.
I don't disagree with that. I'm just not going to paint a picture where using rawhide as your main system won't lead to downtime and lost productivity. And as many people state, we're not going to find those important bugs until somebody does use it as their main system, either rawhide, a snapshot, or the final release.
I'm more convinced that we'll get far faster/better results by investing more time/effort/code into the automated testing system.
I think they're complementary. Automated testing is great, but it can never catch everything, it's probably not really going to get close. And automated testing should make Rawhide more reliable and hence help out with this side of things (having more real fleshy people use it and yell when stuff breaks). And there are people who can get involved in one side but not the other (as you can see I have a great talent for poking at difficult areas, but I couldn't write an automated test for *anything*...)
I don't see why there needs to be an opposition, really. And this whole idea about having more people run Rawhide doesn't involve any 'extra' coding.
On Fri, 2009-02-27 at 16:02 -0800, Jesse Keating wrote:
but they are still going to be broken. You're still relying on your userbase as the early warning detection system.
Yes! Exactly! That's what I want! An early-warning detection system user base. Thank you for getting the point. :)
If you don't have people finding problems, who will? As I said, automatic testing can never find everything, it's just not possible.
On Fri, 2009-02-27 at 17:28 -0800, Adam Williamson wrote:
Yes! Exactly! That's what I want! An early-warning detection system user base. Thank you for getting the point. :)
If you don't have people finding problems, who will? As I said, automatic testing can never find everything, it's just not possible.
The problem is that you want to use people to detect the breakage, but the people you want aren't really willing to deal with breakage. Do you see a stalemate here?
On Fri, 2009-02-27 at 18:14 -0800, Jesse Keating wrote:
On Fri, 2009-02-27 at 17:28 -0800, Adam Williamson wrote:
Yes! Exactly! That's what I want! An early-warning detection system user base. Thank you for getting the point. :)
If you don't have people finding problems, who will? As I said, automatic testing can never find everything, it's just not possible.
The problem is that you want to use people to detect the breakage, but the people you want aren't really willing to deal with breakage. Do you see a stalemate here?
I'm trying. :) I know there's a lot more than five people reading this list, so maybe some of them will see my point here.
I know various other people I've spoken to about this have been firmly on my side, and I've been urged by more than one person to (I quote) 'JFDI' in relation to trying to get more people to use Rawhide.
On Fri, Feb 27, 2009 at 06:19:16PM -0800, Adam Williamson wrote:
On Fri, 2009-02-27 at 18:14 -0800, Jesse Keating wrote:
On Fri, 2009-02-27 at 17:28 -0800, Adam Williamson wrote:
Yes! Exactly! That's what I want! An early-warning detection system user base. Thank you for getting the point. :)
If you don't have people finding problems, who will? As I said, automatic testing can never find everything, it's just not possible.
The problem is that you want to use people to detect the breakage, but the people you want aren't really willing to deal with breakage. Do you see a stalemate here?
I'm trying. :) I know there's a lot more than five people reading this list, so maybe some of them will see my point here.
I know various other people I've spoken to about this have been firmly on my side, and I've been urged by more than one person to (I quote) 'JFDI' in relation to trying to get more people to use Rawhide.
So what exactly are you going to JFD? So far evangalizing isn't getting you very far. Are you going to:
1) Do something from a test/QA standpoint to help people know when rawhide is somewhat stable?
2) Do something to help flag badly broken rawhide composes so people don't waste valuable time updating to known broken stuff?
3) Anything other than invite people to join in the pain that can be rawhide without actually doing something to lessen that pain and make the distro _better_?
josh
On Fri, 2009-02-27 at 21:24 -0500, Josh Boyer wrote:
So what exactly are you going to JFD? So far evangalizing isn't getting you very far.
He says, boldly. You haven't given it much of a chance, have you? This has been going, what, a couple of hours? I don't give up that fast, I'm afraid.
Are you going to:
- Do something from a test/QA standpoint to help people know when rawhide is somewhat stable?
Yes, I'm going to run it and complain loudly when bits of it break. I'll also fix the ones I can, where needed.
- Do something to help flag badly broken rawhide composes so people don't waste valuable time updating to known broken stuff?
See above. I'm going to run Rawhide and when it's screwed, for me, I'll say so. This will be useful to anyone else who may be affected by the same issues as me. When you have lots of people running the code, you have lots of people shouting when it's broken. So, it's flagged.
- Anything other than invite people to join in the pain that can be rawhide without actually doing something to lessen that pain and make the distro _better_?
I've been saying the whole time that my whole point is that if more people use Rawhide, including the people who are actually *making* Rawhide, the pain will be lessened.
Look, I used to maintain a few hundred packages for MDV, and I made damn sure not to break them egregiously. I'm happy to package stuff for Fedora too, where there's a need (so far I haven't come across anything I use that's under-maintained or orphaned, or not packaged, though). I'd be happy to work on fixing bugs in things where I could, although I'm not a coder. But that's not what I've been asked to do. I've been asked to be a community guy. My *job* is basically to evangelize. I'm not here to write code, believe it or not. :)
On Fri, Feb 27, 2009 at 21:24:08 -0500, Josh Boyer jwboyer@gmail.com wrote:
So what exactly are you going to JFD? So far evangalizing isn't getting you very far. Are you going to:
Do something from a test/QA standpoint to help people know when rawhide is somewhat stable?
Do something to help flag badly broken rawhide composes so people don't waste valuable time updating to known broken stuff?
Anything other than invite people to join in the pain that can be rawhide without actually doing something to lessen that pain and make the distro _better_?
4) Do something to get problems in rawhide fixed faster.
5) Provide some new reasons for people to want to run rawhide. (E.g. better access developers)
Adam Williamson wrote:
On Fri, 2009-02-27 at 18:14 -0800, Jesse Keating wrote:
On Fri, 2009-02-27 at 17:28 -0800, Adam Williamson wrote:
Yes! Exactly! That's what I want! An early-warning detection system user base. Thank you for getting the point. :)
If you don't have people finding problems, who will? As I said, automatic testing can never find everything, it's just not possible.
The problem is that you want to use people to detect the breakage, but the people you want aren't really willing to deal with breakage. Do you see a stalemate here?
I'm trying. :) I know there's a lot more than five people reading this list, so maybe some of them will see my point here.
I know various other people I've spoken to about this have been firmly on my side, and I've been urged by more than one person to (I quote) 'JFDI' in relation to trying to get more people to use Rawhide.
I see your point. But I don't think it's going to be a very popular religon here :-) In Fedora, we do have people building the distro. And that's their concentration. But we also have people building the individual components that make up the distribution. And that's their intended focus. We tell packagers that most changes should be going upstream because we are heavily focused on development of the code itself. We have a number of maintainers that are more than willing to give the packaging portion of their responsibilities to others so they can concentrate on the upstream coding portion.
And when it comes down to it, I think that the focus on upstream development is a core piece of Fedora. So I'd love to see some of your ideas mature a bit and find a way to make Fedora better. But I don't think that trying to get developers to run rawhide all the time so they can work on getting X not to crash, their wireless card to work, evolution not to be buggy, and other things for which they are not working frantically upstream is going to work.
It might be better to get people to run RawHide from beta on (and move that back to alpha at some point :-). Or determining what subset of Fedora-ans are primarily distro-focused instead of upstream focused and finding a way to tie them into the process of releasing packages. Or....
-Toshio
On Fri, 2009-02-27 at 19:46 -0800, Toshio Kuratomi wrote:
I'm trying. :) I know there's a lot more than five people reading this list, so maybe some of them will see my point here.
I know various other people I've spoken to about this have been firmly on my side, and I've been urged by more than one person to (I quote) 'JFDI' in relation to trying to get more people to use Rawhide.
I see your point. But I don't think it's going to be a very popular religon here :-) In Fedora, we do have people building the distro. And that's their concentration. But we also have people building the individual components that make up the distribution. And that's their intended focus.
And when it comes down to it, I think that the focus on upstream development is a core piece of Fedora. So I'd love to see some of your ideas mature a bit and find a way to make Fedora better. But I don't think that trying to get developers to run rawhide all the time so they can work on getting X not to crash, their wireless card to work, evolution not to be buggy, and other things for which they are not working frantically upstream is going to work.
That's worth replying to, actually, because you're right - I may well have fudged the terms 'developer' and 'maintainer' at some point in this thread, and I really shouldn't have done, because as you point out it's an important distinction here. I'm mostly concerned with maintainers, not developers. If your work is principally on upstream code, then it's not really a big deal whether you run Rawhide or not, though obviously in the wider goal you form part of the group of users who it would be *nice to have* testing Rawhide. It's mostly people whose work is in maintaining the packages that make up Fedora that I think it would be a really good idea to have running Rawhide.
Sorry if that was confusing people. I forgot that the developer / maintainer distinction is an important one here and on this list.
Adam Williamson wrote:
That's worth replying to, actually, because you're right - I may well have fudged the terms 'developer' and 'maintainer' at some point in this thread, and I really shouldn't have done, because as you point out it's an important distinction here. I'm mostly concerned with maintainers, not developers. If your work is principally on upstream code, then it's not really a big deal whether you run Rawhide or not, though obviously in the wider goal you form part of the group of users who it would be *nice to have* testing Rawhide. It's mostly people whose work is in maintaining the packages that make up Fedora that I think it would be a really good idea to have running Rawhide.
Sorry if that was confusing people. I forgot that the developer / maintainer distinction is an important one here and on this list.
It's also important to realize that in Fedora many of our packages are maintained by developers (one anecdote which kind of illustrates this happened a few weeks ago when behdad offered to let others maintain the packages he is the maintainer of so he can concentrate on his upstream work on them). So when you talk about getting the X package maintainers to run RawHide so they won't break stuff while letting the X developers work on their upstream code on a stable base you've got to realize that they're actually all upstream developers who happen to pull double duty by making the Fedora packages.
This isn't the case for all packages and packagers but a lot of the basic packages that, if they break people will think "raw hide is broken", are this way. kernel, xorg, gnome platform, etc. So you'll have to figure out if the people who aren't upstream developers form a significant base that can work with your ideas or how to adapt your ideas to the types of contributors that we have.
-Toshio
On Fri, 2009-02-27 at 20:25 -0800, Toshio Kuratomi wrote:
It's also important to realize that in Fedora many of our packages are maintained by developers (one anecdote which kind of illustrates this happened a few weeks ago when behdad offered to let others maintain the packages he is the maintainer of so he can concentrate on his upstream work on them). So when you talk about getting the X package maintainers to run RawHide so they won't break stuff while letting the X developers work on their upstream code on a stable base you've got to realize that they're actually all upstream developers who happen to pull double duty by making the Fedora packages.
This isn't the case for all packages and packagers but a lot of the basic packages that, if they break people will think "raw hide is broken", are this way. kernel, xorg, gnome platform, etc. So you'll have to figure out if the people who aren't upstream developers form a significant base that can work with your ideas or how to adapt your ideas to the types of contributors that we have.
Hope no-one's getting tired of this discussion, but I think it's interesting. :)
Yes, I do understand that. Two things:
a), fortunately, it's an idea that scales - even if we only have, say, five pure maintainers who currently aren't running Rawhide, and two of 'em switch, that's a benefit. I'm not looking for an overnight 100% conversion rate here...
b) I think it's important to recognize that packaging is a Big Job that's as important as hacking. There's nothing wrong with packagers and developers being the same people, but if you see packaging as basically an annoyance that gets in the way of your Real Work on upstream development, that might be a problem - if behdad was getting to feeling that way, it sounds like he did exactly the right thing in splitting the work up. To my way of thinking, if you're a maintainer, that's a responsibility that should be seen as equal in importance to upstream development.
On Fri, 2009-02-27 at 14:32 -0800, Adam Williamson wrote:
Email breaking is rather unlikely. I don't think there's many people left who keep all their actual email in a single client and cross their fingers that it won't break.
Wrong. I use evolution, a lot. I recently had to setup pine as a backup b/c evo was completely broken for a good portion of the run up to f10.
How often does Rawhide really fail to boot? I mean, really? So bad that you can't fix it with a single kernel parameter or booting last week's kernel or something? This is part of the reputation inflation thing I'm wondering about. It just doesn't match my experience of dev branches.
I'm confused.
In your first message you were saying that rawhide is worse than all other distro's development branches. Now you're saying rawhide isn't that bad at all?
-sv
On Fri, 2009-02-27 at 21:02 -0500, seth vidal wrote:
On Fri, 2009-02-27 at 14:32 -0800, Adam Williamson wrote:
Email breaking is rather unlikely. I don't think there's many people left who keep all their actual email in a single client and cross their fingers that it won't break.
Wrong. I use evolution, a lot. I recently had to setup pine as a backup b/c evo was completely broken for a good portion of the run up to f10.
So, you worked around the issue successfully. There you go. :)
But, why was Evo so broken? This seems odd. As I mentioned, my previous distro packages pre-releases of GNOME and Evolution, and I run Evolution. I certainly don't think Evolution was broken for a significant period around August-October last year. I feel sure I would've remembered.
Perhaps this is a case where, if there were more people running Rawhide - like, fr'instance, whoever packages Evolution - it would've got fixed faster...
I'm confused.
In your first message you were saying that rawhide is worse than all other distro's development branches. Now you're saying rawhide isn't that bad at all?
Fair point. I should make that clearer.
Broadly I think Rawhide has a much worse reputation than it necessarily deserves, but I also think it probably is *somewhat* more commonly broken than other distros. The objection that this is because Fedora is more bleeding-edge is probably partially valid, but I don't think it's the whole story.
I suspect Rawhide is not as bad as many people think it is, and I further suspect it could be even better if more people ran it. Is that clearer? :)
On Fri, 2009-02-27 at 18:18 -0800, Adam Williamson wrote:
So, you worked around the issue successfully. There you go. :)
I limped around it. To manage the amount of email I get I use lots of vfolders. Evo broke for vfolders and vfolders of vfolders.
to be clear, it is STILL broken.
But, why was Evo so broken? This seems odd. As I mentioned, my previous distro packages pre-releases of GNOME and Evolution, and I run Evolution. I certainly don't think Evolution was broken for a significant period around August-October last year. I feel sure I would've remembered.
Then clearly you don't really USE evolution.
Perhaps this is a case where, if there were more people running Rawhide
- like, fr'instance, whoever packages Evolution - it would've got fixed
faster...
No. It's broken upstream too.
I suspect Rawhide is not as bad as many people think it is, and I further suspect it could be even better if more people ran it. Is that clearer? :)
Not really.
I would like you to do this. Draft your thoughts for and about rawhide. Write them up in the wiki and then post a short summary of those thoughts to fedora-devel-list linking to the points in the wiki.
Try to be concise and brief.
Your emails are a bit scattered and I don't think you're improving the situation by your current plan of attack.
-sv
On Fri, 2009-02-27 at 18:18 -0800, Adam Williamson wrote:
But, why was Evo so broken? This seems odd. As I mentioned, my previous distro packages pre-releases of GNOME and Evolution, and I run Evolution. I certainly don't think Evolution was broken for a significant period around August-October last year. I feel sure I would've remembered.
Broken for a day is a 'significant period'.
Perhaps this is a case where, if there were more people running Rawhide
- like, fr'instance, whoever packages Evolution - it would've got fixed
faster...
I don't think so. The maintainer would have seen it broken at the same time everybody else did, that is when they updated to that day's rawhide. The fix is no sooner, its still broken for that entire day.
This goes back to the discussion we've had about why rawhide is only once a day, and that's not a discussion for this thread.
On Fri, 2009-02-27 at 14:32 -0800, Adam Williamson wrote:
Email breaking is rather unlikely.
Depends what mail client you use ;)
How often does Rawhide really fail to boot?
It's usually not that serious, it's some other annoyance that is (yes) normally easily fixed within an hour or less. But that's still real actual time, and even more so, by its very nature you can't allocate that hour in advance. Suppose you need to give a presentation this morning but you don't know that your system is going to boot/run your X session/run OO/and do video out today. That's just an example, and a reason why I like the confidence of a release.
I've been using and developing on Linux systems for 14 years now. In that time I've used almost any distribution you could name, many that no longer even exist, and a lot of "unstable" stuff (Red Hat/Novell/Canonical/SPI). But eventually, I got to a point where I preferred having separate playpens for unstable stuff so that I could choose when I wanted to poke and fix them.
Jon.
On Tue, 2009-03-03 at 03:30 -0500, Jon Masters wrote:
It's usually not that serious, it's some other annoyance that is (yes) normally easily fixed within an hour or less. But that's still real actual time, and even more so, by its very nature you can't allocate that hour in advance. Suppose you need to give a presentation this morning but you don't know that your system is going to boot/run your X session/run OO/and do video out today. That's just an example, and a reason why I like the confidence of a release.
Sure. I'm not being a fundamentalist here. As I said, obviously there are people who need to run a stable release - some need it available somewhere, some need it on their main system but might have Rawhide elsewhere, some need stable on everything. I'm not saying everyone should run Rawhide everywhere, or Rawhide should be suitable for everyone to run everywhere (that's clearly never going to happen). Really I'm just saying it'd be nice to have more people using Rawhide, and to have Rawhide in a state which is conducive to this. That's all.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jesse Keating wrote:
On Fri, 2009-02-27 at 16:39 -0500, Jeremy Katz wrote:
That said, I've been running rawhide on basically all of my boxes all the time without a need for a reinstall[1] for a decade later this year! :-)
and the counter example is trying to run rawhide, have a day without email working. Have a day without the system booting, have a day without the wireless working, so on and so forth. Those days add up quickly when it's your critical functionality that breaks.
Making it harder to make those things break just means we wind up with rawhide, and rawerhide where the real changes are made, and the whole process repeats itself.
Sure, I'd love more people to use rawhide, and I'd love rawhide to break less often, but you're not going to win any favors by convincing developers to use rawhide and then not hear from them for a few days because all their communication software just broke.
Maybe we should encourage (NOT require) maintainers to dual boot or use older machines to test rawhide out with on a weekly basis or something. Obviously not everyone has the time or hardware, but I was pleasantly surprised that 802.1x Just Worked™ with Network Manager for once. If anything, it would keep people more in-tune with what is coming down the tubes and alert to problems that may arise from things being pushed to earlier releases and other possible breakage. If some problems (like the gcc-4.4 rebuild failures) had been caught by at least some maintainers before reading the ML, turn around time may have decreased. Thoughts? Overall, keeping rawhide fast-paced, but decreasing time between breakage and fixing would be a big improvement (rather than testers -> bugzilla -> discussion -> fix, just test -> fix).
- --Ben
On Fri, 2009-02-27 at 18:29 -0500, Ben Boeckel wrote:
Maybe we should encourage (NOT require) maintainers to dual boot or use older machines to test rawhide out with on a weekly basis or something.
And the problem with this is following Rawhide will inevitably work flawlessly on the spare test box, but upon updating your critical primary machine to the final release, it fails miserably:
https://bugzilla.redhat.com/show_bug.cgi?id=474977 https://bugzilla.redhat.com/show_bug.cgi?id=487432
Unless your test box is an exact duplicate of the same hardware, Finagle's law dictates This Will Never Work. (Not even "Both are r300" is good enough. :P)
On Fri, 27 Feb 2009 16:22:35 -0500, seth vidal skvidal@fedoraproject.org wrote:
To be fair - no other distro revs as quickly or as much as fedora does, either. We tend to get new things first. That's one of Fedora's goals.
Gentoo is still faster. They had usbmon a few months before Fedora. I only threw it into Rawhide after they used it for a while and even sent me patches.
You can say we're the fastest of "traditional" or "serious" distros, which is still pretty good.
-- Pete
I am also quite sure that OpenSuSe has Python 2.6 in their last release, so there have been a few cases where fedora has been "beaten" to the latest and greatest technology releases.
Pete Zaitcev wrote:
Gentoo is still faster. They had usbmon a few months before Fedora. I only threw it into Rawhide after they used it for a while and even sent me patches.
It depends a lot on the package. KDE 4 was first in an experimental overlay, then hardmasked, for months in Gentoo when we already shipped it as our only KDE in Fedora 9.
Kevin Kofler
Adam Williamson wrote:
It's not, really. Fedora's is the only development branch which is so neglected, no other distro's is. To give the example I'm most familiar with, Mandriva's development branch has, this cycle, gone through a complete rebuild, Python 2.5 -> 2.6 migration, Tcl 8.5 -> 8.6 migration, X server 1.4 -> 1.6 (git snapshot then final release) migration, and a few other major changes. Most developers run it, as do quite a lot of testers, and it generally works. (While the Python 2.6 rebuild was going on, if you tried to upgrade, you'd see about four hundred errors. This was a fairly good clue that you should wait until the rebuild was complete before updating. Most people are able to handle this level of cogitation.)
They were only able to do this that reliably because Fedora did all the testing for them. ;-) Python 2.6 and X server 1.6 are old news for us.
That said, Tcl/Tk 8.6 is interesting, we're still stuck at 8.5 in Rawhide. :-( Given the amount of legacy Tcl/Tk software in Fedora, I'm not sure upgrading to a beta version (which is what 8.6 still is) is that great an idea (8.5 caused enough problems when we moved to it), but still, we're lagging behind there. :-(
Kevin Kofler
On Sat, 2009-02-28 at 02:31 +0100, Kevin Kofler wrote:
Branch alert!
They were only able to do this that reliably because Fedora did all the testing for them. ;-) Python 2.6 and X server 1.6 are old news for us.
I don't think it's that simple, but...OK, whatever.
That said, Tcl/Tk 8.6 is interesting, we're still stuck at 8.5 in Rawhide. :-( Given the amount of legacy Tcl/Tk software in Fedora, I'm not sure upgrading to a beta version (which is what 8.6 still is) is that great an idea (8.5 caused enough problems when we moved to it), but still, we're lagging behind there. :-(
That was mine, actually. It's quite a good example. I did a private build of Tcl/Tk 8.6, then over the course of a couple of weeks, patched, rebuilt and tested every Tcl/Tk-based app in the distro, then pushed them to Cooker in a lump. Was this, in a sense, a 'cookerer'? I guess so. But it did the job, and I don't think there would have been any benefit in pushing the updated Tcl before I was done testing the rebuilds.
There's probably a few issues lurking, but mostly it went OK. Anyhoo. Off-topic here...
Adam Williamson wrote:
That was mine, actually. It's quite a good example. I did a private build of Tcl/Tk 8.6, then over the course of a couple of weeks, patched, rebuilt and tested every Tcl/Tk-based app in the distro, then pushed them to Cooker in a lump. Was this, in a sense, a 'cookerer'? I guess so. But it did the job, and I don't think there would have been any benefit in pushing the updated Tcl before I was done testing the rebuilds.
There's probably a few issues lurking, but mostly it went OK. Anyhoo. Off-topic here...
You can probably do something very similar with a different tag in Koji. That's how Python 2.6 was introduced in rawhide. Fedora maintainers should be using this feature in this build system more often. Openssl hassles could have been avoided by using it as well for example.
Rahul
Rahul Sundaram wrote:
You can probably do something very similar with a different tag in Koji. That's how Python 2.6 was introduced in rawhide. Fedora maintainers should be using this feature in this build system more often. Openssl hassles could have been avoided by using it as well for example.
So can we get Tcl/Tk 8.6 into F11 even if it's late? :-)
Kevin Kofler
Kevin Kofler wrote:
Rahul Sundaram wrote:
You can probably do something very similar with a different tag in Koji. That's how Python 2.6 was introduced in rawhide. Fedora maintainers should be using this feature in this build system more often. Openssl hassles could have been avoided by using it as well for example.
So can we get Tcl/Tk 8.6 into F11 even if it's late? :-)
Could be depending on how disruptive it is.
Rahul
On Sun, 2009-03-01 at 05:26 +0530, Rahul Sundaram wrote:
Kevin Kofler wrote:
Rahul Sundaram wrote:
You can probably do something very similar with a different tag in Koji. That's how Python 2.6 was introduced in rawhide. Fedora maintainers should be using this feature in this build system more often. Openssl hassles could have been avoided by using it as well for example.
So can we get Tcl/Tk 8.6 into F11 even if it's late? :-)
Could be depending on how disruptive it is.
It doesn't seem to have been a big issue for MDV. Most of the trouble I had was in converting things to the new (for MDV) Tcl packaging policy I implemented at the same time - which is basically the Fedora policy, because I liked the look of it.
In terms of pure 8.5 -> 8.6 issues, there weren't many, 99% of them really being just one issue (the use of interp->result is now disallowed by default, and quite a lot of Tcl code uses this, even though it's been officially deprecated and not recommended for like a decade). It's generally very easy for a coder to fix (so not always for me :>), I upstreamed fixes in quite a few apps, for apps which are dead upstream but in MDV you can pull my patches from MDV SVN, and in the worst case, you can allow its use by adding a #define at the top of the source file concerned (I had to do this in a few packages where I couldn't grok the 'right' way to fix the code).
So I would say it would be possible. Whether it's desirable for Fedora, I don't really know. It may not be a good idea to do it this late, for a release which is already pretty stuffed with features. Who's the Tcl/Tk maintainer?
Oh, worth noting that probably the biggest Tcl-using app is amsn. You can patch amsn 0.97.2 to more or less work with 8.6, but it still had a few issues. In the end I just bumped MDV to current SVN amsn instead, on the recommendation of upstream, which has rather a lot of nice new features anyway.
On Mon, Mar 2, 2009 at 7:01 PM, Adam Williamson awilliam@redhat.com wrote:
On Sun, 2009-03-01 at 05:26 +0530, Rahul Sundaram wrote:
Kevin Kofler wrote:
Rahul Sundaram wrote:
You can probably do something very similar with a different tag in Koji. That's how Python 2.6 was introduced in rawhide. Fedora maintainers should be using this feature in this build system more often. Openssl hassles could have been avoided by using it as well for example.
So can we get Tcl/Tk 8.6 into F11 even if it's late? :-)
Could be depending on how disruptive it is.
It doesn't seem to have been a big issue for MDV. Most of the trouble I had was in converting things to the new (for MDV) Tcl packaging policy I implemented at the same time - which is basically the Fedora policy, because I liked the look of it.
In terms of pure 8.5 -> 8.6 issues, there weren't many, 99% of them really being just one issue (the use of interp->result is now disallowed by default, and quite a lot of Tcl code uses this, even though it's been officially deprecated and not recommended for like a decade). It's generally very easy for a coder to fix (so not always for me :>), I upstreamed fixes in quite a few apps, for apps which are dead upstream but in MDV you can pull my patches from MDV SVN, and in the worst case, you can allow its use by adding a #define at the top of the source file concerned (I had to do this in a few packages where I couldn't grok the 'right' way to fix the code).
So I would say it would be possible. Whether it's desirable for Fedora, I don't really know. It may not be a good idea to do it this late, for a release which is already pretty stuffed with features. Who's the Tcl/Tk maintainer?
Oh, worth noting that probably the biggest Tcl-using app is amsn. You can patch amsn 0.97.2 to more or less work with 8.6, but it still had a few issues. In the end I just bumped MDV to current SVN amsn instead, on the recommendation of upstream, which has rather a lot of nice new features anyway.
Speaking of Tcl/Tk, does anyone know whether Tcl 8.6 is backward compatible with 8.5? From my experience, 8.5 *appears* to be backward compatible with 8.4: a graphics library for this Scheme dialect I use, Chez, comes as a binary compiled against Tk 8.4, and symlinking gets it to run just fine.
If 8.4 apps run fine on 8.5 and 8.6, perhaps we could add the necessary symlinks.
Thanks,
Michel Salim wrote:
On Mon, Mar 2, 2009 at 7:01 PM, Adam Williamson awilliam@redhat.com wrote:
On Sun, 2009-03-01 at 05:26 +0530, Rahul Sundaram wrote:
Kevin Kofler wrote:
Rahul Sundaram wrote:
You can probably do something very similar with a different tag in Koji. That's how Python 2.6 was introduced in rawhide. Fedora maintainers should be using this feature in this build system more often. Openssl hassles could have been avoided by using it as well for example.
So can we get Tcl/Tk 8.6 into F11 even if it's late? :-)
Could be depending on how disruptive it is.
It doesn't seem to have been a big issue for MDV. Most of the trouble I had was in converting things to the new (for MDV) Tcl packaging policy I implemented at the same time - which is basically the Fedora policy, because I liked the look of it.
In terms of pure 8.5 -> 8.6 issues, there weren't many, 99% of them really being just one issue (the use of interp->result is now disallowed by default, and quite a lot of Tcl code uses this, even though it's been officially deprecated and not recommended for like a decade). It's generally very easy for a coder to fix (so not always for me :>), I upstreamed fixes in quite a few apps, for apps which are dead upstream but in MDV you can pull my patches from MDV SVN, and in the worst case, you can allow its use by adding a #define at the top of the source file concerned (I had to do this in a few packages where I couldn't grok the 'right' way to fix the code).
So I would say it would be possible. Whether it's desirable for Fedora, I don't really know. It may not be a good idea to do it this late, for a release which is already pretty stuffed with features. Who's the Tcl/Tk maintainer?
Me.
Oh, worth noting that probably the biggest Tcl-using app is amsn. You can patch amsn 0.97.2 to more or less work with 8.6, but it still had a few issues. In the end I just bumped MDV to current SVN amsn instead, on the recommendation of upstream, which has rather a lot of nice new features anyway.
Speaking of Tcl/Tk, does anyone know whether Tcl 8.6 is backward compatible with 8.5? From my experience, 8.5 *appears* to be backward compatible with 8.4: a graphics library for this Scheme dialect I use, Chez, comes as a binary compiled against Tk 8.4, and symlinking gets it to run just fine.
You are joking right? Tcl 8.5 and 8.4 have a lot of differences. The worst of them is #483836 which can be hardly fixed. Tcl has released 8.6b1 which won't be in F-11 for sure. I'm waiting for stable release. The list of dependencies could be found here: https://fedoraproject.org/wiki/Features/tcl8.5. Details about tcl versions could be found here: http://www.tcl.tk/software/tcltk/choose.html
If 8.4 apps run fine on 8.5 and 8.6, perhaps we could add the necessary symlinks.
Thanks,
Regards,
On Tue, Mar 3, 2009 at 2:29 AM, Marcela Maslanova mmaslano@redhat.com wrote:
You are joking right? Tcl 8.5 and 8.4 have a lot of differences. The worst of them is #483836 which can be hardly fixed. Tcl has released 8.6b1 which won't be in F-11 for sure. I'm waiting for stable release. The list of dependencies could be found here: https://fedoraproject.org/wiki/Features/tcl8.5. Details about tcl versions could be found here: http://www.tcl.tk/software/tcltk/choose.html
Uh, thanks. That looks to be quite a problem indeed. Actually, the lack of threading might explain some of the bugs I see with Chez Scheme's graphics module.
Will 8.6 be compiled with threading support for F-12?
Thanks,
Michel Salim wrote:
On Tue, Mar 3, 2009 at 2:29 AM, Marcela Maslanova mmaslano@redhat.com wrote:
You are joking right? Tcl 8.5 and 8.4 have a lot of differences. The worst of them is #483836 which can be hardly fixed. Tcl has released 8.6b1 which won't be in F-11 for sure. I'm waiting for stable release. The list of dependencies could be found here: https://fedoraproject.org/wiki/Features/tcl8.5. Details about tcl versions could be found here: http://www.tcl.tk/software/tcltk/choose.html
Uh, thanks. That looks to be quite a problem indeed. Actually, the lack of threading might explain some of the bugs I see with Chez Scheme's graphics module.
Will 8.6 be compiled with threading support for F-12?
Thanks,
I don't know if it will be with thread support.
There will be probably two or three beta version, which I will try.
On Tue, 2009-03-03 at 16:28 +0100, Marcela Maslanova wrote:
Michel Salim wrote:
On Tue, Mar 3, 2009 at 2:29 AM, Marcela Maslanova mmaslano@redhat.com wrote:
You are joking right? Tcl 8.5 and 8.4 have a lot of differences. The worst of them is #483836 which can be hardly fixed. Tcl has released 8.6b1 which won't be in F-11 for sure. I'm waiting for stable release. The list of dependencies could be found here: https://fedoraproject.org/wiki/Features/tcl8.5. Details about tcl versions could be found here: http://www.tcl.tk/software/tcltk/choose.html
Uh, thanks. That looks to be quite a problem indeed. Actually, the lack of threading might explain some of the bugs I see with Chez Scheme's graphics module.
Will 8.6 be compiled with threading support for F-12?
Thanks,
I don't know if it will be with thread support.
There will be probably two or three beta version, which I will try.
In Mandriva we actually had threading support for a while and then I was specifically asked to disable it as it causes a substantial problem with Expect:
https://qa.mandriva.com/show_bug.cgi?id=42596
as per the rather substantial discussion both in that report and in the associated upstream conversation:
http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/805731c32f...
it was determined that building with threading really doesn't help anything much. So, as mentioned in that bug, I disabled threading in the MDV build.
Why did want you want to have threading enabled?
Adam Williamson wrote:
On Tue, 2009-03-03 at 16:28 +0100, Marcela Maslanova wrote:
Michel Salim wrote:
On Tue, Mar 3, 2009 at 2:29 AM, Marcela Maslanova mmaslano@redhat.com wrote:
You are joking right? Tcl 8.5 and 8.4 have a lot of differences. The worst of them is #483836 which can be hardly fixed. Tcl has released 8.6b1 which won't be in F-11 for sure. I'm waiting for stable release. The list of dependencies could be found here: https://fedoraproject.org/wiki/Features/tcl8.5. Details about tcl versions could be found here: http://www.tcl.tk/software/tcltk/choose.html
Uh, thanks. That looks to be quite a problem indeed. Actually, the lack of threading might explain some of the bugs I see with Chez Scheme's graphics module.
Will 8.6 be compiled with threading support for F-12?
Thanks,
I don't know if it will be with thread support.
There will be probably two or three beta version, which I will try.
In Mandriva we actually had threading support for a while and then I was specifically asked to disable it as it causes a substantial problem with Expect:
https://qa.mandriva.com/show_bug.cgi?id=42596
as per the rather substantial discussion both in that report and in the associated upstream conversation:
http://groups.google.com/group/comp.lang.tcl/browse_thread/thread/805731c32f...
Yes, I read it.
it was determined that building with threading really doesn't help anything much. So, as mentioned in that bug, I disabled threading in the MDV build.
Why did want you want to have threading enabled?
Some packages work with enabled threading. Also tcl8.4 was built with thread support and users will be disappointed when their application refuse to work ;-)
On Wed, 2009-03-04 at 07:46 +0100, Marcela Maslanova wrote:
Why did want you want to have threading enabled?
Some packages work with enabled threading. Also tcl8.4 was built with
Do you mean, they work with threading enabled but not with it disabled?
On Mon, 2009-03-02 at 21:07 -0500, Michel Salim wrote:
Speaking of Tcl/Tk, does anyone know whether Tcl 8.6 is backward compatible with 8.5? From my experience, 8.5 *appears* to be backward compatible with 8.4: a graphics library for this Scheme dialect I use, Chez, comes as a binary compiled against Tk 8.4, and symlinking gets it to run just fine.
Practically speaking, it sometimes works, as you can see. But it's not officially supported. Minor version bumps - 8.4 -> 8.5, 8.5 -> 8.6 - are allowed to (and do) break API and ABI compatibility for Tcl. Fedora's Tcl policy explicitly requires Tcl packages install to Tcl version-dependent directories in order to ensure that all code is run with the Tcl minor version level it was built (or 'built') for, so I doubt its maintainer would be in favour of symlink hacks...
If 8.4 apps run fine on 8.5 and 8.6, perhaps we could add the necessary symlinks.
On Sun, 2009-03-01 at 02:43 +0530, Rahul Sundaram wrote:
Adam Williamson wrote:
That was mine, actually. It's quite a good example. I did a private build of Tcl/Tk 8.6, then over the course of a couple of weeks, patched, rebuilt and tested every Tcl/Tk-based app in the distro, then pushed them to Cooker in a lump. Was this, in a sense, a 'cookerer'? I guess so. But it did the job, and I don't think there would have been any benefit in pushing the updated Tcl before I was done testing the rebuilds.
There's probably a few issues lurking, but mostly it went OK. Anyhoo. Off-topic here...
You can probably do something very similar with a different tag in Koji. That's how Python 2.6 was introduced in rawhide. Fedora maintainers should be using this feature in this build system more often. Openssl hassles could have been avoided by using it as well for example.
Unfortunately this is not true due to the circular build dependencies where a package which you want to rebuild buildrequires a package which has the old SONAME dep and itself buildrequires a package you just want to rebuild. The cycle can be of course longer.
So the only non-kludgey way would be to add a compat openssl package just to remove it a few weeks later as I don't want to maintain it.
Adam Williamson wrote:
Chicken and egg situation. Someone has to take the leap. Eventually, once enough developers are on Rawhide, there'll be a culture where people generally don't break things too egregiously, and are immediately complained-at if they do, workarounds become known, fixes are made quickly. But anyhoo, I have more developed thoughts along these lines coming in future.
I don't think that would be feasible without another layer above Rawhide (like Debian's experimental) and I'm not sure that'd help QA because we'd be splitting testers and I think the experimental layer in particular would get very little testing.
Kevin Kofler
On Fri, 27 Feb 2009 09:54:36 -0500, Jon Masters jonathan@jonmasters.org wrote:
It would be nice to have everyone who works on Rawhide, work *from* Rawhide. I suspect this would make people generally less keen to break stuff. =)
That's precisely why it's not practical to use Rawhide as a day-to-day platform. I know others will disagree and that's fine, but I long since switched back to a stable Fedora 9/10 setup. It's tough enough ever getting a rawhide that will install, let alone not break randomly.
Are you talking to me, Jon? My desktop was Rawhide for years.
The main reason being, it's impossible to get anything fixed in stock Fedora, with good approximation (unless the problem is declared "security"). Sometimes it happens, but the bug has to be an eggregious show-stopper that affects thousands of users. Anything smaller will be "fixed in devel". Upstream always says "try the latest git, come back if you can reproduce it".
KVM is great at letting one poke safely at stuff.
Only on CPUs that support it. Also it requires ungodly amounts of RAM to be useful.
Look, I know that the security implications of using Rawhide are scary in abstract. But I work for a company where people use Windows for work, they use Blackberries, Linksys routers, Skype, all sorts of dubious shit. It's not like Rawhide is any worse.
-- Pete
Pete Zaitcev wrote:
The main reason being, it's impossible to get anything fixed in stock Fedora, with good approximation (unless the problem is declared "security"). Sometimes it happens, but the bug has to be an eggregious show-stopper that affects thousands of users. Anything smaller will be "fixed in devel". Upstream always says "try the latest git, come back if you can reproduce it".
What package are you talking about? The kernel gets updated to stable releases in stable Fedora in most cases (2.6.28 was skipped, but the plan is that 2.6.29 will be pushed), so things do get fixed in stable releases. It also gets updates from the upstream stable branches and sometimes backported bugfixes. KDE is also maintained in a similar way in Fedora. But of course if you want to run the latest prerelease kernel from git or the latest prerelease KDE from svn you won't find that in a stable Fedora. ;-)
Kevin Kofler
On Sun, 01 Mar 2009 22:43:46 +0100, Kevin Kofler kevin.kofler@chello.at wrote:
Pete Zaitcev wrote:
Upstream always says "try the latest git, come back if you can reproduce it".
What package are you talking about?
Mozilla and Liferea are the two that bother me the most. For kernel we're pretty good at tracking the -stable, like you said.
-- Pete
On Sun, 2009-03-01 at 22:43 +0100, Kevin Kofler wrote:
of course if you want to run the latest prerelease kernel from git or the latest prerelease KDE from svn you won't find that in a stable Fedora. ;-)
Yes, you "will". As others have said, running a stable Fedora allows you to replace just the one piece you care about today - for example newer kernel builds. I regularly run all manner of upstream and also test builds of RHEL-RT kernels on my laptop without worrying about whether the reason it fails to boot is related to something I don't care about at that particular moment[0].
Jon.
[0] I agree with the comments about initrd. I have been bitten by that lack of including virtio modules a bunch of times recently when testing kernels. I was asked earlier about zlib support in m-i-t and whether anyone really cares any more. I thought not (since we have compressed filesystems and nobody even in embedded is using compressed modules), but perhaps there is a use case there.
Jon Masters wrote:
Yes, you "will". As others have said, running a stable Fedora allows you to replace just the one piece you care about today - for example newer kernel builds. I regularly run all manner of upstream and also test builds of RHEL-RT kernels on my laptop without worrying about whether the reason it fails to boot is related to something I don't care about at that particular moment[0].
That usually works for the kernel, not so much for userspace software (especially something big like KDE) unless you rebuild it from the SRPM. And most packages also don't track trunk in Rawhide quite as aggressively as the kernel does (some packagers only ever import stable releases; for KDE we import prereleases of the KDE release series we want to ship in the next stable release early in the Fedora release cycle, but once the .0 release is released we switch to tracking the stable releases, not pre-alpha trunk - also note that KDE release cycles are longer than kernel release cycles), so you don't even always have a SRPM to rebuild.
Kevin Kofler
On Tue, 2009-03-03 at 23:43 +0100, Kevin Kofler wrote:
Jon Masters wrote:
Yes, you "will". As others have said, running a stable Fedora allows you to replace just the one piece you care about today - for example newer kernel builds. I regularly run all manner of upstream and also test builds of RHEL-RT kernels on my laptop without worrying about whether the reason it fails to boot is related to something I don't care about at that particular moment[0].
That usually works for the kernel, not so much for userspace software (especially something big like KDE) unless you rebuild it from the SRPM.
My answer is "it depends". I'm trying to give examples of reasons why you wouldn't run rawhide, or why you might use a virtual machine, etc. The point is, it is wrong to say "all developers must run rawhide".
Jon.
Jon Masters wrote:
My answer is "it depends". I'm trying to give examples of reasons why you wouldn't run rawhide, or why you might use a virtual machine, etc. The point is, it is wrong to say "all developers must run rawhide".
I'm not saying that (actually I still run F9 on this machine), but I _am_ saying that installing Rawhide packages on a stable release is in general not expected to work.
There are of course plenty of solutions - VMs, outsourcing testing to somebody else, rebuilding packages from SRPM etc. - but just installing the Rawhide package is one of the least reliable ones.
Kevin Kofler
"TL" == Tom Lane tgl@redhat.com writes:
TL> I'm personally still ticked off that I'm being forced to update my TL> development workstation to F-10 immediately in order to continue TL> doing useful work on rawhide packages.
Just FYI, I sucked the rpm packages from http://people.redhat.com/mitr/sha256-rpm/f9/ and installed them on my builders. There were depenency problems with gdb and net-snmp, which I removed, but after install things are fine and I can continue to do mock builds of rawhide packages. That may not be helpful to you but it did at least get me building things again.
TL> Since F-9 is still supported, isn't it a management failing to TL> have allowed this to happen without a plan to make mock on F-9 TL> work?
Mock still works on F9 just fine; you simply can't use it to build things for rawhide. I guess it's a balancing act between that and potentially breaking systems.
- J<
Jason L Tibbitts III tibbs@math.uh.edu writes:
"TL" == Tom Lane tgl@redhat.com writes: TL> Since F-9 is still supported, isn't it a management failing to TL> have allowed this to happen without a plan to make mock on F-9 TL> work?
Mock still works on F9 just fine; you simply can't use it to build things for rawhide.
Right, at the same time that we are breaking lots o' packages with new libtool and new gcc versions, and people desperately need to test fixes for those changes. I count myself very fortunate that I was proactive enough to fix my own packages last week against the gcc44 branch. Otherwise I'd be flat out screwed now; I can't update my machine yet because I need it working in order to deal with other pressing business.
Workarounds invented after the fact don't impress me. This should have been foreseen and avoided by the simple expedient of not rushing things on core infrastructure changes. If we'd waited till F9 was EOL before starting to depend on F10-only RPM features, we'd not have this mess.
regards, tom lane
-------- Original Message -------- Subject: Re: Ready for new RPM version? From: Tom Lane tgl@redhat.com To: Development discussions related to Fedora fedora-devel-list@redhat.com Date: 02/26/2009 12:24 PM
Jon Ciesla limb@jcomserv.net writes:
Yeah, it seems like F12 material. Going with a beta version of critical infrastructure like RPM strikes me as sheer insanity. Or have we learned nothing from how badly the still-in-progress RPM update was mismanaged? These things need to be taken *slowly*.
regards, tom lane
From an end-users perspective, going from Fedora Core 2 up to Fedora 10, I've never seen any RPM issues.
I'd be interested in your answer to Seth's question.
F11 is not frozen yet, and if this is a minor update that only brings speed boosts... why not?
Panu Matilainen wrote:
Are we ready to consider a brand new RPM version for F11, amidst all this mass-rebuild-for-strong-hash chaos and just days to go to development freeze?
We just put out first rpm 4.7.0 beta: http://lists.rpm.org/pipermail/rpm-announce/2009-February/000016.html. This is nothing like the 4.4.2.x -> 4.6.0 leap-of-faith upgrade last year but it's still non-trivial amount of changes to get the kind of memory use and performance improvements that 4.7.0 has, which is why it's not just 4.6.1.
The wording of Fedora Feature policy pretty explicitly singles out each RPM upgrade to be a Feature... I would like to hear a preliminary opinion on it: if everybody is going to be an outright "NO!" then I'm not going to waste my time with writing up a Feature page. If it's "maybe" or "it depends" then ok, will submit as a feature in time for tomorrows FESCo meeting.
So, should I bother with a RPM 4.7 feature page or not?
Just a packager's perspective but:
1) The memory optimization features look great! 2) A few of the API changes aren't clear if they remove old API. Should that be assumed wherever "should be transparent" isn't written? 3) As the rpm maintainer, do you recommend we go with this for F11?
-Toshio
On Thu, 26 Feb 2009, Toshio Kuratomi wrote:
Panu Matilainen wrote:
Are we ready to consider a brand new RPM version for F11, amidst all this mass-rebuild-for-strong-hash chaos and just days to go to development freeze?
We just put out first rpm 4.7.0 beta: http://lists.rpm.org/pipermail/rpm-announce/2009-February/000016.html. This is nothing like the 4.4.2.x -> 4.6.0 leap-of-faith upgrade last year but it's still non-trivial amount of changes to get the kind of memory use and performance improvements that 4.7.0 has, which is why it's not just 4.6.1.
The wording of Fedora Feature policy pretty explicitly singles out each RPM upgrade to be a Feature... I would like to hear a preliminary opinion on it: if everybody is going to be an outright "NO!" then I'm not going to waste my time with writing up a Feature page. If it's "maybe" or "it depends" then ok, will submit as a feature in time for tomorrows FESCo meeting.
So, should I bother with a RPM 4.7 feature page or not?
Just a packager's perspective but:
- The memory optimization features look great!
- A few of the API changes aren't clear if they remove old API. Should
that be assumed wherever "should be transparent" isn't written?
Removals are stated explicitly AFAICT, but all of them are things that have only ever been useful within rpm and now wouldn't do anything at all. "No existing API consumer should be affected" goes for all of the API changes whether written or not. (but ok will clarify, the current version is just the first draft)
- As the rpm maintainer, do you recommend we go with this for F11?
Would I have started this thread if I didn't? :)
- Panu -
Panu Matilainen wrote:
Are we ready to consider a brand new RPM version for F11, amidst all this mass-rebuild-for-strong-hash chaos and just days to go to development freeze?
We just put out first rpm 4.7.0 beta: http://lists.rpm.org/pipermail/rpm-announce/2009-February/000016.html. This is nothing like the 4.4.2.x -> 4.6.0 leap-of-faith upgrade last year but it's still non-trivial amount of changes to get the kind of memory use and performance improvements that 4.7.0 has, which is why it's not just 4.6.1.
The wording of Fedora Feature policy pretty explicitly singles out each RPM upgrade to be a Feature... I would like to hear a preliminary opinion on it: if everybody is going to be an outright "NO!" then I'm not going to waste my time with writing up a Feature page. If it's "maybe" or "it depends" then ok, will submit as a feature in time for tomorrows FESCo meeting.
So, should I bother with a RPM 4.7 feature page or not?
I would say go for it. Performance improvements are something we really need. As long as it isn't a potential world breaking change like the 4.6 series, why not.
Rahul
Rahul Sundaram sundaram@fedoraproject.org wrote:
Panu Matilainen wrote:
Are we ready to consider a brand new RPM version for F11, amidst all this mass-rebuild-for-strong-hash chaos and just days to go to development freeze?
[...]
I would say go for it. Performance improvements are something we really need. As long as it isn't a potential world breaking change like the 4.6 series, why not.
Agree.
Could they please make an RPM available for futzing around?
On Thu, 26 Feb 2009, Horst H. von Brand wrote:
Rahul Sundaram sundaram@fedoraproject.org wrote:
Panu Matilainen wrote:
Are we ready to consider a brand new RPM version for F11, amidst all this mass-rebuild-for-strong-hash chaos and just days to go to development freeze?
[...]
I would say go for it. Performance improvements are something we really need. As long as it isn't a potential world breaking change like the 4.6 series, why not.
Agree.
Could they please make an RPM available for futzing around?
I put the SRPM to http://laiskiainen.org/rpm/fedora/ for now. Should build + work without problems on F10 and rawhide, but you'll need to rebuild dependencies (notably gdb and net-snmp) for the soname change.
- Panu -
2009/2/27 Panu Matilainen pmatilai@laiskiainen.org:
I put the SRPM to http://laiskiainen.org/rpm/fedora/ for now. Should build + work without problems on F10 and rawhide, but you'll need to rebuild dependencies (notably gdb and net-snmp) for the soname change.
Hi,
Anyone can help me to downgrade my system to 4.6? I am stuck.
Thanks!
Dne Thu, 5 Mar 2009 22:01:57 +0800 Yuan Yijun bbbush.yuan@gmail.com napsal(a):
2009/2/27 Panu Matilainen pmatilai@laiskiainen.org:
I put the SRPM to http://laiskiainen.org/rpm/fedora/ for now. Should build + work without problems on F10 and rawhide, but you'll need to rebuild dependencies (notably gdb and net-snmp) for the soname change.
Hi,
Anyone can help me to downgrade my system to 4.6? I am stuck.
Why, do you have any problems with 4.7-beta? It works fine for me so far.
You can download the rpm-*4.6.0*.rpm packages manually from any Rawhide mirror and then: rpm -Uvh --oldpackage rpm-*4.6.0*.rpm
Michal
2009/3/5 Michal Schmidt mschmidt@redhat.com:
Anyone can help me to downgrade my system to 4.6? I am stuck.
Why, do you have any problems with 4.7-beta? It works fine for me so far.
You can download the rpm-*4.6.0*.rpm packages manually from any Rawhide mirror and then: rpm -Uvh --oldpackage rpm-*4.6.0*.rpm
I was going to upgrade my F10 to rawhide, so I installed rpm 4.7b1 first. But soon I realized I need both rpm 4.7b1 build for F10 and rawhide. Then I give up and installed rpm 4.6, but rpm database seems to have changed.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Yuan Yijun さんは書きました:
2009/3/5 Michal Schmidt mschmidt@redhat.com:
Anyone can help me to downgrade my system to 4.6? I am stuck.
Why, do you have any problems with 4.7-beta? It works fine for me so far.
Have you used ext4 rather than ext3?
- - kaio
- -- Caius Chance, Soft Eng, I18N, Red Hat APAC, cchance AT redhat DOT com JP (Qual), RHCE, MCSE, CCNA, JLPT4, http://apac.redhat.com/disclaimer
2009/3/6 Caius kaio Chance cchance@redhat.com:
Have you used ext4 rather than ext3?
ext4. Anything to do with rpm database?
2009/3/6 Yuan Yijun bbbush.yuan@gmail.com:
I was going to upgrade my F10 to rawhide, so I installed rpm 4.7b1 first. But soon I realized I need both rpm 4.7b1 build for F10 and rawhide. Then I give up and installed rpm 4.6, but rpm database seems to have changed.
Additional information: I tried kernel for f11 before downgrade to 4.6. Now I installed 4.7b1 again, and go back to f10 kernel, the rpm database is still not usable. I'll try it later with f11 kernel.
On Fri, 6 Mar 2009, Yuan Yijun wrote:
2009/3/5 Michal Schmidt mschmidt@redhat.com:
Anyone can help me to downgrade my system to 4.6? I am stuck.
Why, do you have any problems with 4.7-beta? It works fine for me so far.
You can download the rpm-*4.6.0*.rpm packages manually from any Rawhide mirror and then: rpm -Uvh --oldpackage rpm-*4.6.0*.rpm
I was going to upgrade my F10 to rawhide, so I installed rpm 4.7b1 first. But soon I realized I need both rpm 4.7b1 build for F10 and rawhide. Then I give up and installed rpm 4.6, but rpm database seems to have changed.
Right, the gotcha here has to do with the Berkeley DB version rpm was built against: on F10, it's 4.5.20 and in rawhide it's 4.7.25. If nuking the environment ('rm -f /var/lib/rpm/__*') doesn't clear that up, you'll need to rev back the database to db 4.5.20 with the db utils, something like this: # rpm -Uvh --oldpackage rpm-*4.6.0*.rpm # cp -avp /var/lib/rpm/ /var/lib/rpm.save/ # cd /var/lib/rpm/ # mv Packages Packages.orig # db_dump Packages.orig db45_load Packages # rpm --rebuilddb
- Panu -
On Thu, 2009-02-26 at 19:35 +0200, Panu Matilainen wrote:
Are we ready to consider a brand new RPM version for F11, amidst all this mass-rebuild-for-strong-hash chaos and just days to go to development freeze?
We just put out first rpm 4.7.0 beta: http://lists.rpm.org/pipermail/rpm-announce/2009-February/000016.html. This is nothing like the 4.4.2.x -> 4.6.0 leap-of-faith upgrade last year but it's still non-trivial amount of changes to get the kind of memory use and performance improvements that 4.7.0 has, which is why it's not just 4.6.1.
The wording of Fedora Feature policy pretty explicitly singles out each RPM upgrade to be a Feature... I would like to hear a preliminary opinion on it: if everybody is going to be an outright "NO!" then I'm not going to waste my time with writing up a Feature page. If it's "maybe" or "it depends" then ok, will submit as a feature in time for tomorrows FESCo meeting.
So, should I bother with a RPM 4.7 feature page or not?
Roll it in for F11 beta and let's see how much breaks. Thanks, -sv
On Thu, Feb 26, 2009 at 7:40 PM, seth vidal skvidal@fedoraproject.org wrote:
On Thu, 2009-02-26 at 19:35 +0200, Panu Matilainen wrote:
Are we ready to consider a brand new RPM version for F11, amidst all this mass-rebuild-for-strong-hash chaos and just days to go to development freeze?
We just put out first rpm 4.7.0 beta: http://lists.rpm.org/pipermail/rpm-announce/2009-February/000016.html. This is nothing like the 4.4.2.x -> 4.6.0 leap-of-faith upgrade last year but it's still non-trivial amount of changes to get the kind of memory use and performance improvements that 4.7.0 has, which is why it's not just 4.6.1.
The wording of Fedora Feature policy pretty explicitly singles out each RPM upgrade to be a Feature... I would like to hear a preliminary opinion on it: if everybody is going to be an outright "NO!" then I'm not going to waste my time with writing up a Feature page. If it's "maybe" or "it depends" then ok, will submit as a feature in time for tomorrows FESCo meeting.
So, should I bother with a RPM 4.7 feature page or not?
Roll it in for F11 beta and let's see how much breaks.
+ 1
We could still revert to 4.6 if it really breaks stuff so go ahead ;)
Panu Matilainen (pmatilai@laiskiainen.org) said:
So, should I bother with a RPM 4.7 feature page or not?
If we're doing it, it should have a feature page. Whether or not we're doing it should depend on:
- will it be final by final release? (I'd prefer to not ship an RC. Yes, I know we did with F10, and that's part of the problem) - what user visible changes will this make, especially that could fail package builds. From reading the release note, there's one of these. - does it change the output package format in any way that would make packages unreadable by prior versions?
etc.
Bill
Bill Nottingham wrote:
Panu Matilainen (pmatilai@laiskiainen.org) said:
So, should I bother with a RPM 4.7 feature page or not?
- does it change the output package format in any way that would make packages unreadable by prior versions?
If the output package format is not 100% usable by previous versions of rpm (all the way back to the rpm that was in the original Fedora 9 release) then such a change is forbidden without explicit migration and compatibility features. Not only would that require a feature page, it requires testing for a full release cycle.
On Thu, 2009-02-26 at 11:41 -0800, John Reiser wrote:
Bill Nottingham wrote:
Panu Matilainen (pmatilai@laiskiainen.org) said:
So, should I bother with a RPM 4.7 feature page or not?
- does it change the output package format in any way that would make packages unreadable by prior versions?
If the output package format is not 100% usable by previous versions of rpm (all the way back to the rpm that was in the original Fedora 9 release) then such a change is forbidden without explicit migration and compatibility features. Not only would that require a feature page, it requires testing for a full release cycle.
"forbidden"? Forbidden by whom?
I'm curious where you're pulling all of this declarative language from.
-sv
John Reiser wrote:
Bill Nottingham wrote:
Panu Matilainen (pmatilai@laiskiainen.org) said:
So, should I bother with a RPM 4.7 feature page or not?
- does it change the output package format in any way that would make packages unreadable by prior versions?
If the output package format is not 100% usable by previous versions of rpm (all the way back to the rpm that was in the original Fedora 9 release) then such a change is forbidden without explicit migration and compatibility features.
This seems a little too strict to me when taken with the fact that we've already broken output package format between rawhide and F10-GA's rpm. The bar for doing that might not have been placed correctly but I think it's unreasonable to say 4.7 can't get in if it is no more incompatible than that decision.
Unless explicit migration and compatibility features encompass the requirements and limitations placed on the larger hash feature (such as, you must go from F-9 to F-10 in order to use preupgrade, etc).
-Toshio
Toshio Kuratomi píše v Čt 26. 02. 2009 v 11:48 -0800:
Unless explicit migration and compatibility features encompass the requirements and limitations placed on the larger hash feature (such as, you must go from F-9 to F-10 in order to use preupgrade, etc).
You don't. I have tested preupgrade from F-9 to F-11 with SHA-256, and it works. Mirek
Miloslav Trmač wrote:
Toshio Kuratomi píše v Čt 26. 02. 2009 v 11:48 -0800:
Unless explicit migration and compatibility features encompass the requirements and limitations placed on the larger hash feature (such as, you must go from F-9 to F-10 in order to use preupgrade, etc).
You don't. I have tested preupgrade from F-9 to F-11 with SHA-256, and it works.
Oh cool. Sorry for relaying misinformation.
-Toshio
Miloslav Trmač wrote:
Toshio Kuratomi píše v Čt 26. 02. 2009 v 11:48 -0800:
Unless explicit migration and compatibility features encompass the requirements and limitations placed on the larger hash feature (such as, you must go from F-9 to F-10 in order to use preupgrade, etc).
You don't. I have tested preupgrade from F-9 to F-11 with SHA-256, and it works. Mirek
Has anyone tried a yum upgrade to F-11? I would think upgrading rpm and yum first would be all the prerequisites you'd need, no?
Jon Ciesla píše v Čt 26. 02. 2009 v 14:41 -0600:
Has anyone tried a yum upgrade to F-11? I would think upgrading rpm and yum first would be all the prerequisites you'd need, no? From F-10 with updates there is no reason to expect any problems.
From F-9 the recommendation is to perform a full update to F-10 with all
updates. Updating only rpm to the F-10 update version seemed to work fine when I tried it, but nobody maintains this upgrade path. Mirek
Miloslav Trmač wrote:
Jon Ciesla píše v Čt 26. 02. 2009 v 14:41 -0600:
Has anyone tried a yum upgrade to F-11? I would think upgrading rpm and yum first would be all the prerequisites you'd need, no?
From F-10 with updates there is no reason to expect any problems.
From F-9 the recommendation is to perform a full update to F-10 with all
updates. Updating only rpm to the F-10 update version seemed to work fine when I tried it, but nobody maintains this upgrade path. Mirek
I know it isn't :) Never stopped me before. Hence:
http://fedoraproject.org/wiki/SIGs/LiveUpgrade
On Thu, Feb 26, 2009 at 3:08 PM, Jon Ciesla limb@jcomserv.net wrote:
Miloslav Trmač wrote:
Jon Ciesla píše v Čt 26. 02. 2009 v 14:41 -0600:
Has anyone tried a yum upgrade to F-11? I would think upgrading rpm and yum first would be all the prerequisites you'd need, no?
From F-10 with updates there is no reason to expect any problems.
From F-9 the recommendation is to perform a full update to F-10 with all
updates. Updating only rpm to the F-10 update version seemed to work fine when I tried it, but nobody maintains this upgrade path. Mirek
I know it isn't :) Never stopped me before. Hence:
http://fedoraproject.org/wiki/SIGs/LiveUpgrade
-- in your fear, speak only peace in your fear, seek only love
-d. bowie
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Heh, I think you should go for it and update RPM to 4.7.0. We really should try to improve rpm's/yum's performance as much as possible (although, there will always be some lag, because of python interpretation, but it is quite small and barely noticeable most of the time) and it looks like RPM 4.7.0 doesn't break compatibility with the old package format even though it finally does support LZMA based RPM packages. And it is definitely good to hear that LiveUpgrade still works. I use LiveUpgrade for my testing VMs because its a pain to run the ISO or the DVD for upgrading on those, especially since it isn't nearly as critical as real machines.
On Thu, 26 Feb 2009, Bill Nottingham wrote:
Panu Matilainen (pmatilai@laiskiainen.org) said:
So, should I bother with a RPM 4.7 feature page or not?
If we're doing it, it should have a feature page. Whether or not we're doing it should depend on:
- will it be final by final release? (I'd prefer to not ship an
RC. Yes, I know we did with F10, and that's part of the problem)
That's certainly the intention, and yes 4.6.0 dragged far too long in -rc series. If that fails to happen for whatever reason there's always the possibility of going back to 4.6.0 which in this case is just a matter of epoch bump and rebuilding the handful of packages that link to librpm directly. There are no database or other such format issues involved here.
- what user visible changes will this make, especially that could
fail package builds. From reading the release note, there's one of these.
Hmm? If you mean the noarch check, that's already in rawhide rpm.
- does it change the output package format in any way that would
make packages unreadable by prior versions?
Only if you use the posix file capabilities (but this is protected against with a rpmlib() dependency).
- Panu -
Panu Matilainen wrote:
Are we ready to consider a brand new RPM version for F11, amidst all this mass-rebuild-for-strong-hash chaos and just days to go to development freeze?
We just put out first rpm 4.7.0 beta: http://lists.rpm.org/pipermail/rpm-announce/2009-February/000016.html. This is nothing like the 4.4.2.x -> 4.6.0 leap-of-faith upgrade last year but it's still non-trivial amount of changes to get the kind of memory use and performance improvements that 4.7.0 has, which is why it's not just 4.6.1.
The wording of Fedora Feature policy pretty explicitly singles out each RPM upgrade to be a Feature... I would like to hear a preliminary opinion on it: if everybody is going to be an outright "NO!" then I'm not going to waste my time with writing up a Feature page. If it's "maybe" or "it depends" then ok, will submit as a feature in time for tomorrows FESCo meeting.
So, should I bother with a RPM 4.7 feature page or not?
One question:
"# Support for the new XZ (aka LZMA) compression format in package payloads and sources has been added."
Is this still considered experimental? Are we considering switching to it by default? Any benchmarks?
Rahul
On Thu, Feb 26, 2009 at 8:48 PM, Rahul Sundaram sundaram@fedoraproject.org wrote:
Panu Matilainen wrote:
Are we ready to consider a brand new RPM version for F11, amidst all this mass-rebuild-for-strong-hash chaos and just days to go to development freeze?
We just put out first rpm 4.7.0 beta: http://lists.rpm.org/pipermail/rpm-announce/2009-February/000016.html. This is nothing like the 4.4.2.x -> 4.6.0 leap-of-faith upgrade last year but it's still non-trivial amount of changes to get the kind of memory use and performance improvements that 4.7.0 has, which is why it's not just 4.6.1.
The wording of Fedora Feature policy pretty explicitly singles out each RPM upgrade to be a Feature... I would like to hear a preliminary opinion on it: if everybody is going to be an outright "NO!" then I'm not going to waste my time with writing up a Feature page. If it's "maybe" or "it depends" then ok, will submit as a feature in time for tomorrows FESCo meeting.
So, should I bother with a RPM 4.7 feature page or not?
One question:
"# Support for the new XZ (aka LZMA) compression format in package payloads and sources has been added."
Is this still considered experimental? Are we considering switching to it by default? Any benchmarks?
We can't this would require another rebuild, so this should be F12 material
drago01 drago01@gmail.com wrote:
On Thu, Feb 26, 2009 at 8:48 PM, Rahul Sundaram sundaram@fedoraproject.org wrote:
Panu Matilainen wrote:
[...]
One question:
"# Support for the new XZ (aka LZMA) compression format in package payloads and sources has been added."
Is this still considered experimental? Are we considering switching to it by default? Any benchmarks?
We can't this would require another rebuild, so this should be F12 material
Why? AFAIU, it can handle the old format happily too. Just use the new compression whenever the package is rebuilt for whatever *other* reason. When there are no more "old" packages around, drop the old format for good. Rawhide churn is large enough as it is.
Horst H. von Brand (vonbrand@inf.utfsm.cl) said:
We can't this would require another rebuild, so this should be F12 material
Why? AFAIU, it can handle the old format happily too. Just use the new compression whenever the package is rebuilt for whatever *other* reason. When there are no more "old" packages around, drop the old format for good. Rawhide churn is large enough as it is.
Because I'm fairly sure that changing the compression format is another one of those "can't read newly built RPM with older versions of RPM" problems...
Bill
On Thu, 26 Feb 2009, Horst H. von Brand wrote:
drago01 drago01@gmail.com wrote:
On Thu, Feb 26, 2009 at 8:48 PM, Rahul Sundaram sundaram@fedoraproject.org wrote:
Panu Matilainen wrote:
[...]
One question:
"# Support for the new XZ (aka LZMA) compression format in package payloads and sources has been added."
Is this still considered experimental? Are we considering switching to it by default? Any benchmarks?
We can't this would require another rebuild, so this should be F12 material
Why? AFAIU, it can handle the old format happily too. Just use the new compression whenever the package is rebuilt for whatever *other* reason. When there are no more "old" packages around, drop the old format for good. Rawhide churn is large enough as it is.
That'd be yet another incompatibility, one that even current F10 rpm can't handle at the moment (although backporting is feasible and even planned for some a 4.6.x maintenance release once xz-utils has a stable release)
- Panu -
On Fri, 2009-02-27 at 01:18 +0530, Rahul Sundaram wrote:
One question:
"# Support for the new XZ (aka LZMA) compression format in package payloads and sources has been added."
Is this still considered experimental? Are we considering switching to it by default? Any benchmarks?
MDV switched a cycle or two back.
The benchmarks, IIRC, showed that LZMA is slightly slower than gzip but rather faster than bzip2 at decompress time, and compresses significantly better than either.
On Thu, Feb 26, 2009 at 9:48 PM, Rahul Sundaram sundaram@fedoraproject.org wrote:
"# Support for the new XZ (aka LZMA) compression format in package payloads and sources has been added."
Is this still considered experimental? Are we considering switching to it by default? Any benchmarks?
If we are going to switch, someone (probably myself) will need to patch deltarpm to support LZMA payloads (which will hopefully be fairly trivial).
Jonathan
On Fri, 2009-02-27 at 20:13 +0200, Jonathan Dieter wrote:
On Thu, Feb 26, 2009 at 9:48 PM, Rahul Sundaram sundaram@fedoraproject.org wrote:
"# Support for the new XZ (aka LZMA) compression format in package payloads and sources has been added."
Is this still considered experimental? Are we considering switching to it by default? Any benchmarks?
If we are going to switch, someone (probably myself) will need to patch deltarpm to support LZMA payloads (which will hopefully be fairly trivial).
Jonathan, would it be worthwhile to re-approach the rpm devs about deltarpm merging?
-sv
On Fri, 2009-02-27 at 13:22 -0500, seth vidal wrote:
On Fri, 2009-02-27 at 20:13 +0200, Jonathan Dieter wrote:
If we are going to switch, someone (probably myself) will need to patch deltarpm to support LZMA payloads (which will hopefully be fairly trivial).
Jonathan, would it be worthwhile to re-approach the rpm devs about deltarpm merging?
I wasn't aware they'd ever been approached, but it sounds good to me. Michael Schroeder, upstream for deltarpm, normally follows this list, but I'm CC'ing him anyhow.
Jonathan
On Fri, Feb 27, 2009 at 08:38:19PM +0200, Jonathan Dieter wrote:
On Fri, 2009-02-27 at 13:22 -0500, seth vidal wrote:
On Fri, 2009-02-27 at 20:13 +0200, Jonathan Dieter wrote:
If we are going to switch, someone (probably myself) will need to patch deltarpm to support LZMA payloads (which will hopefully be fairly trivial).
Jonathan, would it be worthwhile to re-approach the rpm devs about deltarpm merging?
I wasn't aware they'd ever been approached, but it sounds good to me. Michael Schroeder, upstream for deltarpm, normally follows this list, but I'm CC'ing him anyhow.
We're using lzma (now xz) compressen since openSUSE 11.0 (released almost a year ago), so it's indeed pretty trivial.
(Regarding "merging": it's a standalone tool. You could bundle it with rpm, though.)
Cheers, Michael.
Jonathan Dieter wrote:
If we are going to switch, someone (probably myself) will need to patch deltarpm to support LZMA payloads (which will hopefully be fairly trivial).
I'd presume so. If you cannot figure it out, I can help. I think the deltarpm user base is exactly the one benefitting the most from LZMA payloads.
Kevin Kofler