For the past several days I've been getting daily nagmails about the fact that libtiff hasn't been pushed into f13 (example attached). Because it's a critpath package, I as the lowly maintainer do not have privileges to push it stable, not even after two weeks. Those who do have privileges to approve this sort of thing evidently are paying no attention to f13 packages, not even security bugs on critpath packages.
I will refrain from ranting, and just point out that something is pretty darn broken about this process. Why are the nagmails going to someone with no power to fix the problem? Shouldn't somebody with approval power be paying more than zero attention to older branches?
regards, tom lane
------- Forwarded Message
Date: Sat, 09 Apr 2011 00:00:43 +0000 From: updates@fedoraproject.org To: tgl@redhat.com Subject: [Fedora Update] [CRITPATH] [old_testing_critpath] libtiff-3.9.4-4.fc13
The critical path update for libtiff-3.9.4-4.fc13 has been in 'testing' status for over 2 weeks, and has yet to be approved.
================================================================================ libtiff-3.9.4-4.fc13 ================================================================================ Update ID: FEDORA-2011-3827 Release: Fedora 13 Status: testing Type: security Karma: 0 Bugs: 684939 - CVE-2011-1167 libtiff: heap-based buffer overflow in : thunder decoder (ZDI-11-107) : 684007 - libtiff fails to decode some G4 images : correctly : 678635 - CVE-2011-0192 libtiff: buffer overflow in : Fax4Decode Notes: Fix incorrect fix for CVE-2011-0192 Add fix for CVE-2011-1167 : Fix buffer overrun in fax decoding (CVE-2011-0192) as : well as a non-security-critical crash in gif2tiff. Submitter: tgl Submitted: 2011-03-21 20:38:28 Comments: bodhi - 2011-03-21 20:38:42 (karma 0) This update has been submitted for testing by tgl.
bodhi - 2011-03-22 18:53:10 (karma 0) This update has been pushed to testing
https://admin.fedoraproject.org/updates/libtiff-3.9.4-4.fc13
------- End of Forwarded Message
On Fri, 2011-04-08 at 20:27 -0400, Tom Lane wrote:
I will refrain from ranting, and just point out that something is pretty darn broken about this process. Why are the nagmails going to someone with no power to fix the problem? Shouldn't somebody with approval power be paying more than zero attention to older branches?
They *are* paying attention. Testers get the same nagmails you do.
In fact, there's plenty of approvers available, but you're not engaging with them. They might not know how to test libtiff, or what needs testing, so other stuff gets tested first.
The solution is simple: ASK FOR HELP. Pop into #fedora-qa or ask on the test list. Give some details about what needs to be tested (and how to test it) and it'll be sorted out very quickly.
Updates get approved much faster when the maintainer bothers to engage with the testers. This should surprise no one. Fedora is made of people, isn't it?
The only thing broken here is the expectation that testing doesn't require your assistance, or isn't your problem.
-w
On Fri, 2011-04-08 at 20:43 -0400, Will Woods wrote:
The only thing broken here is the expectation that testing doesn't require your assistance, or isn't your problem.
Well, F13 does tend to get pretty backed up; few people are running it any more. I boot a virt instance of it and do a fedora-easy-karma run every so often, but that's only every month or so, and I can't upkarma *every* update because some I don't have an appropriate setup to test (though this one I would do next time I get to doing an F13 run). I think we've kicked around a few ideas for dealing with this problem with the 'current minus one' release, but nothing definite has come of it yet.
Related to this, fesco wanted to look at some changes for security updates for stable releases:
https://fedorahosted.org/bodhi/ticket/581
Hopefully something like this would help the above case.
kevin
Kevin Fenzi wrote:
Related to this, fesco wanted to look at some changes for security updates for stable releases:
https://fedorahosted.org/bodhi/ticket/581
Hopefully something like this would help the above case.
While I welcome those changes, I don't understand why we need to make the update rules to be enforced by Bodhi more and more complicated (and in fact, too complicated for Bodhi to implement correctly, there are already several corner cases in which the implementation in Bodhi differs from what FESCo requested) when we could just ask maintainers for a bit of common sense and do without any software enforcement.
As you're seeing from all those proposals being floated for various special cases, there are many factors to consider in the tradeoff between getting important fixes out quickly and getting changes tested. I think there's a lot to gain from being flexible. No hardcoded policy will do the right thing in all cases. This thread is just one of the many cases where it goes wrong.
Homo sapiens sapiens has an organ called the "brain", which is very effective at making decisions. We have many of those available, one per maintainer. Why not use this processing power for decision making?
Kevin Kofler
On Sat, 09 Apr 2011 13:07:21 +0200 Kevin Kofler kevin.kofler@chello.at wrote:
While I welcome those changes, I don't understand why we need to make the update rules to be enforced by Bodhi more and more complicated (and in fact, too complicated for Bodhi to implement correctly, there are already several corner cases in which the implementation in Bodhi differs from what FESCo requested) when we could just ask maintainers for a bit of common sense and do without any software enforcement.
As you're seeing from all those proposals being floated for various special cases, there are many factors to consider in the tradeoff between getting important fixes out quickly and getting changes tested. I think there's a lot to gain from being flexible. No hardcoded policy will do the right thing in all cases. This thread is just one of the many cases where it goes wrong.
Homo sapiens sapiens has an organ called the "brain", which is very effective at making decisions. We have many of those available, one per maintainer. Why not use this processing power for decision making?
To some extent I agree with you. ;)
We went though several models over the years...
- Anything goes, up to the maintainer.
This gave us major updates in stable releases, things that weren't tested very well or widely, lots of smaller updates for minor things leading to churn, etc.
- Anything goes, up to the maintainer, but verify/put some framework on it.
Sadly, there's no way to verify/sanity check all updates from a rel-eng point of view. The flow is far too vast, so the only way we can really test/check things is...
- Some rules/structure, enforced by the tool and verified/checked by anyone out there who cares to do so.
I agree that the complexity is anoying and hard to get right, but not sure we could go to less rules without hitting cases we really would like to check for.
Things like bodhi 2.0 and autoqa will help too... when they finally arrive. ;)
The current situation is not ideal, but we are trying...
kevin
Kevin Fenzi wrote:
- Anything goes, up to the maintainer.
This gave us major updates in stable releases,
That's a feature. :-)
things that weren't tested very well or widely,
Yet they worked…
lots of smaller updates for minor things leading to churn, etc.
Very few updates were genuinely useless. Even a minor bugfix is a bugfix and should get pushed. Fighting "churn" as a "problem" only leads to sitting on fixes instead of getting them out to our users as soon as possible. Churn is a feature!
Kevin Kofler
On Fri, Apr 08, 2011 at 20:43:05 -0400, Will Woods wwoods@redhat.com wrote:
The only thing broken here is the expectation that testing doesn't require your assistance, or isn't your problem.
Except this affects more than Tom. Some people aren't getting updates because of the misunderstanding and/or lack of resources that prevented this update from going out in a timely manner. This isn't the first time this kind of thing has been reported, particularly with a near end of life release.
I know there is stuff going on to develop test plans and the like, but it still is probably worth asking questions about how we could do things better.
On Fri, 2011-04-08 at 21:28 -0500, Bruno Wolff III wrote:
On Fri, Apr 08, 2011 at 20:43:05 -0400, Will Woods wwoods@redhat.com wrote:
The only thing broken here is the expectation that testing doesn't require your assistance, or isn't your problem.
Except this affects more than Tom. Some people aren't getting updates because of the misunderstanding and/or lack of resources that prevented this update from going out in a timely manner. This isn't the first time this kind of thing has been reported, particularly with a near end of life release.
I know there is stuff going on to develop test plans and the like, but it still is probably worth asking questions about how we could do things better.
You know, F14 went out the door with a *known broken* mdadm because mdadm sat in updates-testing and didn't get critpath approval for almost 2 months. And I put out a call for testers on this list when I filed the update. As a result, people would install F14 and then have broken raid arrays on reboot or no raid array at all on reboot. It was *horribly* broken. And the solution was sitting in updates-testing for months.
And here we are, about to go down the same road again. I have an update in updates-testing, it's getting no love, and the package that's in the release is *known broken*. It has not been updated for systemd to begin with. Nor for tmpfs /var/run. And just like last time, I put out a call for testers on this mailing list.
But like I tried to explain after F14's fiasco, most people simply don't have the knowledge and hardware to truly test mdadm. No doubt mdadm is an important boot time process and worthy of special testing so as to not render a system unbootable, but I would argue that unless you have testers with this knowledge, then you need to get your critpath process out of my way and let me make the call on when to update this package. There is an inherit logical failure in your system if your system puts the decision making process in the hands of people that aren't qualified/motivated to make the decision and takes it out of the hands of the ones that are.
Now I'm seeing new bugs trickle in about mdadm in the live image, and I have no clue if there is something I need to fix because I haven't gotten my update pushed to stable yet so these people are running against a known broken mdadm. The fixed mdadm makes changes specifically in the area this bug is about, but how am I supposed to know if those changes will solve this specific issue when it can't be tested!
Well, I'm heading out of town for two weeks and will be away from net connectivity. This release's mdadm is what it is and it ain't getting any better. And it would have been nice to have it get wider testing in the last 10 days that it's been sitting in updates-testing so I would know if there is any validity to this live image bug I've got now, but too late for that. Of course, it's still sitting in updates-testing, and I'm not going to be around to push it on out. At least I enabled karma automatism this time. Hopefully, F15 won't be screwed the way F14 was.
You know, I think you guys have this entire critpath thing totally backwards. You should *never* be keeping maintainers away from their testers, but that's exactly what this process does. People running alphas and betas and release candidates *are* testers by definition. You shouldn't be sequestering critpath updates away from the broadest possible testing audience they can have, you should be pushing them proactively and getting the broadest testing possible. If I can get my packages updated quickly, then at least I can proactively fix any breakage that a new package causes. If and only if a package fixes all the known issues should you freeze it and require anything like this critpath process. But as long as the package in the alpha/beta is known to still be broken, then get the hell out of the maintainer's way and let us do our job.
Doug Ledford wrote:
Now I'm seeing new bugs trickle in about mdadm in the live image, and I have no clue if there is something I need to fix because I haven't gotten my update pushed to stable yet so these people are running against a known broken mdadm. The fixed mdadm makes changes specifically in the area this bug is about, but how am I supposed to know if those changes will solve this specific issue when it can't be tested!
Of course a package in updates-testing can be tested. You could ask the users who report bugs to try the package in updates-testing. Then you'd find out if it fixes those particular problems.
That may not help you getting the package pushed to stable though.
Björn Persson
The bug I'm looking at right now is specifically against the live image, so no I can't test that with something in updates testing. It needs to make it to the base before it gets on the live media to see if it solves the problem there.
Sent from my iPhone
On Apr 10, 2011, at 1:13 PM, Björn Persson bjorn@xn--rombobjrn-67a.se wrote:
Doug Ledford wrote:
Now I'm seeing new bugs trickle in about mdadm in the live image, and I have no clue if there is something I need to fix because I haven't gotten my update pushed to stable yet so these people are running against a known broken mdadm. The fixed mdadm makes changes specifically in the area this bug is about, but how am I supposed to know if those changes will solve this specific issue when it can't be tested!
Of course a package in updates-testing can be tested. You could ask the users who report bugs to try the package in updates-testing. Then you'd find out if it fixes those particular problems.
That may not help you getting the package pushed to stable though.
Björn Persson
devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 10 April 2011 20:01, Doug Ledford dledford@redhat.com wrote:
The bug I'm looking at right now is specifically against the live image, so no I can't test that with something in updates testing. It needs to make it to the base before it gets on the live media to see if it solves the problem there.
------- I am one of those caught by this bug that Doug is talking about. I did not managed to install F15. I have just a regular PC without RAID (that is, this issue could affect many users).
On Sun, 2011-04-10 at 20:34 +0100, Piscium wrote:
On 10 April 2011 20:01, Doug Ledford dledford@redhat.com wrote:
The bug I'm looking at right now is specifically against the live image, so no I can't test that with something in updates testing. It needs to make it to the base before it gets on the live media to see if it solves the problem there.
I am one of those caught by this bug that Doug is talking about. I did not managed to install F15. I have just a regular PC without RAID (that is, this issue could affect many users).
Your bug has nothing to do with mdadm; that error appears on boot in all cases, but is not the cause of your problem.
That's good to know since I'm now out of contact after tonight. Can someone close out the erroneous mdadm bug if it's caused by something else then please?
Sent from my iPhone
On Apr 10, 2011, at 4:38 PM, Adam Williamson awilliam@redhat.com wrote:
On Sun, 2011-04-10 at 20:34 +0100, Piscium wrote:
On 10 April 2011 20:01, Doug Ledford dledford@redhat.com wrote:
The bug I'm looking at right now is specifically against the live image, so no I can't test that with something in updates testing. It needs to make it to the base before it gets on the live media to see if it solves the problem there.
I am one of those caught by this bug that Doug is talking about. I did not managed to install F15. I have just a regular PC without RAID (that is, this issue could affect many users).
Your bug has nothing to do with mdadm; that error appears on boot in all cases, but is not the cause of your problem. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Sun, 2011-04-10 at 15:01 -0400, Doug Ledford wrote:
The bug I'm looking at right now is specifically against the live image, so no I can't test that with something in updates testing. It needs to make it to the base before it gets on the live media to see if it solves the problem there.
BTW, someone did mention to me that the Beta might need the new mdadm for the /run change, but there were no critical bugs already filed on it. I tested it on my laptop, which has an Intel BIOS RAID array; booting a live image composed with the current mdadm sees the array, and so does anaconda if you boot a traditional installer image with the current mdadm. So I wasn't able to find any release-critical issue which would require the new mdadm.
One of the changes in the updated mdadm package is to ghost /var/run/mdadm and to create it in the mdmonitor init script and also to set the SELinux state on the new dir. So while things booted ok for you, monitoring of arrays is DOA in the version prior to the update.
Sent from my iPhone
On Apr 10, 2011, at 4:37 PM, Adam Williamson awilliam@redhat.com wrote:
On Sun, 2011-04-10 at 15:01 -0400, Doug Ledford wrote:
The bug I'm looking at right now is specifically against the live image, so no I can't test that with something in updates testing. It needs to make it to the base before it gets on the live media to see if it solves the problem there.
BTW, someone did mention to me that the Beta might need the new mdadm for the /run change, but there were no critical bugs already filed on it. I tested it on my laptop, which has an Intel BIOS RAID array; booting a live image composed with the current mdadm sees the array, and so does anaconda if you boot a traditional installer image with the current mdadm. So I wasn't able to find any release-critical issue which would require the new mdadm. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Sun, Apr 10, 2011 at 12:45:56PM -0400, Doug Ledford wrote:
And here we are, about to go down the same road again. I have an update in updates-testing, it's getting no love, and the package that's in the release is *known broken*. It has not been updated for systemd to begin with. Nor for tmpfs /var/run. And just like last time, I put out a call for testers on this mailing list.
I had a closer look at the raid setup on my f15-box and as the raid was up as expected and poking at the raid with mdadm didn't turn up any issues, I've given it positive karma which has made it "Critpath approved".
I mostly agree that Fedora as a whole has gone too far in the restrictions that are put in front of packagers to get updates pushed out to the distribution (and I'm not even maintaining any critpath packages).
Back when this all started I felt that the promise was that "we'll put all this in place now and once AutoQA is ready, it'll all become much easier for everyone".
And while AutoQA seems to have come a long way in the last 8 months or so it's still not ready/solid/... enough to be used to base automatic decisions on (I'm not complaining - just stating facts) - so I'm still hopeful that the thumbscrews can be loosened somewhat.
But like I tried to explain after F14's fiasco, most people simply don't have the knowledge and hardware to truly test mdadm.
It doesn't render my system unbootable, my raid still comes up after the update and casual mdadm calls don't turn up anything suspicious. That is all what I have tested and I don't feel that it's 'not enough'. The requirements on testing updates aren't very high - there just aren't enough testers (also many are testing not-yet-released versions in a vm and those are most likely not set up with a raid array ...).
Well, I'm heading out of town for two weeks and will be away from net connectivity. This release's mdadm is what it is and it ain't getting any better.
Looking at mdadm I notice two things:
1. The package doesn't have a single co-maintainer. Having two or more people work on it would make "I'll be gone for two weeks" a non- issue. There must be others interested and knowledgeable in the area that could serve as a backup?
2. You're working on it in bursts - mostly a few weeks before the release. Submitting updates (especially rawhide-updates) more often would also make things easier right before the release.
On 04/10/2011 01:23 PM, Sven Lankes wrote:
On Sun, Apr 10, 2011 at 12:45:56PM -0400, Doug Ledford wrote:
And here we are, about to go down the same road again. I have an update in updates-testing, it's getting no love, and the package that's in the release is *known broken*. It has not been updated for systemd to begin with. Nor for tmpfs /var/run. And just like last time, I put out a call for testers on this mailing list.
I had a closer look at the raid setup on my f15-box and as the raid was up as expected and poking at the raid with mdadm didn't turn up any issues, I've given it positive karma which has made it "Critpath approved".
Thanks for that. I hope you read my other emails to Adam about the testing of mdadm. My point of those being that there is more to mdadm than *just* bringing the raid arrays up (although that is, of course, the biggest thing). The fact that monitoring is down on the previous version but ok on the current version is a big deal. Monitoring is almost as important in the real world as it is the difference between an array going degraded and you knowing or you doing nothing until it finally dies altogether.
I mostly agree that Fedora as a whole has gone too far in the restrictions that are put in front of packagers to get updates pushed out to the distribution (and I'm not even maintaining any critpath packages).
Back when this all started I felt that the promise was that "we'll put all this in place now and once AutoQA is ready, it'll all become much easier for everyone".
And while AutoQA seems to have come a long way in the last 8 months or so it's still not ready/solid/... enough to be used to base automatic decisions on (I'm not complaining - just stating facts) - so I'm still hopeful that the thumbscrews can be loosened somewhat.
When I was in 9th grade here in the US, I participated in the National History Day competition. You had to make a individual project, or group project, or several other classes of entry. I always did individual project (this was my third year competing). And each year the theme for the competition was set early on and you had to be able to create a project that embodied that theme. This years theme was Rights versus Responsibilities. My project was about a saloon in the town that I grew up in. Back in the 1800's, the town I grew up in was this booming mining town (lead, zinc, and galena). And, of course, this was the "wild west" days back in the US. The streets were all dirt, people had gun fights to settle differences, and the saloon was the major center of social activity. This particular saloon had a bar and restaurant on the first floor, a casino on the second floor, and a brothel on the third floor. It was a rough and tumble place with little in the way of order or law or discipline. Then along comes the 1920's in the US. That's the era of prohibition. Alcohol was illegal, and it nearly killed this saloon entirely. Not to mention the local officials cracked down on the other unsavory aspect of the place. Then in the 1930's, prohibition was repealed and people had the right to drink again. They tried to revive the saloon, only to find that people weren't so willing to accept the free and loose nature that the original saloon had, and it never really recovered. My project made it all the way to nationals, and I was asked to defend it in front of a panel of judges and defend how it applied to the theme. I responded to their inquiries with the belief that the House of Lords in Joplin, Missouri represented the three stages that society often hits in the process of establishing a balance between rights and responsibilities. At some point in time, the rights will far outweigh the responsibilities. People will be free to do as they please with no consequences for their actions. Then, usually as a direct result of abuses of those rights, society will crack down and take those rights away. Usually imposing entirely overly restrictive consequences on people in order to curb the abuse. Then, over time, society will come to realize they might have over reacted and will curb the consequences and bring the rights of the individual back in line with their responsibilities. My project then was about these three stages and what they meant to this one establishment. I took 8th place at nationals that year (a classmate of mine placed in the top 3 with a project about Harriet Tubman, but the fact that a little town with a population of only 40,000 took two positions of the top 8 at nationals that year is a story about our teacher, Marla Marantz).
The point of this long, rambling story that you couldn't care less about is that I get the impression that Fedora is in stage 2 right now. We saw abuses by maintainers in the past, and we responded with draconian rules that tied their hands, but in the process have ignored the fact that the rules were too restrictive and didn't take various other situations into account. Now we are waiting for the pendulum to swing a little more back to the middle of a balance between the freedom we used to have and some accountability for our actions. That's all fine and dandy, I'm just saying we need to quit wasting time in phase two and move on to phase three.
But like I tried to explain after F14's fiasco, most people simply don't have the knowledge and hardware to truly test mdadm.
It doesn't render my system unbootable, my raid still comes up after the update and casual mdadm calls don't turn up anything suspicious. That is all what I have tested and I don't feel that it's 'not enough'. The requirements on testing updates aren't very high - there just aren't enough testers (also many are testing not-yet-released versions in a vm and those are most likely not set up with a raid array ...).
Well, I'm heading out of town for two weeks and will be away from net connectivity. This release's mdadm is what it is and it ain't getting any better.
Looking at mdadm I notice two things:
- The package doesn't have a single co-maintainer. Having two or more people work on it would make "I'll be gone for two weeks" a non- issue. There must be others interested and knowledgeable in the area that could serve as a backup?
If there were any interested parties I'm open. Keep in mind that when I was asked about the CVS access controls in the past, I opened mdadm up to proven packagers. Now, I know that isn't the same terminology used today, but the idea is the same. I specifically told them to set the access controls so that good packagers could make changes and I'm not the sort of fascist maintainer that will throw a fit if someone else does something. I will, if I deem a change bad, back it out and do something different (or list me reasons why it was bad and do nothing), but that's it.
- You're working on it in bursts - mostly a few weeks before the release. Submitting updates (especially rawhide-updates) more often would also make things easier right before the release.
I maintain lots of packages, both in rhel and fedora, and I work based upon release schedules. The next thing to be released gets my attention. And sometimes not even that if I'm busy solving customer focused problems at the moment :-(
On Sun, 2011-04-10 at 23:21 -0400, Doug Ledford wrote:
I had a closer look at the raid setup on my f15-box and as the raid was up as expected and poking at the raid with mdadm didn't turn up any issues, I've given it positive karma which has made it "Critpath approved".
Thanks for that. I hope you read my other emails to Adam about the testing of mdadm. My point of those being that there is more to mdadm than *just* bringing the raid arrays up (although that is, of course, the biggest thing). The fact that monitoring is down on the previous version but ok on the current version is a big deal. Monitoring is almost as important in the real world as it is the difference between an array going degraded and you knowing or you doing nothing until it finally dies altogether.
Well, we are still talking about a *pre-release* here, remember. No-one's supposed to trust any data (or drives) they care about to a pre-release. A failure in RAID monitoring would not break any Beta release criteria, though we would have probably accepted it as NTH if it had been proposed. (It also doesn't break any Final release criteria at present; we could consider changing that, but we might not). You don't need to worry about Final as the update will get pushed as soon as the Beta freeze is lifted, but if future issues arise, please do propose a bug as NTH or Blocker if you think it should be fixed before release.
Since this is an issue in monitoring and not array activation, it can be fixed satisfactorily with an update, yes? The fixed mdadm will be available as an update immediately after install (if the user leaves updates-testing checked) or once the freeze is lifted (if the user disables that repo).
On Sun, 2011-04-10 at 12:45 -0400, Doug Ledford wrote:
And here we are, about to go down the same road again. I have an update in updates-testing, it's getting no love, and the package that's in the release is *known broken*. It has not been updated for systemd to begin with. Nor for tmpfs /var/run. And just like last time, I put out a call for testers on this mailing list.
It got one +1 the day you submitted it, but the tester isn't a proventester; if he had been, that would have been enough for it to go through.
You know, I think you guys have this entire critpath thing totally backwards. You should *never* be keeping maintainers away from their testers, but that's exactly what this process does. People running alphas and betas and release candidates *are* testers by definition. You shouldn't be sequestering critpath updates away from the broadest possible testing audience they can have, you should be pushing them proactively and getting the broadest testing possible.
I'm not sure you understand the process. People running Branched releases - like 15 at present - get the packages in updates-testing. That repo is enabled *by default* when you install a pre-release. So as soon as you submit an update for a pre-release, you can expect that anyone running that pre-release and doing regular updates will get the package.
Comment inline below:
Sent from my iPhone
On Apr 10, 2011, at 4:34 PM, Adam Williamson awilliam@redhat.com wrote:
On Sun, 2011-04-10 at 12:45 -0400, Doug Ledford wrote:
And here we are, about to go down the same road again. I have an update in updates-testing, it's getting no love, and the package that's in the release is *known broken*. It has not been updated for systemd to begin with. Nor for tmpfs /var/run. And just like last time, I put out a call for testers on this mailing list.
It got one +1 the day you submitted it, but the tester isn't a proventester; if he had been, that would have been enough for it to go through.
Yes, and you are no doubt a proven tester, and your ok would have gotten the package through the process. Yet based upon the comment below, and my comments regarding your testing in the previous email, I think I have demonstrated why sometimes, the maintainer really does know best and why this process is broken IMHO.
You know, I think you guys have this entire critpath thing totally backwards. You should *never* be keeping maintainers away from their testers, but that's exactly what this process does. People running alphas and betas and release candidates *are* testers by definition. You shouldn't be sequestering critpath updates away from the broadest possible testing audience they can have, you should be pushing them proactively and getting the broadest testing possible.
I'm not sure you understand the process. People running Branched releases - like 15 at present - get the packages in updates-testing.
Getting a package from updates testing isn't good enough for mdadm. That doesn't rebuild initramfs images, nor does it test install compatibility. Those things are far more important to get right with mdadm.
That repo is enabled *by default* when you install a pre-release. So as soon as you submit an update for a pre-release, you can expect that anyone running that pre-release and doing regular updates will get the package. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On 04/10/2011 01:34 PM, Adam Williamson wrote:
On Sun, 2011-04-10 at 12:45 -0400, Doug Ledford wrote:
And here we are, about to go down the same road again. I have an update in updates-testing, it's getting no love, and the package that's in the release is *known broken*. It has not been updated for systemd to begin with. Nor for tmpfs /var/run. And just like last time, I put out a call for testers on this mailing list.
It got one +1 the day you submitted it, but the tester isn't a proventester; if he had been, that would have been enough for it to go through.
You know, I think you guys have this entire critpath thing totally backwards. You should *never* be keeping maintainers away from their testers, but that's exactly what this process does. People running alphas and betas and release candidates *are* testers by definition. You shouldn't be sequestering critpath updates away from the broadest possible testing audience they can have, you should be pushing them proactively and getting the broadest testing possible.
I'm not sure you understand the process. People running Branched releases - like 15 at present - get the packages in updates-testing. That repo is enabled *by default* when you install a pre-release. So as soon as you submit an update for a pre-release, you can expect that anyone running that pre-release and doing regular updates will get the package.
I just realized today for the first time that our nightlies are based on stable, not testing. I think that's something we need to address. It's probably still useful to have nightlies based on stable, but I think it's rather vital to have images created with the updates in the queue.
So, yes, -testing is the default for f15 installs, but the problem is you have to get 15 installed first, at which point you can't test the live image/installer part of the critical path, since you are now in an installed environment, not a live image/installer.
On Sun, Apr 10, 2011 at 18:19:26 -0700, Christopher Aillon caillon@redhat.com wrote:
I just realized today for the first time that our nightlies are based on stable, not testing. I think that's something we need to address. It's probably still useful to have nightlies based on stable, but I think it's rather vital to have images created with the updates in the queue.
The nightlies are intended to be made from stable, so that they are more likely to work and near releases (including test ones) corrsepond to the upcoming release.
So, yes, -testing is the default for f15 installs, but the problem is you have to get 15 installed first, at which point you can't test the live image/installer part of the critical path, since you are now in an installed environment, not a live image/installer.
There may need to be special instructions for testing things that get included in the initramfs to get them tested.
On 04/10/2011 07:39 PM, Bruno Wolff III wrote:
On Sun, Apr 10, 2011 at 18:19:26 -0700, Christopher Aillon caillon@redhat.com wrote:
I just realized today for the first time that our nightlies are based on stable, not testing. I think that's something we need to address. It's probably still useful to have nightlies based on stable, but I think it's rather vital to have images created with the updates in the queue.
The nightlies are intended to be made from stable, so that they are more likely to work and near releases (including test ones) corrsepond to the upcoming release.
I definitely agree that the nightlies need to be made from stable sources.
OTOH, the process for testing anything that is part of the installation process (anaconda, lorax, mdadm ...) seems to be more of a PITA than it really needs to be (someone has to build the .iso manually and push it to fedorapeople in order to share it).
So, yes, -testing is the default for f15 installs, but the problem is you have to get 15 installed first, at which point you can't test the live image/installer part of the critical path, since you are now in an installed environment, not a live image/installer.
There may need to be special instructions for testing things that get included in the initramfs to get them tested.
Another option would be to make it easier to build and host images build from testing for updates that affect the installation process. I'll have to think about realistic ways that would be possible unless someone else has an idea.
Until then, instructions would help or someone is going to have to build and push the testing image by hand.
Tim
On 04/11/2011 12:13 AM, Tim Flink wrote:
On 04/10/2011 07:39 PM, Bruno Wolff III wrote:
On Sun, Apr 10, 2011 at 18:19:26 -0700, Christopher Ailloncaillon@redhat.com wrote:
I just realized today for the first time that our nightlies are based on stable, not testing. I think that's something we need to address. It's probably still useful to have nightlies based on stable, but I think it's rather vital to have images created with the updates in the queue.
The nightlies are intended to be made from stable, so that they are more likely to work and near releases (including test ones) corrsepond to the upcoming release.
I definitely agree that the nightlies need to be made from stable sources.
And I did too. I also agree that we need to get nightlies made with testing. I don't think this is an either-or situation.
On 04/11/2011 01:21 AM, Christopher Aillon wrote:
On 04/11/2011 12:13 AM, Tim Flink wrote:
On 04/10/2011 07:39 PM, Bruno Wolff III wrote:
On Sun, Apr 10, 2011 at 18:19:26 -0700, Christopher Ailloncaillon@redhat.com wrote:
I just realized today for the first time that our nightlies are based on stable, not testing. I think that's something we need to address. It's probably still useful to have nightlies based on stable, but I think it's rather vital to have images created with the updates in the queue.
The nightlies are intended to be made from stable, so that they are more likely to work and near releases (including test ones) corrsepond to the upcoming release.
I definitely agree that the nightlies need to be made from stable sources.
And I did too. I also agree that we need to get nightlies made with testing. I don't think this is an either-or situation.
Good point, I didn't mean to imply that it had to be one or the other; just that testing-based nightlies alone aren't enough.
My next questions would be: - Is this needed often enough to justify building another nightly? -> Or would it be more effort than it's worth to build testing based nightlies on a less regular basis?
- If so, what would need to be done in order to propose this and hopefully see it happen?
Tim
On 04/10/2011 06:39 PM, Bruno Wolff III wrote:
On Sun, Apr 10, 2011 at 18:19:26 -0700, Christopher Ailloncaillon@redhat.com wrote:
I just realized today for the first time that our nightlies are based on stable, not testing. I think that's something we need to address. It's probably still useful to have nightlies based on stable, but I think it's rather vital to have images created with the updates in the queue.
The nightlies are intended to be made from stable
Yes, and I already agreed that it's good that we have them.
But not having a set of nightlies based on testing is a problem, and I think we really really need to fix that. I see no reason we need to pick one or the other, let's do both!
On Mon, Apr 11, 2011 at 00:18:24 -0700, Christopher Aillon caillon@redhat.com wrote:
But not having a set of nightlies based on testing is a problem, and I think we really really need to fix that. I see no reason we need to pick one or the other, let's do both!
That's probably an issue for infrasctructure. If doing the extra builds isn't a probelm from their point of veiw, then it could probably be done.
On Sun, 2011-04-10 at 18:19 -0700, Christopher Aillon wrote:
I just realized today for the first time that our nightlies are based on stable, not testing. I think that's something we need to address. It's probably still useful to have nightlies based on stable, but I think it's rather vital to have images created with the updates in the queue.
It would be nice to have both, but we didn't previously have the resources; we may do now they're being done by Bodhi. But we always intentionally picked the 'stable' case as we felt it was the more useful of the two, given we could only have one.
Will Woods wrote:
In fact, there's plenty of approvers available, but you're not engaging with them. They might not know how to test libtiff, or what needs testing, so other stuff gets tested first.
The fact is, this is a SECURITY UPDATE and as such it should go out even without testing. It's not acceptable to sit on security updates for weeks. And it's just a FACT that Fedora n-1 gets near-zero testing.
The solution is simple: ASK FOR HELP.
The solution is simple: The red tape on update pushing needs to be repealed.
Kevin Kofler
On Sat, Apr 09, 2011 at 05:32:04AM +0200, Kevin Kofler wrote:
Will Woods wrote:
In fact, there's plenty of approvers available, but you're not engaging with them. They might not know how to test libtiff, or what needs testing, so other stuff gets tested first.
The fact is, this is a SECURITY UPDATE and as such it should go out even without testing. It's not acceptable to sit on security updates for weeks.
No, security updates are not _that_ special. For example, there's an avahi update in pipeline. It has broken dependencies. Pushing this would broke some systems. I'm talking about: https://admin.fedoraproject.org/updates/avahi-0.6.27-6.fc14
On Sat, Apr 9, 2011 at 12:57 PM, Tomasz Torcz tomek@pipebreaker.pl wrote:
On Sat, Apr 09, 2011 at 05:32:04AM +0200, Kevin Kofler wrote:
Will Woods wrote:
In fact, there's plenty of approvers available, but you're not engaging with them. They might not know how to test libtiff, or what needs testing, so other stuff gets tested first.
The fact is, this is a SECURITY UPDATE and as such it should go out even without testing. It's not acceptable to sit on security updates for weeks.
No, security updates are not _that_ special. For example, there's an avahi update in pipeline. It has broken dependencies. Pushing this would broke some systems. I'm talking about: https://admin.fedoraproject.org/updates/avahi-0.6.27-6.fc14
Packages with broken dependencies should just be unpushable (autoqa was supposed to fix this but not sure what happend to it ...)
We really should do an automated dep check before pushing updates (and reject those with broken deps).
On Sat, 2011-04-09 at 13:31 +0200, drago01 wrote:
On Sat, Apr 9, 2011 at 12:57 PM, Tomasz Torcz tomek@pipebreaker.pl wrote:
On Sat, Apr 09, 2011 at 05:32:04AM +0200, Kevin Kofler wrote:
Will Woods wrote:
In fact, there's plenty of approvers available, but you're not engaging with them. They might not know how to test libtiff, or what needs testing, so other stuff gets tested first.
The fact is, this is a SECURITY UPDATE and as such it should go out even without testing. It's not acceptable to sit on security updates for weeks.
No, security updates are not _that_ special. For example, there's an avahi update in pipeline. It has broken dependencies. Pushing this would broke some systems. I'm talking about: https://admin.fedoraproject.org/updates/avahi-0.6.27-6.fc14
Packages with broken dependencies should just be unpushable (autoqa was supposed to fix this but not sure what happend to it ...)
We really should do an automated dep check before pushing updates (and reject those with broken deps).
autoqa is doing this since recently, but only as an advisory check until we make sure it's running smoothly.
On 04/09/2011 05:31 AM, drago01 wrote:
On Sat, Apr 9, 2011 at 12:57 PM, Tomasz Torcz tomek@pipebreaker.pl wrote:
On Sat, Apr 09, 2011 at 05:32:04AM +0200, Kevin Kofler wrote:
Will Woods wrote:
In fact, there's plenty of approvers available, but you're not engaging with them. They might not know how to test libtiff, or what needs testing, so other stuff gets tested first.
The fact is, this is a SECURITY UPDATE and as such it should go out even without testing. It's not acceptable to sit on security updates for weeks.
No, security updates are not _that_ special. For example, there's an avahi update in pipeline. It has broken dependencies. Pushing this would broke some systems. I'm talking about: https://admin.fedoraproject.org/updates/avahi-0.6.27-6.fc14
Packages with broken dependencies should just be unpushable (autoqa was supposed to fix this but not sure what happend to it ...)
We really should do an automated dep check before pushing updates (and reject those with broken deps).
Actually, we are running automated dependency checks on builds. Comments should be re-enabled in bodhi soon (in the next couple of days unless something changes) but as Adam said, everything is just a warning for now - no automation is preventing the push of updates with broken dependencies.
I may be biased, but I know that I'm looking forward to the new depcheck and upgradepath goodness :)
Tim
Tomasz Torcz wrote, at 04/09/2011 07:57 PM +9:00:
On Sat, Apr 09, 2011 at 05:32:04AM +0200, Kevin Kofler wrote:
Will Woods wrote:
In fact, there's plenty of approvers available, but you're not engaging with them. They might not know how to test libtiff, or what needs testing, so other stuff gets tested first.
The fact is, this is a SECURITY UPDATE and as such it should go out even without testing. It's not acceptable to sit on security updates for weeks.
No, security updates are not _that_ special. For example, there's an avahi update in pipeline. It has broken dependencies. Pushing this would broke some systems. I'm talking about: https://admin.fedoraproject.org/updates/avahi-0.6.27-6.fc14
So as a result we are just leaving this security issue unresolved more than one month? Okay, it is all very well that we try to explain why the new updates request is not yet pushed, however then people would ask, "so why can't Fedora try to fix such issue like broken dependency ASAP? Short of man power? Is Fedora just making light of security issues?"
Who is responsible for this issue?
Regards, Mamoru
On Sun, 10 Apr 2011 15:41:25 +0900 TASAKA Mamoru mtasaka@fedoraproject.org wrote:
Tomasz Torcz wrote, at 04/09/2011 07:57 PM +9:00:
On Sat, Apr 09, 2011 at 05:32:04AM +0200, Kevin Kofler wrote:
Will Woods wrote:
In fact, there's plenty of approvers available, but you're not engaging with them. They might not know how to test libtiff, or what needs testing, so other stuff gets tested first.
The fact is, this is a SECURITY UPDATE and as such it should go out even without testing. It's not acceptable to sit on security updates for weeks.
No, security updates are not _that_ special. For example, there's an avahi update in pipeline. It has broken dependencies. Pushing this would broke some systems. I'm talking about: https://admin.fedoraproject.org/updates/avahi-0.6.27-6.fc14
So as a result we are just leaving this security issue unresolved more than one month? Okay, it is all very well that we try to explain why the new updates request is not yet pushed, however then people would ask, "so why can't Fedora try to fix such issue like broken dependency ASAP? Short of man power? Is Fedora just making light of security issues?"
Who is responsible for this issue?
I would say (in order):
- The person who submitted the update.
- Any co-maintainers the package has that could fix it and push a new update.
- Any provenpackagers who are interested in the package and can go fix it and push a fixed update.
- FESCo or rel-eng if no one else steps up and someone notifies those bodies of the problem, so someone there can fix it.
kevin
Am Samstag, den 09.04.2011, 05:32 +0200 schrieb Kevin Kofler:
Will Woods wrote:
The solution is simple: ASK FOR HELP.
The solution is simple: The red tape on update pushing needs to be repealed.
As someone who is still suffering from the KDE 4.6.1 update and who has not received notable support from your or the KDE SIG I object to lowering the test requirements for updates.
Regards, Christoph
Christoph Wickert wrote:
As someone who is still suffering from the KDE 4.6.1 update and who has not received notable support from your or the KDE SIG I object to lowering the test requirements for updates.
Uh, we're doing what we can about the Akonadi issues. The thing is, we cannot reproduce them, nor could the users who tested 4.6 before we pushed it. (We've had even prereleases available in the kde-unstable repository, then 4.6.0 and 4.6.1 in kde-testing. Several users tested those. kde- unstable also had kdepim 4.6, but several people excluded it specifically. kde-testing shipped 4.6.0 with kdepim 4.4.10, exactly the combination we pushed to F14. The update was also in updates-testing for 11 days total and had a karma of +2, with 2 -1 comments about regressions which were both fixed in the version we pushed to stable, and 4 +1 comments. One of the +1 votes was from a proventester, so this update would have fulfilled even the stricter requirements for critical path packages.) It's hard to fix an issue we cannot reproduce.
We tried a fix from upstream to solve Akonadi-related problems, which wasn't developed for your exact issue, but which we thought might have helped too. It turns out it didn't help. (It does fix an annoyance other users were encountering though.)
We cannot do all that much more on our end. Have you talked to kdepim upstream? As far as I know, you actually know the kdepim developers better than we do… The upstream developers are the people most likely to be able to do anything about your problem. It's hard to fix an issue in code we didn't develop.
And aren't you the one who wanted us to ship F15 with kdepim 4.6 beta? (Yes, it's still in beta, even now, and I doubt it will be out of beta when F15 releases. F15 will ship with kdepim 4.4.x.) Yet when I suggested trying that to see whether it works any better, you dismissed my suggestion as an insane one.
Kevin Kofler
Am Sonntag, den 10.04.2011, 23:12 +0200 schrieb Kevin Kofler:
Christoph Wickert wrote:
As someone who is still suffering from the KDE 4.6.1 update and who has not received notable support from your or the KDE SIG I object to lowering the test requirements for updates.
Uh, we're doing what we can about the Akonadi issues. The thing is, we cannot reproduce them,
But I can and I haven't seen any instructions what I should do. I am willing to try broken update again in order to provide more info, but I can only provide the info I am asked for.
nor could the users who tested 4.6 before we pushed it. (We've had even prereleases available in the kde-unstable repository, then 4.6.0 and 4.6.1 in kde-testing. Several users tested those. kde- unstable also had kdepim 4.6, but several people excluded it specifically. kde-testing shipped 4.6.0 with kdepim 4.4.10, exactly the combination we pushed to F14.
This is the problem: It was one huge update, so when a person gives +1, you have no idea what he actually tested. We don't know if the people tested kontact at all, they just approved the huge update and might not even have kdepim installed.
The update was also in updates-testing for 11 days total and had a karma of +2, with 2 -1 comments about regressions which were both fixed in the version we pushed to stable, and 4 +1 comments. One of the +1 votes was from a proventester, so this update would have fulfilled even the stricter requirements for critical path packages.) It's hard to fix an issue we cannot reproduce.
This means we need more testing rather than less, so your suggestion to remove "red tape" is counterproductive.
We tried a fix from upstream to solve Akonadi-related problems, which wasn't developed for your exact issue, but which we thought might have helped too. It turns out it didn't help. (It does fix an annoyance other users were encountering though.)
We cannot do all that much more on our end. Have you talked to kdepim upstream? As far as I know, you actually know the kdepim developers better than we do… The upstream developers are the people most likely to be able to do anything about your problem. It's hard to fix an issue in code we didn't develop.
I don't expect you to know the code but as the maintainers I expect you to be able to give me some debugging instructions that you would then use to get in touch with the developers.
I haven't met them again because I only see them once a week and when I do, I will try to get some help there. As a matter of fact you pushed a very hairy update to a stable release and it broke for some people, so you are not in the position to demand less testing.
And aren't you the one who wanted us to ship F15 with kdepim 4.6 beta? (Yes, it's still in beta, even now, and I doubt it will be out of beta when F15 releases. F15 will ship with kdepim 4.4.x.)
No, I wanted to ship the final, not the beta because I relied on my colleagues.
Yet when I suggested trying that to see whether it works any better, you dismissed my suggestion as an insane one.
Trying what?
Regards, Christoph
Christoph Wickert wrote:
But I can and I haven't seen any instructions what I should do. I am willing to try broken update again in order to provide more info, but I can only provide the info I am asked for.
Well, one thing worth testing is trying to figure out what part of kdepim or Akonadi causes the problem. (I wrote in the bug report that this is information which would be useful.) For example, downgrade, disable the "Kolab server" contacts source, upgrade again, does it still misbehave? If that's not it, you can try temporarily disabling other data sources. (For example, do you have akonadi-googledata installed? If so, try removing that, it helped for the other person who reported having this issue.)
But obviously, all this is a PITA to test, and I cannot make any promises about its effectiveness. What's sure is that IF this works, it will help us reduce the problem space from a very huge amount of code to a merely large amount of code.
Another thing which SOMETIMES helps debugging hangs (and only hangs; if you're now seeing other kinds of misbehavior, this won't be useful) is to send a SIGABRT to the process (using kill -SIGABRT) to trigger DrKonqi (or ABRT, for stuff not using DrKonqi) and get a backtrace of where it's stuck. But that doesn't work if DrKonqi isn't printing the backtraces properly (running the app in gdb can help in that case), nor if the "hang" is actually a result of getting stuck in the main event loop with nothing to do (I've seen that kind of hangs, the backtrace is useless in those cases).
It's also very hard to provide debugging instructions because the symptoms you report change all the time. I'm not even sure that what you're seeing is one bug and not several different ones.
The update was also in updates-testing for 11 days total and had a karma of +2, with 2 -1 comments about regressions which were both fixed in the version we pushed to stable, and 4 +1 comments. One of the +1 votes was from a proventester, so this update would have fulfilled even the stricter requirements for critical path packages.) It's hard to fix an issue we cannot reproduce.
This means we need more testing rather than less, so your suggestion to remove "red tape" is counterproductive.
No, we don't need more testing. It's not realistically possible to test things more than we did. Considering the statistical incidence of the bug in question, we'd have needed hundreds, if not thousands, of testers to catch it. It's just not a commonly hit bug.
I don't expect you to know the code but as the maintainers I expect you to be able to give me some debugging instructions that you would then use to get in touch with the developers.
I think the upstream developers would certainly be able to give you better instructions for debugging their code.
I haven't met them again because I only see them once a week and when I do, I will try to get some help there.
Upstream also has an IRC chan, #kontact. You've been to our IRC chan to ask for help, why haven't you tried the upstream chan? (I actually told you on IRC to try talking to upstream.)
You also haven't filed an upstream bug, why? The only linked upstream bug is the one you say is a different issue. https://bugs.kde.org/
As a matter of fact you pushed a very hairy update to a stable release and it broke for some people
It broke for 2 people (one of whom found a workaround that solved the problem for him) out of thousands of users.
I'm also fairly sure it fixed dozens of times more bugs than it caused.
No, I wanted to ship the final, not the beta because I relied on my colleagues.
The fact is, the promised (kdepim 4.6) RC still isn't there, weeks after it was scheduled, let alone an actual release. Instead, we got another (very late) beta, after weeks of no updates at all.
And somehow, they managed to break 4.4.10 too. I don't think we should be the ones to blame for kdepim being broken.
Kevin Kofler
On Sat, Apr 9, 2011 at 1:27 AM, Tom Lane tgl@redhat.com wrote:
For the past several days I've been getting daily nagmails about the fact that libtiff hasn't been pushed into f13 (example attached). Because it's a critpath package, I as the lowly maintainer do not have privileges to push it stable, not even after two weeks. Those who do have privileges to approve this sort of thing evidently are paying no attention to f13 packages, not even security bugs on critpath packages.
I will refrain from ranting, and just point out that something is pretty darn broken about this process. Why are the nagmails going to someone with no power to fix the problem? Shouldn't somebody with approval power be paying more than zero attention to older branches?
I would generally agree with the brokenness of critical path. I maintain the libraries that provide support for certain fruit based iDevices and for some reason they're classed as crit path where as clutter which is one of the core libraries of gnome 3 and its not. I don't get it!
Peter
On Sun, 2011-04-10 at 21:47 +0100, Peter Robinson wrote:
I would generally agree with the brokenness of critical path. I maintain the libraries that provide support for certain fruit based iDevices and for some reason they're classed as crit path where as clutter which is one of the core libraries of gnome 3 and its not. I don't get it!
This is really a pretty different complaint, and I'm not sure it's justified. The definition of critical path is perfectly clear. 'Weird' packages being part of the critical path usually simply happens through dependencies; some package that really *is* vital happens to depend on your library.
(What I'd like to be able to do in this kind of case is have Bodhi explain, hey, this package is critpath because $THIS_OTHER_PACKAGE depends on it, and if $THIS_OTHER_PACKAGE is working okay, then this package has fulfilled its critpath responsibilities, go ahead and +1 it).
Dne 10.4.2011 23:07, Adam Williamson napsal(a):
(What I'd like to be able to do in this kind of case is have Bodhi explain, hey, this package is critpath because $THIS_OTHER_PACKAGE depends on it, and if $THIS_OTHER_PACKAGE is working okay, then this package has fulfilled its critpath responsibilities, go ahead and +1 it).
I think that this is really too simplistic system (especially given that our dependencies are broken, because we are missing Suggests/Recommends … Ceterum autem censeo, Carthaginem esse delendam). Let me show you one more example.
I have posted some updates to mobile-broadband-provider-info. These are just data files for NetworkManager, they need frequent updates, and the biggest disaster which can happen in case of their brokenness (which is quite low, anyway, these are XML files validated during the build) is that somebody won't be able to connect to the Internet via mobile phone. However, because it is a dependency for NetworkManager, it is in the critical path.
And, so although I asked on #fedora-qa for testing already twice, https://admin.fedoraproject.org/updates/mobile-broadband-provider-info-1.201... has been in updates-testing since 2011-02-19 01:03:39.
Best,
Matěj
On Mon, Apr 11, 2011 at 01:43:14PM +0200, Matej Cepl wrote:
I have posted some updates to mobile-broadband-provider-info. These are just data files for NetworkManager, they need frequent updates, and the biggest disaster which can happen in case of their brokenness (which is quite low, anyway, these are XML files validated during the build) is that somebody won't be able to connect to the Internet via mobile phone.
So people with cellphone as only internet connectivity option will be unable unable to download fixed packages?
On Monday 11 April 2011 13:58:21 Tomasz Torcz wrote:
So people with cellphone as only internet connectivity option will be unable unable to download fixed packages?
Nope. They just have to enter their connection settings manually. Instructions were provided by their ISP, probably along with some crappy Windows software. Besides, there are numerous other offline places to find that information (flyers, recent cell phones, etc.). It's really no big deal.
On Mon, 2011-04-11 at 13:43 +0200, Matej Cepl wrote:
Dne 10.4.2011 23:07, Adam Williamson napsal(a):
(What I'd like to be able to do in this kind of case is have Bodhi explain, hey, this package is critpath because $THIS_OTHER_PACKAGE depends on it, and if $THIS_OTHER_PACKAGE is working okay, then this package has fulfilled its critpath responsibilities, go ahead and +1 it).
I think that this is really too simplistic system (especially given that our dependencies are broken, because we are missing Suggests/Recommends … Ceterum autem censeo, Carthaginem esse delendam). Let me show you one more example.
There's nothing much we could do about that within the context of the critpath process. As you note, this is really more about limitations of package dependencies.
I have posted some updates to mobile-broadband-provider-info. These are just data files for NetworkManager, they need frequent updates, and the biggest disaster which can happen in case of their brokenness (which is quite low, anyway, these are XML files validated during the build) is that somebody won't be able to connect to the Internet via mobile phone.
O rly? Are you *sure*? Sure it's not at all possible there could be a bug somewhere in NM which causes it to crash because it misparses an odd character in one of the files, for instance? "It's just a configuration / data file, it can't possibly break anything!" is one of those assertions that bitter experience tends to prove incorrect on occasion :)
Adam Williamson wrote:
O rly? Are you *sure*? Sure it's not at all possible there could be a bug somewhere in NM which causes it to crash because it misparses an odd character in one of the files, for instance? "It's just a configuration / data file, it can't possibly break anything!" is one of those assertions that bitter experience tends to prove incorrect on occasion :)
But is that minute risk worth withholding the useful bugfix update for 2+ MONTHS, because of completely unrealistic testing requirements which just won't be fulfilled out there in the real world for a n-1 release?
Kevin Kofler
Dne 11.4.2011 17:33, Adam Williamson napsal(a):
O rly? Are you *sure*?
Well, as much as I could be sure that reading of XML file with libxml is risc-free process (yes, I think it is). OTOH, your decision is not cost-free either ... users of F13 have over the year old http://koji.fedoraproject.org/koji/buildinfo?buildID=152611 with these fixes missing:
* Fri Feb 18 2011 Matěj Cepl mcepl@redhat.com - 1.20110218-1 - Update to latest upstream checkout including: * south africa: add 8.ta (Telkom) provider (bgo #641916), remove username for Cell-C (bgo #640794) * switzerland: update Orange plans and APNs (bgo #638115) * tanzania: add Sasatel and TTCL, add CDMA for Zantel (bgo #634609) * india: new unified BSNL APNs (rh #667280) * ec: add Movistar Ecuador (bgo #638223)
* Fri Dec 31 2010 Matěj Cepl mcepl@redhat.com - 1.20101231-1 - Update to latest upstream checkout including: Afghanistan, Argentina, Armenia, Australia, Austria, Bahrain, Canada, Croatia, Denmark, Dominican Republic, Finland, France, French Polynesia, Germany, Greece, Hong Kong, Hungary, China, Iceland, India, Indonesia, Iran, Israel, Israel, Italy, Latvia, Luxembourg, Mexico, Montenegro, Netherlands, New Zealand, Nicaragua, Norway, Paraguay, Philippines, Poland, Portugal, Romania, Rwanda/Burundi, Slovakia, Slovenia, Spain, Sudan, Sweden, Switzerland, Thailand, Tunisia, Uganda, United Arab
Matěj
On Tue, 2011-04-12 at 19:26 +0200, Matej Cepl wrote:
Dne 11.4.2011 17:33, Adam Williamson napsal(a):
O rly? Are you *sure*?
Well, as much as I could be sure that reading of XML file with libxml is risc-free process (yes, I think it is). OTOH, your decision is not cost-free either ...
What decision? I didn't make one. Please understand this: just because I reply to a post which overall espouses the point of view X, it does not mean that I espouse the point of view Not-X. I responded to a specific assertion you made - that changing data files cannot possibly cause major problems. I did not engage with the wider question of what constitutes a good update validation process.