public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Jeremy <jlrubin@mit•edu>
To: Luke Dashjr <luke@dashjr•org>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Taproot activation meeting on IRC - Tuesday 16th March 19:00 UTC
Date: Mon, 15 Mar 2021 13:59:11 -0700	[thread overview]
Message-ID: <CAD5xwhg7-KXysYb4sT+uvnPBZm+LanERsgyOiZOyEDjo=kRjRA@mail.gmail.com> (raw)
In-Reply-To: <202103151937.38260.luke@dashjr.org>

[-- Attachment #1: Type: text/plain, Size: 4325 bytes --]

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 <luke@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
>
>

[-- Attachment #2: Type: text/html, Size: 6359 bytes --]

  reply	other threads:[~2021-03-15 20:59 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-15 17:20 Luke Dashjr
2021-03-15 19:14 ` Jeremy
2021-03-15 19:37   ` Luke Dashjr
2021-03-15 20:59     ` Jeremy [this message]
2021-03-15 21:46       ` Luke Dashjr
2021-03-16 17:42 ` Emil Pfeffer
2021-03-17  8:21 Prayank
2021-03-19 10:45 ` Emil Pfeffer
2021-03-19 16:55   ` Prayank

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAD5xwhg7-KXysYb4sT+uvnPBZm+LanERsgyOiZOyEDjo=kRjRA@mail.gmail.com' \
    --to=jlrubin@mit$(echo .)edu \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=luke@dashjr$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox