Bryce Harrington-5 wrote:

"fix released" is really an inaccurate term. Even in Ubuntu development it really just means "fixed in development", not in a released version.

For Ubuntu it means that a package that fixes the bug is available for the official repositories. On top of that, the bugs are tracked separately in different versions, and are marked Fix Released only when really fixed in the given distro version (a package is available). For me this is fair enough.

For upstream projects marking bugs fixed in SVN is just an abuse of the bug status, because there is no release where this bug is fixed. Calling SVN snapshot builds "releases" is just weird, because their quality is not suitable for general use, and they are not supposed to be make it into distributions or official Windows installers.

Bryce Harrington-5 wrote:

Regarding consternation of users over what "fix released" means, I suspect that just getting a release out would assuage that.

It would fix the problem temporarily until bugs in the new release are found and fixed. The Fix Committed status, when used to mark anything that's not in an official release but already fixed, is just way more useful - this way the user knows what can he expect from the upcoming stable version or the current development version (in fact it can help make him a tester!), and the devs know how much progress has been made with regards to long standing bugs. It provides more information than lumping Fix Released and Fix Committed together.

Regards, Krzysztof Kosiński.

On Mon, Oct 27, 2008 at 1:46 PM, Bryce Harrington <bryce@...1798...> wrote:

Every assertion you make in this last paragraph can be debated. However, using the inflammatory term "abuse" in reference to our current processes makes it sound like you're just trolling anyway.

I honestly do not see any trolling here. It's a valid concern. I personally do not care much about how we mark bugs, so long as it's consistent, but I do understand how our current system may look slightly weird. I think everyone who cares about this part of the project should make an effort to discuss it in a civil and productive manner.

Bryce Harrington-5 wrote:

Every assertion you make in this last paragraph can be debated. However, using the inflammatory term "abuse" in reference to our current processes makes it sound like you're just trolling anyway.

I'm not trolling. I'm aware that recently I'm sounding overly critical of everything. Don't take it personally - it's just because I prefer to focus on things that I think can be improved rather than things that are already good. When problems don't get talked about, they don't get solved. There are many great things about Inkscape, like the open and inclusive culture, the simple yet powerful UI, the incredible rate of new development going on, and I could spend hours writing about them, but it wouldn't make Inkscape any better than it is now.

Back to the bug status issue. I'm not a native speaker and thought that "abuse" is a relatively neutral term, so take it with a grain of salt. Regarding my assertions:

1. "there is no release where this bug is fixed" - this boils down to how we define a release. I think an official release (what distros call "upstream releases") is a good definition. If we had a formal development release process, we could also include development releases in this definition. 2. "Calling SVN snapshot builds "releases" is just weird" - I didn't find a project that would consider their nightly trunk builds "releases". There are some projects that roll out development releases, like Gnome, but those follow a formal release process. They use Bugzilla, which doesn't distinguish between "fix committed" and "fix released", but bugs are reported against a specific version of an application. This provides roughly the same amount of information as the "Fix Committed" status. Perhaps I should have used the words "very unusual" instead of "just weird". 3. "their quality is not suitable for general use" - SVN trunk is rarely release-quality. 4. "they are not supposed to make it into distributions or official Windows installers" - there are installers for SVN snapshots, but they are not listed as official releases on Inkscape's homepage. I think I don't need to explain this further because several people here know much more about release management than I do.

By the way, I don't know what is imprecise about the Fix Committed status. To the user it says: it will be fixed in the next version, wait for it or download an SVN snapshot to get rid of this bug. To the developer it says: you don't need to work on this, somebody else already fixed it. I agree that in the context of a developer the difference between "Fix Committed" and "Fix Released" is minor - both say that you don't need to work on this issue. For users and release managers it is an important distinction.

Regards, Krzysztof Kosiński

On Mon, 2008-10-27 at 22:20 +0300, Alexandre Prokoudine wrote:

On Mon, Oct 27, 2008 at 8:59 PM, Krzysztof Kosiński wrote:

...

By the way, I don't know what is imprecise about the Fix Committed status. To the user it says: it will be fixed in the next version, wait for it or download an SVN snapshot to get rid of this bug. To the developer it says: you don't need to work on this, somebody else already fixed it. I agree that in the context of a developer the difference between "Fix Committed" and "Fix Released" is minor - both say that you don't need to work on this issue. For users and release managers it is an important distinction.

Well, I agree with that. There is a "but" however.

The thing is that we fix *a lot* of bugs and commit *a lot* of patches during every release cycle. And it looks like we are moving towards a one-release-a-year release cycle. Which practically means that release wardens will have to somehow go through the whole bugtracker, find all "fix committed" in a time range and change them to "fix released". A *rough* estimation would give over 500 such cases. I know of no tools to ease this pain.

Well, now that there are Launchpad APIs published such a tool would be pretty easy to do... not that it's done, but in theory it should be easy. :)

--Ted

On Mon, Oct 27, 2008 at 10:59:08AM -0700, Krzysztof Kosi??ski wrote:

Bryce Harrington-5 wrote:

...

Every assertion you make in this last paragraph can be debated. However, using the inflammatory term "abuse" in reference to our current processes makes it sound like you're just trolling anyway.

I'm not trolling. I'm aware that recently I'm sounding overly critical of everything. Don't take it personally - it's just because I prefer to focus on things that I think can be improved rather than things that are already good. When problems don't get talked about, they don't get solved. There are many great things about Inkscape, like the open and inclusive culture, the simple yet powerful UI, the incredible rate of new development going on, and I could spend hours writing about them, but it wouldn't make Inkscape any better than it is now.

Back to the bug status issue. I'm not a native speaker and thought that "abuse" is a relatively neutral term, so take it with a grain of salt.

Okay, understood. No, 'abuse' is far from a neutral term. For reference it is often used in relation to child molestation or wife beating.

Like Bulia points out, we've generally striven to keep discussions civil and productive in the past, so it stands out when extreme wording is used, perhaps more than it should.

Regarding my assertions:

1. "there is no release where this bug is fixed" - this boils down to how we

define a release. 2. "Calling SVN snapshot builds "releases" is just weird" - I didn't find a project that would consider their nightly trunk builds "releases". 3. "their quality is not suitable for general use" - SVN trunk is rarely release-quality.

Basically it sounds like the point of dispute is that we define the nightlies to be good enough to be treated as "releases" for the Fix Released status, but you disagree with this.

In pure form, 'Fix Committed' literally means the fix is committed to a version control system, but not yet available for users in a way they can consume. And 'Fix Released' in its literal state means it's available in a tarball or other package that can be downloaded and used by the public at large.

Development releases sit in sort of a gray area in that they're not "official", so require a bit more thought.

Ubuntu treats a bug as Fix Released when .debs have been built for the package in question and are available from the development archive. They don't wait until the distro is officially released. Nor in fact do they even wait until there is an alpha release.

Ubuntu actually uses a mechanises process built into the build system to flip bugs from Fix Committed to Fix Released, once its done building the packages and posting them for users to sync. No promises that Ubuntu overall is installable or usable.

For us, in theory we would set the bug to Fix Committed when we checked in the code, and have our snapshot builders flip them to Fix Released at the point that they make the compiled packages available. But in practice we don't have things set up that way, so just have developers set bugs directly to Fix Released at commit time, and trust that the nightly builds will work.

Now, part of the argument is that the nightlies aren't stable. I'd say that's actually not material to the discussion; I've never heard someone define a state for a particular bug in terms of the overall project's state. But I think it's worthwhile to address this as well.

For a considerable period of time, most Inkscape users I spoke to would use svn snapshots preferentially to the release due to new features. Indeed, the stability of the nightlies was a point of pride in the project.

The 0.46->0.47 development was planned from the start to involve major refactoring work that we knew would destabilize the tree, which it sounds like it has. But don't extrapolate this to mean that every development period is similarly unstable; on the contrary, the Inkscape team has tended to be very conscious of using a refactoring approach that keeps the tree always buildable and relatively stable. Indeed, because of that practice we'd put off a number of major rearchitecting efforts that were risky, and decided to bite the bullet now, accept that the dailies would be more unstable than usual, and return to our normal practices in the future.

So like I said before, this probably just indicates we need to get through a release.

By the way, I don't know what is imprecise about the Fix Committed status. To the user it says: it will be fixed in the next version, wait for it or download an SVN snapshot to get rid of this bug.

No, according to https://wiki.ubuntu.com/Bugs/Status it just means it's committed someplace, it makes no promises that the user can easily get the snapshot tarball or built publically. If a bug is fixed in the current development branch, that's sufficient for marking it Fix Released.

Bryce

On Mon, Oct 27, 2008 at 7:09 PM, Krzysztof Kosiński <tweenk.pl@...400...> wrote:

Thanks for writing up a detailed explanation. But putting aside how Ubuntu uses the system (after all it's a distribution, not a single project, so emulating everything they do may not be the best choice), I think using "Fix Committed" to mark bugs fixed in SVN and "Fix Released" to mark bugs fixed in an official release would provide more information than not distinguishing between those two, if someone can figure out how to exploit the automatic "Fix Committed" -> "Fix Released" mechanism.

So, basically, this is a call for launchpad devs, not us. As soon as they implement an easy way to see the stats of bugs in svn (i.e. not committed) and to switch committed->released, we can change the way we do it.

On Mon, Oct 27, 2008 at 8:22 PM, Krzysztof Kosiński <tweenk.pl@...400...> wrote:

What does it mean? Do you mean an "Unfixed" bug count which wouldn't include "Fix Committed" bugs? If this is the case, there's an easy solution: don't assign bugs to anyone until they are actively working on them (i.e. the status is not "In Progress"). The Unassigned count would then give an information about how many bugs are there left to fix.

That solution is as bad as our current one, just different :) It's all extra work. Many bugs get fixed without ever being assigned to anyone. Others get assigned and remain unfixed for years. So no, that won't work.

On Oct 27, 2008, at 5:59 PM, Krzysztof Kosiński wrote:

bulia byak wrote:

...

Many bugs get fixed without ever being assigned to anyone. Others get assigned and remain unfixed for years.

Problem 1: whoever sets Fix committed and is not the author of the fix assigns the bug to Inkscape Bug Team.

Problem 2: discipline people so that they don't assign bugs they are not actively working on to themselves, this is a bad practice in itself.

Number 2 there is not a good approach. I don't think I'm aware of any professional development that doesn't assign bugs.

The general workflow I've seen work well over and over is that many, if not all, bugs get assigned to the most appropriate person, counting any appropriate leveling.

However, the person with bugs assigned does not switch the status to "In Progress" until they actually start working on it.

some benefits:

If someone else has time and ability, they can grab the not-in- progress bug away from someone and work on it.

If someone just wants to help, they can *first* look at unassigned bugs.

If someone grabs a bug away from someone else, they know who to best ask for history, plan of attach, help, etc.

On Oct 27, 2008, at 4:00 PM, bulia byak wrote:

On Mon, Oct 27, 2008 at 7:09 PM, Krzysztof Kosiński <tweenk.pl@...400...> wrote:

...

Thanks for writing up a detailed explanation. But putting aside how Ubuntu uses the system (after all it's a distribution, not a single project, so emulating everything they do may not be the best choice), I think using "Fix Committed" to mark bugs fixed in SVN and "Fix Released" to mark bugs fixed in an official release would provide more information than not distinguishing between those two, if someone can figure out how to exploit the automatic "Fix Committed" -> "Fix Released" mechanism.

So, basically, this is a call for launchpad devs, not us. As soon as they implement an easy way to see the stats of bugs in svn (i.e. not committed) and to switch committed->released, we can change the way we do it.

I'm very strongly in agreement with that.

Our current bug tracking is OK, but not great. Any improvement in workflows would be more than welcome.

I imagine that if the Launchpad devs get some precise workflow details of how things can be improved, then they will have a better chance at getting such improvements in.