On Mon, Jan 26, 2009 at 12:19 PM, Rahul Sundaram
<sundaram@xxxxxxxxxxxxxxxxx> wrote:
> Chris Weyl wrote:
>
>> It's hardly a "small additional cost", especially when looked at in
>> aggregate; this would be an additional non-automateable step required
>> for every update release that is of very questionable value/utility to
>> the vast majority of our users.
>
> I wouldn't say that. Currently it is of questionable value currently but it
> would be much more valuable without just version bumping and more careful
> thought put into justifying the need for updates. Every update adds to a
> large cost in terms of build time, bandwidth, potential regressions etc.
...costs which are trivial next to the packager/maintainer time and
increase in their workload. (did I mention, largely unpaid workload?)
If you think that "version bumping" is a bad thing (which, frankly, I
suspect most people refer to as "tracking upstream"), then argue we
should put in place guidelines requiring "maintainers evaluate and
justify issuing an update"... of course, then we'd need a review
board, appeal process, procedures, etc, etc. If you're worried about
regressions, then let's get something going that tracks what packages
depend on the package the update and exercises their functionality...
Which would be next to impossible for programs that don't have a test
suite. (Arguably, the best way to detect and correct regressions is
to track upstream and provide feedback to them.)
None of these "goals" will be helped by imposing a barely related new
manual process requirement that you concede is "[c]ertainly of
questionable value".
>> I realize it would make your life
>> easier, but is it worth an additional imposition on our already
>> highly-regulated maintainers just to make your life easier?
>
> This is hardly about just me. I am not the only user on low bandwidth
> connections at times. Many regions of the world are as you can see from the
> number of people agreeing with the general idea.
I suspect those on low-bandwidth connections would be better served by presto.
>> Basically, this seems to be "I don't really trust the package
>> maintainer's decision on why I should upgrade, so I want to know what
>> changes this introduces."
>
> There are other considerations including but not limited to bandwidth and
> yes, the criteria that users choose for consuming updates can be quite
> different from the maintainer's reason for pushing the update and without
> the maintainers informing me of why they decided to do a push, users can't
> arbitrate their decisions either.
Not to be blunt, but "too bad". That's why we're called
"maintainers", and they are "end users". If "updating to 1.2.3" isn't
good enough, and someone really wants to know what's going on with the
package, then they should read upstream's changelog. That's what it's
there for, and why we incorporate it by reference.
People know that Fedora aims to be leading-edge technology. They
expect our packages to track upstream pretty closely, and understand,
yes, we do sometimes have regressions (that are generally tracked
pretty quickly, from what I've seen). If "too many updates" is a
problem, then perhaps they should rethink what they're doing.
-Chris
--
Chris Weyl
Ex astris, scientia
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
