[bazaar] [ANN] bzr-2.5b3 has gone gold !

[Martin Pool]

On 11 November 2011 09:18, Martin Packman <martin.packman at canonical.com> wrote:
> On 10/11/2011, Vincent Ladeuil <vila+bzr at canonical.com> wrote:
>>
>> Right, the problem is that not all packagers seem to be subscribed to
>> bzr-packagers[1] and that the common understanding is that 'going gold' is
>> clearly intended to apply to the source release.
>
> Using the current terminology seems more confusing than just saying
> "[ANN] bzr-2.5b3 source ready for packaging" or similar. As a term of
> art 'going gold' implies about the right thing, but it sounds too
> shiny to the ear for general listeners.

+1

I think just saying "2.5b3 source is frozen" would be better.

I think the term originally comes from proprietary software shipped on
physical meda where they would make a 'golden' cd or iso.  There are
some obvious differences, one being that at that point all the
installer work was done, another being that the announcement was less
visible to users than it is here.

> It's further confused by <https://launchpad.net/bzr> announcing the
> latest version is 2.5b3 which only has a tarball, rather than 2.4.2 or
> the previous beta. Perhaps the expectation is most users go through a
> less developer-oriented gateway, like the wiki, pypi, or one of the
> other aggregation sites.

I think Launchpad ought to be able to act as the project's home page,
and the fact it can't offer separate stable and beta downloads is a
bug (I think a filed bug.)

One way we can work around it is perhaps not to mark the milestone
released until it is complete with its packages.  I don't know if you
can attach files to an unreleased milestone though - but this too
could be fixed.

> Jonathan also noted that being able to re-roll the tarball in response
> to packager feedback is useful. I agree that tagging a source release
> without seeing if it has build issues on some platform or other is
> suboptimal, but think the tagging first approach we have now is
> probably the right compromise. There's too much manual work for
> certain platforms to justify a RC each time, over a redo when
> something goes wrong.

Right, I think we want to aim for a process that gets the release
right the first time, and when we do get it right having a separate rc
(with announcements, packaging, etc) is just waste.  If there are
problems in the tarball discovered during packaging we should just
burn off that release and proceed to the next one.  Having multiple
things claiming to be 2.5b3 is just asking for confusion.

> The right solution here in the long term, is to
> get the packaging well enough automated that we do it continuously for
> trunk and run the test suite against the installed versions.

+1

I do wonder if it would be a better use of time to just have daily
builds off trunk rather than specifically announced betas.  The
drawbacks probably are that there are people who will use betas that
won't test nightlies, and that some platforms don't have automated
builds.

m