A note to all Fedora maintainers and especially to the Red Hat people who are involved in development every day:
Please fix your bugs [1] in the release they were filed against instead of just closing them NEXTRELASE!
I know it sounds slinky to just close everything NEXTRELEASE and I know I sucks to get reports of bugs you've already fixed. But in 99% of all cases it shouldn't be to hard to get the fix also into the stable release.
Telling people to upgrade to the rawhide version is _not_an_option_ if it pulls in another 996 package plus the latest untested development kernel and 8 unresolved deps.
Thanks for your understanding. Christoph
[1] I'm talking about bugs, not about enhancements.
Christoph Wickert wrote:
A note to all Fedora maintainers and especially to the Red Hat people who are involved in development every day:
Please fix your bugs [1] in the release they were filed against instead of just closing them NEXTRELASE!
Doesn't that depend on how serious the bugs are? Sometimes upstream has gone way ahead, changed their configuration format etc and backporting the fix or just pushing the update with all the other changes is too invasive.
Rahul
2009/3/10 Rahul Sundaram wrote:
Christoph Wickert wrote:
A note to all Fedora maintainers and especially to the Red Hat people who are involved in development every day:
Please fix your bugs [1] in the release they were filed against instead of just closing them NEXTRELASE!
Doesn't that depend on how serious the bugs are? Sometimes upstream has gone way ahead, changed their configuration format etc and backporting the fix or just pushing the update with all the other changes is too invasive.
The issue highlighted by Christoph is very important and needs attention. There are cases where back porting may be putting in too much effort. But that case is exception (I guess rare and for few packages) and best judge would be package maintainer.
But for usual cases it is better to fix the bugs for the release they have been made against, rather then just fixing it for rawhide and marking it nextrelease. At least putting your best effort.
Rahul
-- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
On Tue, Mar 10, 2009 at 03:21:34PM +0530, Rahul Sundaram wrote:
Christoph Wickert wrote:
A note to all Fedora maintainers and especially to the Red Hat people who are involved in development every day:
Please fix your bugs [1] in the release they were filed against instead of just closing them NEXTRELASE!
Doesn't that depend on how serious the bugs are? Sometimes upstream has gone way ahead, changed their configuration format etc and backporting the fix or just pushing the update with all the other changes is too invasive.
While there may well be some bugs that are too complex to backport to the current supported release, this is not the general case. I have had faaaar too many bugs I've reported against F9/10 with trivial fixes only ever fixed in rawhide. This can be really discouraging & annoying as the end user reporting the issue. Of course on the flip side, I'm guilty of only fixing some of my own components' bugs in rawhide too, when I could have backported fixes. I think package maintainers need to be more aware of the fact that users want their bugs fixed in the release they are using, unless there's a good reason why not. So if a maintainer has to close a F9/10 bug against rawhide only, then please do curtosy of telling the user why it is not pratical to fix it in stable release it was reported against.
Regards, Daniel
Am Dienstag, den 10.03.2009, 15:21 +0530 schrieb Rahul Sundaram:
Christoph Wickert wrote:
A note to all Fedora maintainers and especially to the Red Hat people who are involved in development every day:
Please fix your bugs [1] in the release they were filed against instead of just closing them NEXTRELASE!
Doesn't that depend on how serious the bugs are? Sometimes upstream has gone way ahead, changed their configuration format etc and backporting the fix or just pushing the update with all the other changes is too invasive.
Agreed, but in the case I have in mind * the bug is so serious that he makes the package not working * we are upstream and * there is nothing to backport. Nevertheless the maintainer told me to get the rawhide package.
Rahul
Regards, Christoph
On Tuesday, March 10 2009, Christoph Wickert said:
Am Dienstag, den 10.03.2009, 15:21 +0530 schrieb Rahul Sundaram:
Christoph Wickert wrote:
A note to all Fedora maintainers and especially to the Red Hat people who are involved in development every day:
Please fix your bugs [1] in the release they were filed against instead of just closing them NEXTRELASE!
Doesn't that depend on how serious the bugs are? Sometimes upstream has gone way ahead, changed their configuration format etc and backporting the fix or just pushing the update with all the other changes is too invasive.
Agreed, but in the case I have in mind * the bug is so serious that he makes the package not working * we are upstream and * there is nothing to backport. Nevertheless the maintainer told me to get the rawhide package.
So, as the person who has apparently pissed you off this morning, it's not as trivial as you're making it out to be. I'm sorry that you want to be doing the development of the live images for the next release on Fedora 10, but the fact of the matter is that as the base system of Fedora moves onward, it's not just a foregone conclusion that everything can be done on the previous release. Yes, I could push back the single patch for the syslinux path change... but that *isn't* sufficient to make a working rawhide live image while on Fedora 10. You also need things like a) a newer kernel so that your system doesn't livelock while writing to ext4 b) a newer squashfs-tools so that you can build an image that works with the rawhide kernel[1] c) one or two other things are a little different and could have side effects -- sure, those could be tested extensively and dealt with/fixed/whatnot. But that's then effort not spent on implementing things for the future. And given the intended audience of livecd-tools, that's really not the best use of effort.
Jeremy
[1] And this one is even more insidious because the new mksquashfs won't build an image that works with old kernels... so we push it back to F10 and all of sudden, building F10 images breaks for people.
On Mar 10, 2009, at 9:48 AM, Jeremy Katz wrote:
On Tuesday, March 10 2009, Christoph Wickert said:
Am Dienstag, den 10.03.2009, 15:21 +0530 schrieb Rahul Sundaram:
Christoph Wickert wrote:
A note to all Fedora maintainers and especially to the Red Hat people who are involved in development every day:
Please fix your bugs [1] in the release they were filed against instead of just closing them NEXTRELASE!
Doesn't that depend on how serious the bugs are? Sometimes upstream has gone way ahead, changed their configuration format etc and backporting the fix or just pushing the update with all the other changes is too invasive.
Agreed, but in the case I have in mind * the bug is so serious that he makes the package not working * we are upstream and * there is nothing to backport. Nevertheless the maintainer told me to get the rawhide package.
So, as the person who has apparently pissed you off this morning, it's not as trivial as you're making it out to be. I'm sorry that you want to be doing the development of the live images for the next release on Fedora 10, but the fact of the matter is that as the base system of Fedora moves onward, it's not just a foregone conclusion that everything can be done on the previous release. Yes, I could push back the single patch for the syslinux path change... but that *isn't* sufficient to make a working rawhide live image while on Fedora 10. You also need things like a) a newer kernel so that your system doesn't livelock while writing to ext4 b) a newer squashfs-tools so that you can build an image that works with the rawhide kernel[1] c) one or two other things are a little different and could have side effects -- sure, those could be tested extensively and dealt with/fixed/whatnot. But that's then effort not spent on implementing things for the future. And given the intended audience of livecd-tools, that's really not the best use of effort.
Jeremy
[1] And this one is even more insidious because the new mksquashfs won't build an image that works with old kernels... so we push it back to F10 and all of sudden, building F10 images breaks for people.
Is the squashfs change the holdup on getting 2.6.29 in F10? Last time I tried the koji 2.6.29 F10 kernel, this was an issue in doing a custom application respin.
joe
On Tuesday, March 10 2009, Joe Nall said:
On Mar 10, 2009, at 9:48 AM, Jeremy Katz wrote:
[1] And this one is even more insidious because the new mksquashfs won't build an image that works with old kernels... so we push it back to F10 and all of sudden, building F10 images breaks for people.
Is the squashfs change the holdup on getting 2.6.29 in F10? Last time I tried the koji 2.6.29 F10 kernel, this was an issue in doing a custom application respin.
Kyle backed the squashfs in the f10 kernel back to what we were previously shipping. The bigger holdoup for 2.6.29 in F10 is that 2.6.29 final isn't released yet :-)
Jeremy
Jeremy Katz wrote:
So, as the person who has apparently pissed you off this morning, it's not as trivial as you're making it out to be. I'm sorry that you want to be doing the development of the live images for the next release on Fedora 10, but the fact of the matter is that as the base system of Fedora moves onward, it's not just a foregone conclusion that everything can be done on the previous release. Yes, I could push back the single patch for the syslinux path change... but that *isn't* sufficient to make a working rawhide live image while on Fedora 10. You also need things like a) a newer kernel so that your system doesn't livelock while writing to ext4 b) a newer squashfs-tools so that you can build an image that works with the rawhide kernel[1] c) one or two other things are a little different and could have side effects -- sure, those could be tested extensively and dealt with/fixed/whatnot. But that's then effort not spent on implementing things for the future. And given the intended audience of livecd-tools, that's really not the best use of effort.
FWIW, while I don't know how a proper fix would look like (maybe mock could be somehow part of the equation), I think this "building live images only works on the same version of Fedora the live image is of" issue really needs some sort of solution.
Kevin Kofler
On Tue, Mar 10, 2009 at 10:38:30PM +0100, Kevin Kofler wrote:
Jeremy Katz wrote:
So, as the person who has apparently pissed you off this morning, it's not as trivial as you're making it out to be. I'm sorry that you want to be doing the development of the live images for the next release on Fedora 10, but the fact of the matter is that as the base system of Fedora moves onward, it's not just a foregone conclusion that everything can be done on the previous release. Yes, I could push back the single patch for the syslinux path change... but that *isn't* sufficient to make a working rawhide live image while on Fedora 10. You also need things like a) a newer kernel so that your system doesn't livelock while writing to ext4 b) a newer squashfs-tools so that you can build an image that works with the rawhide kernel[1] c) one or two other things are a little different and could have side effects -- sure, those could be tested extensively and dealt with/fixed/whatnot. But that's then effort not spent on implementing things for the future. And given the intended audience of livecd-tools, that's really not the best use of effort.
FWIW, while I don't know how a proper fix would look like (maybe mock could be somehow part of the equation), I think this "building live images only works on the same version of Fedora the live image is of" issue really needs some sort of solution.
Which is exactly how the images are built. In a mock chroot of the version you are building for.
josh
On Tue, 2009-03-10 at 18:44 -0400, Josh Boyer wrote:
Which is exactly how the images are built. In a mock chroot of the version you are building for.
Not the live images. Last I heard, livecd-creator + mock was still a no-go.
On Tue, Mar 10, 2009 at 03:52:39PM -0700, Jesse Keating wrote:
On Tue, 2009-03-10 at 18:44 -0400, Josh Boyer wrote:
Which is exactly how the images are built. In a mock chroot of the version you are building for.
Not the live images. Last I heard, livecd-creator + mock was still a no-go.
Gah, you are correct. I was too hasty. Sorry Kevin
josh
On Tuesday, March 10 2009, Jesse Keating said:
On Tue, 2009-03-10 at 18:44 -0400, Josh Boyer wrote:
Which is exactly how the images are built. In a mock chroot of the version you are building for.
Not the live images. Last I heard, livecd-creator + mock was still a no-go.
With the work that happened for faking out SELinux policy changes for livecd-creator, it should be possible to get mock to better support SELinux which was the main problem from what I remember. That still doesn't help things like "if your kernel isn't new enough, you will live lock writing to ext4" though :-) Or as a possible future "your kernel doesn't support all the btrfs bits".
Jeremy
On Wed, 2009-03-11 at 09:32 -0400, Jeremy Katz wrote:
That still doesn't help things like "if your kernel isn't new enough, you will live lock writing to ext4" though :-)
Uhhhh... so before I go converting my F10 systems to ext4, what kernel version should I be running?
On Friday 13 March 2009 12:29:57 Callum Lerwick wrote:
On Wed, 2009-03-11 at 09:32 -0400, Jeremy Katz wrote:
That still doesn't help things like "if your kernel isn't new enough, you will live lock writing to ext4" though :-)
Uhhhh... so before I go converting my F10 systems to ext4, what kernel version should I be running?
While there are some corner cases here and there, everything recent seems to hold up just fine. I've been using ext4 quite heavily for several months now on F10 boxes -- root and home on my laptop, the data volume where all my source trees are housed on my workstation. Haven't hit any issues w/the latest F10 updates kernel on either system (nor w/the kernel before that, best as I can recall).
Am Dienstag, den 10.03.2009, 10:48 -0400 schrieb Jeremy Katz:
On Tuesday, March 10 2009, Christoph Wickert said:
Am Dienstag, den 10.03.2009, 15:21 +0530 schrieb Rahul Sundaram:
Christoph Wickert wrote:
A note to all Fedora maintainers and especially to the Red Hat people who are involved in development every day:
Please fix your bugs [1] in the release they were filed against instead of just closing them NEXTRELASE!
Doesn't that depend on how serious the bugs are? Sometimes upstream has gone way ahead, changed their configuration format etc and backporting the fix or just pushing the update with all the other changes is too invasive.
Agreed, but in the case I have in mind * the bug is so serious that he makes the package not working * we are upstream and * there is nothing to backport. Nevertheless the maintainer told me to get the rawhide package.
So, as the person who has apparently pissed you off this morning, it's not as trivial as you're making it out to be.
I don't think that I made it trivial. We were talking about two bugs yesterday. One of them requires a lot of changes (# 489431), that's why I wrote that 99% of the fixes should be easy to backport. Obviously 489431 is not.
The other one (# 473584) is an easy to fix crash. I have been spending time on troubleshooting it yesterday, because you were not able to reproduce it, so you closed it right away. I found the issue, provided the details you asked for, but you just closed the bug again 10 minutes later for it was fixed in rawhide (although not really verified). At this point a bug reporter/triager feels you are not valuing his efforts but pulling his leg.
I have to admit that I was pissed off, but this is because it was not the first time you "fixed" a bug this way. Remember bug 318811? livecd-tools were broken in F7 for nearly 8 months you did not fix it, although you already had the fixes in rawhide when I reported that bug. In the end the person who fixed was Robert Scheck, not you as the maintainer.
Please don't get me wrong: I don't want to point fingers, that's why I did not provide names or bug numbers at first. I just wanted to clarify things for all Fedora maintainers and especially Red Hat people, because I have seen many of them behaving just like you.
Regards, Christoph
On Tue, 2009-03-10 at 03:18 +0100, Christoph Wickert wrote:
A note to all Fedora maintainers and especially to the Red Hat people who are involved in development every day:
Please fix your bugs [1] in the release they were filed against instead of just closing them NEXTRELASE!
The last time I pushed an update for e.g. F-10 and ticked the "auto-close bug" bodhi feature. The bugs got closed as "NEXTRELEASE" when the F-10 update was pushed. So it might not be the case that all of those "NEXTRELEASE" closures were actually punted to the next fedora release.
C.
Am Dienstag, den 10.03.2009, 10:25 +0000 schrieb Caolán McNamara:
On Tue, 2009-03-10 at 03:18 +0100, Christoph Wickert wrote:
A note to all Fedora maintainers and especially to the Red Hat people who are involved in development every day:
Please fix your bugs [1] in the release they were filed against instead of just closing them NEXTRELASE!
The last time I pushed an update for e.g. F-10 and ticked the "auto-close bug" bodhi feature. The bugs got closed as "NEXTRELEASE" when the F-10 update was pushed. So it might not be the case that all of those "NEXTRELEASE" closures were actually punted to the next fedora release.
I have to admit that bodhi's behavior is confusing, but it only applies to packages that are getting pushed for F{9,10}. I was talking about maintainers who are not pushing updates for a stable release and tell people to get the packages from rawhide.
C.
Regards, Christoph
On Di März 10 2009, Christoph Wickert wrote:
Please fix your bugs [1] in the release they were filed against instead of just closing them NEXTRELASE!
I know it sounds slinky to just close everything NEXTRELEASE and I know
Currently NEXTRELEASE is used by Bodhi when bugs are closed with updates to stable releases, I guess NEXTREALEASE here means the next release of the package.
Regards, Till
Till Maas wrote:
On Di März 10 2009, Christoph Wickert wrote:
Please fix your bugs [1] in the release they were filed against instead of just closing them NEXTRELASE!
I know it sounds slinky to just close everything NEXTRELEASE and I know
Currently NEXTRELEASE is used by Bodhi when bugs are closed with updates to stable releases, I guess NEXTREALEASE here means the next release of the package.
Regards, Till
A quick comment would clarify for "current" users.
Frank
On Tue, 2009-03-10 at 11:37 +0100, Till Maas wrote:
On Di März 10 2009, Christoph Wickert wrote:
Please fix your bugs [1] in the release they were filed against instead of just closing them NEXTRELASE!
I know it sounds slinky to just close everything NEXTRELEASE and I know
Currently NEXTRELEASE is used by Bodhi when bugs are closed with updates to stable releases, I guess NEXTREALEASE here means the next release of the package.
No, NEXTRELEASE means the next release of the distribution. The status for bugs that are fixed in the same release is ERRATA.
On Tue, 2009-03-10 at 08:17 -0400, Ignacio Vazquez-Abrams wrote:
On Tue, 2009-03-10 at 11:37 +0100, Till Maas wrote:
On Di März 10 2009, Christoph Wickert wrote:
Please fix your bugs [1] in the release they were filed against instead of just closing them NEXTRELASE!
I know it sounds slinky to just close everything NEXTRELEASE and I know
Currently NEXTRELEASE is used by Bodhi when bugs are closed with updates to stable releases, I guess NEXTREALEASE here means the next release of the package.
No, NEXTRELEASE means the next release of the distribution. The status for bugs that are fixed in the same release is ERRATA.
This is how it should be, but bodhi sees it differently and apparently the decision (by whomever, it escaped my memory right now) is to use "NEXTRELEASE" for Fedora updates as "ERRATA" is only for RHEL. NOt that I would follow that logic ;-).
Nils
Am Dienstag, den 10.03.2009, 13:26 +0100 schrieb Nils Philippsen:
On Tue, 2009-03-10 at 08:17 -0400, Ignacio Vazquez-Abrams wrote:
No, NEXTRELEASE means the next release of the distribution. The status for bugs that are fixed in the same release is ERRATA.
This is how it should be, but bodhi sees it differently and apparently the decision (by whomever, it escaped my memory right now) is to use "NEXTRELEASE" for Fedora updates
Sure? At least it used to work properly:
updates@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |CLOSED Resolution|RAWHIDE |CURRENTRELEASE Fixed In Version| |1.9.32-1.fc8
Nils
Regards, Christoph
On Tue, 2009-03-10 at 13:45 +0100, Christoph Wickert wrote:
Am Dienstag, den 10.03.2009, 13:26 +0100 schrieb Nils Philippsen:
On Tue, 2009-03-10 at 08:17 -0400, Ignacio Vazquez-Abrams wrote:
No, NEXTRELEASE means the next release of the distribution. The status for bugs that are fixed in the same release is ERRATA.
This is how it should be, but bodhi sees it differently and apparently the decision (by whomever, it escaped my memory right now) is to use "NEXTRELEASE" for Fedora updates
Sure? At least it used to work properly:
updates@fedoraproject.org changed:
What |Removed |Added
Status|CLOSED |CLOSED Resolution|RAWHIDE |CURRENTRELEASE
Fixed In Version| |1.9.32-1.fc8
Remembered that wrongly, sorry. IMO it should still be ERRATA rather than CURRENTRELEASE, as the latter implies (to me anyway) that it is fixed in the current release of the product (e.g. F-10), and that you shouldn't expect an update for the product release you reported against (e.g. F-9). This is bad because right now we have one bug tracker (bugzilla.redhat.com) where these resolution values are used inconsistently between products (Red Hat products vs. Fedora products).
I won't be filing bugs against Bodhi, though, since this is a question of policy where the proper discussion forum isn't Bodhi's bug tracker IMO.
Nils
On Tue, Mar 10, 2009 at 01:26:28PM +0100, Nils Philippsen wrote:
On Tue, 2009-03-10 at 08:17 -0400, Ignacio Vazquez-Abrams wrote:
On Tue, 2009-03-10 at 11:37 +0100, Till Maas wrote:
On Di März 10 2009, Christoph Wickert wrote:
Please fix your bugs [1] in the release they were filed against instead of just closing them NEXTRELASE!
I know it sounds slinky to just close everything NEXTRELEASE and I know
Currently NEXTRELEASE is used by Bodhi when bugs are closed with updates to stable releases, I guess NEXTREALEASE here means the next release of the package.
No, NEXTRELEASE means the next release of the distribution. The status for bugs that are fixed in the same release is ERRATA.
This is how it should be, but bodhi sees it differently and apparently the decision (by whomever, it escaped my memory right now) is to use "NEXTRELEASE" for Fedora updates as "ERRATA" is only for RHEL. NOt that I would follow that logic ;-).
I wrote the code in bodhi for this, but I recall changing it's behavior a couple of times in the past based on various requests. If you think it should behave differently, please file a ticket.
https://fedorahosted.org/bodhi/newticket
Thanks,
luke
On Tue, 2009-03-10 at 03:18 +0100, Christoph Wickert wrote:
A note to all Fedora maintainers and especially to the Red Hat people who are involved in development every day:
Please fix your bugs [1] in the release they were filed against instead of just closing them NEXTRELASE!
I know it sounds slinky to just close everything NEXTRELEASE and I know I sucks to get reports of bugs you've already fixed. But in 99% of all cases it shouldn't be to hard to get the fix also into the stable release.
Hm... I am getting confused here. I thought NEXTRELEASE relates to package release not distro release, whereas RAWHIDE is what is supposed to be used when fixed in rawhide... At least one of us definitely needs to be wrong...
But anyway, I got your message and I fully agree with that.
Martin
On Tue, Mar 10, 2009 at 05:49:10PM +0100, Martin Sourada wrote:
On Tue, 2009-03-10 at 03:18 +0100, Christoph Wickert wrote:
A note to all Fedora maintainers and especially to the Red Hat people who are involved in development every day:
Please fix your bugs [1] in the release they were filed against instead of just closing them NEXTRELASE!
I know it sounds slinky to just close everything NEXTRELEASE and I know I sucks to get reports of bugs you've already fixed. But in 99% of all cases it shouldn't be to hard to get the fix also into the stable release.
Hm... I am getting confused here. I thought NEXTRELEASE relates to package release not distro release, whereas RAWHIDE is what is supposed to be used when fixed in rawhide... At least one of us definitely needs to be wrong...
If that were the case, then CURRENTRELEASE would make no sense.
On Tue, 2009-03-10 at 13:06 -0400, Chuck Anderson wrote:
On Tue, Mar 10, 2009 at 05:49:10PM +0100, Martin Sourada wrote:
On Tue, 2009-03-10 at 03:18 +0100, Christoph Wickert wrote:
A note to all Fedora maintainers and especially to the Red Hat people who are involved in development every day:
Please fix your bugs [1] in the release they were filed against instead of just closing them NEXTRELASE!
I know it sounds slinky to just close everything NEXTRELEASE and I know I sucks to get reports of bugs you've already fixed. But in 99% of all cases it shouldn't be to hard to get the fix also into the stable release.
Hm... I am getting confused here. I thought NEXTRELEASE relates to package release not distro release, whereas RAWHIDE is what is supposed to be used when fixed in rawhide... At least one of us definitely needs to be wrong...
If that were the case, then CURRENTRELEASE would make no sense.
Indeed... That sort of slipped my attention. Makes sense.
Martin
On Tuesday 10 March 2009 13:06:32 Chuck Anderson wrote:
On Tue, Mar 10, 2009 at 05:49:10PM +0100, Martin Sourada wrote:
On Tue, 2009-03-10 at 03:18 +0100, Christoph Wickert wrote:
A note to all Fedora maintainers and especially to the Red Hat people who are involved in development every day:
Please fix your bugs [1] in the release they were filed against instead of just closing them NEXTRELASE!
I know it sounds slinky to just close everything NEXTRELEASE and I know I sucks to get reports of bugs you've already fixed. But in 99% of all cases it shouldn't be to hard to get the fix also into the stable release.
Hm... I am getting confused here. I thought NEXTRELEASE relates to package release not distro release, whereas RAWHIDE is what is supposed to be used when fixed in rawhide... At least one of us definitely needs to be wrong...
If that were the case, then CURRENTRELEASE would make no sense.
https://bugzilla.redhat.com/page.cgi?id=fields.html
Hm... I am getting confused here. I thought NEXTRELEASE relates to package release not distro release, whereas RAWHIDE is what is supposed to be used when fixed in rawhide... At least one of us definitely needs to be wrong...
If that were the case, then CURRENTRELEASE would make no sense.
Is there any other documents which clearly defines RAWHIDE, CURRENTRELEASE and NEXTRELEASE? They all can have different and same interpretations at the same time, which is adding to the confusion. CURRENTRELEASE is the most confusing one, as it is neither rawhide nor necessarily the release for which the bug was filed. What is unsupported or unreleased product if it is not rawhide or devel?
On Tue, Mar 10, 2009 at 01:30:08PM -0400, Jarod Wilson wrote:
On Tuesday 10 March 2009 13:06:32 Chuck Anderson wrote:
On Tue, Mar 10, 2009 at 05:49:10PM +0100, Martin Sourada wrote:
On Tue, 2009-03-10 at 03:18 +0100, Christoph Wickert wrote:
A note to all Fedora maintainers and especially to the Red Hat people who are involved in development every day:
Please fix your bugs [1] in the release they were filed against instead of just closing them NEXTRELASE!
I know it sounds slinky to just close everything NEXTRELEASE and I know I sucks to get reports of bugs you've already fixed. But in 99% of all cases it shouldn't be to hard to get the fix also into the stable release.
Hm... I am getting confused here. I thought NEXTRELEASE relates to package release not distro release, whereas RAWHIDE is what is supposed to be used when fixed in rawhide... At least one of us definitely needs to be wrong...
If that were the case, then CURRENTRELEASE would make no sense.
How did you find that? I was looking for it, but couldn't find it linked from anywhere.
Chuck Anderson wrote:
How did you find that? I was looking for it, but couldn't find it linked from anywhere.
It's linked, at least, in the word "Status" at the bottom of each bug, next to the drop-down where you would set the status.
On Tue, 2009-03-10 at 14:24 -0400, Todd Zullinger wrote:
Chuck Anderson wrote:
How did you find that? I was looking for it, but couldn't find it linked from anywhere.
It's linked, at least, in the word "Status" at the bottom of each bug, next to the drop-down where you would set the status.
I think there may be some confusion here caused by the fact that RHEL and Fedora seem to use rather different conventions. The info in that page is mostly to do with the RHEL process, not the Fedora one.
For RHEL, 'NEXTRELEASE' means 'it'll be fixed in the next version of RHEL, but not this one'. For Fedora, 'RAWHIDE' seems to be used for this. I'm not sure there's a benefit in having both of these.
As you can see from that page, 'CURRENTRELEASE' has a specific meaning for RHEL which doesn't translate to what some people seem to believe it should be used for, for Fedora. For RHEL it doesn't mean 'it existed in a stable release and will be fixed with an update to the release against which it was reported' - that's what ERRATA means.
Possibly the clearest thing to do would just be to use the same flow RHEL uses, even if the names would be a bit odd for Fedora (since we don't really have 'Errata' for Fedora releases). Otherwise, the Fedora flow should at least be clearly defined somewhere, and explained on that page in Bugzilla.
On Tue, Mar 10, 2009 at 11:57:10AM -0700, Adam Williamson wrote:
On Tue, 2009-03-10 at 14:24 -0400, Todd Zullinger wrote:
Chuck Anderson wrote:
How did you find that? I was looking for it, but couldn't find it linked from anywhere.
It's linked, at least, in the word "Status" at the bottom of each bug, next to the drop-down where you would set the status.
[snip]
Possibly the clearest thing to do would just be to use the same flow RHEL uses, even if the names would be a bit odd for Fedora (since we don't really have 'Errata' for Fedora releases). Otherwise, the Fedora flow should at least be clearly defined somewhere, and explained on that page in Bugzilla.
The Fedora bug flow is defined here:
https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow
Although it is lacking clear guidelines on the choice of sub-state for the CLOSED state. That just requires a little docs work on the wiki.
Daniel
"Daniel P. Berrange" berrange@redhat.com writes:
The Fedora bug flow is defined here:
Although it is lacking clear guidelines on the choice of sub-state for the CLOSED state. That just requires a little docs work on the wiki.
Well, the choice of sub-state is exactly what's being debated here. I think it's more than a "missing docs" problem, since (1) it's not clear that we have a consensus, and (2) bodhi doesn't read docs. Whatever we settle on will have to be implemented in bodhi.
Another thing that would be nice is to get bugzilla to show a link to this page instead of the RHEL one when looking at a Fedora bug.
BTW, I notice that this diagram seems to treat NEEDINFO as an independent state, which is no longer true --- it's just a flag now.
regards, tom lane
On Tue, Mar 10, 2009 at 11:56 AM, Tom Lane tgl@redhat.com wrote:
"Daniel P. Berrange" berrange@redhat.com writes:
The Fedora bug flow is defined here:
Although it is lacking clear guidelines on the choice of sub-state for the CLOSED state. That just requires a little docs work on the wiki.
Well, the choice of sub-state is exactly what's being debated here. I think it's more than a "missing docs" problem, since (1) it's not clear that we have a consensus, and (2) bodhi doesn't read docs. Whatever we settle on will have to be implemented in bodhi.
Another thing that would be nice is to get bugzilla to show a link to this page instead of the RHEL one when looking at a Fedora bug.
BTW, I notice that this diagram seems to treat NEEDINFO as an independent state, which is no longer true --- it's just a flag now.
regards, tom lane
Tom, There should be a new version soon, it was brought up in IRC a while ago, and the task was assigned today in the Bugzappers meeting.
On Tue, 2009-03-10 at 19:10 +0000, Daniel P. Berrange wrote:
On Tue, Mar 10, 2009 at 11:57:10AM -0700, Adam Williamson wrote:
On Tue, 2009-03-10 at 14:24 -0400, Todd Zullinger wrote:
Chuck Anderson wrote:
How did you find that? I was looking for it, but couldn't find it linked from anywhere.
It's linked, at least, in the word "Status" at the bottom of each bug, next to the drop-down where you would set the status.
[snip]
Possibly the clearest thing to do would just be to use the same flow RHEL uses, even if the names would be a bit odd for Fedora (since we don't really have 'Errata' for Fedora releases). Otherwise, the Fedora flow should at least be clearly defined somewhere, and explained on that page in Bugzilla.
The Fedora bug flow is defined here:
https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow
Although it is lacking clear guidelines on the choice of sub-state for the CLOSED state. That just requires a little docs work on the wiki.
Hehe. I was actually going to link to that page and then didn't, for two reasons:
1) as you say, it fudges the CLOSED resolutions anyway 2) it's being revised (we're working on it today) since NEEDINFO isn't a status these days.
On Tue, Mar 10, 2009 at 10:57 AM, Adam Williamson awilliam@redhat.com wrote:
Possibly the clearest thing to do would just be to use the same flow RHEL uses, even if the names would be a bit odd for Fedora (since we don't really have 'Errata' for Fedora releases). Otherwise, the Fedora flow should at least be clearly defined somewhere, and explained on that page in Bugzilla.
Or fedora migrates to a different bug tracking system dedicated to Fedora workflow without any of the rhel memes hanging around.
-jef"Hopes his wife doesn't concluded that he got sick and lost his voice as an excuse to not talk to the in-laws at all this week while they are visiting"spaleta
Jeff Spaleta wrote:
On Tue, Mar 10, 2009 at 10:57 AM, Adam Williamson awilliam@redhat.com wrote:
Possibly the clearest thing to do would just be to use the same flow RHEL uses, even if the names would be a bit odd for Fedora (since we don't really have 'Errata' for Fedora releases). Otherwise, the Fedora flow should at least be clearly defined somewhere, and explained on that page in Bugzilla.
Or fedora migrates to a different bug tracking system dedicated to Fedora workflow without any of the rhel memes hanging around.
I suppose we can do that as long as we have a way for the Fedora bugzilla instance and the RHEL bugzilla instance to talk to each other cleanly.
Rahul
On Tue, Mar 10, 2009 at 11:36 AM, Rahul Sundaram sundaram@fedoraproject.org wrote:
I suppose we can do that as long as we have a way for the Fedora bugzilla instance and the RHEL bugzilla instance to talk to each other cleanly.
Who said Fedora's bug warehouse had to be bugzilla?
-jef
Jeff Spaleta (jspaleta@gmail.com) said:
On Tue, Mar 10, 2009 at 11:36 AM, Rahul Sundaram sundaram@fedoraproject.org wrote:
I suppose we can do that as long as we have a way for the Fedora bugzilla instance and the RHEL bugzilla instance to talk to each other cleanly.
Who said Fedora's bug warehouse had to be bugzilla?
Bugzilla is the worst bug tracker there is... except for all the others.
Frankly, unless you have hardware, bandwidth, and admin lined up for a new bug system (and a way to import all the old data, *preferably with keeping the numbers and links intact*), I'm not sure we're ready to go down this road.
Bill
Jeff Spaleta wrote:
On Tue, Mar 10, 2009 at 11:36 AM, Rahul Sundaram wrote:
I suppose we can do that as long as we have a way for the Fedora bugzilla instance and the RHEL bugzilla instance to talk to each other cleanly.
Who said Fedora's bug warehouse had to be bugzilla?
What else would it be? You don't have to make it seem so mysterious. Just give us more details on what your proposal actually is.
Rahul
On Wed, 2009-03-11 at 01:21 +0530, Rahul Sundaram wrote:
Jeff Spaleta wrote:
On Tue, Mar 10, 2009 at 11:36 AM, Rahul Sundaram wrote:
I suppose we can do that as long as we have a way for the Fedora bugzilla instance and the RHEL bugzilla instance to talk to each other cleanly.
Who said Fedora's bug warehouse had to be bugzilla?
What else would it be? You don't have to make it seem so mysterious. Just give us more details on what your proposal actually is.
I wish it could be Launchpad, because it's zillions of times better than Bugzilla for distributions (it handles SCM integration, integration with other tracking systems, and multiple release management excellently). There's just that little open source problem :\
It is worth keeping in mind, though, because it demonstrates in concrete form that there really are things that could be handled *way* better than they are in Bugzilla, for a Linux distribution.
Adam Williamson wrote:
I wish it could be Launchpad, because it's zillions of times better than Bugzilla for distributions (it handles SCM integration, integration with other tracking systems, and multiple release management excellently). There's just that little open source problem :\
It is worth keeping in mind, though, because it demonstrates in concrete form that there really are things that could be handled *way* better than they are in Bugzilla, for a Linux distribution.
Launchpad is pretty horrid for an upstream tool though... or rather as a consumer trying to get something from the upstream tool. It would be interesting to see an instance that was just a downstream, distribution tool and didn't confuse things with upstream stuff as well.
-Toshio
On Tue, 2009-03-10 at 14:01 -0700, Adam Williamson wrote:
I wish it could be Launchpad, because it's zillions of times better than Bugzilla for distributions (it handles SCM integration, integration with other tracking systems, and multiple release management excellently). There's just that little open source problem :\
And yet I get totally lost every time I try to find something in launch pad.
Adam Williamson wrote:
On Wed, 2009-03-11 at 01:21 +0530, Rahul Sundaram wrote:
Jeff Spaleta wrote:
On Tue, Mar 10, 2009 at 11:36 AM, Rahul Sundaram wrote:
I suppose we can do that as long as we have a way for the Fedora bugzilla instance and the RHEL bugzilla instance to talk to each other cleanly.
Who said Fedora's bug warehouse had to be bugzilla?
What else would it be? You don't have to make it seem so mysterious. Just give us more details on what your proposal actually is.
I wish it could be Launchpad, because it's zillions of times better than Bugzilla for distributions (it handles SCM integration, integration with other tracking systems, and multiple release management excellently). There's just that little open source problem :\
That's in getting partially fixed in a few months
https://dev.launchpad.net/OpenSourcing
There are still two components that are going to remain proprietary as part of Canonical "secret sauce" business model but maybe can just replace that for our needs and of course Launchpad will probably be stuck with bzr while we need to support other SCM's as well.
Rahul
On Tue, Mar 10, 2009 at 1:45 PM, Rahul Sundaram sundaram@fedoraproject.org wrote:
There are still two components that are going to remain proprietary as part of Canonical "secret sauce" business model but maybe can just replace that for our needs and of course Launchpad will probably be stuck with bzr while we need to support other SCM's as well.
I think Canonical hasn't been as forthcoming as they could about how important the not to be released CodeHosting is to actually making any implementation of launchpad work on a daily basis. Take that as speculation on my part of course, since what is publicly avaliable concerning the role of the CodeHosting component is quite sparse.
But I wouldn't hold my breath for the Malone component being opened in such a way that it was easily turned into a stand alone bug tracking service. And I don't think we'll see the point in investing the manpower to reverse engineer CodeHosting just to get an alternative bug tracker working.
-jef
On Tuesday 10 March 2009, Rahul Sundaram wrote:
[...] and of course Launchpad will probably be stuck with bzr while we need to support other SCM's as well.
Even if this is not a substitute for real "native" integration, I've heard that Launchpad has continuous cvs and svn imports and that it is planned for git too.
http://lists.alioth.debian.org/pipermail/bash-completion-devel/2009-February...
This is not to advocate LP in any way, I haven't even really used it myself. Just thought I'd mention it.
Ville Skyttä wrote:
On Tuesday 10 March 2009, Rahul Sundaram wrote:
[...] and of course Launchpad will probably be stuck with bzr while we need to support other SCM's as well.
Even if this is not a substitute for real "native" integration, I've heard that Launchpad has continuous cvs and svn imports and that it is planned for git too.
What does that mean in practise? I can pull but not push?
Rahul
On Wednesday 11 March 2009, Rahul Sundaram wrote:
Ville Skyttä wrote:
On Tuesday 10 March 2009, Rahul Sundaram wrote:
[...] and of course Launchpad will probably be stuck with bzr while we need to support other SCM's as well.
Even if this is not a substitute for real "native" integration, I've heard that Launchpad has continuous cvs and svn imports and that it is planned for git too.
What does that mean in practise? I can pull but not push?
Probably. As said, I haven't used LP myself. Pull only would probably not be that interesting, but I guess this would provide the possibility of browsing the code and change histories on LP web, linking from them to bug numbers, searching the code and possibly some other integration (I don't know if LP has all of these even for bzr thought). How interesting this is depends what the requirements for "we need to support other SCM's as well" are and whether it implies that LP needs to be some way more tightly integrated with them.
On Wed, 2009-03-11 at 03:15 +0530, Rahul Sundaram wrote:
There are still two components that are going to remain proprietary as part of Canonical "secret sauce" business model but maybe can just replace that for our needs and of course Launchpad will probably be stuck with bzr while we need to support other SCM's as well.
Yes. There are bad implementation details in Launchpad for sure. I was more viewing it as a good model of the things that Bugzilla really doesn't do well - tracking bugs across different projects, and managing multiple releases of a distribution (since it wasn't designed to do either of those).
Adam Williamson said the following on 03/11/2009 07:32 AM Pacific Time:
On Wed, 2009-03-11 at 03:15 +0530, Rahul Sundaram wrote:
There are still two components that are going to remain proprietary as part of Canonical "secret sauce" business model but maybe can just replace that for our needs and of course Launchpad will probably be stuck with bzr while we need to support other SCM's as well.
Yes. There are bad implementation details in Launchpad for sure. I was more viewing it as a good model of the things that Bugzilla really doesn't do well - tracking bugs across different projects, and managing multiple releases of a distribution (since it wasn't designed to do either of those).
The guided process process of filing new bugs in Launchpad is extremely smooth and user friendly--no comparison to all the fields you have to manually select and scroll from in bugzilla. Before filing my bug it also prompted me with a listing of existing bugs to see if my issue already existed--a very useful way to catch and reduce duplicates.
I've only filed one bug at Launchpad. It was for an upstream project that lives there and I was given a direct URL to it by the maintainer so maybe my experience is not representative of most.
John
John Poelstra wrote:
The guided process process of filing new bugs in Launchpad is extremely smooth and user friendly--no comparison to all the fields you have to manually select and scroll from in bugzilla. Before filing my bug it also prompted me with a listing of existing bugs to see if my issue already existed--a very useful way to catch and reduce duplicates.
Well, KDE's Bugzilla instance has a wizard interface for filing bugs and it also shows a list of existing bugs which it may be a duplicate of (based on keywords in the subject).
Their customizations can be found at: http://websvn.kde.org/branches/bugs/3.2/ (I wish the RH customizations were published in a similar way. They had promised getting them into Fedora at some point, but that never happened, the bugzilla package now in Fedora is a plain vanilla Bugzilla maintained by a community volunteer.)
Kevin Kofler
John Poelstra wrote:
The guided process process of filing new bugs in Launchpad is extremely smooth and user friendly--no comparison to all the fields you have to manually select and scroll from in bugzilla. Before filing my bug it also prompted me with a listing of existing bugs to see if my issue already existed--a very useful way to catch and reduce duplicates.
Well, KDE's Bugzilla instance has a wizard interface for filing bugs and it also shows a list of existing bugs which it may be a duplicate of (based on keywords in the subject).
Their customizations can be found at: http://websvn.kde.org/branches/bugs/3.2/ (I wish the RH customizations were published in a similar way. They had promised getting them into Fedora at some point, but that never happened, the bugzilla package now in Fedora is a plain vanilla Bugzilla maintained by a community volunteer.)
Kevin Kofler
Am Donnerstag, den 12.03.2009, 10:22 -0700 schrieb John Poelstra:
The guided process process of filing new bugs in Launchpad is extremely smooth and user friendly--no comparison to all the fields you have to manually select and scroll from in bugzilla.
Yes, it's easy, but my experience is that I had edit a lot of fields manually afterward. If you want a user friendly way of filing bugs, take a look at Gnome's bugzilla, their guided ("simple") mode is much better than ours (because we only have advanced mode)
Before filing my bug it also prompted me with a listing of existing bugs to see if my issue already existed--a very useful way to catch and reduce duplicates.
Our bugzilla did that too once in simple mode (when we had the simple mode).
Regards, Christoph
Am Dienstag, den 10.03.2009, 14:01 -0700 schrieb Adam Williamson:
On Wed, 2009-03-11 at 01:21 +0530, Rahul Sundaram wrote:
Jeff Spaleta wrote:
On Tue, Mar 10, 2009 at 11:36 AM, Rahul Sundaram wrote:
I suppose we can do that as long as we have a way for the Fedora bugzilla instance and the RHEL bugzilla instance to talk to each other cleanly.
Who said Fedora's bug warehouse had to be bugzilla?
What else would it be? You don't have to make it seem so mysterious. Just give us more details on what your proposal actually is.
I wish it could be Launchpad, because it's zillions of times better than Bugzilla for distributions [...]
I strongly disagree. Maybe I'm going to reconsider my opinion if anybody can tell me how to restrict the search in LP to an individual component or release. I already asked on several Ubuntu channels but nobody was able (or willing¹) to answer my question.
Regards, Christoph
¹ In fact I got flamed because of my "fedora" cloak, bit that's a different story...
On Tue, 2009-03-10 at 23:45 +0100, Christoph Wickert wrote:
I wish it could be Launchpad, because it's zillions of times better than Bugzilla for distributions [...]
I strongly disagree. Maybe I'm going to reconsider my opinion if anybody can tell me how to restrict the search in LP to an individual component or release. I already asked on several Ubuntu channels but nobody was able (or willing¹) to answer my question.
Actually, from a quick glance, you seem to be right - the search interface looks terrible.
I should have been more careful in my mail. I haven't done a careful LP / Bugzilla comparative analysis. It's more just that whenever I look at an issue in LP, I see the things that we're *really* missing in BZ, simply because BZ was never designed as an issue tracker for distributions. I really wanted to look at LP as a model for those things, not suggest that it's perfect as-is.
On Wed, Mar 11, 2009 at 07:46:33AM -0700, Adam Williamson wrote:
Actually, from a quick glance, you seem to be right - the search interface looks terrible.
I should have been more careful in my mail. I haven't done a careful LP / Bugzilla comparative analysis. It's more just that whenever I look at an issue in LP, I see the things that we're *really* missing in BZ, simply because BZ was never designed as an issue tracker for distributions. I really wanted to look at LP as a model for those things, not suggest that it's perfect as-is.
You're comparing Apples and Oranges... Bugzilla is a bug tracker. Malone is a bug tracker. *Launchpad* is a Debian packager workflow tool.
Comparing Launchpad to Bugzilla is silly, comparing it to Koji + Bodhi + Bugzilla + FAS + CVS is more fair.
regards, Kyle
On Wed, 2009-03-11 at 11:52 -0400, Kyle McMartin wrote:
On Wed, Mar 11, 2009 at 07:46:33AM -0700, Adam Williamson wrote:
Actually, from a quick glance, you seem to be right - the search interface looks terrible.
I should have been more careful in my mail. I haven't done a careful LP / Bugzilla comparative analysis. It's more just that whenever I look at an issue in LP, I see the things that we're *really* missing in BZ, simply because BZ was never designed as an issue tracker for distributions. I really wanted to look at LP as a model for those things, not suggest that it's perfect as-is.
You're comparing Apples and Oranges... Bugzilla is a bug tracker. Malone is a bug tracker. *Launchpad* is a Debian packager workflow tool.
Comparing Launchpad to Bugzilla is silly, comparing it to Koji + Bodhi + Bugzilla + FAS + CVS is more fair.
Well, I don't really see it that way. Here's my workflow - I come across a link to an Ubuntu bug report (at launchpad.net), so I go and look at it, and I see the stuff I like - right at the top I can see that it exists in, say, Itchy, Scratchy and Dopey(*), as well as in the upstream code (and I can immediately see the status of the upstream report). This is the stuff that there's just no good way to do in Bugzilla. Believe me, I've thought of about sixteen different ways to try and track the same bug across multiple distribution releases in Bugzilla, and there isn't any one which handles it as well as Launchpad does.
Or Malone. Fine, call it Malone if you like. I'm sure you get my point. There's not much to be gained by being over-nice with the terminology.
On 03/11/2009 12:04 PM, Adam Williamson wrote:
Well, I don't really see it that way. Here's my workflow - I come across a link to an Ubuntu bug report (at launchpad.net), so I go and look at it, and I see the stuff I like - right at the top I can see that it exists in, say, Itchy, Scratchy and Dopey(*), as well as in the upstream code (and I can immediately see the status of the upstream report). This is the stuff that there's just no good way to do in Bugzilla. Believe me, I've thought of about sixteen different ways to try and track the same bug across multiple distribution releases in Bugzilla, and there isn't any one which handles it as well as Launchpad does.
So, the longer term plan is to enable workflows like this in the "Fedora Community" application (used to be called "MyFedora") with moksha.
/* Look at our pretty mockups! https://fedoraproject.org/wiki/FedoraCommunity/Mockups */
It won't happen in the first iteration (coming soon!), but it is something that I think we want to target for the second milestone. We'll definitely be looking for feedback on some example workflows that people would like to be able to use in Fedora.
~spot
On Wed, 2009-03-11 at 12:22 -0400, Tom "spot" Callaway wrote:
On 03/11/2009 12:04 PM, Adam Williamson wrote:
Well, I don't really see it that way. Here's my workflow - I come across a link to an Ubuntu bug report (at launchpad.net), so I go and look at it, and I see the stuff I like - right at the top I can see that it exists in, say, Itchy, Scratchy and Dopey(*), as well as in the upstream code (and I can immediately see the status of the upstream report). This is the stuff that there's just no good way to do in Bugzilla. Believe me, I've thought of about sixteen different ways to try and track the same bug across multiple distribution releases in Bugzilla, and there isn't any one which handles it as well as Launchpad does.
So, the longer term plan is to enable workflows like this in the "Fedora Community" application (used to be called "MyFedora") with moksha.
/* Look at our pretty mockups! https://fedoraproject.org/wiki/FedoraCommunity/Mockups */
It won't happen in the first iteration (coming soon!), but it is something that I think we want to target for the second milestone. We'll definitely be looking for feedback on some example workflows that people would like to be able to use in Fedora.
Well, fine, if it's an overlay on top of Bugzilla I guess that could work.
I see nothing in those mockups that would address this, however. In fact, the bug mockup specifically shows each report as related to a single release.
The use cases I care about are exactly as I wrote: I need to be able to look at a bug report and see what releases it expects. We need to be able to set the status of the bug independently for each release it affects - it could be WONTFIX for F-9, ASSIGNED for F-10 and FIXED for Rawhide. We need to be able to associate it with reports in other bug tracking systems, as LP does, and see the status of these other reports directly from the Fedora report. And this needs to be searchable (I need to be able to search for bugs which are NEW in F-10, and get the right results).
(There's other things talked about in the text accompanying the bug mockup that I might want to talk to you about, but I'll save that from messing up this thread :>)
On Wed, 2009-03-11 at 10:06 -0700, Adam Williamson wrote:
The use cases I care about are exactly as I wrote: I need to be able to look at a bug report and see what releases it expects.
s/expects/affects/
these 6 o' clock mornings are not agreeing with me...
On Wed, 2009-03-11 at 10:06 -0700, Adam Williamson wrote:
The use cases I care about are exactly as I wrote: I need to be able to look at a bug report and see what releases it expects. We need to be able to set the status of the bug independently for each release it affects - it could be WONTFIX for F-9, ASSIGNED for F-10 and FIXED for Rawhide. We need to be able to associate it with reports in other bug tracking systems, as LP does, and see the status of these other reports directly from the Fedora report. And this needs to be searchable (I need to be able to search for bugs which are NEW in F-10, and get the right results).
Just noticed another nice LP feature in the ext4 bug report someone just linked to:
"I'm going to mark this bug as "affecting" ecryptfs-utils, but mark it "invalid", such that search results for users with the same problem might find themselves here."
Can't do THAT in BZ, either.
https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781 , comment from Dustin Kirkland on 2009-03-07 (on the negative side of the ledger, LP comments don't appear to be numbered :>). Permalink is https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/317781/comments/57 (so there's the hidden comment number...)
Em Wed, Mar 11, 2009 at 09:04:17AM -0700, Adam Williamson escreveu:
Well, I don't really see it that way. Here's my workflow - I come across a link to an Ubuntu bug report (at launchpad.net), so I go and look at it, and I see the stuff I like - right at the top I can see that it exists in, say, Itchy, Scratchy and Dopey(*), as well as in the upstream code (and I can immediately see the status of the upstream report). This is the stuff that there's just no good way to do in Bugzilla. Believe me, I've thought of about sixteen different ways to try and track the same bug across multiple distribution releases in Bugzilla, and there isn't any one which handles it as well as Launchpad does.
at least the upstream link/status seems to be addressed by "See Also" field and webservices, currently under development:
http://www.bugzilla.org/status/2009-02-02.html
[]s Wanderlei Antonio Cavassin Mandriva Linux
On Wed, 2009-03-11 at 15:47 -0300, Wanderlei Antonio Cavassin wrote:
Em Wed, Mar 11, 2009 at 09:04:17AM -0700, Adam Williamson escreveu:
Well, I don't really see it that way. Here's my workflow - I come across a link to an Ubuntu bug report (at launchpad.net), so I go and look at it, and I see the stuff I like - right at the top I can see that it exists in, say, Itchy, Scratchy and Dopey(*), as well as in the upstream code (and I can immediately see the status of the upstream report). This is the stuff that there's just no good way to do in Bugzilla. Believe me, I've thought of about sixteen different ways to try and track the same bug across multiple distribution releases in Bugzilla, and there isn't any one which handles it as well as Launchpad does.
at least the upstream link/status seems to be addressed by "See Also" field and webservices, currently under development:
We do actually have the upstream linking feature in current RH Bugzilla. I hadn't noticed that it does the live status stuff, but it does in fact seem to.
Le Mar 10 mars 2009 20:42, Jeff Spaleta a écrit :
On Tue, Mar 10, 2009 at 11:36 AM, Rahul Sundaram sundaram@fedoraproject.org wrote:
I suppose we can do that as long as we have a way for the Fedora bugzilla instance and the RHEL bugzilla instance to talk to each other cleanly.
Who said Fedora's bug warehouse had to be bugzilla?
Be serious. Even SUN uses bugzilla for openjdk (and the java people like to reinvent wheels many times over)
Christopher Aillon wrote:
On 03/10/2009 12:36 PM, Rahul Sundaram wrote:
I suppose we can do that as long as we have a way for the Fedora bugzilla instance and the RHEL bugzilla instance to talk to each other cleanly.
Bugzilla has had this capability forever. I've seen it work, too!
Well I have seen this put up as a reason why Fedora should not have it's own bugzilla instance and I haven't seen bugzilla do this yet and I am not sure how well it does work. Where are you using it?
Rahul
On Wed, Mar 11, 2009 at 01:28:44AM +0530, Rahul Sundaram wrote:
Christopher Aillon wrote:
On 03/10/2009 12:36 PM, Rahul Sundaram wrote:
I suppose we can do that as long as we have a way for the Fedora bugzilla instance and the RHEL bugzilla instance to talk to each other cleanly.
Bugzilla has had this capability forever. I've seen it work, too!
Well I have seen this put up as a reason why Fedora should not have it's own bugzilla instance and I haven't seen bugzilla do this yet and I am not sure how well it does work. Where are you using it?
There are lots of bug mirroring tools out there for bugzilla. A number of them already talk to the Red Hat bugzilla instance.
josh
Josh Boyer wrote:
On Wed, Mar 11, 2009 at 01:28:44AM +0530, Rahul Sundaram wrote:
Christopher Aillon wrote:
On 03/10/2009 12:36 PM, Rahul Sundaram wrote:
I suppose we can do that as long as we have a way for the Fedora bugzilla instance and the RHEL bugzilla instance to talk to each other cleanly.
Bugzilla has had this capability forever. I've seen it work, too!
Well I have seen this put up as a reason why Fedora should not have it's own bugzilla instance and I haven't seen bugzilla do this yet and I am not sure how well it does work. Where are you using it?
There are lots of bug mirroring tools out there for bugzilla. A number of them already talk to the Red Hat bugzilla instance.
To be more specific, I am talking about say GNOME or KDE bugzilla talking to Red Hat bugzilla instance or something like that. Even otherwise, I would like specific examples so that I can try this out.
Rahul
Christoph Wickert wrote:
A note to all Fedora maintainers and especially to the Red Hat people who are involved in development every day:
Please fix your bugs [1] in the release they were filed against instead of just closing them NEXTRELASE!
Related annoyance: bugfixes getting pushed only for the latest release and not for the previous, still supported release.
If you push out a bugfix to F10, please also push it out to F9 at the same time unless there's a really good reason not to!
Kevin Kofler
On 2009-03-10, 21:45 GMT, Kevin Kofler wrote:
If you push out a bugfix to F10, please also push it out to F9 at the same time unless there's a really good reason not to!
I think this is actually a) highly contoversial, b) certainly not possible to solve by blanket rule for everybody.
Matěj
On Wed, 2009-03-11 at 00:38 +0100, Matej Cepl wrote:
On 2009-03-10, 21:45 GMT, Kevin Kofler wrote:
If you push out a bugfix to F10, please also push it out to F9 at the same time unless there's a really good reason not to!
I think this is actually a) highly contoversial, b) certainly not possible to solve by blanket rule for everybody.
Sufficiently disparate code base (which is probably the case with X11 between F-9 and F-10) is a really good reason not to push for both releases at the same time, you probably would have to evaluate if a specific issue is present in the older version at all, then adapt the fix. This doesn't make invalid what Kevin said, the "blanket rule" already covers those cases where it's not feasible to do so.
Nils
On 2009-03-11, 13:46 GMT, Nils Philippsen wrote:
Sufficiently disparate code base (which is probably the case with X11 between F-9 and F-10) is a really good reason not to push for both releases at the same time, you probably would
OK, I should be more specific -- my biggest problem is not with disparate code base, but with users of older distro (which I presume want them for their bigger stability) not being spammed with every fart maintainer generates.
Matej
Matej Cepl wrote:
OK, I should be more specific -- my biggest problem is not with disparate code base, but with users of older distro (which I presume want them for their bigger stability) not being spammed with every fart maintainer generates.
A bugfix is not a "fart" nor should it impact stability.
Kevin Kofler