I like it, even if gcs want to be more agile at first
1. can help testing/debugging against a broadly used store 2. stops us accidentally breaking things (who would do that 🙂) 3. makes it easier to do changes across the modules Because Chris is involved, I'm not worried about this being a big code dump with us expected to maintain it ourselves -this was my initial fear. steve On Tue, 22 Apr 2025 at 05:26, Chris Nauroth <cnaur...@apache.org> wrote: > Hi Wei-Chiu, > > This is an important trade-off to consider. There is some discussion in the > JIRA issue comments relevant to this topic. To summarize, we prefer closer > integration with the ASF community as we continue to evolve this > FileSystem. It's true that releases will operate at a different cadence, > but vendors are equipped to release on their own schedule. We think this is > the right choice overall. > > Chris Nauroth > > > On Mon, Apr 21, 2025 at 4:42 PM Wei-Chiu Chuang <weic...@apache.org> > wrote: > > > Chris, > > I'm curious is having a GCS fs implementation in the main Hadoop repo the > > right choice? As mentioned by Steve, Hadoop release cadence tends to be > > slow. There's a lot of legacy code so release work is usually a multi > month > > effort. Have you considered having it in a separate repo? > > > > On Mon, Apr 21, 2025 at 4:25 PM Chris Nauroth <cnaur...@apache.org> > wrote: > > > >> Hello everyone, > >> > >> I have created a new HADOOP-19343 feature branch for ongoing development > >> of > >> a GCS FileSystem implementation. > >> > >> https://issues.apache.org/jira/browse/HADOOP-19343 > >> > >> https://github.com/apache/hadoop/tree/HADOOP-19343 > >> > >> This feature is targeting Apache Hadoop 3.5.0. Ongoing development of > the > >> GCS FileSystem can target this branch. I'll also perform periodic > rebases > >> to the tip of trunk. I expect the risk of merge conflicts will be low, > >> because this is introducing a new, isolated sub-module. > >> > >> Thank you. > >> > >> Chris Nauroth > >> > > >
