Hi,
I'm trying to meet a (probably overly aggressive) personal goal of having zero NEW rawhide bugs (which are not Package Reviews) by the time of Fedora 10 GA. Along the way I thought I'd post some of the questions and issues I see while triaging these bugs so we can all learn. I encourage others to do the same. I've just knocked the list down to close to 500!
If you want to join in and help the query for NEW rawhide bugs excluding package reviews is here: http://tinyurl.com/6llac8
Here is what I have so far:
# Is there a general policy around using perl in pre/post ? https://bugzilla.redhat.com/show_bug.cgi?id=462996
# Should this be considered a blocker? Do we have any requirements about being able to build all packages from source before GA? https://bugzilla.redhat.com/show_bug.cgi?id=462971
# Is this bug filed against the right component? What else could I request to help troubleshoot this bug? https://bugzilla.redhat.com/show_bug.cgi?id=463044
# what kind of debug information to advise? # Should pulse audio really have these kind of problems due to removing libfalshsupport? https://bugzilla.redhat.com/show_bug.cgi?id=463108
# does anyone have a labeled USB disk handy that could try this? https://bugzilla.redhat.com/show_bug.cgi?id=463106
# How should we be triaging "branch" and other CVS type requests ? https://bugzilla.redhat.com/show_bug.cgi?id=463105 https://bugzilla.redhat.com/show_bug.cgi?id=463397 https://bugzilla.redhat.com/show_bug.cgi?id=463175 https://bugzilla.redhat.com/show_bug.cgi?id=463139
# This CVS request has comment saying "it is done". Can bug be closed or where can I check to help verify and then close bug? https://bugzilla.redhat.com/show_bug.cgi?id=463124 https://bugzilla.redhat.com/show_bug.cgi?id=463105 https://bugzilla.redhat.com/show_bug.cgi?id=463175
# sounds like an F10Blocker, but I'm not familiar with what PackageKit should or should not do or what it used to do https://bugzilla.redhat.com/show_bug.cgi?id=463566
# Should we exclude the component "fedora-packager" from our queries of bugs to triage? https://bugzilla.redhat.com/show_bug.cgi?id=463397
# is this critical enough to be a blocker? https://bugzilla.redhat.com/show_bug.cgi?id=463054 https://bugzilla.redhat.com/show_bug.cgi?id=463048 https://bugzilla.redhat.com/show_bug.cgi?id=463047
# This bug is assigned to a defunct email address... how will this bug be addressed? https://bugzilla.redhat.com/show_bug.cgi?id=462671
On Tuesday 23 September 2008 19:30:15 John Poelstra wrote:
I'm trying to meet a (probably overly aggressive) personal goal of having zero NEW rawhide bugs (which are not Package Reviews) by the time of Fedora 10 GA.
Please leave my packages alone. I leave them in NEW until I've had a chance to review them. If you change it, I may think I've already taken some action action.
-Steve
Steve Grubb said the following on 09/23/2008 07:22 PM Pacific Time:
On Tuesday 23 September 2008 19:30:15 John Poelstra wrote:
I'm trying to meet a (probably overly aggressive) personal goal of having zero NEW rawhide bugs (which are not Package Reviews) by the time of Fedora 10 GA.
Please leave my packages alone. I leave them in NEW until I've had a chance to review them. If you change it, I may think I've already taken some action action.
-Steve
My apologies. We've been following this process for a long time as outlined here: https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#ASSIGNED
I'll try to remember to look at the "assigned to" designation in each bug as I go.
John
On Tue, Sep 23, 2008 at 9:48 PM, John Poelstra poelstra@redhat.com wrote:
Steve Grubb said the following on 09/23/2008 07:22 PM Pacific Time:
On Tuesday 23 September 2008 19:30:15 John Poelstra wrote:
I'm trying to meet a (probably overly aggressive) personal goal of having zero NEW rawhide bugs (which are not Package Reviews) by the time of Fedora 10 GA.
Please leave my packages alone. I leave them in NEW until I've had a chance to review them. If you change it, I may think I've already taken some action action.
-Steve
My apologies. We've been following this process for a long time as outlined here: https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#ASSIGNED
I'll try to remember to look at the "assigned to" designation in each bug as I go
Well, that doesn't scale well, now does it? :-)
Steve, seriously, that one extra click to see the Comments is too much for you? No email is sent to you on the status change? You're not using eclipse with the mylyn plugin to bugzilla? ;-) Throw us a bone here. Extra requests like yours just make the process that much... more of a process.
jerry
On Tuesday 23 September 2008 22:48:04 John Poelstra wrote:
I'll try to remember to look at the "assigned to" designation in each bug as I go.
The problem is that RHEL and Fedora bugs are in the same bugzilla view. I sometimes have a lot of bugs in my view. I use the NEW state to know which one I have not started working on vs the ones that I am interacting with the reporter. If there was another state, in-work, I could better tell what is in flight and what has not been touched by me and you could do your triaging without causing me to lose my own state. :)
Thanks, -Steve
On Tue, Sep 23, 2008 at 10:09 PM, Steve Grubb sgrubb@redhat.com wrote:
On Tuesday 23 September 2008 22:48:04 John Poelstra wrote:
I'll try to remember to look at the "assigned to" designation in each bug as I go.
The problem is that RHEL and Fedora bugs are in the same bugzilla view. I sometimes have a lot of bugs in my view. I use the NEW state to know which one I have not started working on vs the ones that I am interacting with the reporter. If there was another state, in-work, I could better tell what is in flight and what has not been touched by me and you could do your triaging without causing me to lose my own state. :)
Fair enough explanation. But, as I hinted at in my message a few minutes ago, this can make more work for others. Maybe John knows you're the exception in the process, but somebody else probably won't. Hence, it doesn't scale well.
Not suggesting you change your workflow, but ... well, I guess that is what I'm suggesting.
jerry
On Tue, Sep 23, 2008 at 11:09 PM, Steve Grubb sgrubb@redhat.com wrote:
The problem is that RHEL and Fedora bugs are in the same bugzilla view. I sometimes have a lot of bugs in my view. I use the NEW state to know which one I have not started working on vs the ones that I am interacting with the reporter. If there was another state, in-work, I could better tell what is in flight and what has not been touched by me and you could do your triaging without causing me to lose my own state. :)
I think that this is a reasonable request. You have to understand that due to the packages that Steve maintains, they can get quite a few bug reports. If Steve went through his day managing mail from Bugzilla, no work would actually ever get done :) It's even worse for the kernel guys.
Here is Steve's current list that I can see - note that since he maintains many security-sensitive packages (that is after all his job :) ), there are likely bugs that I can't see, even doubly so since he maintains some of the same packages for RHEL, most of which are marked private in my experience even if they aren't (a pet peeve of mine, but that's for another thread.....)
As you can see, quite a workload to manage :)
On Tue, Sep 23, 2008 at 10:55 PM, Jon Stanley jonstanley@gmail.com wrote:
On Tue, Sep 23, 2008 at 11:09 PM, Steve Grubb sgrubb@redhat.com wrote:
The problem is that RHEL and Fedora bugs are in the same bugzilla view. I sometimes have a lot of bugs in my view. I use the NEW state to know which one I have not started working on vs the ones that I am interacting with the reporter. If there was another state, in-work, I could better tell what is in flight and what has not been touched by me and you could do your triaging without causing me to lose my own state. :)
I think that this is a reasonable request. You have to understand that due to the packages that Steve maintains, they can get quite a few bug reports. If Steve went through his day managing mail from Bugzilla, no work would actually ever get done :) It's even worse for the kernel guys.
Life's a bitch. Deal.
Here is Steve's current list that I can see - note that since he maintains many security-sensitive packages (that is after all his job :) ), there are likely bugs that I can't see, even doubly so since he maintains some of the same packages for RHEL, most of which are marked private in my experience even if they aren't (a pet peeve of mine, but that's for another thread.....)
As you can see, quite a workload to manage :)
Rubbish. https://bugzilla.redhat.com/show_bug.cgi?id=164833 hasn't been touched in over 3 years. (yes, I just keyed on the lowest number I saw at a glance) If bugzilla doesn't fit to manage a todo list, use PostIt(tm) notes for pete's sake.
Sorry to be so blunt, but for the love Fedora I've been downloading, testing, modifying, re-testing, re-downloading, burning, installing and so on for years, and so now for three months I've been a member of this list thinking, "I know I can help. I have the experience, know-how, and hardware." Yet, in those few months, what I encounter most consistently are walls that *prevent* us from helping. That's frustrating. A developer with "quite a workload"? Show me one who doesn't....
jerry
On Wednesday 24 September 2008 05:41:18 Jerry Amundson wrote:
Life's a bitch. Deal.
You'll just "deal" when your packages stop getting updates because people are overloaded?
And before you say it, ... no, you aren't always going to easily replace those particular people ...
Steve Grubb wrote:
On Tuesday 23 September 2008 19:30:15 John Poelstra wrote:
I'm trying to meet a (probably overly aggressive) personal goal of having zero NEW rawhide bugs (which are not Package Reviews) by the time of Fedora 10 GA.
Please leave my packages alone. I leave them in NEW until I've had a chance to review them. If you change it, I may think I've already taken some action action.
I guess triagers hear this a lot... I know I've been talking to several people about this, but has a serious request for a CONFIRMED status or flag ever been put in with the bugzilla maintainers? I'm not sure whether that can be done for the Fedora Product alone, as obviously (if it can only be done for the entire bugzilla, globally) this would impact RH's workflows.
Kind regards,
Jeroen van Meeuwen -kanarip
On Wednesday 24 September 2008 05:46:52 Jeroen van Meeuwen wrote:
Please leave my packages alone. I leave them in NEW until I've had a chance to review them. If you change it, I may think I've already taken some action action.
I guess triagers hear this a lot... I know I've been talking to several people about this, but has a serious request for a CONFIRMED status or flag ever been put in with the bugzilla maintainers?
Not by me, I'm generally too busy to read in detail all that is going on within Fedora. Its only when things affect me that I start talking about it. So, what does CONFIRMED mean? If something were not CONFIRMED, I still don't want people to close it before I look at it. Sometimes even an invalid bug has some good suggestions that I may want to consider.
I also wonder what is the point of this exercise? A bug in NEW that is a year old is one thing, a bug that is in NEW for 1 day is another. It would seem that bugs over a certain age are really a problem that is "stuck" and may need intervention. But, its been my experience that getting bugs from NEEDINFO back to ASSIGNED or MODIFIED to CLOSED are where the problems are.
-Steve
Steve Grubb wrote:
On Wednesday 24 September 2008 05:46:52 Jeroen van Meeuwen wrote:
Please leave my packages alone. I leave them in NEW until I've had a chance to review them. If you change it, I may think I've already taken some action action.
I guess triagers hear this a lot... I know I've been talking to several people about this, but has a serious request for a CONFIRMED status or flag ever been put in with the bugzilla maintainers?
Not by me, I'm generally too busy to read in detail all that is going on within Fedora. Its only when things affect me that I start talking about it. So, what does CONFIRMED mean? If something were not CONFIRMED, I still don't want people to close it before I look at it. Sometimes even an invalid bug has some good suggestions that I may want to consider.
I also wonder what is the point of this exercise? A bug in NEW that is a year old is one thing, a bug that is in NEW for 1 day is another. It would seem that bugs over a certain age are really a problem that is "stuck" and may need intervention. But, its been my experience that getting bugs from NEEDINFO back to ASSIGNED or MODIFIED to CLOSED are where the problems are.
Sorry, I maybe should have elaborated on a CONFIRMED status/flag a little more;
Right now when a bug is created it is in status NEW. Triagers may or may not fire at will at these bugs and get some additional information, close the bug NOTABUG, see the bug is solved in NEXTRELEASE or RAWHIDE, whathaveyou. I *think* overall this helps people (like you?) in that you don't need to hunt down additional information from people logging bogus bugs against the packages you maintain, but like lots of other people, we do not read all email we get from bugzilla (which right now is the only real notification you get on the bug, if we don't take those bugs into account that have not rightfully been set to ASSIGNED, right?).
However, from there (the NEW status), there is no additional available indicator to let people know the bug has been "triaged" (someone has requested additional information, the bug has been reproduced, etc.), other then changing the status to "ASSIGNED" -which is what some people are complaining about, which is understandable. Hence the thought about a CONFIRMED status or flag, indicating "someone knowledgeable has looked at the bug" -hopefully taking some workload off the shoulders of people that are to actually resolve bugs.
Since this is just an idea, I'd like to see what other people think about ways of letting a triager indicate the bug is triaged/reviewed without disturbing existing workflows too much...
Any thoughts?
Kind regards,
Jeroen van Meeuwen -kanarip
Jeroen van Meeuwen said the following on 09/24/2008 05:17 AM Pacific Time:
Steve Grubb wrote:
On Wednesday 24 September 2008 05:46:52 Jeroen van Meeuwen wrote:
Please leave my packages alone. I leave them in NEW until I've had a chance to review them. If you change it, I may think I've already taken some action action.
I guess triagers hear this a lot... I know I've been talking to several people about this, but has a serious request for a CONFIRMED status or flag ever been put in with the bugzilla maintainers?
Not by me, I'm generally too busy to read in detail all that is going on within Fedora. Its only when things affect me that I start talking about it. So, what does CONFIRMED mean? If something were not CONFIRMED, I still don't want people to close it before I look at it. Sometimes even an invalid bug has some good suggestions that I may want to consider.
I also wonder what is the point of this exercise? A bug in NEW that is a year old is one thing, a bug that is in NEW for 1 day is another. It would seem that bugs over a certain age are really a problem that is "stuck" and may need intervention. But, its been my experience that getting bugs from NEEDINFO back to ASSIGNED or MODIFIED to CLOSED are where the problems are.
Sorry, I maybe should have elaborated on a CONFIRMED status/flag a little more;
Right now when a bug is created it is in status NEW. Triagers may or may not fire at will at these bugs and get some additional information, close the bug NOTABUG, see the bug is solved in NEXTRELEASE or RAWHIDE,
We are NOT CLOSING bugs or making decisions like this for package maintainers except in cases where not enough information has been provided for more than 30 days. Our workflow focuses on NEW bugs and bugs in NEEDINFO for > 30 days.
whathaveyou. I *think* overall this helps people (like you?) in that you don't need to hunt down additional information from people logging bogus bugs against the packages you maintain, but like lots of other people, we do not read all email we get from bugzilla (which right now is the only real notification you get on the bug, if we don't take those bugs into account that have not rightfully been set to ASSIGNED, right?).
Bugzilla provides very mail rich header information. It is pretty easy to narrow down bugzilla email by reason that it is being sent to you. I read every email for all the bugs I'm CCd on and ignore a lot of others.
However, from there (the NEW status), there is no additional available indicator to let people know the bug has been "triaged" (someone has requested additional information, the bug has been reproduced, etc.), other then changing the status to "ASSIGNED" -which is what some people are complaining about, which is understandable. Hence the thought about a CONFIRMED status or flag, indicating "someone knowledgeable has looked at the bug" -hopefully taking some workload off the shoulders of people that are to actually resolve bugs.
Another possibility is the "Triaged" keyword which is already present. I can't remember why we decided against it in January. I believe the original intention was to work within the existing bug states present without making the workflow too complicated.
Since this is just an idea, I'd like to see what other people think about ways of letting a triager indicate the bug is triaged/reviewed without disturbing existing workflows too much...
Any thoughts?
I'm curious to know how widespread of a "problem" it is that has our bug triagers moving bugs from NEW to ASSIGNED? IOW how many package maintainers is this a problem for? 1, 2, 10, 100 ? I'm not against trying fix this, just curious how significant the "problem" is?
John
John Poelstra wrote:
I'm curious to know how widespread of a "problem" it is that has our bug triagers moving bugs from NEW to ASSIGNED? IOW how many package maintainers is this a problem for? 1, 2, 10, 100 ? I'm not against trying fix this, just curious how significant the "problem" is?
This being the main question to respond to, I just wanna say that although the problem *never ever* happens to me, if a bug is ASSIGNED to me right now, I'm responsible. Period.
If however it would have been the real ASSIGNED status, it would merely indicate that someone else thinks it is my responsibility. The only responsibility I have at that point though is to either ACCEPT the bug, or ASSIGN it to whatever party I think is responsible.
Makes sense?
Kind regards,
Jeroen van Meeuwen -kanarip
On 2008-09-27, 02:42 GMT, Jeroen van Meeuwen wrote:
This being the main question to respond to, I just wanna say that although the problem *never ever* happens to me, if a bug is ASSIGNED to me right now, I'm responsible. Period.
If however it would have been the real ASSIGNED status, it would merely indicate that someone else thinks it is my responsibility. The only responsibility I have at that point though is to either ACCEPT the bug, or ASSIGN it to whatever party I think is responsible.
Just to keep the issues in proportions -- that's all 10 bugs (http://tinyurl.com/4gpxvd) we are talking about, right?
Anyway, yes, there is a difference between two meanings of ASSIGNED and the second one is the official one. However, I don't think the difference is that important. When you see a bug which is ASSIGNED to you and it shouldn't be (and of course it happens, because bug triagers have no way to understand your packages as well as you do), you just reassign it to somebody who is the (more probable) rightful owner of the bug.
If the issue is conceptualization, then what about understanding ASSIGNED as your first definition, where "responsible for" could be resolved not only in fixing the bug but also in reassigning, WONTFIXing, etc.
There is no judicial proceeding about the assigning of bugs, Fedora is meant to be a group of cooperating sane individuals, so if bug triagers do best they can, but when they wrong, there is no big deal in your saying "Wrong, try better next time" and reassigning to somebody better.
Why is the difference between your two definitions such a big deal for you? And I am really asking, I would like to know.
Matěj
Matej Cepl wrote:
On 2008-09-27, 02:42 GMT, Jeroen van Meeuwen wrote:
This being the main question to respond to, I just wanna say that although the problem *never ever* happens to me, if a bug is ASSIGNED to me right now, I'm responsible. Period.
If however it would have been the real ASSIGNED status, it would merely indicate that someone else thinks it is my responsibility. The only responsibility I have at that point though is to either ACCEPT the bug, or ASSIGN it to whatever party I think is responsible.
Just to keep the issues in proportions -- that's all 10 bugs (http://tinyurl.com/4gpxvd) we are talking about, right?
Like I said, this never happens to me, as far as RH Bugzilla is concerned I might add.
Also, you can take "responsible" lightly as far as my personal involvement in RH Bugzilla is concerned. It's not like I commercially support, maintain and develop packages or programs entire business depend on ;-)
Anyway, yes, there is a difference between two meanings of ASSIGNED and the second one is the official one. However, I don't think the difference is that important.
It is, since the entire discussion is due to people using ASSIGNED status for what (in the entire process) sounds like should be ACCEPTED, and the ASSIGNED status being the only thing keeping the bug from being NEW, or at least that's what I'm seeing. Whether you make triaged a keyword, add a CONFIRMED or ACCEPTED status, do it with flags or whathaveyou doesn't really matter in that aspect, but, imho, there has to be a step between a bug being NEW and someone being responsible or "responsible" for the bug to be resolved.
Why is the difference between your two definitions such a big deal for you? And I am really asking, I would like to know.
Hey, I'm not losing any sleep over it if that's what you think ;-)
I just honestly think there's something we can improve here, and I've had my share of processes that were just wrong, and I've had my share in improving these processes.
Kind regards,
Jeroen van Meeuwen -kanarip
On 2008-09-27, 02:14 GMT, John Poelstra wrote:
Another possibility is the "Triaged" keyword which is already present. I can't remember why we decided against it in January. I believe the original intention was to work within the existing bug states present without making the workflow too complicated.
Given that the "Triaged" keyword would be essentially a synonymum for ASSIGNED, it seems to me useless.
Matěj
Steve Grubb said the following on 09/24/2008 04:13 AM Pacific Time:
I also wonder what is the point of this exercise? A bug in NEW that is a year old is one thing, a bug that is in NEW for 1 day is another. It would seem that bugs over a certain age are really a problem that is "stuck" and may need intervention. But, its been my experience that getting bugs from NEEDINFO back to ASSIGNED or MODIFIED to CLOSED are where the problems are.
I guess from a triage perspective we're trying to go through the bugs that haven't been looked at yet to see if we can help prod them along, request more information, add them to a blocker list, or change them to the correct component.
John
On Wed, 2008-09-24 at 11:46 +0200, Jeroen van Meeuwen wrote:
Steve Grubb wrote:
On Tuesday 23 September 2008 19:30:15 John Poelstra wrote:
I'm trying to meet a (probably overly aggressive) personal goal of having zero NEW rawhide bugs (which are not Package Reviews) by the time of Fedora 10 GA.
Please leave my packages alone. I leave them in NEW until I've had a chance to review them. If you change it, I may think I've already taken some action action.
I guess triagers hear this a lot... I know I've been talking to several people about this, but has a serious request for a CONFIRMED status or flag ever been put in with the bugzilla maintainers? I'm not sure whether that can be done for the Fedora Product alone, as obviously (if it can only be done for the entire bugzilla, globally) this would impact RH's workflows.
+1 for adding CONFIRMED status to bugzilla. I don't think it would affect RH products much. Either it wouldn't be used at all or treated like equivalent to NEW for them.
On Wed, 2008-09-24 at 13:14 +0200, Tomas Mraz wrote:
I guess triagers hear this a lot... I know I've been talking to several people about this, but has a serious request for a CONFIRMED status or flag ever been put in with the bugzilla maintainers? I'm not sure whether that can be done for the Fedora Product alone, as obviously (if it can only be done for the entire bugzilla, globally) this would impact RH's workflows.
+1 for adding CONFIRMED status to bugzilla. I don't think it would affect RH products much. Either it wouldn't be used at all or treated like equivalent to NEW for them.
I would be for it as well. I do believe the gnome bugzilla uses something along those lines. It's nice as a bug filer as well to see something go from UNCONFIRMED (or NEW) to CONFIRMED. At least I know that they see it as a problem, whether or not it'll get fixed any time soon doesn't matter, they've at least acknowledged the problem.
Jesse Keating said the following on 09/24/2008 08:41 AM Pacific Time:
On Wed, 2008-09-24 at 13:14 +0200, Tomas Mraz wrote:
I guess triagers hear this a lot... I know I've been talking to several people about this, but has a serious request for a CONFIRMED status or flag ever been put in with the bugzilla maintainers? I'm not sure whether that can be done for the Fedora Product alone, as obviously (if it can only be done for the entire bugzilla, globally) this would impact RH's workflows.
+1 for adding CONFIRMED status to bugzilla. I don't think it would affect RH products much. Either it wouldn't be used at all or treated like equivalent to NEW for them.
I would be for it as well. I do believe the gnome bugzilla uses something along those lines. It's nice as a bug filer as well to see something go from UNCONFIRMED (or NEW) to CONFIRMED. At least I know that they see it as a problem, whether or not it'll get fixed any time soon doesn't matter, they've at least acknowledged the problem.
Since we didn't have the CONFIRMED state at the time we hoped that the NEW --> ASSIGNED transition might be a similar indication.
What would be the preference for indicating that a bug has been "triaged"?
1) Keyword = "Triaged" 2) CONFIRMED bug state 3) CONFIRMED flag
I believe #3 offers the advantage of being able to set ACLs as to who can or can't set a particular flag.
In the meantime I'll see what I can find out from our bugilla people.
John
John Poelstra wrote:
Since we didn't have the CONFIRMED state at the time we hoped that the NEW --> ASSIGNED transition might be a similar indication.
NEW => ASSIGNED works, but only if you have ASSIGNED => ACCEPTED.
Either way, it is an extra status/flag/keyword/whatnot, and whatever may turn out to work the best for all people (in a situation /from/ the current one), arguments for and against every *possible* solution should be gathered and recorded because even corporate workflows, not any different from software, may benefit from Free and Open Source Software.
-Jeroen
On Wed, Sep 24, 2008 at 4:46 AM, Jeroen van Meeuwen kanarip@kanarip.com wrote:
Steve Grubb wrote:
On Tuesday 23 September 2008 19:30:15 John Poelstra wrote:
I'm trying to meet a (probably overly aggressive) personal goal of having zero NEW rawhide bugs (which are not Package Reviews) by the time of Fedora 10 GA.
Please leave my packages alone. I leave them in NEW until I've had a chance to review them. If you change it, I may think I've already taken some action action.
I guess triagers hear this a lot... I know I've been talking to several people about this, but has a serious request for a CONFIRMED status or flag ever been put in with the bugzilla maintainers? I'm not sure whether that can be done for the Fedora Product alone, as obviously (if it can only be done for the entire bugzilla, globally) this would impact RH's workflows.
Quoting https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow#ON_QA does "The VERIFIED bug state is not used by Fedora." indicate VERIFIED is also not used by RH? If it is not used, could VERIFIED == CONFIRMED?
Also, my apologies for the ranting of my evil twin. [take your meds. take your meds...] On on positive note, communication on the topic continues in spite of my, ahem, unorthodox methods.
Lastly, Happy Birthday Fedora!! :-) :-)
jerry
On 2008-09-24, 02:22 GMT, Steve Grubb wrote:
Please leave my packages alone. I leave them in NEW until I've had a chance to review them. If you change it, I may think I've already taken some action action.
Hi, Steve,
I follow the discussion coming out of this message with a keen interest, but I would vote strongly (as only one of bug zappers), against any individual exceptions from the general policies described on https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow I would totally welcome any comments and criticism for this workflow AS WHOLE, but if we get too much in the exception business whole process would get too complicated for volunteers bug zappers.
Having said that, I totally understand, that we should accommodate developers workflows as well (or in the first place?). I don't think that introducting CONFIRMED (or UNCONFIRMED) bug status is a good solution, because it a huge undertaking which would be friendly to some but hostile all others who managed to turn around their workflows around the current environment. For all those, whom the workflow suggested at the above URL doesn't fir into how they do thinks (and I was talking about that with some of them and they seemed to agree with me in the end; yes, Tomáš, I am looking at you! ;-)) I would point to the existence of the still living status ON_DEV. It is now of no use to anybody and there is no official use for it, however it still remains here (so that old bugs don't have to be converted, or something -- I am not sure what exact reasons lead bugzilla maintainers to keep it around, but good they did).
Wouldn't it be possible for you to redefine ASSIGNED as "this is bug-triaged and really on my plate to do something about it, eventually" and then use ON_DEV as "the stuff I am working on right now"? By this, we (I hope) can acommodate your needs, and still we don't have to make big changes in our bugzilla (and bug zappers workflow).
Any comments?
Best,
Matěj
On Wed, 2008-09-24 at 16:32 +0200, Matej Cepl wrote:
On 2008-09-24, 02:22 GMT, Steve Grubb wrote:
Please leave my packages alone. I leave them in NEW until I've had a chance to review them. If you change it, I may think I've already taken some action action.
Hi, Steve,
I follow the discussion coming out of this message with a keen interest, but I would vote strongly (as only one of bug zappers), against any individual exceptions from the general policies described on https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow I would totally welcome any comments and criticism for this workflow AS WHOLE, but if we get too much in the exception business whole process would get too complicated for volunteers bug zappers.
Having said that, I totally understand, that we should accommodate developers workflows as well (or in the first place?). I don't think that introducting CONFIRMED (or UNCONFIRMED) bug status is a good solution, because it a huge undertaking which would be friendly to some but hostile all others who managed to turn around their workflows around the current environment. For all those, whom the workflow suggested at the above URL doesn't fir into how they do thinks (and I was talking about that with some of them and they seemed to agree with me in the end; yes, Tomáš, I am looking at you! ;-)) I would point to the existence of the still living status ON_DEV. It is now of no use to anybody and there is no official use for it, however it still remains here (so that old bugs don't have to be converted, or something -- I am not sure what exact reasons lead bugzilla maintainers to keep it around, but good they did).
Wouldn't it be possible for you to redefine ASSIGNED as "this is bug-triaged and really on my plate to do something about it, eventually" and then use ON_DEV as "the stuff I am working on right now"? By this, we (I hope) can acommodate your needs, and still we don't have to make big changes in our bugzilla (and bug zappers workflow).
Any comments?
Using ON_DEV instead of the old meaning of ASSIGNED just means that you would force changing the meaning of ASSIGNED for all of the other product processes (such as RHEL) otherwise it would still mean that ASSIGNED on RHEL means completely different thing than ASSIGNED on Fedora. And ASSIGNED on RHEL would be equivalent to ON_DEV on Fedora. This doesn't seem to me as good thing.
Adding a CONFIRMED (status or flag or keyword) or reusing ON_DEV for the triaged meaning changes just the triagers work and nothing else.
On 2008-09-24, 15:26 GMT, Tomas Mraz wrote:
Using ON_DEV instead of the old meaning of ASSIGNED just means that you would force changing the meaning of ASSIGNED for all of the other product processes (such as RHEL) otherwise it would still mean that ASSIGNED on RHEL means completely different thing than ASSIGNED on Fedora. And ASSIGNED on RHEL would be equivalent to ON_DEV on Fedora. This doesn't seem to me as good thing.
a) Actually, I have heard complaints about confusion of meaning of ASSIGNED only from few people.
Redefining ASSIGNED to your taste would mean that we have to go through all ASSIGNED bugs and decide about each of them whether they should be ASSIGNED or ON_DEV.
b) I cannot find any definition of ASSIGNED other than what's FESCO decision on fedoraproject wiki and this in bugzilla:
ASSIGNED This bug is well described, triaged, and assigned to the proper person, but not fixed. From here, additional triage can cause a bug to be given to another person or component, flagged as needinfo, or moved to CLOSED. Otherwise, a bug will be fixed and moved into MODIFIED.
I don't see here anything else, than what I think ASSIGNED means (and what you were asking me to push into ASSIGNED and what we agreed on IRC ON_DEV is good for).
Could you point me to some other URL with more official definition for RHEL, please?
Adding a CONFIRMED (status or flag or keyword) or reusing ON_DEV for the triaged meaning changes just the triagers work and nothing else.
And yes introducing ON_DEV for developers changes just their work (and by far not all of them) and nothing else ... ;-).
Peace be with you :)
Matěj
(I am not sure, whether this message won't be double-posted, sorry if it is). On 2008-09-24, 02:22 GMT, Steve Grubb wrote:
Please leave my packages alone. I leave them in NEW until I've had a chance to review them. If you change it, I may think I've already taken some action action.
Hi, Steve,
I follow the discussion coming out of this message with a keen interest, but I would vote strongly (as only one of bug zappers), against any individual exceptions from the general policies described on https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow I would totally welcome any comments and criticism for this workflow AS WHOLE, but if we get too much in the exception business whole process would get too complicated for volunteer bug zappers.
Having said that, I totally understand that we should accommodate developer workflows as well (or in the first place?), but I am afraid that introducting CONFIRMED (or UNCONFIRMED) bug status would bring more problems than benefits.
So, if you have problems to work with the workflow suggested above, I would point you to the existence of still living status ON_DEV, which is not part of any official workflow, but it still remains in our bugzilla (and it probably won't go away anytime soon).
Wouldn't it be possible for you to redefine ASSIGNED as "this is bug-triaged and really on my plate to do something about it, eventually" and then use ON_DEV as "the stuff I am working on right now"? By this, we (I hope) can acommodate your needs, and still we don't have to make big changes in our bugzilla (and bug zappers workflow).
Any comments?
Best,
Matěj
On Tue, 2008-09-23 at 16:30 -0700, John Poelstra wrote:
Hi,
# Is there a general policy around using perl in pre/post ? https://bugzilla.redhat.com/show_bug.cgi?id=462996
There is no such policy.
On Wed, Sep 24, 2008 at 3:55 AM, Ralf Corsepius rc040203@freenet.de wrote:
On Tue, 2008-09-23 at 16:30 -0700, John Poelstra wrote:
Hi,
# Is there a general policy around using perl in pre/post ? https://bugzilla.redhat.com/show_bug.cgi?id=462996
There is no such policy.
I wish there was a policy for not using perl in pre/post scripts. The number of packages that use perl in a single line of the spec file and don't require it as a general dependency hence pulling in all of perl for nothing.
Peter
On 2008-09-30, 09:23 GMT, Peter Robinson wrote:
I wish there was a policy for not using perl in pre/post scripts. The number of packages that use perl in a single line of the spec file and don't require it as a general dependency hence pulling in all of perl for nothing.
File bugs and attach patches to .spec files. It shouldn't be that hard, especially for one-liners you mentioned.
Matej
On Tue, Sep 30, 2008 at 11:49 AM, Matej Cepl mcepl@redhat.com wrote:
On 2008-09-30, 09:23 GMT, Peter Robinson wrote:
I wish there was a policy for not using perl in pre/post scripts. The number of packages that use perl in a single line of the spec file and don't require it as a general dependency hence pulling in all of perl for nothing.
File bugs and attach patches to .spec files. It shouldn't be that hard, especially for one-liners you mentioned.
I have been filing bugs, in a lot of cases I haven't had time to attach patches, but I have against a couple where they've been simple fixes.
Peter
On Tue, 30 Sep 2008, Peter Robinson wrote:
To: For testers of Fedora Core development releases fedora-test-list@redhat.com From: Peter Robinson pbrobinson@gmail.com Subject: Re: Help me triage
On Wed, Sep 24, 2008 at 3:55 AM, Ralf Corsepius rc040203@freenet.de wrote:
On Tue, 2008-09-23 at 16:30 -0700, John Poelstra wrote:
Hi,
# Is there a general policy around using perl in pre/post ? https://bugzilla.redhat.com/show_bug.cgi?id=462996
There is no such policy.
I wish there was a policy for not using perl in pre/post scripts. The number of packages that use perl in a single line of the spec file and don't require it as a general dependency hence pulling in all of perl for nothing.
Not been following this topic that closely. Are you referring to using perl for pre/post RPM package installation?
Kind Regards,
Keith Roberts
Peter
-- fedora-test-list mailing list fedora-test-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
----------------------------------------------------------------- Websites: http://www.php-debuggers.net http://www.karsites.net http://www.raised-from-the-dead.org.uk
The mind of the prudent is ever getting knowledge, and the eear of the wise is ever seeking, inquiring for and craving knowledge. Pr. 18:15 Amp
All email addresses are challenge-response protected with TMDA [http://tmda.net] -----------------------------------------------------------------
# Is there a general policy around using perl in pre/post ? https://bugzilla.redhat.com/show_bug.cgi?id=462996
There is no such policy.
I wish there was a policy for not using perl in pre/post scripts. The number of packages that use perl in a single line of the spec file and don't require it as a general dependency hence pulling in all of perl for nothing.
Not been following this topic that closely. Are you referring to using perl for pre/post RPM package installation?
Yes. As per the RHBZ bug that's mentioned (and just been closed because the perl script has been replaced with a sed script).
Peter
On Tue, 30 Sep 2008, Peter Robinson wrote:
To: Keith Roberts keith@karsites.net, For testers of Fedora Core development releases fedora-test-list@redhat.com From: Peter Robinson pbrobinson@gmail.com Subject: Re: Help me triage
# Is there a general policy around using perl in pre/post ? https://bugzilla.redhat.com/show_bug.cgi?id=462996
There is no such policy.
I wish there was a policy for not using perl in pre/post scripts. The number of packages that use perl in a single line of the spec file and don't require it as a general dependency hence pulling in all of perl for nothing.
Not been following this topic that closely. Are you referring to using perl for pre/post RPM package installation?
Yes. As per the RHBZ bug that's mentioned (and just been closed because the perl script has been replaced with a sed script).
Peter
Would it be practical to use a PHP CLI script for pre/post RPM installation - not in this particular case, but in general? I find that bash scripts are a bit cryptic, and lack the power that PHP CLI scripts can offer. I have written backup scripts using PHP CLI mode scripts, and then called bash O/S shell programs that are not natively suppoerted by PHP. This gives me all the power of bash shell scripting, and all the added functionality and ease of use of PHP syntax :)
Kind Regards,
Keith Roberts
On 2008-09-30, 20:04 GMT, Keith Roberts wrote:
Would it be practical to use a PHP CLI script for pre/post RPM installation - not in this particular case, but in general?
NO -- it is exactly the same problem as with perl/python/whateverelse-which-is-certain-to-be-installed -- you would have to Require some huge multimegabyte junk, which probably user don't want.
Matěj
On Tue, Sep 30, 2008 at 09:04:38PM +0100, Keith Roberts wrote:
On Tue, 30 Sep 2008, Peter Robinson wrote:
To: Keith Roberts keith@karsites.net, For testers of Fedora Core development releases fedora-test-list@redhat.com From: Peter Robinson pbrobinson@gmail.com Subject: Re: Help me triage
# Is there a general policy around using perl in pre/post ? https://bugzilla.redhat.com/show_bug.cgi?id=462996
There is no such policy.
I wish there was a policy for not using perl in pre/post scripts. The number of packages that use perl in a single line of the spec file and don't require it as a general dependency hence pulling in all of perl for nothing.
Not been following this topic that closely. Are you referring to using perl for pre/post RPM package installation?
Yes. As per the RHBZ bug that's mentioned (and just been closed because the perl script has been replaced with a sed script).
Peter
Would it be practical to use a PHP CLI script for pre/post RPM installation - not in this particular case, but in general? I find that bash scripts are a bit cryptic, and lack the power that PHP CLI scripts can offer. I have written backup scripts using PHP CLI mode scripts, and then called bash O/S shell programs that are not natively suppoerted by PHP. This gives me all the power of bash shell scripting, and all the added functionality and ease of use of PHP syntax :)
This is totally missing the point. The fact that RPM %post scripts exist at all is bad enough, but if you find yourself needing more "power" than just shell its usually a sign that you're solving the wrong problem. PHP isn't helping here - in fact it would be encouraging over-use of scripts. It is a pretty reasonable generalization that if you need more than shell, then you're probably doing it wrong. Furthermore anything you do in %post, needs to be reversable upon uninstall for %postun when the last instance of a package is removed. If your script is longer than a couple of lines of shell, then its highly unlikely you'll be able to create a bug-free %postun to reverse its action.
Daniel
On Tue, Sep 23, 2008 at 7:30 PM, John Poelstra poelstra@redhat.com wrote:
# Is there a general policy around using perl in pre/post ? https://bugzilla.redhat.com/show_bug.cgi?id=462996
Not that I'm aware of, I'll check the guidelines and that particular bug.
# Should this be considered a blocker? Do we have any requirements about being able to build all packages from source before GA? https://bugzilla.redhat.com/show_bug.cgi?id=462971
Matt Domsch regularly rebuilds rawhide in mock to catch things like this and auto-files bugs (FTBFS bugs). This was filed by a normal person, and fixed by the maintainer a few days later. FESCo has or is voting on at some point (I forget which) a policy that items that don't build from source by the time of beta get dropped. There was some backlash, since some of the items took very long dependency chains with them. Therefore I think it's more like "drop a leaf" type policy now.
Either way, not a release blocker :)
# Is this bug filed against the right component? What else could I request to help troubleshoot this bug? https://bugzilla.redhat.com/show_bug.cgi?id=463044
This doesn't appear to be filed against the correct version - note all of the .fc9 packages that he's talking about. Looks more like a hardware problem to me, though.
# what kind of debug information to advise? # Should pulse audio really have these kind of problems due to removing libfalshsupport? https://bugzilla.redhat.com/show_bug.cgi?id=463108
I don't think that should b0rk PA, the maintainer has requested additional info here :)
# does anyone have a labeled USB disk handy that could try this? https://bugzilla.redhat.com/show_bug.cgi?id=463106
Not off the top, sure I could make one.
# How should we be triaging "branch" and other CVS type requests ? https://bugzilla.redhat.com/show_bug.cgi?id=463105 https://bugzilla.redhat.com/show_bug.cgi?id=463397 https://bugzilla.redhat.com/show_bug.cgi?id=463175 https://bugzilla.redhat.com/show_bug.cgi?id=463139
Make sure that they have the fedora-cvs? flag set, and cvsadmin's will get to it, most likely in a matter of hours.
# This CVS request has comment saying "it is done". Can bug be closed or where can I check to help verify and then close bug? https://bugzilla.redhat.com/show_bug.cgi?id=463124 https://bugzilla.redhat.com/show_bug.cgi?id=463105 https://bugzilla.redhat.com/show_bug.cgi?id=463175
If they are package reviews, and CVS is done, the maintainer may wish to use them for bodhi updates or something. If it's an EPEL branch or something, then I guess close it.
# sounds like an F10Blocker, but I'm not familiar with what PackageKit should or should not do or what it used to do https://bugzilla.redhat.com/show_bug.cgi?id=463566
Sounds more like notting making a note to himself.
# Should we exclude the component "fedora-packager" from our queries of bugs to triage? https://bugzilla.redhat.com/show_bug.cgi?id=463397
This is a misfiled bug - that should have a completed package review :)
# is this critical enough to be a blocker? https://bugzilla.redhat.com/show_bug.cgi?id=463054 https://bugzilla.redhat.com/show_bug.cgi?id=463048 https://bugzilla.redhat.com/show_bug.cgi?id=463047
Dunno.....have to look at em :)
# This bug is assigned to a defunct email address... how will this bug be addressed? https://bugzilla.redhat.com/show_bug.cgi?id=462671
That package was orphaned and picked up by the current maintainer, whose address is not defunct :)
On Tue, 23 Sep 2008 16:30:15 -0700, John Poelstra wrote:
# This CVS request has comment saying "it is done". Can bug be closed or where can I check to help verify and then close bug? https://bugzilla.redhat.com/show_bug.cgi?id=463124 https://bugzilla.redhat.com/show_bug.cgi?id=463105 https://bugzilla.redhat.com/show_bug.cgi?id=463175
The work-flow of branch creation requests is misleading. They are to be closed no sooner than after the package has been built successfully for the branch. The goal of branch requests is to make available the package, not just create a branch in cvs.
John Poelstra wrote:
Hi,
I'm trying to meet a (probably overly aggressive) personal goal of having zero NEW rawhide bugs (which are not Package Reviews) by the time of Fedora 10 GA. Along the way I thought I'd post some of the questions and issues I see while triaging these bugs so we can all learn. I encourage others to do the same. I've just knocked the list down to close to 500!
If you want to join in and help the query for NEW rawhide bugs excluding package reviews is here: http://tinyurl.com/6llac8
I just closed https://bugzilla.redhat.com/show_bug.cgi?id=446389 ;-) One more off the list ;-)
# Should this be considered a blocker? Do we have any requirements about being able to build all packages from source before GA? https://bugzilla.redhat.com/show_bug.cgi?id=462971
I think we do... but I can't recall where.
# does anyone have a labeled USB disk handy that could try this? https://bugzilla.redhat.com/show_bug.cgi?id=463106
I could, give me a day or two. Comment in bug.
# How should we be triaging "branch" and other CVS type requests ? https://bugzilla.redhat.com/show_bug.cgi?id=463105 https://bugzilla.redhat.com/show_bug.cgi?id=463397 https://bugzilla.redhat.com/show_bug.cgi?id=463175 https://bugzilla.redhat.com/show_bug.cgi?id=463139
I don't think we should, but who am I ;-)
# This CVS request has comment saying "it is done". Can bug be closed or where can I check to help verify and then close bug? https://bugzilla.redhat.com/show_bug.cgi?id=463124 https://bugzilla.redhat.com/show_bug.cgi?id=463105 https://bugzilla.redhat.com/show_bug.cgi?id=463175
Normally a Review/CVS request stays open until the package is built and submitted to updates or lands in rawhide. If the package is only landing in rawhide though there is no automagic bug closing (like bodhi can do when you submit the build to updates/ or updates-testing/).
# is this critical enough to be a blocker? https://bugzilla.redhat.com/show_bug.cgi?id=463054 https://bugzilla.redhat.com/show_bug.cgi?id=463048 https://bugzilla.redhat.com/show_bug.cgi?id=463047
Here's another one I don't think is important enough to be a blocker:
https://bugzilla.redhat.com/show_bug.cgi?id=462601
# This bug is assigned to a defunct email address... how will this bug be addressed? https://bugzilla.redhat.com/show_bug.cgi?id=462671
It says in comment #2 that it is fixed as well. Should this not be closed NEXTRELEASE (or CURRENTRELEASE?).
Kind regards,
Jeroen van Meeuwen -kanarip
On Tue, Sep 23, 2008 at 04:30:15PM -0700, John Poelstra wrote:
Hi,
I'm trying to meet a (probably overly aggressive) personal goal of having zero NEW rawhide bugs (which are not Package Reviews) by the time of Fedora 10 GA. Along the way I thought I'd post some of the questions and issues I see while triaging these bugs so we can all learn. I encourage others to do the same. I've just knocked the list down to close to 500!
If you want to join in and help the query for NEW rawhide bugs excluding package reviews is here: http://tinyurl.com/6llac8
Here is what I have so far:
# Is there a general policy around using perl in pre/post ? https://bugzilla.redhat.com/show_bug.cgi?id=462996
Not that I know of, but it is good practice to avoid creating unneccessary dependancies if there are alternatives, particularly if the choice is between a large package & small package. Many perl scripts can be done just as well with a short piece of awk/sed. This makes it much easier for people who want to build minimal/small Fedora images because they don't unneccessarily bring in the entire of Perl just for a %post script. Not that I want to single out perl - the same rationale would apply to unneccessary use of python, if the use in question could be easily written in awk/sed.
Daniel
On Wed, 2008-09-24 at 12:25 +0100, Daniel P. Berrange wrote:
On Tue, Sep 23, 2008 at 04:30:15PM -0700, John Poelstra wrote:
Hi,
I'm trying to meet a (probably overly aggressive) personal goal of having zero NEW rawhide bugs (which are not Package Reviews) by the time of Fedora 10 GA. Along the way I thought I'd post some of the questions and issues I see while triaging these bugs so we can all learn. I encourage others to do the same. I've just knocked the list down to close to 500!
If you want to join in and help the query for NEW rawhide bugs excluding package reviews is here: http://tinyurl.com/6llac8
Here is what I have so far:
# Is there a general policy around using perl in pre/post ? https://bugzilla.redhat.com/show_bug.cgi?id=462996
Not that I know of, but it is good practice to avoid creating unneccessary dependancies if there are alternatives, particularly if the choice is between a large package & small package. Many perl scripts can be done just as well with a short piece of awk/sed. This makes it much easier for people who want to build minimal/small Fedora images because they don't unneccessarily bring in the entire of Perl just for a %post script. Not that I want to single out perl - the same rationale would apply to unneccessary use of python, if the use in question could be easily written in awk/sed.
Fully agreed, but ... consider both python and perl * are part of the base-packages Fedora is based on. * there are other dependencies adding much more bloat to "minimal installs"
That said, though it's advisable to avoid anything outside of POSIX in specs' %pre/%post, I don't any pressing need to push people at avoid perl or python.
Ralf
On Wed, Sep 24, 2008 at 01:32:12PM +0200, Ralf Corsepius wrote:
On Wed, 2008-09-24 at 12:25 +0100, Daniel P. Berrange wrote:
On Tue, Sep 23, 2008 at 04:30:15PM -0700, John Poelstra wrote:
Hi,
I'm trying to meet a (probably overly aggressive) personal goal of having zero NEW rawhide bugs (which are not Package Reviews) by the time of Fedora 10 GA. Along the way I thought I'd post some of the questions and issues I see while triaging these bugs so we can all learn. I encourage others to do the same. I've just knocked the list down to close to 500!
If you want to join in and help the query for NEW rawhide bugs excluding package reviews is here: http://tinyurl.com/6llac8
Here is what I have so far:
# Is there a general policy around using perl in pre/post ? https://bugzilla.redhat.com/show_bug.cgi?id=462996
Not that I know of, but it is good practice to avoid creating unneccessary dependancies if there are alternatives, particularly if the choice is between a large package & small package. Many perl scripts can be done just as well with a short piece of awk/sed. This makes it much easier for people who want to build minimal/small Fedora images because they don't unneccessarily bring in the entire of Perl just for a %post script. Not that I want to single out perl - the same rationale would apply to unneccessary use of python, if the use in question could be easily written in awk/sed.
Fully agreed, but ... consider both python and perl
- are part of the base-packages Fedora is based on.
That list of base packages is pretty arbitrary, basically chosen as suitable for a general purpose Fedora deployment. If you are creating derived distributions or appliance images you may not be building a general purpose OS anymore, and as such plenty of packages can be dropped - if the dependancies are created in an intelligent way. In recent times Fedora is actually pretty good in this respect - sometimes we find crazy deps when building minimal oVirt images, but packages maintainers have been very good at addresing bugs like this when we've found them.
- there are other dependencies adding much more bloat to "minimal
installs"
Again, don't think of minimal install in terms of what Fedora defines for its general purpose spin, because minimal has a different definition depending on your use case.
That said, though it's advisable to avoid anything outside of POSIX in specs' %pre/%post, I don't any pressing need to push people at avoid perl or python.
I don't want to specify an exclusion for particular packages - I just want people to evaluate the situation and take into account the dependancy chains they're introducing & whether they're truely justified. All too often Perl/Python are used when there's no compelling need for them to be - other times their use is justified.
Daniel
I'm trying to meet a (probably overly aggressive) personal goal of having zero NEW rawhide bugs (which are not Package Reviews) by the time of Fedora 10 GA. Along the way I thought I'd post some of the questions and issues I see while triaging these bugs so we can all learn. I encourage others to do the same. I've just knocked the list down to close to 500!
If you want to join in and help the query for NEW rawhide bugs excluding package reviews is here: http://tinyurl.com/6llac8
Here is what I have so far:
# Is there a general policy around using perl in pre/post ? https://bugzilla.redhat.com/show_bug.cgi?id=462996
Not that I know of, but it is good practice to avoid creating unneccessary dependancies if there are alternatives, particularly if the choice is between a large package & small package. Many perl scripts can be done just as well with a short piece of awk/sed. This makes it much easier for people who want to build minimal/small Fedora images because they don't unneccessarily bring in the entire of Perl just for a %post script. Not that I want to single out perl - the same rationale would apply to unneccessary use of python, if the use in question could be easily written in awk/sed.
Fully agreed, but ... consider both python and perl
- are part of the base-packages Fedora is based on.
- there are other dependencies adding much more bloat to "minimal
installs"
That's not entirely true. In fact its very easy now to run a complete gnome desktop without perl at all. I'm doing it quite successfully with rawhide on my eeePC. I've filed a number of bugs (the one mentioned above it done by me) to fix issues with dependencies on perl since the alpha release, unfortunately a number of the bug fixes didn't make the beta but have since made it to rawhide (evolution, gstreamer-plugins-base, libbonobo now all don't depend on perl) there have also been a number of others that have split the perl dependency out into a sub package. The only other package that depends on perl just because of the pre/post scripts is docbook-dtds. The bug for that one is https://bugzilla.redhat.com/show_bug.cgi?id=462997 and not having it is a bit of a bummer as evince depends on that package and viewing PDFs is quite useful. I would ultimately like to see the Live CD not depending on perl. This will save a number of meg off the build. Python is quite a bit harder as it is used in a lot of RH systems packages.
Peter
On Tue, 2008-09-30 at 10:42 +0100, Peter Robinson wrote:
I'm trying to meet a (probably overly aggressive) personal goal of having zero NEW rawhide bugs (which are not Package Reviews) by the time of Fedora 10 GA. Along the way I thought I'd post some of the questions and issues I see while triaging these bugs so we can all learn. I encourage others to do the same. I've just knocked the list down to close to 500!
If you want to join in and help the query for NEW rawhide bugs excluding package reviews is here: http://tinyurl.com/6llac8
Here is what I have so far:
# Is there a general policy around using perl in pre/post ? https://bugzilla.redhat.com/show_bug.cgi?id=462996
Not that I know of, but it is good practice to avoid creating unneccessary dependancies if there are alternatives, particularly if the choice is between a large package & small package. Many perl scripts can be done just as well with a short piece of awk/sed. This makes it much easier for people who want to build minimal/small Fedora images because they don't unneccessarily bring in the entire of Perl just for a %post script. Not that I want to single out perl - the same rationale would apply to unneccessary use of python, if the use in question could be easily written in awk/sed.
Fully agreed, but ... consider both python and perl
- are part of the base-packages Fedora is based on.
- there are other dependencies adding much more bloat to "minimal
installs"
That's not entirely true.
Check "Base" in comps.xml, check mock's default setup - It's a convention.
In fact its very easy now to run a complete gnome desktop without perl at all.
[..]
In fact its very easy now to run a complete gnome desktop without perl at all. I'm doing it quite successfully with rawhide on my eeePC
I wish the same would apply to python, lua and others, it would spare quite a number of bytes on my i586, because I am using perl, but don't have much use for python ...
This will save a number of meg off the build. Python is quite a bit harder as it is used in a lot of RH systems packages.
Right, a major problem with RH based distros.
Ralf
Fully agreed, but ... consider both python and perl
- are part of the base-packages Fedora is based on.
- there are other dependencies adding much more bloat to "minimal
installs"
That's not entirely true.
Check "Base" in comps.xml, check mock's default setup - It's a convention.
Sorry, my not entirely true was it can be done. Its been made easier in the last couple of weeks with some fixing of packages thanks to a number of helpful maintainers.
In fact its very easy now to run a complete gnome desktop without perl at all.
[..]
In fact its very easy now to run a complete gnome desktop without perl at all. I'm doing it quite successfully with rawhide on my eeePC
I wish the same would apply to python, lua and others, it would spare quite a number of bytes on my i586, because I am using perl, but don't have much use for python ...
I use perl extensively on my servers, just not on my workstations. I'm trying to squeeze a useful desktop OS into the capacity of an eeePC that would be usable for the average Joe eeePC user, anyone who knows how to use perl would know how to install it.
This will save a number of meg off the build. Python is quite a bit harder as it is used in a lot of RH systems packages.
Right, a major problem with RH based distros.
On Tue, Sep 23, 2008 at 04:30:15PM -0700, John Poelstra wrote:
I'm trying to meet a (probably overly aggressive) personal goal .....
......
# Is there a general policy around using perl in pre/post ? https://bugzilla.redhat.com/show_bug.cgi?id=462996
John,
I suspect that there is not but perhaps there should be.
I have see numerous packages fail in their pre/post scripts on inspection of kickstart logs all for want of perl and various other tools.....
Eliminating unnecessary and redundant tools when possible would be a positive step.... But what tools are the desired core set of tools?
In the context of Linux as it is today I would prefer Python over Perl and while sh+stuff is traditional I think Python is rich enough and just fine.
As the below shows, Perl is not doing anything very complex and if the system has enough Python to run rpm and yum it should be possible to recode the scripts.
With regard to sh in pre/post tools.... With sh the interesting actions are commonly done by tools in the "+stuff" category for which a partial list looks sort of like: [, ar, at, awk, basename, bash, batch, bc, cat, chcon, checkpolicy, chgrp, chmod, chown, ci, cksum, clear, cmp, co, col, colcrt, colrm, column, cp, cpio, curl, cut, cut, date, dc, dd, df, diff, diff3, dig, domainname, du, echo, ed, ed, egrep, env, ex, exec, expect, false, fgrep, file, find, find, fmt, ftp, gawk, getopt, gettext, grep, gtar, gunzip, gzip, head, HEAD, hexdump, host, hostname, install, ipcalc, join, kill, last, ldd, less, link, ln, locale, ls, make, mkdir, mknod, mktemp, mv, netstat, nisdomainname, od, ping, ping6, ps, pwd, rcp, rcs, rm, rmdir, rsync, scp, sed, sleep, sort, stty, sudo, sum, tail, tar, tee, test, time, touch, tr, uniq, unlink, unzip, uptime, w, wall, wc, wget, which, who, yes, zcat.... The point of the list is that sh and friends can pull in a longish list so shell scripts are not always the simplifying win one might want.
In the case of nss-mdns when wanted it is so fundamental (name services) that the less stuff it depends on the better.
====================================================================================== Description : nss-mdns is a plugin for the GNU Name Service Switch (NSS) functionality of the GNU C Library (glibc) providing host name resolution via Multicast DNS (aka Zeroconf, aka Apple Rendezvous, aka Apple Bonjour), effectively allowing name resolution by common Unix/Linux programs in the ad-hoc mDNS domain .local.
====================================================================================== $ rpm -q -f /etc/nsswitch.conf glibc-2.8-8.x86_64 glibc-2.8-8.i686
====================================================================================== # rpm -q --scripts -p ./fedora/packages/nss-mdns-0.10-4.fc9.x86_64.rpm postinstall scriptlet (using /bin/sh): /sbin/ldconfig # Perl-fu to add mdns4_minimal to the hosts line of /etc/nsswitch.conf if [ -f /etc/nsswitch.conf ] ; then perl -ibak -pe ' sub insert { my @bits = split(" ", shift); if (grep { $_ eq "mdns4_minimal" || $_ eq "mdns4" || $_ eq "mdns6_minimal" || $_ eq "mdns6" || $_ eq "mdns_minimal" || $_ eq "mdns" } @bits) { return join " ", @bits; } return join " ", map { $_ eq "dns" ? ("mdns4_minimal", "[NOTFOUND=return]", $_) : $_ } @bits; }
s/^(hosts:\s+)(.*)$/$1.insert($2)/e; ' /etc/nsswitch.conf fi preuninstall scriptlet (using /bin/sh): # Perl-fu to remove mdns4_minimal from the hosts line of /etc/nsswitch.conf if [ "$1" -eq 0 -a -f /etc/nsswitch.conf ] ; then perl -ibak -pe ' my @remove = ( "mdns4_minimal [NOTFOUND=return]", "mdns4_minimal", "mdns4", "mdns6_minimal [NOTFOUND=return]", "mdns6_minimal", "mdns6", "mdns_minimal [NOTFOUND=return]", "mdns_minimal", "mdns", ); sub remove { my $s = shift; foreach my $bit (@remove) { $s =~ s/\s+\Q$bit\E//g; } return $s; } s/^(hosts:\s+)(.*)$/$1.remove($2)/e; ' /etc/nsswitch.conf fi postuninstall program: /sbin/ldconfig ======================================================================================
BTW: Some projects like the OLPC project have very limited resources and perl is not on the default list but Python is. I noticed this with ntptrace.... on an XO recently...
On 2008-09-29, 04:39 GMT, Nifty Fedora Mitch wrote:
I have see numerous packages fail in their pre/post scripts on inspection of kickstart logs all for want of perl and various other tools.....
Well, if they are missing Requires(pre) or something like that then there most definitively is policy for that, and it is bug.
Matěj
BTW: Some projects like the OLPC project have very limited resources and perl is not on the default list but Python is. I noticed this with ntptrace.... on an XO recently...
OLPC actively removes perl as a dependency. If they can't in the main upstream package they fork the package and maintain their own version.
Peter