My main quibble was the extra 6 working days, and effort, to make a small change to the release candidate; that 6 days could be 3 days.
I meant to start a thread “What are we teaching projects?” but I’m busy, so I’ll do it here. Recent posts [1] have accused Apache of being rigid, dogmatic. These criticisms are, in my opinion, totally valid. And they matter, because we are losing projects to other foundations. We are no longer the only bar in town [2]. What are we teaching projects? We are teaching them that we are dogmatic, for no good reason. This was a teachable moment. We could have said “Hey, this is a minor change, let’s expedite the vote”. A good top-level project would have done that. Should do that, out of respect for our contributors’ time. We — the incubator PMC — did not do that. What the HELL are we thinking?! Last thought. Several IPMC members have sophisticated scripts to check license headers, NOTICE files, keys. Those sophisticated scripts inevitably catch things. And when they catch something the buzzer goes off and it’s another 7 days. Two questions. 1. Is it possible to automate this — create a .yaml file in each project, and some standard scripts that can be called by any project, regardless of its language or build system — to generate LICENSE, NOTICE etc. 2. If we don’t/can't automate this, what is the harm? I know that top-level projects don’t do these checks. I know that Apache-licensed projects in other foundations don’t do these checks. Where are the law-suits? If the harm is not that great, why do we bother? Julian [1] https://xuanwo.io/2024/09-what-did-asf-do-wrong/ [2] https://www.morling.dev/blog/thoughts-on-moving-debezium-to-commonhaus-foundation/ > On Dec 2, 2024, at 1:48 AM, Bertil Chapuis <bchap...@gmail.com> wrote: > > It’s a good idea, I will also ask for help in the geospatial mailing list. > > I wouldn’t say that the mentors are completely inactive; we’ve had a couple > of fruitful exchanges on various aspects of the project (e.g., we managed to > integrate Apache SIS for raster processing during the summer). However, when > it comes to voting, we really struggle to collect the necessary votes in a > timely fashion. > > I believe that when entering the incubator, we underestimated the amount of > work required to comply with the Apache guidelines. The work to get the code > in compliance was almost ready, but we didn’t expect that many test files and > datasets would have to be replaced with synthetic data due to licensing > concerns. Addressing this was very time-consuming, and I think we lost a lot > of our momentum. Even if this work was far from being fun, I’m happy of what > we did, as we managed to fix licensing issues in important upstream projects > such as proj4j. I really hope we can now address these final issues and > accelerate the release process. Having enough active voters will indeed be > critical in this regard. > > Best regards, > > Bertil > > >> On 1 Dec 2024, at 05:43, Justin Mclean <jus...@classsoftware.com> wrote: >> >> Hi, >> >> If you don't have active mentors, perhaps you should replace the inactive >> ones? Asking here on the list might attract some more mentors. >> >> Kind Regards, >> Justin >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
