*tap* *tap* *tap*

[Stephen John Smoogen]

On Mon, Aug 30, 2010 at 15:56, Jon Masters <jonathan at 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 at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/server
>



-- 
Stephen J Smoogen.
“The core skill of innovators is error recovery, not failure avoidance.”
Randy Nelson, President of Pixar University.
"We have a strategic plan. It's called doing things.""
— Herb Kelleher, founder Southwest Airlines