10 seconds, plus the time waiting around for replies, and the time
spent reading the replies.
> > If a release is badly broken, another one is usually quick to follow
> > it, anyway.
> There's usually a lag of 30min to an hour between the last changeset and
> the the one that changes the version tag anyway. I would
> hope/assume(dangerous) this is when it's beeing built and tested. One
> more script to that mix that runs a subset of ltp might add an
> additional 5 min. Alternatively, a note of intent to lkml might add a
> few seconds to that delay.
> If I counted timezones etc. right, here's a quick picture of the number
> of minutes between the last changeset and the changeset that tagged it
> with the version number:
> 2.5.60 52 min.
> 2.5.59 42 min.
> 2.5.58 31 min.
> 2.5.57 16 min.
> *** 2.5.58 was release something like 12 hours later
> Is it less work to do a few minutes of extra testing, or go through
> another release in the same day?
Probably less work for Linus to go through another release, plus it
means that people who are not testing -bk snapshots for whatever
reason are more involved in the development process.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/