: Dailies (nice) would need some distinguishing feature in EXTRAVERSION,
: please. "-20Apr02" would suit.
= Well, hopefully it will be "-pre020420" so that increasing kernel
= versions can be sorted... Also, skip releasing snapshots on days
= when no new deltas have been applied...
In the good old days we had frequent releases.
For example, the 1.3 series went from 1.3.1 to 1.3.100
in eleven months, an average of one patch every three days.
These days we have pre-patches (15 since Feb 1), and patches
(5 since Feb 1) showing an average of one patch every four days.
So, maybe there is a small slow-down, or maybe the testintervals
were chosen unfortunately.
If it is possible to increase the fequency with which patches are
released, then that is very good. There is no need to invent new
numbering schemes. Indeed, I would be in favour of collapsing
the present scheme (for 2.5), and call everything patch-2.5.N,
no reason to panic when N reaches into the hundreds.
The reason I object to "-20Apr02" or "-pre020420" is that it
makes it difficult to see whether there are missing patches
in a given archive. Sequential numbering is better.
(Moreover, there might be two patches on one day, there is a
handful of examples already.)
Concerning the collapsing of patches and prepatches:
For a stable series like 2.4 one needs pre-patches to have a
test-period. For an unstable series like 2.5 pre-patches only
cause a small amount of hassle (the naming is different, they
live in different directories, the patches are not incremental,
incremental patches again have a different naming scheme)
and as far as I can see the presumed advantage, namely that the
result of a patch is more stable than that of a pre-patch, is
absent so far in the 2.5 series. Maybe prepatches should first
be reinvented again shortly before the release of 2.6.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/