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
