On Tue, Jan 24, 2017 at 07:06:29PM +0000, Daniel Shahaf wrote:
> Stefan Sperling wrote on Tue, Jan 24, 2017 at 19:06:13 +0100:
> > On Tue, Jan 24, 2017 at 05:52:39PM +0000, Daniel Shahaf wrote:
> > > I wonder if we should delay the release announcement until we can link
> > > to a bunch of .deb/.rpm/GUIs/* from it. This way, once we do announce@,
> > > we can hope for a higher proportion of readers to act about it.
> > >
> > > (I'm not proposing to change the "no official binary releases" policy;
> > > just to wait until downstreams have made their own binaries available)
> > I don't think our own release announcement has any bearing on this.
> > We can just announce when we're ready. Once binaries become available
> > they can also announced on our lists (e.g. by replying to the release
> > announcement mailthread, as has often been done).
> Announcing binaries on the users@ list only reaches users who subscribed
> to the support questions firehose.
We could also add links to news items our web site, even after the fact.
> Our target audience for the alpha
> announcement is users who are willing to run alpha code on their wc's.
> I assume some of these people are on announce@ but not on users@.
I don't know the subscriber list so I can't tell the difference between
> > If we do this, it would be good to know upfront what kind of binaries
> > we can expect and should wait for. And that might complicate things.
> That's just a synchronization problem and is easily solved. I'm more
> concerned that we'd need to come up with objective criteria for *which*
> third parties we do or don't include in our own annoucnements.
Our own release date is unpredictable. We cannot tell anyone when it will
be done until it is done, which makes such synchronization difficult,
not easy. So I really don't think we should wait for anyone else, or let
anyone else wait for us after some prematurely announced release date
which we missed.
I'm also concerned about waiting for third parties which make promises in
good faith but then turn out to be unable to follow up and cause deadlock.
Your suggestion creates extra work for the release manager and I don't
see the benefit that gives this idea an advantage over just announcing
the release by itself and then letting third parties deal with binaries,
as we have always been doing.
Received on 2017-01-25 11:37:38 CET