Should bugs close when Nokia has an internal fix or when the public has the fix?
 

Apparently the bug-tracking process used by Maemo is to close bugs when Nokia has a fix to the bug internally. As someone who has been involved with Free Software for awhile, this surprises me.

In all the other projects I've seen (even similar ones with corporate guardianship like Fedora/Red Hat), bugs get closed when the PUBLIC has a fix. This makes sense to me. What good is a "resolved" bug if we can't get the software?

-Jeff

Re: Should bugs close when Nokia has an internal fix or when the public has the fix?
 

If it's fixed in the code, it's fixed. Plus: It's good to know it's fixed and will be available in a future update. (Most usually. I remember at least one Diablo-bug that was fixed, but the fix was never released.)

I wouldn't want to miss this information. You can use it to, say, search for bugs in the current firmware that are already resolved.

There's a status "verified", IIRC. This would be more what you expect, I think: A user reports a bug, Nokia fixes it, Nokia releases the bugfix, the user verifies that this really solves his problem and sets it to verified. (I'm not sure if verified is used a lot, though.)

Re: Should bugs close when Nokia has an internal fix or when the public has the fix?
 

Usually developers resolve as FIXED when the fix is integrated to the main line. The fact that the fix is public is "secondary" since in those projects every single commit is public. But is not unusual to find FIXED bugs committed to a main branch, and then it's your job to get it and compile it if you want to test it.

As a user or reporter of th bug you still have the option to VERIFY or REOPEN when you can test the fix, same in Maemo as in any software project.

Re: Should bugs close when Nokia has an internal fix or when the public has the fix?
 

It should be labeled fixed when they fixed the code. People will know it'll be fixed and the programmers won't have to maintain two different systems of fixed bugs.
Then again, they should actually release firmware too once in a while for us to benefit from it :p

Re: Should bugs close when Nokia has an internal fix or when the public has the fix?
 

I talked to andre__ a bit about it (maemo bugmaster), and when bugzilla gets upgraded to 3.4 a "ON_QA" may be added. I suggested following this typical (though maybe a bit slow by Fedora standards) bug report as an example:
https://bugzilla.redhat.com/show_bug.cgi?id=538118

They had a bug, they had a source fix, and had even pushed out a *binary* fix to the public before the status was changed. And even though they have a binary fix in the public, it is still not *CLOSED*, it is "ON_QA". Then when it hits their final repos, it gets closed.

That seems to be a very good way to do it and it seems to me that Maemo (Nokia) should look to Fedora (Red Hat) as a model because they are doing things very well and are in a similar type of situation (e.g. large corporation heavily involved in a "community" distribution).

Every time you CLOSE a bug with "fixed internally, if you don't know how to build a .deb, go wait", you annoy your customers. WORKSFORUSWAITFORITNOOB, is not the best status...

-Jeff

Re: Should bugs close when Nokia has an internal fix or when the public has the fix?
 

This is just unneeded bugzilla drama. Marking a bug fixed doesn't stop you from commenting and so forth, its not really that big of a deal.

They do ask the reporters to verify the bug is fixed once the release is public. So I think this 'verification' step should solve any possible issues of it not-really-being-fixed.

Re: Should bugs close when Nokia has an internal fix or when the public has the fix?
 

Sorry, the poll and subject are expressed way too simplistically. I'm going to have to agree with eean.

Re: Should bugs close when Nokia has an internal fix or when the public has the fix?
 

No, this is not drama. In the Maemo case, there is such a long queue from "developer-fixed" to "user-verified" that it could well make sense to add an additional status or two.

Re: Should bugs close when Nokia has an internal fix or when the public has the fix?
 

I don't think anyone argues against that, twaelti. Isn't eean supporting that when he says "verification step"?

Re: Should bugs close when Nokia has an internal fix or when the public has the fix?
 

I'll add this... I think the wording in the OP is too simplistic like Texrat said because of this:

Nokia Released and made Maemo 5.. they should support it. Since they support it, then when a bug is filed with their software - then it should not be set to "fixed" until it has been fixed by nokia AND released to the public (an internal Fix does nothing for the people USING the device).

If the community happens to fix it.. then that's just extra easy for Nokia - grab the community fix, and implement it into a patch/update.

The "verification" thing in the last few posts I think addresses this sort of ideal.

The OP however, doesn't specify if we're talking just Maemo bugs, third party software bugs or "Should not be 'Fixed' until *after* released", None of the Above, All of the Above.... etc.

This discussion is not as "easy" as the OP makes it seem. It isn't as simple as "Pick One: A), or B)."