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 <https://twitter.com/JeremyRubin> > <https://twitter.com/JeremyRubin> > > > On Mon, Mar 15, 2021 at 10:20 AM Luke Dashjr via bitcoin-dev < > > [email protected]> 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 > > [email protected] > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
