| 1 |
On Wed, Aug 21, 2013 at 10:56 AM, Tom Wijsman <TomWij@g.o> wrote: |
| 2 |
> |
| 3 |
> That doesn't make it a special case here, imo; especially not, since |
| 4 |
> we are designing and implementing ebuilds that _build_ the kernel. |
| 5 |
> Whether it provides the sources, or build it; what does that matter? |
| 6 |
|
| 7 |
Yes and no. I don't think the kernel needs a separate |
| 8 |
QA/stabilization policy per-se. |
| 9 |
|
| 10 |
However, it probably isn't a good barometer of the state of the tree. |
| 11 |
On the one hand, it is probably one of the most popular and |
| 12 |
looked-after packages in the tree. On the other hand it has releases |
| 13 |
with both high frequency and impact. There really isn't a single FOSS |
| 14 |
project like the Linux kernel anywhere. |
| 15 |
|
| 16 |
So this isn't about making up different rules for the kernel. The |
| 17 |
issue is more that I wouldn't use the kernel as my main example of the |
| 18 |
state of the tree. I'm not sure it even makes sense to have single |
| 19 |
examples so much as categories. |
| 20 |
|
| 21 |
It might be interesting to see how up-to-date stable packages are when |
| 22 |
looking at system vs non-system (glibc vs mplayer), package popularity |
| 23 |
(firefox vs baobab), desktop vs server (vlc vs mysql), and so on. I |
| 24 |
suspect though that it has as much to do with maintainer philosophy as |
| 25 |
the package itself - some maintainers pay more attention to stable. |
| 26 |
|
| 27 |
Rich |
Archives