Comment 10 for bug 962671

Revision history for this message
Jelmer Vernooij (jelmer) wrote : Re: [Bug 962671] Re: bzr-explorer is not compatible with bzr 2.6b1

On Mon, Mar 26, 2012 at 02:30:37PM -0000, treaves wrote:
> Yes, as a mater of fact, I do. And when me, or one of the other
> developers marks a bug as fix-committed, then the fix has been
> committed. And when that is released, the bug gets marked as fix-
> released.
I appreciate that we should clearly communicate what the status of a
particular bug is. And that inconsistency in the way bug statusses are
used isn't helpful.

That said, I don't think it's as straightforward as you say.

If a change has been committed in a contributors branch but hasn't
been merged into the main branch, is it fixcommitted too? Or is it committed
when it lands on mainline, or on the currently supported series
branch? How should you distinguish between these states?

Similarly, is it released when it has been a part of an alpha release,
or only if it has ended up in a final release, if it has been part of
an RC?

What about for projects that don't do official releases but just have
a SCM branch? Should they keep their fixcommitted bugs open forever?

> See, these are actual words, not made up combinations of letters. And
> as such, they have a meaning. And the definition of committed, in the
> context of SCM, is that something has been added to the repository.
> And the definition of a release is that there is a binary build or
> package available for users to download.
Releasing something is (among other things) making it available for public use.

Of course, FOSS releases are traditionally done by publishing a tarball,
but the dictionary definition of "release" doesn't say anywhere that
it has to be a tarball.

> I hope you've learned something today.
You're welcome to question the way things are done. There's no need to
be condescending.

Cheers,

Jelmer