[Ksummit-2012-discuss] [ATTEND] <ding> "Bring out your dead" <ding>...

Steven Rostedt rostedt at goodmis.org
Fri Jun 29 02:28:56 UTC 2012


On Mon, 2012-06-25 at 20:03 -0400, Paul Gortmaker wrote:

>  1) Once you step outside of the mainstream arch and/or into the hobby
>     realm, you are pretty much guaranteed to not be using a distro, but
>     rather a custom build, custom .config and even custom kernel.  But
>     of course you have the source too.  How else could you have
>     created your custom build?  So, you are free to revert/patch back in
>     whatever driver(s) or support you want, and share it (made easy with
>     github) with whoever you want.  If there is interest in it, it will
>     survive.  Even if you are the one and only person interested, you've
>     still made it survive.  The actual location of the source code really
>     is not of unconditional importance.

Although, if there's one person willing to keep it alive, why not let it
stay in the kernel. But place more burden on that one person to make
sure updates work for it.

Remember, the birth of Linux was for that one guy with the hobby. Lets
not stomp on him now that Linux is in the big leagues.

> 
>  2) With point #1 in mind, there simply isn't the absolute finality
>     associated with mainline removal in linux as there would be in the
>     binary world, say if Windows8 said they were dropping Adaptec AHA1542
>     SCSI support (assuming it isn't long gone already.)
> 
>  3) Things that are being considered for removal are least likely to
>     see an advantage by being on the bleeding edge.  Take the MCA case.
>     If you'll allow me the conclusion that MCA on 3.5 wouldn't have
>     been any fundamentally better than MCA on 3.4 -- then you can
>     get on the (semi announced) 3.4 LTSI train, and have a supported
>     kernel base for your MCA that will take you well into the year 2014!

I was also thinking that perhaps this could be the rational for upping
the major number. I know Linus said that the major number is just that,
a number, but instead of a number meaning what features and archs are
being added, have it mean what features and archs are being removed :)

I'm sure Linus wont go for that either. But if we do up the major number
every 10 years, we can make announcements years a head of time saying
what's going to be dropped at that point. Have people speak up and say
they will (and actively do) maintain it, otherwise it's gone.

A test of maintainership, is simply letting the legacy code break. If it
does not get fixed in a few years, rip it out. If people are maintaining
it out of tree, and not pushing patches into the mainline kernel, then
they can keep all the code out of tree and not burden the rest of the
developers with it.

And one final note... +1 on your subject reference ;-)

-- Steve




More information about the Ksummit-2012-discuss mailing list