> I can land fix/improvements to my internal fork faster than having it > accepted/landed in the open-source, so I will land it locally and then > upstream it
It’s likely that this is true for everyone, especially if we’re talking about larger changes. Unfortunately this particular path also means there’s a risk of divergence: a fix you land in open-source might be slightly different from your original version, maybe due to review feedback, or due to concurrent developments. On Tue, Oct 21, 2025, at 3:20 AM, Jaydeep Chovatia wrote: > I think there is one more more version for people to run their own fork, > which is "I can land fix/improvements to my internal fork faster than having > it accepted/landed in the open-source, so I will land it locally and then > upstream it." Over the period of time, the maintenar will lose track of the > upstream tickets because internally it got already landed/working. > Eventually, the fork will end up with many more custom patches and then > people are forced to continue with the private fork forever. > > Jaydeep > > On Mon, Oct 20, 2025 at 12:37 PM Jeff Jirsa <[email protected]> wrote: >> There’s a variant of (1) I’ve seen at multiple past employers, which is “we >> have a problem right now and we’re not sure what the long term fix is, but >> we’re addressing it internally and may do something different long term in >> the public repo.” It’s not actually about bespoke integration, it’s more >> about nascent ideas that get tested and deployed and iterated on. For >> example, early TWCS started out as a DTCS patch that used an alternative >> timestamp in the sstable metadata with the old DTCS tiering logic before the >> approach changed into avoiding the tiering and using the existing timestamp. >> >> >> >> >> >>> On Oct 20, 2025, at 12:24 PM, Josh McKenzie <[email protected]> wrote: >>> >>> We had a long conversation about the potential of piloting a supported >>> backport release branch here: >>> https://lists.apache.org/thread/xbxt21rttsqvhmh8ds9vs2cr7fx27w3k >>> >>> When I tried to summarize the thread and identify next steps, one >>> observation stood out: I think we did a good job establishing the shape of >>> the challenge we'd like to address (people want to work on OSS, not >>> maintain private forks), but I don't think we got to the root of why this >>> challenge exists. If we take action now we run the risk of having the wrong >>> solution to the right problem. >>> >>> So: why are people running forks? Some reasons I've seen brought up: >>> 1. You need bespoke code to integrate with internal infrastructure >>> 2. You've written a new feature targeting your internal version, >>> upstreamed the code, and have to wait for the feature to be in a GA release >>> 3. Someone else has contributed a feature to trunk that's attractive and >>> it's less work or more palatable to back-port it to your private fork and >>> maintain the diff than to qualify a custom release off trunk >>> 4. You have stability concerns with GA releases or running a release based >>> off trunk >>> The backport branch we discussed in the previous thread would primarily >>> address #4 (stability concerns) and secondarily #2 and #3 (feature >>> availability). All four motivations could be addressed in other >>> ways—ideally by reducing the pressure to fork in the first place, rather >>> than accommodating forks as inevitable. >>> >>> If you're running a fork and open to sharing your experience, do these >>> reasons match yours, or is something else at play? The more detail we can >>> gather, the better we can target improvements where they'll actually help. >>> >>> I know these conversations take time and can be hard; I appreciate everyone >>> taking the time and energy to help us collectively improve. >>> >>> ~Josh >>>
