Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8A4F1C0001 for ; Mon, 15 Mar 2021 20:59:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 70F506F584 for ; Mon, 15 Mar 2021 20:59:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wy5QkqtVnE8w for ; Mon, 15 Mar 2021 20:59:26 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by smtp3.osuosl.org (Postfix) with ESMTPS id D6B2660642 for ; Mon, 15 Mar 2021 20:59:25 +0000 (UTC) Received: from mail-io1-f52.google.com (mail-io1-f52.google.com [209.85.166.52]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 12FKxM5L007343 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 15 Mar 2021 16:59:23 -0400 Received: by mail-io1-f52.google.com with SMTP id 81so34897782iou.11 for ; Mon, 15 Mar 2021 13:59:23 -0700 (PDT) X-Gm-Message-State: AOAM531jzOVDgy+6h8wTmBetbpLl9GWHCPzaeUtFiHhW7aznc5w6Bhv0 BozSO6S9WhfEXhklO8a9h6GGguf735/fITQaG7Y= X-Google-Smtp-Source: ABdhPJwh+D1K3INpCzQjWo/m9Qqv8ATJ4Lmw9At1GpwG7Ln/JPyam4ysNT0E6FKQj8wt2LIbYW2fyPjhdOsfkQdk5Go= X-Received: by 2002:a05:6602:1592:: with SMTP id e18mr1011741iow.49.1615841962695; Mon, 15 Mar 2021 13:59:22 -0700 (PDT) MIME-Version: 1.0 References: <202103151720.04687.luke@dashjr.org> <202103151937.38260.luke@dashjr.org> In-Reply-To: <202103151937.38260.luke@dashjr.org> From: Jeremy Date: Mon, 15 Mar 2021 13:59:11 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Luke Dashjr Content-Type: multipart/alternative; boundary="0000000000003320d305bd9986f2" Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2021 20:59:27 -0000 --0000000000003320d305bd9986f2 Content-Type: text/plain; charset="UTF-8" Can you expand on the timeline issue? Which timelines are incompatible and why? It does seem like a release done *today* cannot happen anyways, so it sounds like it's already too late... or do you mean beginning the release process today? -- @JeremyRubin On Mon, Mar 15, 2021 at 12:38 PM Luke Dashjr wrote: > While I agree 24 hours is too short notice, if someone wishes to insist on > keeping the current timeline, software supporting it should be released > _today_. Putting the meeting off a week would almost necessarily imply > rejection of any desires to stick to the original plan. > > So for that reason, I think we need to at least try to have a meeting > tomorrow, at least to give anyone who won't agree to such a delay a chance > to > speak up before it's too late, and have his argument fairly considered. > > We can still have a meeting next week. The idea of having one every other > week > seems like a good idea to avoid this in the future, too. > > Luke > > > On Monday 15 March 2021 19:14:02 Jeremy wrote: > > Please announce such meetings with more than ~24 hours notice -- this has > > happened several times and while I recognize the pace of development on > > this issue I think that slotting a consensus meeting with less than 24 > > hours is inappropriate. > > > > I think we should proactively postpone it a week so that there isn't an > > arbitrary "too low turnout" measure and instead anyone who really wants > to > > be present for the meeting can plan to be. > > > > So as not to lose momentum on having a discussion, I propose to plan to > > hold a general discussion tomorrow at that time and a meeting (with the > > intent of resolving issues in a more binding way) next week. It may be a > > good idea to hold the time slot every other week for the next while so > that > > we can avoid this 24 hour thing altogether. > > > > It sucks to lose another week but a precedent of 24 hour notice meetings > > for non urgent changes is very negative. > > > > (This isn't any comment on if ST is OK or not -- the schedules proposed > for > > ST thus far seem acceptable to me) > > > > Best, > > > > Jeremy > > -- > > @JeremyRubin > > > > > > > > On Mon, Mar 15, 2021 at 10:20 AM Luke Dashjr via bitcoin-dev < > > > > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > At the previous meeting, there was consensus for BIP8 activation > > > parameters > > > except for LOT, assuming a release around this time. Since then, a > > > release has not occurred, and the new idea of Speedy Trial has been > > > proposed to preempt the original/main activation plan. > > > > > > It's probably a good idea to meet up again to discuss these things and > > > adjust > > > accordingly. > > > > > > Agenda: > > > > > > - Speedy Trial: Can we get a comparable consensus on the proposal? > > > (Note: current draft conflicts with original plan timeline) > > > > > > - Main activation, post ST: Moving startheight (and timeoutheight?) > later > > > is probably a good idea at this point, both because too little > progress > > > has > > > been made on it, and to avoid the conflict with the current ST draft. > > > > > > - Making progress: To date, too few people have been involved in > > > materialising > > > the main activation plan. If it's going to move forward, more people > > > need to > > > get actively involved. This should not wait for ST to complete, > unless > > > we want another 4-5 month slip of the timeline. > > > > > > This meeting is tentatively scheduled for *tomorrow*, March 16th at the > > > usual > > > time of 19:00 UTC, in freenode's ##Taproot-activation IRC channel. If > > > turnout > > > is too low, we can postpone it a week, but it'd be nice to get things > > > resolved and moving sooner. > > > > > > As a reminder, the channel is also open for ongoing discussion 24/7, > and > > > there > > > is a web chat client here: > > > > > > https://webchat.freenode.net/?channel=##taproot-activation > > > > > > Luke > > > _______________________________________________ > > > bitcoin-dev mailing list > > > bitcoin-dev@lists.linuxfoundation.org > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --0000000000003320d305bd9986f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Can you expand on the tim= eline issue? Which timelines are incompatible and why?

It does seem l= ike a release done *today* cannot happen anyways, so it sounds like it'= s already too late... or do you mean beginning the release process today?

=
On Mon= , Mar 15, 2021 at 12:38 PM Luke Dashjr <luke@dashjr.org> wrote:
While I agree 24 hours is too short notice, if someone wi= shes to insist on
keeping the current timeline, software supporting it should be released _today_. Putting the meeting off a week would almost necessarily imply
rejection of any desires to stick to the original plan.

So for that reason, I think we need to at least try to have a meeting
tomorrow, at least to give anyone who won't agree to such a delay a cha= nce to
speak up before it's too late, and have his argument fairly considered.=

We can still have a meeting next week. The idea of having one every other w= eek
seems like a good idea to avoid this in the future, too.

Luke


On Monday 15 March 2021 19:14:02 Jeremy wrote:
> Please announce such meetings with more than ~24 hours notice -- this = has
> happened several times and while I recognize the pace of development o= n
> this issue I think that slotting a consensus meeting with less than 24=
> hours is inappropriate.
>
> I think we should proactively postpone it a week so that there isn'= ;t an
> arbitrary "too low turnout" measure and instead anyone who r= eally wants to
> be present for the meeting can plan to be.
>
> So as not to lose momentum on having a discussion, I propose to plan t= o
> hold a general discussion tomorrow at that time and a meeting (with th= e
> intent of resolving issues in a more binding way) next week. It may be= a
> good idea to hold the time slot every other week for the next while so= that
> we can avoid this 24 hour thing altogether.
>
> It sucks to lose another week but a precedent of 24 hour notice meetin= gs
> for non urgent changes is very negative.
>
> (This isn't any comment on if ST is OK or not -- the schedules pro= posed for
> ST thus far seem acceptable to me)
>
> Best,
>
> Jeremy
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>
>
> On Mon, Mar 15, 2021 at 10:20 AM Luke Dashjr via bitcoin-dev <
>
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> > At the previous meeting, there was consensus for BIP8 activation<= br> > > parameters
> > except for LOT, assuming a release around this time. Since then, = a
> > release has not occurred, and the new idea of Speedy Trial has be= en
> > proposed to preempt the original/main activation plan.
> >
> > It's probably a good idea to meet up again to discuss these t= hings and
> > adjust
> > accordingly.
> >
> > Agenda:
> >
> > - Speedy Trial: Can we get a comparable consensus on the proposal= ?
> >=C2=A0 =C2=A0(Note: current draft conflicts with original plan tim= eline)
> >
> > - Main activation, post ST: Moving startheight (and timeoutheight= ?) later
> >=C2=A0 =C2=A0is probably a good idea at this point, both because t= oo little progress
> > has
> >=C2=A0 =C2=A0been made on it, and to avoid the conflict with the c= urrent ST draft.
> >
> > - Making progress: To date, too few people have been involved in<= br> > > materialising
> >=C2=A0 =C2=A0the main activation plan. If it's going to move f= orward, more people
> > need to
> >=C2=A0 =C2=A0get actively involved. This should not wait for ST to= complete, unless
> > we want another 4-5 month slip of the timeline.
> >
> > This meeting is tentatively scheduled for *tomorrow*, March 16th = at the
> > usual
> > time of 19:00 UTC, in freenode's ##Taproot-activation IRC cha= nnel. If
> > turnout
> > is too low, we can postpone it a week, but it'd be nice to ge= t things
> > resolved and moving sooner.
> >
> > As a reminder, the channel is also open for ongoing discussion 24= /7, and
> > there
> > is a web chat client here:
> >
> > https://webchat.freenode.net= /?channel=3D##taproot-activation
> >
> > Luke
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundatio= n.org/mailman/listinfo/bitcoin-dev

--0000000000003320d305bd9986f2--