Gregory Maxwell [ARCHIVE] on Nostr: 📅 Original date posted:2011-09-19 🗒️ Summary of this message: The idea of ...
📅 Original date posted:2011-09-19
🗒️ Summary of this message: The idea of maintaining two release lines for Bitcoin is not practical as testing and bug-fixing is already a bottleneck. A bug-fixes only branch may not help much either. Instead, more effort should be put into mainlining changes and restructuring code to better accommodate patches.
📝 Original message:On Mon, Sep 19, 2011 at 8:49 AM, Gavin Andresen <gavinandresen at gmail.com> wrote:
> My initial reaction is no. Testing and bug-fixing is the bottleneck
> for making core bitcoin better, and maintaining two release lines
> won't make that better.
>
> I also think that until we get to a "1.0" that we can all agree is
> ready for everybody AND their grandma to use, using the word "stable"
> would be dishonest.
I think the primary concern that they are attempting to address there
is providing a stable base bitcoind for miners, banks, and webservices
to apply their patches on top of.
Right now, if they want to keep up with development they are stuck
forward porting against often disruptive changes as just about
everyone running something of importance needs some patch or another
so you have people who are clearly in the know like Luke and tcatm
trailing development on some of their systems by many months.
This isn't healthy for the network.
I'm not convinced a bugfixes only branch will help much: Even bug fixes
will disrupt local fixes, and testing and supervising your upgrade usually
takes more effort than the forward porting.
I'd rather see more effort put into mainlining the changes people are
carrying sooner and restructuring code to better accommodate patches
which aren't suitable for mainline. This will also encourage people
to make the fixes they're running publicly available, rather than
just keeping them private for competitive advantage.
Published at
2023-06-07 02:27:16Event JSON
{
"id": "0b28634e3df28a8650fdc259e083925a9ff9918a9ca281a3a5d49443b34fe60f",
"pubkey": "4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73",
"created_at": 1686104836,
"kind": 1,
"tags": [
[
"e",
"0ae916b64652df113a104fccbfbc28fa76834bc49558c45ca1a489a5c0f8c04c",
"",
"root"
],
[
"e",
"77430dec4f846b5c11a9575da1af20032f7d7b193ae67db1ab3eb97b10a00296",
"",
"reply"
],
[
"p",
"857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4"
]
],
"content": "📅 Original date posted:2011-09-19\n🗒️ Summary of this message: The idea of maintaining two release lines for Bitcoin is not practical as testing and bug-fixing is already a bottleneck. A bug-fixes only branch may not help much either. Instead, more effort should be put into mainlining changes and restructuring code to better accommodate patches.\n📝 Original message:On Mon, Sep 19, 2011 at 8:49 AM, Gavin Andresen \u003cgavinandresen at gmail.com\u003e wrote:\n\u003e My initial reaction is no. Testing and bug-fixing is the bottleneck\n\u003e for making core bitcoin better, and maintaining two release lines\n\u003e won't make that better.\n\u003e\n\u003e I also think that until we get to a \"1.0\" that we can all agree is\n\u003e ready for everybody AND their grandma to use, using the word \"stable\"\n\u003e would be dishonest.\n\nI think the primary concern that they are attempting to address there\nis providing a stable base bitcoind for miners, banks, and webservices\nto apply their patches on top of.\n\nRight now, if they want to keep up with development they are stuck\nforward porting against often disruptive changes as just about\neveryone running something of importance needs some patch or another\nso you have people who are clearly in the know like Luke and tcatm\ntrailing development on some of their systems by many months.\n\nThis isn't healthy for the network.\n\nI'm not convinced a bugfixes only branch will help much: Even bug fixes\nwill disrupt local fixes, and testing and supervising your upgrade usually\ntakes more effort than the forward porting.\n\nI'd rather see more effort put into mainlining the changes people are\ncarrying sooner and restructuring code to better accommodate patches\nwhich aren't suitable for mainline. This will also encourage people\nto make the fixes they're running publicly available, rather than\njust keeping them private for competitive advantage.",
"sig": "cc54010369e1b5fe058ad8469580cdef3016c08fc75fc08e6ed84c317e67069a7b492d81f2f8a02c8f213900255a36eac338d96d1b97d1eee1affe29f5f3f40d"
}