Stefan Sperling wrote on Wed, Jan 25, 2017 at 11:37:30 +0100:
> 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:
> > 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.
How about:
1) Once the RM stages the artifacts for the mirrors [starting what would
normally be a 24 hour delay prior to announcing], we post to dev@
inviting client/distro maintainers to link to their own alpha1 releases
within N days.
2) After N days, we announce. If some third party misses the train,
then they're out of that announcement.
> 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.
I was hoping it'd be clear from context, that the intended benefit is
getting more users to test our alpha release. I'm hoping more users
will test the release if we put a "Download <new binary release> of
<your favourite client>" link right in front of them, than if we just
tell them we've released a new source tree.
Anyway, I'm not married to this idea. I just wanted to raise the
question of how we attempt to get more feedback on this alpha than on
previous ones.
Cheers,
Daniel
Received on 2017-01-25 19:44:55 CET