Backlog proposals, now and future - Special Bug Triage meeting, 2008-03-12 17:00UTC

[John Summerfield]

John Poelstra wrote:
> John Summerfield said the following on 03/10/2008 11:40 PM Pacific Time:
>> Take care with closing out old bugs. I've just discovered I have one 
>> hanging out from a f6 beta. I was in "NEEDINFO." I don't recall all 
>> the circumstances, but the nature of the bug requires a new install, 
>> and I don't normally have the hardware - how many people other than R 
>> Day have a brace os spare laptops to hand?
>>
>> Someone with a ks file and vmware could have tested it in a few 
>> minutes, I did so myself when I had a real machine on which I was 
>> installing CentOS 5.1. The bug still exists in CentOS 5.1, and it 
>> needs to be fixed, not discarded.
>>
>> Assuming a user can test a bug some time later is a mistake. It's 
>> often not the case.
>>
> 
> What would you propose instead?
> 
> If someone cannot re-confirm the existence of a problem it is better to 
> close the bug and move on.  In my experience if the problem occurs in a 
> later version it will get reported again and if it is important enough 
> it will get fixed.  I would agree this is not the most efficient or 
> ideal scenario, but neither is trying to search and fix 20,000 open 
> bugs... the result if we stay on our present course.
> 
> And this brings us to another realization and expectation we need to 
> somehow set with our users.  There is no way to conceivably fix every 
> single bug reported for every release.  This is not a problem unique to 
> Fedora--it is the nature of software in general.
> 
> How do we strike a balance and not alienate our users and bug reporters? 
>  Can we do it by setting clearer expectations with our users?  Do we 
> need more package maintainers? Do we ________ ?
> 
> Our current situation (> 12,000 open bugs) will not naturally fix itself.
> 
> You have provided a lot of "that is a bad idea" comments (the easy part) 
> here and elsewhere, but very few constructive alternatives (the hard 
> part).  Given the choice between what is presently happening vs. what 
> I've proposed, naturally I'd vote for what I've proposed because seeks 
> to change and improve the situation :)
> 
> I'm open to alternatives as long as they don't include "do nothing" or I 
> am willing to consider if someone can provide a compelling argument for 
> doing nothing. :)

I thought I got to that. Unquestionably, some bugs don't have enough 
information for them to be fixed. It's reasonable to close them, 
"Insufficient information." It should also be made perfectly clear that 
reopening them is reasonable.

In some cases, and I mentioned one example, it should be easy for 
someone to test. All that's needed is a ks file that could be changed to 
add a line or two to and vmware or some other virtualisation software. 
It would take a few minutes only.

> 
>>>
>>> == Bugzilla Product Versioning ==
>>>  * Fedora will track bugs solely based on the version number of the
>>> release or '''rawhide''': the release under development which has not
>>> been released.
>>
>> I've never seen any merit in distinguishing where a program is used. A 
>> bug in dhcp 4.0 probably exists where ever it's used.
>>
>>
>>>    * There are no term limits, but we want to flush the page each
>>> release so it stays current without a lot of work.  We don't think
>>> asking people to re-add their names once every six months is a big
>>> deal.
>>
>>
>> The users might disagree. In fact, I'm sure they will.
>>
> 
> This is for the bug triage team, not general users.  What would you 
> propose instead?

At some level everyone's a user. In this context, the triage team 
members are users

How about an inactivity timeout? If they've not visibly done something 
in the past period (release cycle maybe), then deregister.


> 
>>>    1. Create/update script ''eol-warning'' script for mass-change of
>>> all bugs for the oldest supported version which will become ''end of
>>> life'' (EOL) one month from GA date
>>
>>
>> If bugfixers are doing their jobs properly:-) this shouldn't 
>> ordinarily happen. There are many scenarios where I can imagine the 
>> original reported will not/cannot test a later version. For example
>> 1. Timing is bad. The bug I mentioned above falls into this category, 
>> I could only test it when installing Linux. Not only that, but (I 
>> think) it has to be a ks install.
>> 2. Something didn't work, the user reported it and used an alternative 
>> tool. There is, for example, some choice when it comes to web 
>> browsers, CD authoring software. A user on dialup is particularly 
>> illequipped to download a browser just to see whether a bug's been fixed.
>> 3. The user's gone to another distro. Even worse, to WIndows.
>>
>> Closing bugs when they have to potential to cause more grief won't do 
>> you much good in the long run.
>>
> 
> Because..... ?

they will likely bite again.

> 
>> Okay that's about it for that document, the rest deals with automatic 
>> disposal of bugs. In case you didn't notice, I don't like the idea, 
>> and in some cases packages in EOL Fedora need ongoing support because 
>> they are also in RHEL. FC6 and RHEL5 for example.
> 
> Except.... how much overlap is there really today between when FC6 was 
> cut for RHEL5.0 and what RHEL5.2 will be when next released?  That would 
> be an interesting comparison of packages--I don't know how close or far 
> away it would be.

Where packages were common, those that I noticed were at the same 
levels, but then I didn't look closely and that's what I expected.

I don't think it's likely RHEL5.2 will have any more new packages than 
RH can help, it's inconvenient to RH and it's not what enterprise 
customers want. They may need to upgrade to newer versions of some 
software (Firefox for example) because of the difficulty of backporting 
fixes, and there might be significant changes to the kernel for new 
device support if there are chronic performance problems


> 
>> Most packages in FC6 need support until EOL of RHE5 and that's some 
>> years ago. I contend the emphasis should be on which packages need to 
>> be supported (eg the release of dhcp that's in FC6/RHEL5), and then 
>> addrss the question of _distribution_ of fixes.
> 
> To my knowledge Red Hat understands that FC6 is EOL and is not heavily 
> relying on it for feedback on RHEL5 today--potentially given my reason 
> above (I do not speak for RHEL).

I wouldn't think RH ever relied on FC6 for feedback on RHEL5, they were 
both in beta at the same time. However, likely common packages (which 
would have been most of RHEL5) would have the same bugs, and if I'd 
reported the video problems I had on FC6 (I probably did not), those 
would have had to be considered for RHEL5 too.

It might be useful in a package bug report to have a "where found" 
field, but for a reporter that shouldn't be a criterion.

It makes sense to for one person (or team) to maintain dhcp (as an 
example) because otherwise the work's duplicated. It might need to be 
built separately for each product that includes it, but that doesn't 
affect liaison with upstream, problem determination and fixing.

A bug in dhcp in fc6 is a bug in dhcp in RHEL5.

Okay, the extent to which that's true depends on the package. Kernels 
are famous for getting updated pretty quickly in  Fedora. efax doesn't 
(there hasn't been a new version for years).




> 
>> If that means the components shared between FC6 and RHEL5 have to be 
>> supported by RHEL employees. I don't see a problem The F community can 
>> apply itself to other matters.
>>
> 
> Red Hat supports and maintains RHEL via the subscription model.  With 
> finite resources and time, the focus of Fedora can only focus on so many 
> releases at a time.  That is the decision Fedora has made--two releases 
> + the release under development.

I know how RHEL is funded, and I know that RH sponsors Fedora. I don't 
know the form of the sponsorship, but I assume that, in part, it's the 
RH employees working on Fedora, and I assume further that RHEL 
employees, in the main, care for the common packages.

If those assumptions are not wholly well-founded, then the support of 
the common packages that RH does do is still available to the Fedora 
team on the same terms as it is for CentOS.



> 
> John
>