Re: RFD: Kernel release numbering

Kyle Moffett
2005-03-04T00:27:23Z

On Mar 03, 2005, at 14:35, Sean wrote:
> Wait a second though, this tree will be branched from the development
> mainline. So it will contain many patches that entered with less
> testing. What will be the policy for dealing with regressions
> relative
> to the previous $sucker release caused by huge patches that entered via
> the development tree? Is reverting them prohibited because of the
> patch
> size?

I can see two conflicting desires in this discussion, the desire to
continue
development to avoid patch backlog, and the desire to slow down and
stabilize
to provide a sane release-candidate and release scheme. Could the two
desires somehow be both resolved simultaneously?

Perhaps instead of forking when 2.6.A is released, Linux could fork
earlier,
after the 2.6.A-bk series. After the fork, the main tree would become
the
new 2.6.A+1-bk, and the forked tree would become 2.6.A+1-pre. Then the
final
stabilization and patches could continue while normal kernel development
moves on. The latest kernel could take advantage of patches to the
release
kernel, but would be able to maintain the steady patch stream. The
release
kernel could be managed by the previously mentioned "sucker", and could
go
through a more-stabilizing and better tested Release Candidate series,
and
then maintain post-release bugfixes. When 2.6.A+1-pre is released, then
all upstream development on the forked 2.6.A-post tree would cease.

Cheers,
Kyle Moffett

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r
!y?(-)
------END GEEK CODE BLOCK------