Hi Julian, I share many of the same sentiments, especially regarding the last part of your email. I won’t elaborate further, as doing so might unintentionally target individuals :-)
On the two-way vote mechanism, I’m not sure it’s something that will change. There are pros and cons of being part of the Incubator. One benefit is that your RC gets reviewed by the IPMC in addition to the PPMC, ensuring a broader evaluation. However, when issues arise, you often have to restart from scratch rather than addressing the specific problem and continuing from where you left off. It’s perhaps one of the lessons the Incubator instills: the cost of mistakes is high, which emphasizes the importance of thorough pre-checks before reaching the RC stage. Does the project sometimes get penalized even when the problem isn’t that significant? That’s certainly up for debate. If there’s a way to streamline this process without compromising quality, I’m all in. That said, I don’t think ASF’s processes are as flawed as they might sometimes appear. For instance, the 72-hour waiting period might feel frustrating when you’re on the receiving end, but it ensures everyone—irrespective of time zones, public holidays, or unforeseen circumstances like illness—gets a fair opportunity to participate. While occasionally irritating, it seems reasonable when viewed from a broader perspective. I completely agree with point [1]. Scripts or checks should either be templated or checked in so that all projects can leverage them consistently before an RC. Regarding point [2], I sometimes feel a -1 on an incubating project can come across as overly harsh. It makes me wonder: what’s the ultimate goal? If it’s a “nice to have,” feedback might be more constructive, allowing the project to address it in subsequent releases. This approach aligns more closely with what happens for way larger issues on most TLPs. That said, Nobody can point fingers too much in such cases—the obvious defense is that a -1 on an RC isn’t a veto. You could always choose to proceed, though you might risk creating an “enemy” for later stages. Who would do that in general in an ideal world. Of course, these are just my personal thoughts, shared with the usual disclaimer: I’m not speaking about any specific individual or situation, and my views don’t necessarily represent the “right” perspective & might be totally wrong in anyone's eyes -Ayush On Tue, 3 Dec 2024 at 01:41, Julian Hyde <jhyde.apa...@gmail.com> wrote: > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
