On Mon, Aug 30, 2010 at 15:56, Jon Masters jonathan@jonmasters.org wrote:
On Mon, 2010-08-30 at 15:57 -0600, Stephen John Smoogen wrote:
Should we try and experiment with a 'sub' distribution? Say take Fedora 12 and keep it running for 18 months? [Lets not get into how this will fail... how could we make it work?]
As I was saying to someone on IRC, the problem is two-fold:
1). Lifetime of the release. When it's over, you're fedora-legacy.
The big issue with Fedora Legacy though was trying to do too much. We were supporting RHL-7.3, RHL-8 and RHL-9 and old Fedora's. You pick one release and you support it. You don't do 4+ ones. As much as sine people like to think RH used to support 7.0/7.1/7.2/7.3 we didnt... we supported 6.2 and latest. if you were at 7.1 and 7.2 came out.. you needed to upgrade.
2). Stable updates are often wholesale rebases. So if you want stability, you need to cherry-pick stuff that wasn't cherry-picked in the original branch. You need to do a lot of extra work, and as was pointed out to me, you'd also be trying to duplicate the legacy model in this aswell, but now with the added overhead of extra backports.
Well the 'solution' to that is choosing what your 'base' is very carefully and only supporting that. Instead of trying to support 1800 src.rpms you focus on 600. Everything else above that 600 that people want goes into powertools :).
[600 is an arbitrary number pulled out of well we don't need to go there.]
So maybe we could pick a very small set of packages and call it a base platform, and have a longer lifetime on it. But first look at why the Fedora Legacy project failed and ask if we can avoid that.
Been there, done that, have the scars (though Jesse got the tattoos).
1) We supported too much: too many releases and too long a lifetime. 2) We expected that the people clamoring for a stable RHL (consultants, small business, etc) would pony up when their business models was more on using other stuff for free. They instead went to new free stuff instead. 3) We did not have a target audience beyond "everyone who was left behind on RHL's crash and burn." [Yes people called it that and worse at the time] 4) Our infrastructure of rebuilding stuff was not very solid so getting a rebuild seemed horribly painful 5) Our rules were at times oppressive because we were trying to satisfy people who wanted RHEL without paying for it... 6) Our audience (both customers and developers) shrank as RHEL became more stable and/or people moved to Fedora or Ubuntu to complete their 'visions'.
There are others but those are the ones I have memorized everytime Mr Kofler brings up my shame. Answers to the above:
1) We support 1 release at a time. 2) We realize that we are small and not expect help until given it. 3) Our audience is people wanting to push beyond what RHEL has in it but want the idea that things break weakly. Our audience is server and o 4) Git/Koji/bodhi/etc are very nice. even plague would be better than what we started with back then 5) We use established rules for packaging and keep our core small. We cherry pick a minimal amount of stuff that we can find a longterm upstream help with and everything else gets 'rebased' regularly if needed. 6) We define what our expected audience is and we keep them with stuff they are looking for. This means figuring out a key 'visionary' market and supplying them with things they need. [The classic RHL market was web servers (ok 'porn') but we can find something more web-3.0 and help them get ahead.]
Jon.
server mailing list server@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/server