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

Re: Lack of update information



On Mon, 2009-01-26 at 18:05 -0600, Matthew Woehlke wrote:
>  
> Aside from upstream (hopefully) not being a mess, there is a difference 
> between "this seems to work" and "what justification, besides that 
> upstream has fixed bugs and added features, can I give to push this update"?
> 
> If a package seems to be non-broken and fixes bugs, that's good enough 
> for me to update. (Of course, I'm also not in a limited-bandwidth 
> situation, but...) Just because I haven't been bitten by a particular 
> bug /yet/ doesn't make updating useless; maybe it saves me from being 
> bit tomorrow.
> 
> Also, notice I didn't actually object to asking for better "what's 
> changed" information. I objected to putting bureaucracy in the way of 
> what Fedora currently is; a distro that tends to closely track upstream.
> 
> > On Mon, 2009-01-26 at 17:29 -0600, Matthew Woehlke wrote:
> >> Should we not release any updates without a Fedora bug being filed 
> >> asking to upgrade to the latest upstream?
> > 
> > That's actually not unreasonable.  The update process should be user
> > driven, as in a user needs or wants something specific from the new
> > upstream code, we don't just install a bot to throw whatever falls out
> > of upstream directly at our users whether they want/need it or not.
> 
> ...except now I have to run around opening a ticket every time KDE bumps 
> its requirement on CMake version, or libical version, or...

But Fedora /releases/ aren't your personal rawhide.  We're providing
releases that are supposed to stay somewhat stable, not to just be a
dumping ground for whatever upstream chooses to drop the day before.  We
have a developmental stream for that, and it makes releases fairly
often.  I just don't understand why we want to treat our /release/
branches as if they were just another rawhide.

-- 
Jesse Keating
Fedora -- FreedomĀ² is a feature!
identi.ca: http://identi.ca/jkeating

Attachment: signature.asc
Description: This is a digitally signed message part


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