The log4j debacle has sure been interesting.
I have heard from at least one user that the project should have reacted
faster to this problem, in order to get a fixed version available
quickly. Our release process takes several days even if everything goes
well, which can be perceived by users as indifference in the face of a
security concern.
What I am thinking is that we might want to have an emergency release
process that consists of checking out the tag for the most current
release available, making as small a change as possible to address a
vulnerability, and then releasing it quickly, skipping as much of the
usual delays as possible, like the 72-hour Vote. Maybe reduce that to 4
hours or 8 hours. The first number that popped into my fron was 24
hours, but that's still a pretty long delay for a major problem like the
log4j vulnerability.
If the versioning code in Solr can deal with it, what I would think of
as the version number for a special release in this case would be
8.10.0.1 -- to indicate that it is almost completely identical to
8.10.0. If the versioning code can't deal with it, I propose that we
alter it so that it can.
Thoughts from my fellow committers? Is this idea completely bonkers?
Would there be changes to the idea that might make it better?
Thanks,
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
For additional commands, e-mail: dev-h...@solr.apache.org
