* [bitcoin-dev] Proposed BIP editor: Kalle Alm
@ 2021-04-23 2:09 Luke Dashjr
2021-04-23 3:36 ` Jeremy
` (4 more replies)
0 siblings, 5 replies; 29+ messages in thread
From: Luke Dashjr @ 2021-04-23 2:09 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
Unless there are objections, I intend to add Kalle Alm as a BIP editor to
assist in merging PRs into the bips git repo.
Since there is no explicit process to adding BIP editors, IMO it should be
fine to use BIP 2's Process BIP progression:
> A process BIP may change status from Draft to Active when it achieves
> rough consensus on the mailing list. Such a proposal is said to have
> rough consensus if it has been open to discussion on the development
> mailing list for at least one month, and no person maintains any
> unaddressed substantiated objections to it.
A Process BIP could be opened for each new editor, but IMO that is
unnecessary. If anyone feels there is a need for a new Process BIP, we can go
that route, but there is prior precedent for BIP editors appointing new BIP
editors, so I think this should be fine.
Please speak up soon if you disagree.
Luke
^ permalink raw reply [flat|nested] 29+ messages in thread* Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm 2021-04-23 2:09 [bitcoin-dev] Proposed BIP editor: Kalle Alm Luke Dashjr @ 2021-04-23 3:36 ` Jeremy 2021-04-23 7:49 ` John Newbery 2021-04-23 7:50 ` Pindar Wong ` (3 subsequent siblings) 4 siblings, 1 reply; 29+ messages in thread From: Jeremy @ 2021-04-23 3:36 UTC (permalink / raw) To: Luke Dashjr, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1384 bytes --] ACK adding Kalle. Kalle is a qualified reviewer / editor and well suited for this role. -- @JeremyRubin <https://twitter.com/JeremyRubin> <https://twitter.com/JeremyRubin> On Thu, Apr 22, 2021 at 7:09 PM Luke Dashjr via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Unless there are objections, I intend to add Kalle Alm as a BIP editor to > assist in merging PRs into the bips git repo. > > Since there is no explicit process to adding BIP editors, IMO it should be > fine to use BIP 2's Process BIP progression: > > > A process BIP may change status from Draft to Active when it achieves > > rough consensus on the mailing list. Such a proposal is said to have > > rough consensus if it has been open to discussion on the development > > mailing list for at least one month, and no person maintains any > > unaddressed substantiated objections to it. > > A Process BIP could be opened for each new editor, but IMO that is > unnecessary. If anyone feels there is a need for a new Process BIP, we can > go > that route, but there is prior precedent for BIP editors appointing new > BIP > editors, so I think this should be fine. > > Please speak up soon if you disagree. > > Luke > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 2479 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm 2021-04-23 3:36 ` Jeremy @ 2021-04-23 7:49 ` John Newbery 0 siblings, 0 replies; 29+ messages in thread From: John Newbery @ 2021-04-23 7:49 UTC (permalink / raw) To: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1739 bytes --] ACK adding Kalle. On Fri, Apr 23, 2021 at 4:36 AM Jeremy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > ACK adding Kalle. > > Kalle is a qualified reviewer / editor and well suited for this role. > -- > @JeremyRubin <https://twitter.com/JeremyRubin> > <https://twitter.com/JeremyRubin> > > > On Thu, Apr 22, 2021 at 7:09 PM Luke Dashjr via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Unless there are objections, I intend to add Kalle Alm as a BIP editor to >> assist in merging PRs into the bips git repo. >> >> Since there is no explicit process to adding BIP editors, IMO it should >> be >> fine to use BIP 2's Process BIP progression: >> >> > A process BIP may change status from Draft to Active when it achieves >> > rough consensus on the mailing list. Such a proposal is said to have >> > rough consensus if it has been open to discussion on the development >> > mailing list for at least one month, and no person maintains any >> > unaddressed substantiated objections to it. >> >> A Process BIP could be opened for each new editor, but IMO that is >> unnecessary. If anyone feels there is a need for a new Process BIP, we >> can go >> that route, but there is prior precedent for BIP editors appointing new >> BIP >> editors, so I think this should be fine. >> >> Please speak up soon if you disagree. >> >> 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 > [-- Attachment #2: Type: text/html, Size: 3326 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm 2021-04-23 2:09 [bitcoin-dev] Proposed BIP editor: Kalle Alm Luke Dashjr 2021-04-23 3:36 ` Jeremy @ 2021-04-23 7:50 ` Pindar Wong 2021-04-23 9:11 ` Eric Martindale 2021-04-23 15:34 ` Antoine Riard ` (2 subsequent siblings) 4 siblings, 1 reply; 29+ messages in thread From: Pindar Wong @ 2021-04-23 7:50 UTC (permalink / raw) To: Luke Dashjr, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1221 bytes --] ACK. p. On Fri, Apr 23, 2021 at 10:09 AM Luke Dashjr via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Unless there are objections, I intend to add Kalle Alm as a BIP editor to > assist in merging PRs into the bips git repo. > > Since there is no explicit process to adding BIP editors, IMO it should be > fine to use BIP 2's Process BIP progression: > > > A process BIP may change status from Draft to Active when it achieves > > rough consensus on the mailing list. Such a proposal is said to have > > rough consensus if it has been open to discussion on the development > > mailing list for at least one month, and no person maintains any > > unaddressed substantiated objections to it. > > A Process BIP could be opened for each new editor, but IMO that is > unnecessary. If anyone feels there is a need for a new Process BIP, we can > go > that route, but there is prior precedent for BIP editors appointing new > BIP > editors, so I think this should be fine. > > Please speak up soon if you disagree. > > Luke > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 1846 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm 2021-04-23 7:50 ` Pindar Wong @ 2021-04-23 9:11 ` Eric Martindale 0 siblings, 0 replies; 29+ messages in thread From: Eric Martindale @ 2021-04-23 9:11 UTC (permalink / raw) To: Pindar Wong, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1704 bytes --] ACK. Kalle has been exceptional throughout his contributions — especially thankful for btcdeb 🙏 On Fri, Apr 23, 2021, 3:51 AM Pindar Wong via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > ACK. > > p. > > > On Fri, Apr 23, 2021 at 10:09 AM Luke Dashjr via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> Unless there are objections, I intend to add Kalle Alm as a BIP editor to >> assist in merging PRs into the bips git repo. >> >> Since there is no explicit process to adding BIP editors, IMO it should >> be >> fine to use BIP 2's Process BIP progression: >> >> > A process BIP may change status from Draft to Active when it achieves >> > rough consensus on the mailing list. Such a proposal is said to have >> > rough consensus if it has been open to discussion on the development >> > mailing list for at least one month, and no person maintains any >> > unaddressed substantiated objections to it. >> >> A Process BIP could be opened for each new editor, but IMO that is >> unnecessary. If anyone feels there is a need for a new Process BIP, we >> can go >> that route, but there is prior precedent for BIP editors appointing new >> BIP >> editors, so I think this should be fine. >> >> Please speak up soon if you disagree. >> >> 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 > [-- Attachment #2: Type: text/html, Size: 2818 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm 2021-04-23 2:09 [bitcoin-dev] Proposed BIP editor: Kalle Alm Luke Dashjr 2021-04-23 3:36 ` Jeremy 2021-04-23 7:50 ` Pindar Wong @ 2021-04-23 15:34 ` Antoine Riard 2021-04-24 10:16 ` nopara73 2021-04-25 20:29 ` [bitcoin-dev] Reminder on the Purpose of BIPs Matt Corallo 2021-04-26 15:02 ` [bitcoin-dev] Proposed BIP editor: Kalle Alm Sjors Provoost 2021-04-26 18:13 ` W. J. van der Laan 4 siblings, 2 replies; 29+ messages in thread From: Antoine Riard @ 2021-04-23 15:34 UTC (permalink / raw) To: Luke Dashjr, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2431 bytes --] Hi Luke, For the records and the subscribers of this list not following #bitcoin-core-dev, this mail follows a discussion which did happen during yesterday irc meetings. Logs here : http://gnusha.org/bitcoin-core-dev/2021-04-22.log I'll reiterate my opinion expressed during the meeting. If this proposal to extend the bip editorship membership doesn't satisfy parties involved or anyone in the community, I'm strongly opposed to have the matter sliced by admins of the Bitcoin github org. I believe that defect or uncertainty in the BIP Process shouldn't be solved by GH janitorial roles and I think their roles don't bestow to intervene in case of loopholes. Further, you have far more contributors involved in the BIP Process rather than only Bitcoin Core ones. FWIW, such precedent merits would be quite similar to lobby directly GH staff... Unless we harm Bitcoin users by not acting, I think we should always be respectful of procedural forms. And in the lack of such forms, stay patient until a solution satisfy everyone. I would recommend the BIP editorship, once extended or not, to move in its own repository in the future. Cheers, Antoine Le jeu. 22 avr. 2021 à 22:09, Luke Dashjr via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> a écrit : > Unless there are objections, I intend to add Kalle Alm as a BIP editor to > assist in merging PRs into the bips git repo. > > Since there is no explicit process to adding BIP editors, IMO it should be > fine to use BIP 2's Process BIP progression: > > > A process BIP may change status from Draft to Active when it achieves > > rough consensus on the mailing list. Such a proposal is said to have > > rough consensus if it has been open to discussion on the development > > mailing list for at least one month, and no person maintains any > > unaddressed substantiated objections to it. > > A Process BIP could be opened for each new editor, but IMO that is > unnecessary. If anyone feels there is a need for a new Process BIP, we can > go > that route, but there is prior precedent for BIP editors appointing new > BIP > editors, so I think this should be fine. > > Please speak up soon if you disagree. > > Luke > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 3171 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm 2021-04-23 15:34 ` Antoine Riard @ 2021-04-24 10:16 ` nopara73 2021-04-25 20:29 ` [bitcoin-dev] Reminder on the Purpose of BIPs Matt Corallo 1 sibling, 0 replies; 29+ messages in thread From: nopara73 @ 2021-04-24 10:16 UTC (permalink / raw) To: Antoine Riard, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 2865 bytes --] ACK adding Kalle On Fri, Apr 23, 2021 at 5:51 PM Antoine Riard via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi Luke, > > For the records and the subscribers of this list not following > #bitcoin-core-dev, this mail follows a discussion which did happen during > yesterday irc meetings. > Logs here : http://gnusha.org/bitcoin-core-dev/2021-04-22.log > > I'll reiterate my opinion expressed during the meeting. If this proposal > to extend the bip editorship membership doesn't satisfy parties involved or > anyone in the community, I'm strongly opposed to have the matter sliced by > admins of the Bitcoin github org. I believe that defect or uncertainty in > the BIP Process shouldn't be solved by GH janitorial roles and I think > their roles don't bestow to intervene in case of loopholes. Further, you > have far more contributors involved in the BIP Process rather than only > Bitcoin Core ones. FWIW, such precedent merits would be quite similar to > lobby directly GH staff... > > Unless we harm Bitcoin users by not acting, I think we should always be > respectful of procedural forms. And in the lack of such forms, stay patient > until a solution satisfy everyone. > > I would recommend the BIP editorship, once extended or not, to move in its > own repository in the future. > > Cheers, > Antoine > > > > > Le jeu. 22 avr. 2021 à 22:09, Luke Dashjr via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> a écrit : > >> Unless there are objections, I intend to add Kalle Alm as a BIP editor to >> assist in merging PRs into the bips git repo. >> >> Since there is no explicit process to adding BIP editors, IMO it should >> be >> fine to use BIP 2's Process BIP progression: >> >> > A process BIP may change status from Draft to Active when it achieves >> > rough consensus on the mailing list. Such a proposal is said to have >> > rough consensus if it has been open to discussion on the development >> > mailing list for at least one month, and no person maintains any >> > unaddressed substantiated objections to it. >> >> A Process BIP could be opened for each new editor, but IMO that is >> unnecessary. If anyone feels there is a need for a new Process BIP, we >> can go >> that route, but there is prior precedent for BIP editors appointing new >> BIP >> editors, so I think this should be fine. >> >> Please speak up soon if you disagree. >> >> 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 > -- Best, Ádám [-- Attachment #2: Type: text/html, Size: 4253 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* [bitcoin-dev] Reminder on the Purpose of BIPs 2021-04-23 15:34 ` Antoine Riard 2021-04-24 10:16 ` nopara73 @ 2021-04-25 20:29 ` Matt Corallo 2021-04-25 21:00 ` Luke Dashjr 1 sibling, 1 reply; 29+ messages in thread From: Matt Corallo @ 2021-04-25 20:29 UTC (permalink / raw) To: Antoine Riard, Bitcoin Protocol Discussion, Luke Dashjr, Karl-Johan Alm There appears to be some severe lack of understanding of the point of the BIP process here. The BIP process exists to be a place for those in the Bitcoin development community (which includes anyone who wishes to participate in it!) to place specifications which may be important for others in the Bitcoin development community to see, to ensure interoperability. It does not, should not, and has never existed to take any positions on...anything. It has always existed to allow those who wish to participate in the Bitcoin development community to publish proposed standards or deployed protocols, in whatever form the authors of the BIPs seem fit. If anyone suggests changes with a BIP's proposed form in a way the original author does not agree with, they have always been free to, and should simply create a new BIP with their proposed form. The BIP editor's role has always been, and should continue to be, to encourage BIP authors to respond to (either by dismissing or accepting) feedback on their BIPs, and encourage formatting in a standard form. The BIP editor's role has never included, and should not include, taking a stance on substantive changes to a BIP's contents - those are up to the author(s) of a BIP, and always have been. If the BIP editor is deliberately refusing to accept changes which the author's approval (which appears to be occurring here), the broader development community (us) should either remove the BIP editor and replace them, or simply ignore the BIP repository entirely (which seems like the most likely outcome here). There really should be no debate over this point, and I'm not entirely sure why anyone would think there should be. Luckily BIPs aren't really all that critical in this instance - they exist to communicate protocols for interoperability, and in this case the protocol changes as proposed have been broadly communicated already. Still, given the apparent lack of desire to remove the BIP editor in this case, I'd suggest we all move on and simply ignore the BIP repository entirely. Simply sending notices of protocol systems to this mailing list is likely sufficient. Matt On 4/23/21 11:34, Antoine Riard via bitcoin-dev wrote: > Hi Luke, > > For the records and the subscribers of this list not following #bitcoin-core-dev, this mail follows a discussion which > did happen during yesterday irc meetings. > Logs here : http://gnusha.org/bitcoin-core-dev/2021-04-22.log <http://gnusha.org/bitcoin-core-dev/2021-04-22.log> > > I'll reiterate my opinion expressed during the meeting. If this proposal to extend the bip editorship membership doesn't > satisfy parties involved or anyone in the community, I'm strongly opposed to have the matter sliced by admins of the > Bitcoin github org. I believe that defect or uncertainty in the BIP Process shouldn't be solved by GH janitorial roles > and I think their roles don't bestow to intervene in case of loopholes. Further, you have far more contributors involved > in the BIP Process rather than only Bitcoin Core ones. FWIW, such precedent merits would be quite similar to lobby > directly GH staff... > > Unless we harm Bitcoin users by not acting, I think we should always be respectful of procedural forms. And in the lack > of such forms, stay patient until a solution satisfy everyone. > > I would recommend the BIP editorship, once extended or not, to move in its own repository in the future. > > Cheers, > Antoine > > > > > Le jeu. 22 avr. 2021 à 22:09, Luke Dashjr via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org>> a écrit : > > Unless there are objections, I intend to add Kalle Alm as a BIP editor to > assist in merging PRs into the bips git repo. > > Since there is no explicit process to adding BIP editors, IMO it should be > fine to use BIP 2's Process BIP progression: > > > A process BIP may change status from Draft to Active when it achieves > > rough consensus on the mailing list. Such a proposal is said to have > > rough consensus if it has been open to discussion on the development > > mailing list for at least one month, and no person maintains any > > unaddressed substantiated objections to it. > > A Process BIP could be opened for each new editor, but IMO that is > unnecessary. If anyone feels there is a need for a new Process BIP, we can go > that route, but there is prior precedent for BIP editors appointing new BIP > editors, so I think this should be fine. > > Please speak up soon if you disagree. > > Luke > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > <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 > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Reminder on the Purpose of BIPs 2021-04-25 20:29 ` [bitcoin-dev] Reminder on the Purpose of BIPs Matt Corallo @ 2021-04-25 21:00 ` Luke Dashjr 2021-04-25 21:14 ` Matt Corallo 2021-04-27 12:16 ` Jorge Timón 0 siblings, 2 replies; 29+ messages in thread From: Luke Dashjr @ 2021-04-25 21:00 UTC (permalink / raw) To: Matt Corallo; +Cc: Bitcoin Protocol Discussion On Sunday 25 April 2021 20:29:44 Matt Corallo wrote: > If the BIP editor is deliberately refusing to accept changes which the > author's approval (which appears to be occurring here), It isn't. I am triaging BIPs PRs the same as I have for years, and will get to them all in due time, likely before the end of the month. Rather, what we have going on is a few bad actors trying to misportray the BIPs as an approval process so they can pretend ST is somehow official, or that the preexisting Core+Taproot client is "breaking" the spec. And to further their agenda, they have been harassing me demanding special treatment. I will not become an accomplice to this deception by giving special treatment, and will process the BIP PR neutrally according to the currently-defined BIP process. Despite the continual harassment, I have even made two efforts to try to (fairly) make things faster, and have been obstructed both times by ST advocates. It appears they intend to paint me as "deliberately refusing" (to use your words) in order to try to put Bitcoin and the BIP process under their control, and abuse it in the same manner in which they abused Bitcoin Core's usual standards (by releasing ST without community consensus). Luke ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Reminder on the Purpose of BIPs 2021-04-25 21:00 ` Luke Dashjr @ 2021-04-25 21:14 ` Matt Corallo 2021-04-25 21:22 ` Luke Dashjr 2021-04-27 12:16 ` Jorge Timón 1 sibling, 1 reply; 29+ messages in thread From: Matt Corallo @ 2021-04-25 21:14 UTC (permalink / raw) To: Luke Dashjr; +Cc: Bitcoin Protocol Discussion On 4/25/21 17:00, Luke Dashjr wrote: > On Sunday 25 April 2021 20:29:44 Matt Corallo wrote: >> If the BIP editor is deliberately refusing to accept changes which the >> author's approval (which appears to be occurring here), > > It isn't. I am triaging BIPs PRs the same as I have for years, and will get to > them all in due time, likely before the end of the month. Please don't play dumb, it isn't a good look. > Rather, what we have going on is a few bad actors trying to misportray the > BIPs as an approval process so they can pretend ST is somehow official, or > that the preexisting Core+Taproot client is "breaking" the spec. And to > further their agenda, they have been harassing me demanding special > treatment. I'd be curious who is doing that, because obviously I'd agree that merging something in a BIP doesn't really have any special meaning. This, however, is a completely different topic from following the BIP process that you had a key hand in crafting. > I will not become an accomplice to this deception by giving special treatment, > and will process the BIP PR neutrally according to the currently-defined BIP > process. Again, please don't play dumb, no one watching believes this - you've been active on the BIP repo on numerous PRs and this has never in the past been the case. > Despite the continual harassment, I have even made two efforts to try to > (fairly) make things faster, and have been obstructed both times by ST > advocates. It appears they intend to paint me as "deliberately refusing" (to > use your words) in order to try to put Bitcoin and the BIP process under > their control, and abuse it in the same manner in which they abused Bitcoin > Core's usual standards (by releasing ST without community consensus). > > Luke > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Reminder on the Purpose of BIPs 2021-04-25 21:14 ` Matt Corallo @ 2021-04-25 21:22 ` Luke Dashjr 2021-04-25 21:31 ` Matt Corallo 0 siblings, 1 reply; 29+ messages in thread From: Luke Dashjr @ 2021-04-25 21:22 UTC (permalink / raw) To: Matt Corallo; +Cc: Bitcoin Protocol Discussion On Sunday 25 April 2021 21:14:08 Matt Corallo wrote: > On 4/25/21 17:00, Luke Dashjr wrote: > > I will not become an accomplice to this deception by giving special > > treatment, and will process the BIP PR neutrally according to the > > currently-defined BIP process. > > Again, please don't play dumb, no one watching believes this - you've been > active on the BIP repo on numerous PRs and this has never in the past been > the case. I started going through PRs a few days ago, in order of "Recently updated" on GitHub, starting with the least-recent following the last one I triaged a month ago that hasn't seen activity.. the same as I have been doing month after month prior to this. If you don't believe me, feel free to look through the repo history. Luke ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Reminder on the Purpose of BIPs 2021-04-25 21:22 ` Luke Dashjr @ 2021-04-25 21:31 ` Matt Corallo 2021-04-26 19:43 ` David A. Harding 0 siblings, 1 reply; 29+ messages in thread From: Matt Corallo @ 2021-04-25 21:31 UTC (permalink / raw) To: Luke Dashjr; +Cc: Bitcoin Protocol Discussion Alright, let's see... Sorting by most recently updated... https://github.com/bitcoin/bips/pulls?page=1&q=is%3Apr+is%3Aopen+sort%3Aupdated-asc+updated%3A%3E2021-01-01 #1104 has been updated nearly daily for the past many weeks. You commented 12 days ago saying "Concept NACK" (which isn't a thing on BIPs - huh? they're author documents, as you're well aware), and nothing further. #1105 which is less recently updated by one on the above list has a comment from you 19 hours ago. I'm really not sure what playing dumb gets you, here. Its really transparent and isn't helpful in any way to anything. In general, I think its time we all agree the BIP process has simply failed and move on. Luckily its not really all that critical and proposed protocol documents can be placed nearly anywhere with the same effect. Matt On 4/25/21 17:22, Luke Dashjr wrote: > On Sunday 25 April 2021 21:14:08 Matt Corallo wrote: >> On 4/25/21 17:00, Luke Dashjr wrote: >>> I will not become an accomplice to this deception by giving special >>> treatment, and will process the BIP PR neutrally according to the >>> currently-defined BIP process. >> >> Again, please don't play dumb, no one watching believes this - you've been >> active on the BIP repo on numerous PRs and this has never in the past been >> the case. > > I started going through PRs a few days ago, in order of "Recently updated" on > GitHub, starting with the least-recent following the last one I triaged a > month ago that hasn't seen activity.. the same as I have been doing month > after month prior to this. > > If you don't believe me, feel free to look through the repo history. > > Luke > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Reminder on the Purpose of BIPs 2021-04-25 21:31 ` Matt Corallo @ 2021-04-26 19:43 ` David A. Harding 2021-04-26 20:04 ` Greg Maxwell ` (2 more replies) 0 siblings, 3 replies; 29+ messages in thread From: David A. Harding @ 2021-04-26 19:43 UTC (permalink / raw) To: Matt Corallo, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3832 bytes --] On Sun, Apr 25, 2021 at 05:31:50PM -0400, Matt Corallo via bitcoin-dev wrote: > In general, I think its time we all agree the BIP process has simply failed > and move on. Luckily its not really all that critical and proposed protocol > documents can be placed nearly anywhere with the same effect. I recommend: 1. We add additional BIP editors, starting with Kalle Alm (if there are no continuing significant objections). 2. We seek Luke Dashjr's resignation as BIPs editor. 3. We begin treating protocol documents outside the BIPs repository as first-class BIP documentation. The first recommendation permits continued maintenance of existing BIPs plus gives the additional maintainers an opportunity to rebuild the credibility of the repository. The second recommendation addresses the dissatisfaction of many BIP authors and potential authors with the current editor, which I think will discourage many of them from making additional significant contributions to the repository. It also seems to me to be a better use of Luke's talents and interests for him to focus on protocol research and review rather than procedurally checking whether a bunch of documents are well formed. The third recommendation provides an escape hatch for anyone, such as Matt, who currently thinks the process has failed, or for anyone who comes to that same conclusion in the future under a different editing team. My specific recommendations there are: a. Anyone writing protocol documentation in the spirit of the BIP process can post their idea to this mailing list like we've always done and, when they've finished collecting initial feedback, they can assign themselves a unique decentralized identifier starting with "bip-". They may also define a shorter alias that they encourage people to use in cases where the correct document can be inferred from context. E.g., bip-wuille-taproot (bip-taproot) bip-towns-versionbits-min-activation-height (bip-vbmah) bip-todd-harding-opt-in-replace-by-fee (bip-opt-in-rbf) b. The author then publishes the document to any place they'd like, although they are strongly encouraged to make any document source available under an open license to ensure others can create their own modifications. c. Implementations of BIPs, whether original repository BIPs or decentralized BIPs, link to the BIPs they implement to ensure researchers and developers can find the relevant protocol documentation. E.g., https://github.com/bitcoin/bitcoin/blob/fe5e495c31de47b0ec732b943db11fe345d874af/doc/bips.md (It may also be advisable for implementations to mirror copies of the BIPs they implement so later modifications to the document don't confuse anyone. For this reason, extremely liberal licensing of BIP documents is encouraged.) d. To help maintain quality and consistency between documentation, the BIP editors provide a BIP document template, guidelines similar to the existing BIP2, and an easy-to-run format linter. I think this decentralized BIPs alternative also helps address some longstanding problems with the BIPs system: that many casual Bitcoin users and developers think of documents in the BIPs repo as authoritative and that there are some development teams (such as for LN) that have already abandoned the BIPs process because, in part, they want complete control over their own documentation. The recommendations above were developed based on conversations I had with a few stakeholders in the BIPs process, but I did not attempt a comprehensive survey and I certainly don't claim to speak for anyone else. I hope the recommendations are satisfactory and I look forward to your feedback. Thanks, -Dave [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Reminder on the Purpose of BIPs 2021-04-26 19:43 ` David A. Harding @ 2021-04-26 20:04 ` Greg Maxwell 2021-04-27 19:43 ` Melvin Carvalho 2021-04-27 9:04 ` W. J. van der Laan 2021-04-27 11:33 ` John Newbery 2 siblings, 1 reply; 29+ messages in thread From: Greg Maxwell @ 2021-04-26 20:04 UTC (permalink / raw) To: David A. Harding, Bitcoin Protocol Discussion I endorse Harding's recommendations. On the point about mirroring, one thing to keep in mind is that the other repositories may go offline. Modification confusion could be avoided by recording what revision (commit hash) was current at the time of inclusion, but the document going offline can only be protected against by maintaining a copy somewhere. On Mon, Apr 26, 2021 at 7:44 PM David A. Harding via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > > On Sun, Apr 25, 2021 at 05:31:50PM -0400, Matt Corallo via bitcoin-dev wrote: > > In general, I think its time we all agree the BIP process has simply failed > > and move on. Luckily its not really all that critical and proposed protocol > > documents can be placed nearly anywhere with the same effect. > > I recommend: > > 1. We add additional BIP editors, starting with Kalle Alm (if there are > no continuing significant objections). > > 2. We seek Luke Dashjr's resignation as BIPs editor. > > 3. We begin treating protocol documents outside the BIPs repository as > first-class BIP documentation. > > The first recommendation permits continued maintenance of existing BIPs > plus gives the additional maintainers an opportunity to rebuild the > credibility of the repository. > > The second recommendation addresses the dissatisfaction of many BIP > authors and potential authors with the current editor, which I think > will discourage many of them from making additional significant > contributions to the repository. It also seems to me to be a better use > of Luke's talents and interests for him to focus on protocol research > and review rather than procedurally checking whether a bunch of > documents are well formed. > > The third recommendation provides an escape hatch for anyone, such as > Matt, who currently thinks the process has failed, or for anyone who > comes to that same conclusion in the future under a different editing > team. My specific recommendations there are: > > a. Anyone writing protocol documentation in the spirit of the BIP > process can post their idea to this mailing list like we've always > done and, when they've finished collecting initial feedback, they can > assign themselves a unique decentralized identifier starting with > "bip-". They may also define a shorter alias that they encourage > people to use in cases where the correct document can be inferred > from context. E.g., > > bip-wuille-taproot (bip-taproot) > bip-towns-versionbits-min-activation-height (bip-vbmah) > bip-todd-harding-opt-in-replace-by-fee (bip-opt-in-rbf) > > b. The author then publishes the document to any place they'd like, although > they are strongly encouraged to make any document source available > under an open license to ensure others can create their own > modifications. > > c. Implementations of BIPs, whether original repository BIPs or > decentralized BIPs, link to the BIPs they implement to ensure > researchers and developers can find the relevant protocol > documentation. E.g., > https://github.com/bitcoin/bitcoin/blob/fe5e495c31de47b0ec732b943db11fe345d874af/doc/bips.md > > (It may also be advisable for implementations to mirror copies of > the BIPs they implement so later modifications to the document > don't confuse anyone. For this reason, extremely liberal > licensing of BIP documents is encouraged.) > > d. To help maintain quality and consistency between documentation, the > BIP editors provide a BIP document template, guidelines similar to > the existing BIP2, and an easy-to-run format linter. > > I think this decentralized BIPs alternative also helps address some > longstanding problems with the BIPs system: that many casual Bitcoin > users and developers think of documents in the BIPs repo as > authoritative and that there are some development teams (such as for LN) > that have already abandoned the BIPs process because, in part, they want > complete control over their own documentation. > > The recommendations above were developed based on conversations I had > with a few stakeholders in the BIPs process, but I did not attempt a > comprehensive survey and I certainly don't claim to speak for anyone > else. I hope the recommendations are satisfactory and I look forward to > your feedback. > > Thanks, > > -Dave > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Reminder on the Purpose of BIPs 2021-04-26 20:04 ` Greg Maxwell @ 2021-04-27 19:43 ` Melvin Carvalho 0 siblings, 0 replies; 29+ messages in thread From: Melvin Carvalho @ 2021-04-27 19:43 UTC (permalink / raw) To: Greg Maxwell, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 6282 bytes --] On Mon, 26 Apr 2021 at 22:08, Greg Maxwell via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I endorse Harding's recommendations. On the point about mirroring, > one thing to keep in mind is that the other repositories may go > offline. > > Modification confusion could be avoided by recording what revision > (commit hash) was current at the time of inclusion, but the document > going offline can only be protected against by maintaining a copy > somewhere. > One could partially solve the mirroring issue by giving each decentralized BIP (optionally) a genesis transaction ID, that moved in time on the block chain This can be made to mirror / witness the evolution in git of the BIP using git commit hashes (in time), and then matching those commit hashes in the block chain by tweaking the public key address by the same amount (with no change address) What would occur then would be a genesis and current definitive HEAD of a BIP, and the history it's gone through. The whole history can be reconstructed from any one transaction. This is quite similar to Peter Todd's single use seals, and the work done on RGB Regarding commit trees going offline, they can be mirrored, hosted on popular sites (github/gitlab) and it's natural that popular repos in git are cloned This also provides a little skin in the game and prevents some sybil attacks, because you need to spend money on a TX In this way whole BIPs can have a life cycle outside of any official body, but also be assigned BIP numbers in the bitcoin repo This mainly an informational idea, however, I have been working on some code and early prototypes to do this, so feel free to message me off-list if there's additional interest > > > On Mon, Apr 26, 2021 at 7:44 PM David A. Harding via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > On Sun, Apr 25, 2021 at 05:31:50PM -0400, Matt Corallo via bitcoin-dev > wrote: > > > In general, I think its time we all agree the BIP process has simply > failed > > > and move on. Luckily its not really all that critical and proposed > protocol > > > documents can be placed nearly anywhere with the same effect. > > > > I recommend: > > > > 1. We add additional BIP editors, starting with Kalle Alm (if there are > > no continuing significant objections). > > > > 2. We seek Luke Dashjr's resignation as BIPs editor. > > > > 3. We begin treating protocol documents outside the BIPs repository as > > first-class BIP documentation. > > > > The first recommendation permits continued maintenance of existing BIPs > > plus gives the additional maintainers an opportunity to rebuild the > > credibility of the repository. > > > > The second recommendation addresses the dissatisfaction of many BIP > > authors and potential authors with the current editor, which I think > > will discourage many of them from making additional significant > > contributions to the repository. It also seems to me to be a better use > > of Luke's talents and interests for him to focus on protocol research > > and review rather than procedurally checking whether a bunch of > > documents are well formed. > > > > The third recommendation provides an escape hatch for anyone, such as > > Matt, who currently thinks the process has failed, or for anyone who > > comes to that same conclusion in the future under a different editing > > team. My specific recommendations there are: > > > > a. Anyone writing protocol documentation in the spirit of the BIP > > process can post their idea to this mailing list like we've always > > done and, when they've finished collecting initial feedback, they can > > assign themselves a unique decentralized identifier starting with > > "bip-". They may also define a shorter alias that they encourage > > people to use in cases where the correct document can be inferred > > from context. E.g., > > > > bip-wuille-taproot (bip-taproot) > > bip-towns-versionbits-min-activation-height (bip-vbmah) > > bip-todd-harding-opt-in-replace-by-fee (bip-opt-in-rbf) > > > > b. The author then publishes the document to any place they'd like, > although > > they are strongly encouraged to make any document source available > > under an open license to ensure others can create their own > > modifications. > > > > c. Implementations of BIPs, whether original repository BIPs or > > decentralized BIPs, link to the BIPs they implement to ensure > > researchers and developers can find the relevant protocol > > documentation. E.g., > > > https://github.com/bitcoin/bitcoin/blob/fe5e495c31de47b0ec732b943db11fe345d874af/doc/bips.md > > > > (It may also be advisable for implementations to mirror copies of > > the BIPs they implement so later modifications to the document > > don't confuse anyone. For this reason, extremely liberal > > licensing of BIP documents is encouraged.) > > > > d. To help maintain quality and consistency between documentation, the > > BIP editors provide a BIP document template, guidelines similar to > > the existing BIP2, and an easy-to-run format linter. > > > > I think this decentralized BIPs alternative also helps address some > > longstanding problems with the BIPs system: that many casual Bitcoin > > users and developers think of documents in the BIPs repo as > > authoritative and that there are some development teams (such as for LN) > > that have already abandoned the BIPs process because, in part, they want > > complete control over their own documentation. > > > > The recommendations above were developed based on conversations I had > > with a few stakeholders in the BIPs process, but I did not attempt a > > comprehensive survey and I certainly don't claim to speak for anyone > > else. I hope the recommendations are satisfactory and I look forward to > > your feedback. > > > > Thanks, > > > > -Dave > > _______________________________________________ > > 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 > [-- Attachment #2: Type: text/html, Size: 8214 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Reminder on the Purpose of BIPs 2021-04-26 19:43 ` David A. Harding 2021-04-26 20:04 ` Greg Maxwell @ 2021-04-27 9:04 ` W. J. van der Laan 2021-04-27 11:49 ` Erik Aronesty 2021-04-27 11:33 ` John Newbery 2 siblings, 1 reply; 29+ messages in thread From: W. J. van der Laan @ 2021-04-27 9:04 UTC (permalink / raw) To: David A. Harding, Bitcoin Protocol Discussion On Monday, April 26th, 2021 at 9:43 PM, David A. Harding via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > On Sun, Apr 25, 2021 at 05:31:50PM -0400, Matt Corallo via bitcoin-dev wrote: > > > In general, I think its time we all agree the BIP process has simply failed > > > > and move on. Luckily its not really all that critical and proposed protocol > > > > documents can be placed nearly anywhere with the same effect. > I like the idea of decentralizing the BIPs process. It is a historical artifact that the bips repository is part of the same organization that bitcoin core is part of. But there shouldn't be the perception that standardization is driven by that, or that there is any kind of (non-trivial) gatekeeping. I understand where this perception is coming from, though. There being 111 PRs open at https://github.com/bitcoin/bips/pulls indicates that there is some kind of bottleneck. I hope adding more BIP editors can mitigate this somewhat. Though it also happens that the BIP author simply don't care about changes anymore and doesn't respond, in which case the PR lingers without any fault from the BIPs maintainer. So something is to be said of having the BIP repository mirror/aggregate author's own work trees, and changes needing to be proposed there instead of "upstream". -W ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Reminder on the Purpose of BIPs 2021-04-27 9:04 ` W. J. van der Laan @ 2021-04-27 11:49 ` Erik Aronesty 0 siblings, 0 replies; 29+ messages in thread From: Erik Aronesty @ 2021-04-27 11:49 UTC (permalink / raw) To: W. J. van der Laan, Bitcoin Protocol Discussion seems like this is solved by a workflow where a maintainer who requests changes clearly tags every entry as "changes needed" or "review requested",, and then the author can resolve/remove the tag after the changes are made. not sure PR's are the right tech here. On Tue, Apr 27, 2021 at 6:28 AM W. J. van der Laan via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > > On Monday, April 26th, 2021 at 9:43 PM, David A. Harding via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > > > On Sun, Apr 25, 2021 at 05:31:50PM -0400, Matt Corallo via bitcoin-dev wrote: > > > > > In general, I think its time we all agree the BIP process has simply failed > > > > > > and move on. Luckily its not really all that critical and proposed protocol > > > > > > documents can be placed nearly anywhere with the same effect. > > > > I like the idea of decentralizing the BIPs process. It is a historical artifact that the bips repository is part of the same organization that bitcoin core is part of. But there shouldn't be the perception that standardization is driven by that, or that there is any kind of (non-trivial) gatekeeping. > > I understand where this perception is coming from, though. There being 111 PRs open at https://github.com/bitcoin/bips/pulls indicates that there is some kind of bottleneck. I hope adding more BIP editors can mitigate this somewhat. > > Though it also happens that the BIP author simply don't care about changes anymore and doesn't respond, in which case the PR lingers without any fault from the BIPs maintainer. So something is to be said of having the BIP repository mirror/aggregate author's own work trees, and changes needing to be proposed there instead of "upstream". > > -W > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Reminder on the Purpose of BIPs 2021-04-26 19:43 ` David A. Harding 2021-04-26 20:04 ` Greg Maxwell 2021-04-27 9:04 ` W. J. van der Laan @ 2021-04-27 11:33 ` John Newbery 2 siblings, 0 replies; 29+ messages in thread From: John Newbery @ 2021-04-27 11:33 UTC (permalink / raw) To: Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 4248 bytes --] ACK. These seem like very reasonable next steps. On Mon, Apr 26, 2021 at 8:43 PM David A. Harding via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Sun, Apr 25, 2021 at 05:31:50PM -0400, Matt Corallo via bitcoin-dev > wrote: > > In general, I think its time we all agree the BIP process has simply > failed > > and move on. Luckily its not really all that critical and proposed > protocol > > documents can be placed nearly anywhere with the same effect. > > I recommend: > > 1. We add additional BIP editors, starting with Kalle Alm (if there are > no continuing significant objections). > > 2. We seek Luke Dashjr's resignation as BIPs editor. > > 3. We begin treating protocol documents outside the BIPs repository as > first-class BIP documentation. > > The first recommendation permits continued maintenance of existing BIPs > plus gives the additional maintainers an opportunity to rebuild the > credibility of the repository. > > The second recommendation addresses the dissatisfaction of many BIP > authors and potential authors with the current editor, which I think > will discourage many of them from making additional significant > contributions to the repository. It also seems to me to be a better use > of Luke's talents and interests for him to focus on protocol research > and review rather than procedurally checking whether a bunch of > documents are well formed. > > The third recommendation provides an escape hatch for anyone, such as > Matt, who currently thinks the process has failed, or for anyone who > comes to that same conclusion in the future under a different editing > team. My specific recommendations there are: > > a. Anyone writing protocol documentation in the spirit of the BIP > process can post their idea to this mailing list like we've always > done and, when they've finished collecting initial feedback, they can > assign themselves a unique decentralized identifier starting with > "bip-". They may also define a shorter alias that they encourage > people to use in cases where the correct document can be inferred > from context. E.g., > > bip-wuille-taproot (bip-taproot) > bip-towns-versionbits-min-activation-height (bip-vbmah) > bip-todd-harding-opt-in-replace-by-fee (bip-opt-in-rbf) > > b. The author then publishes the document to any place they'd like, > although > they are strongly encouraged to make any document source available > under an open license to ensure others can create their own > modifications. > > c. Implementations of BIPs, whether original repository BIPs or > decentralized BIPs, link to the BIPs they implement to ensure > researchers and developers can find the relevant protocol > documentation. E.g., > > https://github.com/bitcoin/bitcoin/blob/fe5e495c31de47b0ec732b943db11fe345d874af/doc/bips.md > > (It may also be advisable for implementations to mirror copies of > the BIPs they implement so later modifications to the document > don't confuse anyone. For this reason, extremely liberal > licensing of BIP documents is encouraged.) > > d. To help maintain quality and consistency between documentation, the > BIP editors provide a BIP document template, guidelines similar to > the existing BIP2, and an easy-to-run format linter. > > I think this decentralized BIPs alternative also helps address some > longstanding problems with the BIPs system: that many casual Bitcoin > users and developers think of documents in the BIPs repo as > authoritative and that there are some development teams (such as for LN) > that have already abandoned the BIPs process because, in part, they want > complete control over their own documentation. > > The recommendations above were developed based on conversations I had > with a few stakeholders in the BIPs process, but I did not attempt a > comprehensive survey and I certainly don't claim to speak for anyone > else. I hope the recommendations are satisfactory and I look forward to > your feedback. > > Thanks, > > -Dave > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 5274 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Reminder on the Purpose of BIPs 2021-04-25 21:00 ` Luke Dashjr 2021-04-25 21:14 ` Matt Corallo @ 2021-04-27 12:16 ` Jorge Timón 1 sibling, 0 replies; 29+ messages in thread From: Jorge Timón @ 2021-04-27 12:16 UTC (permalink / raw) To: Luke Dashjr, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1257 bytes --] > Despite the continual harassment, I have even made two efforts to try to > (fairly) make things faster, and have been obstructed both times by ST > advocates. It appears they intend to paint me as "deliberately refusing" > (to > use your words) in order to try to put Bitcoin and the BIP process under > their control, and abuse it in the same manner in which they abused > Bitcoin > Core's usual standards (by releasing ST without community consensus). > I haven'tpaying attention to the BIPs. But I just want to say I agree it is the case that speed trial didn't have consensus and had many good and logical arguments against it. Sadly discussions around taproot activation I've been lacking logic and having too many irrational arguments appealing to emotions. I'm really disapointed at the community right now. I'm sorry for luke and others defending lot=true (the whole point of bip8 anyway), but I feel ignored and frustrated when I try to participate in these irrational debates. I miss the rational debates here. But if we're gping to turn this list into an irrational place, with ad hominem fallacies and insults, I guess I can say my subjective personal opinion about other people too. I think it is you, Matt, who is playing dumb, not Luke. [-- Attachment #2: Type: text/html, Size: 2017 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm 2021-04-23 2:09 [bitcoin-dev] Proposed BIP editor: Kalle Alm Luke Dashjr ` (2 preceding siblings ...) 2021-04-23 15:34 ` Antoine Riard @ 2021-04-26 15:02 ` Sjors Provoost 2021-04-26 16:56 ` James O'Beirne 2021-04-26 18:13 ` W. J. van der Laan 4 siblings, 1 reply; 29+ messages in thread From: Sjors Provoost @ 2021-04-26 15:02 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1407 bytes --] ACK for adding Kalle. Recent drama aside, having a single editor is not ideal. There's currently 110 open pull requests to the BIPs repo. - Sjors > Op 23 apr. 2021, om 04:09 heeft Luke Dashjr via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven: > > Unless there are objections, I intend to add Kalle Alm as a BIP editor to > assist in merging PRs into the bips git repo. > > Since there is no explicit process to adding BIP editors, IMO it should be > fine to use BIP 2's Process BIP progression: > >> A process BIP may change status from Draft to Active when it achieves >> rough consensus on the mailing list. Such a proposal is said to have >> rough consensus if it has been open to discussion on the development >> mailing list for at least one month, and no person maintains any >> unaddressed substantiated objections to it. > > A Process BIP could be opened for each new editor, but IMO that is > unnecessary. If anyone feels there is a need for a new Process BIP, we can go > that route, but there is prior precedent for BIP editors appointing new BIP > editors, so I think this should be fine. > > Please speak up soon if you disagree. > > Luke > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev [-- Attachment #2: Message signed with OpenPGP --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm 2021-04-26 15:02 ` [bitcoin-dev] Proposed BIP editor: Kalle Alm Sjors Provoost @ 2021-04-26 16:56 ` James O'Beirne 0 siblings, 0 replies; 29+ messages in thread From: James O'Beirne @ 2021-04-26 16:56 UTC (permalink / raw) To: Sjors Provoost, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1749 bytes --] ACK for Kalle. On Mon, Apr 26, 2021, 09:55 Sjors Provoost via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > ACK for adding Kalle. > > Recent drama aside, having a single editor is not ideal. There's currently > 110 open pull requests to the BIPs repo. > > - Sjors > > > Op 23 apr. 2021, om 04:09 heeft Luke Dashjr via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> het volgende geschreven: > > > > Unless there are objections, I intend to add Kalle Alm as a BIP editor to > > assist in merging PRs into the bips git repo. > > > > Since there is no explicit process to adding BIP editors, IMO it should > be > > fine to use BIP 2's Process BIP progression: > > > >> A process BIP may change status from Draft to Active when it achieves > >> rough consensus on the mailing list. Such a proposal is said to have > >> rough consensus if it has been open to discussion on the development > >> mailing list for at least one month, and no person maintains any > >> unaddressed substantiated objections to it. > > > > A Process BIP could be opened for each new editor, but IMO that is > > unnecessary. If anyone feels there is a need for a new Process BIP, we > can go > > that route, but there is prior precedent for BIP editors appointing new > BIP > > editors, so I think this should be fine. > > > > Please speak up soon if you disagree. > > > > 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 > [-- Attachment #2: Type: text/html, Size: 2760 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm 2021-04-23 2:09 [bitcoin-dev] Proposed BIP editor: Kalle Alm Luke Dashjr ` (3 preceding siblings ...) 2021-04-26 15:02 ` [bitcoin-dev] Proposed BIP editor: Kalle Alm Sjors Provoost @ 2021-04-26 18:13 ` W. J. van der Laan 4 siblings, 0 replies; 29+ messages in thread From: W. J. van der Laan @ 2021-04-26 18:13 UTC (permalink / raw) To: Luke Dashjr, Bitcoin Protocol Discussion On Friday, April 23rd, 2021 at 4:09 AM, Luke Dashjr via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > Unless there are objections, I intend to add Kalle Alm as a BIP editor to > assist in merging PRs into the bips git repo. ACK on adding Kalle. I'm happy to finally see someone else interested in BIP maintainer role, for years no one really seemed to care about doing this mostly procedural/bureaucratic function, which is (part of) the reason Luke-Jr ended up as the only BIP maintainer for such a long time. And I disagree that a bot could do this just as well. Auto-merging would open it up to all kinds of DoS attacks, vandalism, and low-effort scams that a person can easily ward against. -W ^ permalink raw reply [flat|nested] 29+ messages in thread
* [bitcoin-dev] Proposed BIP editor: Kalle Alm @ 2021-04-24 4:42 Greg Maxwell 2021-04-24 14:45 ` Matt Corallo 2021-04-26 0:36 ` David A. Harding 0 siblings, 2 replies; 29+ messages in thread From: Greg Maxwell @ 2021-04-24 4:42 UTC (permalink / raw) To: Bitcoin Dev I am opposed to the addition of Kalle Alm at this time. Those who believe that adding him will resolve the situation with Luke-jr's inappropriate behavior re: PR1104 are mistaken. 27e59ffd51ee5a95d0e0faff70e045faca10b00015e90abc1c8de48b1dfff40c ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm 2021-04-24 4:42 Greg Maxwell @ 2021-04-24 14:45 ` Matt Corallo 2021-04-26 0:36 ` David A. Harding 1 sibling, 0 replies; 29+ messages in thread From: Matt Corallo @ 2021-04-24 14:45 UTC (permalink / raw) To: Greg Maxwell, Bitcoin Protocol Discussion What is preventing the BIP maintainership role from moving to a bot? It does seem like a bot should be able to do a fine job given the explicit criteria (though ignoring obvious spam is often nice, its by no means a requirement). Given recent events where humans have....acted like humans, it seems a move to a bot may be warranted. Matt On 4/24/21 00:42, Greg Maxwell via bitcoin-dev wrote: > I am opposed to the addition of Kalle Alm at this time. > > Those who believe that adding him will resolve the situation with > Luke-jr's inappropriate behavior re: PR1104 are mistaken. > > > > 27e59ffd51ee5a95d0e0faff70e045faca10b00015e90abc1c8de48b1dfff40c > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm 2021-04-24 4:42 Greg Maxwell 2021-04-24 14:45 ` Matt Corallo @ 2021-04-26 0:36 ` David A. Harding 2021-04-27 22:30 ` Jaime Caring 1 sibling, 1 reply; 29+ messages in thread From: David A. Harding @ 2021-04-26 0:36 UTC (permalink / raw) To: Greg Maxwell, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 306 bytes --] On Sat, Apr 24, 2021 at 04:42:12AM +0000, Greg Maxwell via bitcoin-dev wrote: > I am opposed to the addition of Kalle Alm at this time. Those who > believe [this] will resolve the situation [...] re: PR1104 are > mistaken. PR1104 has been merged. Do you continue to oppose the addition? Thanks, -Dave [-- Attachment #2: signature.asc --] [-- Type: application/pgp-signature, Size: 833 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm 2021-04-26 0:36 ` David A. Harding @ 2021-04-27 22:30 ` Jaime Caring 2021-04-28 9:52 ` Amir Taaki 0 siblings, 1 reply; 29+ messages in thread From: Jaime Caring @ 2021-04-27 22:30 UTC (permalink / raw) To: David A. Harding, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 1286 bytes --] Kalle should not be made an editor by an ad-hoc process. I reiterate Greg's NACK. I propose that we form a stewardship committee of frequent contributors, including you, Greg, and 21 others. The stewards appoint a small set of editors with permanent oversight by the stewards. A defined process prevents this controversy from arising in the future and makes proceedings clear. My proposal has been moderated off of this list, but may be viewed here: https://github.com/bitcoin/bips/pull/1113 I care not for the role of initial transitory editor. I would be pleased should any responsible community member shoulder this onus in my stead. Peace be upon you, JC On Mon, 26 Apr 2021 at 00:37, David A. Harding via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Sat, Apr 24, 2021 at 04:42:12AM +0000, Greg Maxwell via bitcoin-dev > wrote: > > I am opposed to the addition of Kalle Alm at this time. Those who > > believe [this] will resolve the situation [...] re: PR1104 are > > mistaken. > > PR1104 has been merged. Do you continue to oppose the addition? > > Thanks, > > -Dave > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 2065 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm 2021-04-27 22:30 ` Jaime Caring @ 2021-04-28 9:52 ` Amir Taaki 2021-04-30 15:39 ` Karl 2021-04-30 16:58 ` Jameson Lopp 0 siblings, 2 replies; 29+ messages in thread From: Amir Taaki @ 2021-04-28 9:52 UTC (permalink / raw) To: bitcoin-dev A committee to guide the committee? You guys truly have lost the plot. All the good minds and cryptographers have left Bitcoin. What remains is an empty echo chamber. Truth is these problems start with lack of vision and long-term roadmap, not with the processes themselves. And the Bitcoin Core monopoly created this situation; one coin, one client, one vision. And the inevitable infighting for ultimate power. Really if we want to go down this route, there should be a long period of self reflection about where the problems began rather than patching some process and moving on. I propose Bitcoin Core is dissolved as the official Bitcoin project. The community is free to elect their preferred version of Bitcoin. And most importantly, Bitcoin developers commit to a fully specced standard that all implementations move towards using. On 4/28/21 12:30 AM, Jaime Caring via bitcoin-dev wrote: > Kalle should not be made an editor by an ad-hoc process. I reiterate > Greg's NACK. > > I propose that we form a stewardship committee of frequent contributors, > including you, Greg, and 21 others. The stewards appoint a small set of > editors with permanent oversight by the stewards. A defined process > prevents this controversy from arising in the future and makes > proceedings clear. > > My proposal has been moderated off of this list, but may be viewed here: > https://github.com/bitcoin/bips/pull/1113 > <https://github.com/bitcoin/bips/pull/1113> > > I care not for the role of initial transitory editor. I would be pleased > should any responsible community member shoulder this onus in my stead. > > Peace be upon you, > > JC > > On Mon, 26 Apr 2021 at 00:37, David A. Harding via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > > On Sat, Apr 24, 2021 at 04:42:12AM +0000, Greg Maxwell via > bitcoin-dev wrote: > > I am opposed to the addition of Kalle Alm at this time. Those who > > believe [this] will resolve the situation [...] re: PR1104 are > > mistaken. > > PR1104 has been merged. Do you continue to oppose the addition? > > Thanks, > > -Dave > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > <mailto:bitcoin-dev@lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > <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 > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm 2021-04-28 9:52 ` Amir Taaki @ 2021-04-30 15:39 ` Karl 2021-04-30 16:58 ` Jameson Lopp 1 sibling, 0 replies; 29+ messages in thread From: Karl @ 2021-04-30 15:39 UTC (permalink / raw) To: Amir Taaki, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3483 bytes --] A good solution here is to make it clear to visitors that facilitation, mediation, and organisation help is badly needed in the core development team. People with such expertise can even be hired directly. A good facilitator opens communication paths between all parties, leaving everyone satisfied with decisions. Don't accept a compromise if you can look for something better. On Fri, Apr 30, 2021, 8:00 AM Amir Taaki via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > A committee to guide the committee? You guys truly have lost the plot. > > All the good minds and cryptographers have left Bitcoin. What remains is > an empty echo chamber. > > Truth is these problems start with lack of vision and long-term roadmap, > not with the processes themselves. > > And the Bitcoin Core monopoly created this situation; one coin, one > client, one vision. And the inevitable infighting for ultimate power. > > Really if we want to go down this route, there should be a long period > of self reflection about where the problems began rather than patching > some process and moving on. > > I propose Bitcoin Core is dissolved as the official Bitcoin project. The > community is free to elect their preferred version of Bitcoin. And most > importantly, Bitcoin developers commit to a fully specced standard that > all implementations move towards using. > > On 4/28/21 12:30 AM, Jaime Caring via bitcoin-dev wrote: > > Kalle should not be made an editor by an ad-hoc process. I reiterate > > Greg's NACK. > > > > I propose that we form a stewardship committee of frequent contributors, > > including you, Greg, and 21 others. The stewards appoint a small set of > > editors with permanent oversight by the stewards. A defined process > > prevents this controversy from arising in the future and makes > > proceedings clear. > > > > My proposal has been moderated off of this list, but may be viewed here: > > https://github.com/bitcoin/bips/pull/1113 > > <https://github.com/bitcoin/bips/pull/1113> > > > > I care not for the role of initial transitory editor. I would be pleased > > should any responsible community member shoulder this onus in my stead. > > > > Peace be upon you, > > > > JC > > > > On Mon, 26 Apr 2021 at 00:37, David A. Harding via bitcoin-dev > > <bitcoin-dev@lists.linuxfoundation.org > > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > > > > On Sat, Apr 24, 2021 at 04:42:12AM +0000, Greg Maxwell via > > bitcoin-dev wrote: > > > I am opposed to the addition of Kalle Alm at this time. Those who > > > believe [this] will resolve the situation [...] re: PR1104 are > > > mistaken. > > > > PR1104 has been merged. Do you continue to oppose the addition? > > > > Thanks, > > > > -Dave > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > <mailto:bitcoin-dev@lists.linuxfoundation.org> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > <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 > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 5561 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Proposed BIP editor: Kalle Alm 2021-04-28 9:52 ` Amir Taaki 2021-04-30 15:39 ` Karl @ 2021-04-30 16:58 ` Jameson Lopp 1 sibling, 0 replies; 29+ messages in thread From: Jameson Lopp @ 2021-04-30 16:58 UTC (permalink / raw) To: Amir Taaki, Bitcoin Protocol Discussion [-- Attachment #1: Type: text/plain, Size: 3350 bytes --] On Fri, Apr 30, 2021 at 7:59 AM Amir Taaki via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > A committee to guide the committee? You guys truly have lost the plot. > > All the good minds and cryptographers have left Bitcoin. What remains is > an empty echo chamber. > > Truth is these problems start with lack of vision and long-term roadmap, > not with the processes themselves. > > And the Bitcoin Core monopoly created this situation; one coin, one > client, one vision. And the inevitable infighting for ultimate power. > > Really if we want to go down this route, there should be a long period > of self reflection about where the problems began rather than patching > some process and moving on. > > I propose Bitcoin Core is dissolved as the official Bitcoin project. Nonsense, as it is not the official Bitcoin project. There is no such thing. The community is free to elect their preferred version of Bitcoin. Individuals have voted with their feet and are free to continue to do so. It's anarchy, I tell you! > And most importantly, Bitcoin developers commit to a fully specced > standard that > all implementations move towards using. > Who decides the spec? Perhaps... a committee of some sort? > > On 4/28/21 12:30 AM, Jaime Caring via bitcoin-dev wrote: > > Kalle should not be made an editor by an ad-hoc process. I reiterate > > Greg's NACK. > > > > I propose that we form a stewardship committee of frequent contributors, > > including you, Greg, and 21 others. The stewards appoint a small set of > > editors with permanent oversight by the stewards. A defined process > > prevents this controversy from arising in the future and makes > > proceedings clear. > > > > My proposal has been moderated off of this list, but may be viewed here: > > https://github.com/bitcoin/bips/pull/1113 > > <https://github.com/bitcoin/bips/pull/1113> > > > > I care not for the role of initial transitory editor. I would be pleased > > should any responsible community member shoulder this onus in my stead. > > > > Peace be upon you, > > > > JC > > > > On Mon, 26 Apr 2021 at 00:37, David A. Harding via bitcoin-dev > > <bitcoin-dev@lists.linuxfoundation.org > > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > > > > On Sat, Apr 24, 2021 at 04:42:12AM +0000, Greg Maxwell via > > bitcoin-dev wrote: > > > I am opposed to the addition of Kalle Alm at this time. Those who > > > believe [this] will resolve the situation [...] re: PR1104 are > > > mistaken. > > > > PR1104 has been merged. Do you continue to oppose the addition? > > > > Thanks, > > > > -Dave > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > <mailto:bitcoin-dev@lists.linuxfoundation.org> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > <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 > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 5699 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2021-04-30 16:58 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-04-23 2:09 [bitcoin-dev] Proposed BIP editor: Kalle Alm Luke Dashjr 2021-04-23 3:36 ` Jeremy 2021-04-23 7:49 ` John Newbery 2021-04-23 7:50 ` Pindar Wong 2021-04-23 9:11 ` Eric Martindale 2021-04-23 15:34 ` Antoine Riard 2021-04-24 10:16 ` nopara73 2021-04-25 20:29 ` [bitcoin-dev] Reminder on the Purpose of BIPs Matt Corallo 2021-04-25 21:00 ` Luke Dashjr 2021-04-25 21:14 ` Matt Corallo 2021-04-25 21:22 ` Luke Dashjr 2021-04-25 21:31 ` Matt Corallo 2021-04-26 19:43 ` David A. Harding 2021-04-26 20:04 ` Greg Maxwell 2021-04-27 19:43 ` Melvin Carvalho 2021-04-27 9:04 ` W. J. van der Laan 2021-04-27 11:49 ` Erik Aronesty 2021-04-27 11:33 ` John Newbery 2021-04-27 12:16 ` Jorge Timón 2021-04-26 15:02 ` [bitcoin-dev] Proposed BIP editor: Kalle Alm Sjors Provoost 2021-04-26 16:56 ` James O'Beirne 2021-04-26 18:13 ` W. J. van der Laan 2021-04-24 4:42 Greg Maxwell 2021-04-24 14:45 ` Matt Corallo 2021-04-26 0:36 ` David A. Harding 2021-04-27 22:30 ` Jaime Caring 2021-04-28 9:52 ` Amir Taaki 2021-04-30 15:39 ` Karl 2021-04-30 16:58 ` Jameson Lopp
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox