Re: fedora mission (was Re: systemd and changes)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2010-08-31 at 00:10 -0400, Jon Masters wrote:

> > 6 months for new features in a fast paced distro?
> 
> You know, compared to almost any other Operating System out there, 6
> months is warp speed. I'd rather have fewer features in my stable
> install that worked just right, then get shiny new things and deal with
> some brokenness in return at a defined point in the future.

Other operating systems don't work like Linux distributions; the
applications aren't bundled with the core OS. We go to reasonable
lengths to tell people that installing apps from upstream is Bad and
Wrong. On Windows I don't get all my apps through Windows Update and
wait for Microsoft to sign off on updates. We can't compare our release
processes to theirs, when the products we're creating are substantially
different.

As someone pointed out earlier in the thread, in my experience, most
people are fundamentally inconsistent here: generally we have some
components we want updated a lot and some we don't care about (so
probably don't want updated because we'd only notice if the update
'broke something') or actively don't want updated. However, the actual
members of each of those sets vary wildly from person to person. If most
components are delivered through separate mechanisms, as with say
Windows and OS X and more generally with any operating system whose
distributor doesn't follow the model of recommending users should get
all software through official repositories, then problems don't really
occur: you (the user) can choose how to treat each component.

In the traditional Linux distribution, this isn't the case; all
components are maintained in the same repository, and if you don't use
it, you're 'off the reservation'. That kind of limits the choices of the
distributor.

1) Don't shoot everything through the same hose: separate. Fedora used
to do this, with Core and Extras. Now we don't. I can't really comment
on why, I wasn't around. There are clearly advantages and disadvantages
to doing this.

2) Provide multiple hose variations - however you set it up, give users
some kind of way to pick fast updates for some components and slow
updates for others. (All the proposals about multiple package versions
in repositories, or multiple repositories, come under this heading.)

3) Provide one hose, and pick a policy covering how fast the updates
come out of it, and say 'that's what you get, if you like it take it, if
you don't, we don't support you'.

All of these approaches have drawbacks and advantages. Currently we're
on #3, with the twist that the policy is chosen in a fairly haphazard
way. So far we've discussed sticking with #3 but making the policy more
organized and possibly different, and we've also discussed #2, though it
doesn't seem to be going anywhere. #1 doesn't seem to be much in the
running.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux