The updates firehose
Axel Thimm
Axel.Thimm at ATrpms.net
Sun Jun 10 17:12:40 UTC 2007
On Sun, Jun 10, 2007 at 11:08:35AM -0400, Christopher Aillon wrote:
> Axel Thimm wrote:
> >On Sat, Jun 09, 2007 at 04:05:00PM -0400, Jesse Keating wrote:
> >>Anybody else think we're issuing entirely /way/ too many updates? We've
> >>had 138 "stable" updates, and 177 current "testing" updates. If all
> >>those were to go stable, we're talking over 300 updates, in just over a
> >>week.
> >
> >But is that different than at FC6 release time (I don't know, but I
> >assume it was similar if not even more)? We're not really doing
> >anything different that made updates increase, I would even think that
> >it is more difficult to pass updates since they have to be pushed
> >through bodhi.
> >
> >You only feel like there are that many updates, because they are now
> >all using bodhi while before F7 only 1/4th (Core) would become visible
> >that way.
> >
> >>Seriously. We're drowning our users in updates. Are all of them
> >>really necessary? I feel like we've got this culture of update
> >>whatever/whenever coming from Extras where it was just fire and
> >>forget. While that might be fun for the maintainer, is it fun for
> >>the user? Is it fun for the user with a slow connection?
> >
> >I think Fedora's success is partly due to being updated that way.
>
> I think the ugpradeability is a factor, but I think you've got it wrong.
> If every time someone built a change into rawhide, they also pushed a
> fix to F-7 for example because there's a new version of <insert popular
> app here>, then what's the point in upgrading to F-8 when that's ready?
Well, blindly upgrading everything wasn't advocated, but still, we
have 12/13 of the time 3 releases and 1/13 of the time 4 releases to
support and it often makes sense to keep the same version across the
releases (especially for voluntary contributors). If we were only
pushing into rawhide F7 would had been far more buggier as many bugs
had been found and fixed during FC6.
Furthermore this *is* by definition Fedora's style of existance. And
don't look at the former Extras, the kernel from the former Core is
giving the best example: Perhaps one of foure kernel upgrades are due
to security fixes, and the kernel upgrades are one of the worst
nightmares given 3rd party repos offering kernel module packages.
> Most extras packages have the same version across the board. I
> understand the pros of doing that, but do we really want to turn each
> Fedora release into the next RHL 7.3?
I don't quite understand the comparison, but FWIW RHEL 7.3 was a very
popular release, and if we could have each Fedora release as pupular,
then why now. Also we're not turning into anything, Fedora has been
like that at least since mid-FC3 when Fedora Extras launched (and as
said the kernel is the best example for this happening outside of
Extras anyway), nothing has changed other than pushing stuff through
bodhi.
And I still don't see any drawbacks mentioned. F8 not being worth to
upgrade to because F7 is already that good? A (or every) Fedora
release becoming as popular as RHL 7.3 (but maybe I missed what is
being compared)? These are not really arguments against the current
(and old) workflow model in Fedora, but more in favour. :=)
Hey, let's not forget what Fedora is:
The Fedora Project is a Red Hat-sponsored and community-supported open
source project that promotes RAPID DEVELOPMENT of INNOVATIVE open
source software through a collaborative, community effort.
As a community forum for ADVANCED DEVELOPMENT, the Fedora Project
provides EARLY VISIBILITY to the LATEST open source technology and
serves as a PROVING GROUND for technology that may eventually make its
way into Red Hat's fully-supported commercial solutions such as Red
Hat Enterprise Linux.
--
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20070610/cae5e1cf/attachment.sig>
More information about the fedora-devel-list
mailing list