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 <https://twitter.com/JeremyRubin> <https://twitter.com/JeremyRubin> On Mon, Mar 15, 2021 at 12:38 PM Luke Dashjr <l...@dashjr.org> 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 <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 > > > 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 > >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
