Re: 3.27.90 tarball deadline extended

[Milan Crha <mcrha redhat com>]

On Thu, 2018-02-08 at 13:57 -0600, mcatanzaro gnome org wrote:
> Due to this delay, we will skip the 3.27.91 release altogether, so
> the next tarball deadline will be 3.27.92, on March 5. Perhaps by
> then we will be able to recommend using BuildStream for tarball
> generation.

        Hi,
is it a good idea? I know that 3.27.90 release of some of the products
I care of has issues which I promised to fix in 3.27.91, not longer
than two weeks after 3.27.90, as the GNOME schedule says. Nobody forces
me to not do the release, I know.

I understood that *the release team* has some trouble with tarballs,
but I do not understand why it should be such a big deal for everyone
else. There had been ways to generate tarballs a month ago, and it
didn't change. Not that significantly during that single month. Why to
postpone anything *for the rest of the world* in this transition
period? What I also do not understand is that release team should not
generate any tarballs, it's the developer's duty (I know, I know, the
practice is sometimes somewhat different, but anyway).

You want to use BuildStream, you are in the transition period, but it
doesn't mean that everything freezes, it shouldn't mean that you have
no backup plan if anything breaks. That's the transition period, it's
expected to face bugs and issues. I understood that BuildStream is a
*recommended* way of developing for GNOME, the same as jhbuild was a
*recommended* way of the same. I do not use either of them. I'm able to
create release tarballs for the products I care of. Thus, from my point
of view, as long as developers can create tarballs and release them,
and as long as the release team is able to validate these tarballs,
then there is no need to postpone anything. The worst the BuildStream
"exclusive" usage would be postponed, but not the release of GNOME.
Again, transition period, bugs expected, and so on. Everything makes
sense.

Just my opinion.
        Bye,
        Milan