Thanks for the response, Justin. It's a topic for another thread, but I think the ASF and the Incubator is facing an existential problem. Times have changed. We can't carry on doing what we're doing. Good projects that would have been in the ASF five or ten years ago are choosing to go elsewhere. We are driving at top speed towards a wall. I don't have the energy to grab the steering wheel but let's not pretend that everything is fine.
On 2024/12/03 05:54:20 Justin Mclean wrote: > HI, > > > 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]. > > We don't actively seek out projects, projects that want to join the ASF ask > to do so, because they think they are a good fit, that is by design. > > > 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?! > > The 72 hours is a guideline and can be shorter if a (P)PMC has good reasons > for doing so. Typically, that is used for security fixes, but I don’t see why > it could not be used for minor changes - if the (P)PMC is sure that’s all > that went into the new release candidate. > > > 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. > > There is nothing sophisticated about the scripts I use, it’s Apache Rat and > find plus grep plus human observation. This has been covered in several > Incubator talks if you want to look into it. Looking at the output of Apache > Rat would have shown these issues. However if we wanted a 100% clean Apache > Rat output for all projects that would be a huge amount of work, and often > issues are hidden by having Rat exclusions too wide. > > > 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. > > From experience, it’s not possible to automate all of this. You might be > about to do 80%-90% of it, but that may be project dependent. There are many > issues that automation will not catch, and/or it will also generate a lot of > false positives. e.g. A mention of the GPL license somewhere might mean a) > nothing or b) there’s an optional dependency that’s under the GPL license > (which is fine) or c) there’s a dependency that is under a GPL license (not > fine) or d) GPL-licensed code in the source release (not fine). Or, if a > license of an image is not specified, how would automation know it’s OK to > include it or not? It could be misisng a license from LICENSE, or something > the project is using without permission, or it might not be an issue at all. > > > 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? > > Top-level projects should be doing these checks; releases do need to comply > with ASF policy. Apache license projects outside of the ASF do not need to > follow ASF policy on releases. We do this as a release needs to be an act of > the foundation to provide legal protection to the PMC members who make the > release. Think of it as travel insurance - you hopefully never have to use > it, but when the situation comes up, you be glad you have it. And yes, ASF is > subpoenaed or needs to respond to lawyers several times a year. > > 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
