maemo.org - Talk - Should bugs close when Nokia has an internal fix or when the public has the fix?

maemo.org - Talk (https://talk.maemo.org/index.php)

- Community (https://talk.maemo.org/forumdisplay.php?f=16)

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

Quote:

Originally Posted by jebba (Post 433470)

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...

You are mixing some terminology here.

- RESOLVED FIXED means fixed. Not closed.

- VERIFIED comes after RESOLVED, if the reporter agrees on the resolution (FIXED, DUPLICATE, etc)

- CLOSED comes only after VERIFIED.

See https://bugs.maemo.org/page.cgi?id=f...tml#resolution

I don't see what adding an "ON_QA" brings in the context of bugs.maemo.org, apart from extra work.

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

Indeed, these CLOSED and RESOLVED are two different verifications. A bug is CLOSED once the fix has shipped to users and been VERIFIED. A bug is RESOLVED when the fix has been committed to code (or when the request has been accepted for enhancements).

I can understand being unsatisfied with having to wait for updates, but this is a pointless change to the bug tracking process that's mostly trying to address an emotional issue.

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

I think qgil sorted it out here clearer.The first thing I write in the day can be a bit braindead.

But still when reading the comments, Nokians (and Nokian contractors) are using the word "CLOSED" when they should really be saying "FIXED". What started this thread for me was these comments for example:

Quote:

Closing this now

https://bugs.maemo.org/show_bug.cgi?id=5388#c15

Quote:

Closing.

https://bugs.maemo.org/show_bug.cgi?id=5388#c21

Etc. That occurs in many places of course.

-Jeff

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

You need to find a better example since Claudio's fixes to Hildon are actually public: http://gitorious.org/~csaavedra & http://maemo.gitorious.org/hildon

So it is really up to you to compile Hildon or wait for Nokia to deliver an image with the updated Hildon integrated.

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

Quote:

Originally Posted by qgil (Post 433581)

Oh *I* certainly can, I was talking about the 99% of users that have never used dpkg-buildpackage (nor apt for that matter).

But we're beating a dead horse here.

The ticket(s) actually aren't CLOSED, despite what the comments say, they are FIXED and still OPEN.

That said, Fedora's process is definitely a model for Nokia....

-Jeff

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

Quote:

Originally Posted by jebba (Post 433367)

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?

Actually, in general it's marked fixed when the public has access to the code with the fix in it. Not when a release comes out. So the question really is whether these fixes are going into a public SCM, and whether it's possible for someone outside Nokia to deploy the fix from that SCM and test it.

Sometimes, with Maemo code, that's before the release, and sometimes it's after the release.

Dave.