For emergency releases, we could strive to have at least 6 +1 votes (double of normal), and go the extra mile of testing more than smoketester. That should weigh up for a shorter 24h cycle.
Jan > 16. des. 2021 kl. 15:30 skrev Gus Heck <gus.h...@gmail.com>: > > I think it's fine to have a 24h vote period for "Security" releases, Such > releases should be a regular x.y.z version number, no need for a 4th digit. > 3rd digit is already bugfixes only. I think a CVE on ous or a dependency > that is RCE or information disclosure should be the trigger, and only a > bugfix release can get expedited of course. Otherwise normal release. I don't > think we should shorten it too far, witness how new information became > available regarding further vulnerability.mitigation in this case. Not great > to issue releases too quickly as it can lead to releasing something in error > with a false sense of security. So if we can shave a couple days of fine, but > let's also give some time for proper consideration too. > > On Thu, Dec 16, 2021 at 4:01 AM Uwe Schindler <u...@thetaphi.de > <mailto:u...@thetaphi.de>> wrote: > Hi, > > I agree that we should better take the option to have fast releases. We > should maybe make a rule how many LOC is allowed to shorten the period. > > About the versioning: I would not change the versioning and just add 1 to the > minor release. Plain simple. > > Longer story: If you still want a fourth digit, the versioning schema can > handle this, but the lowest bits (in binary, digits in text form) have some > special meaning (ALPHA, BETA,...) in Lucene's Version.java. So my proposal > for that route would be: As Solr needs its own Version.java anyways > (SolrVersion.java), you can implement it there. But be aware, there's also > Gradle magic and release automation involved. > > For Lucene there's no need for those type of releases, as we are a library > only. > > Uwe > > ----- > Uwe Schindler > Achterdiek 19, D-28357 Bremen > https://www.thetaphi.de <https://www.thetaphi.de/> > eMail: u...@thetaphi.de <mailto:u...@thetaphi.de> > > > -----Original Message----- > > From: Shawn Heisey <apa...@elyograg.org <mailto:apa...@elyograg.org>> > > Sent: Thursday, December 16, 2021 2:43 AM > > To: dev@solr.apache.org <mailto:dev@solr.apache.org> > > Subject: Should we have an "emergency release" procedure? > > > > 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 > > <mailto:dev-unsubscr...@solr.apache.org> > > For additional commands, e-mail: dev-h...@solr.apache.org > > <mailto:dev-h...@solr.apache.org> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > <mailto:dev-unsubscr...@solr.apache.org> > For additional commands, e-mail: dev-h...@solr.apache.org > <mailto:dev-h...@solr.apache.org> > > > > -- > http://www.needhamsoftware.com <http://www.needhamsoftware.com/> (work) > http://www.the111shift.com <http://www.the111shift.com/> (play)
