James Antill wrote:
> On Wed, 2010-03-03 at 07:38 +0100, Kevin Kofler wrote:
>> People who use updates-testing under the current system are signing up to
>> doing testing. Under your proposal, they'd be forced to sign up to get
>> any current updates.
>
> Get current updates => so they can be tested!
But what if I want already tested (for a reasonable period, like 1-2 weeks,
not months!) current updates? I am not alone in that!
>> No, because updates may depend on previous updates to work properly. We
>> can't possibly test or support all possible combinations of updates.
>
> We can't _now_ ... because of packagers like you who want to release
> lots of updates with no or almost no testing!
> If we had less updates, that changed less things and required more
> testing before pushing them to users ... this would be entirely
> possible.
No. For n updates, there are 2^n possible combinations, even with critical
security updates alone, this would not scale.
RHL update announcements used to include this notice:
| Before applying this update, make sure all previously released errata
| relevant to your system have been applied.
IMHO we should add the same disclaimer to Fedora update announcements. The
same reasons which were valid back then still are.
> No, there's suffering because you are breaking their computers with
> your updates (which has been pointed out to you many times in this
> thread).
Nonsense. The bugs being fixed by new KDE releases are often bugs which have
been there all the time, not caused by an update.
> No, I for one will not be just enabling updates-testing if my proposal
> is passed. Again, I imagine that the major of users will not do this ...
> and will be happier to have a smaller number of tested updates.
I think you're illuding yourself. Mainly because updates under your proposal
would not just be "tested", but "arbitrarily delayed to penalize frequently-
updated packages". That has nothing to do with testing at all.
The time required to test an update does NOT depend on previous updates
having been issued for the same package! It is only a function of the
changes in THAT PARTICULAR update.
> You are _forcing_ people to use updates-testing because there is
> nothing else ... things can't be tested by the time they hit "updates",
> so updates is de. facto. "updates-testing".
This is complete and utter nonsense. Updates ARE being tested in updates-
testing. (In fact that's why some people want to ban direct stable pushes,
they want to make sure everything gets testing.) And you still don't justify
why the second update to a package would need more testing than the first
one etc., this makes absolutely no sense to me.
>> They're not testing it, they're receiving it already tested.
>
> Except that it breaks ... but of course that's their problem, not
> yours ... right?
What breaks?
> I think I'm starting to see a pattern here:
>
> . Kevin doesn't use DVD updates, so anything that needlessly breaks DVD
> updates is fine because DVD updates are worthless.
Wrong. DVD updates are broken by design. It's impossible to support them in
its current state and it's unreasonable to expect Fedora to radically change
(we couldn't even do version bumps to fix security issues anymore!) to
accomodate this usecase. The proper solution is to fix Anaconda to include
the updates repository for upgrades. That I happen not to use this broken
feature is entirely irrelevant.
> . Kevin doesn't use selective updates, so packagers doing less work and
> not testing for selective updates is fine because selective updates are
> worthless.
Wrong. Selective updates are broken by design. It's impossible to support
them because the exponential amount of testing will never be achievable,
even if Fedora were to radically minimize its updates. They will always be
something that "may or may not work" and is not recommended. That I happen
not to use this broken feature is entirely irrelevant.
> . Kevin doesn't use --security, so packagers ignoring security issues is
> fine because --security is worthless.
Wrong. --security is broken by design. It's impossible to support it because
it is just a special case of selective updates above. There are also other
technical issues with it (like upgrades which happen to fix security issues,
but this is discovered or announced only after they already got pushed as
non-security). That I happen not to use this broken feature is entirely
irrelevant.
> . Kevin doesn't mind restarting KDE after updates, so any users
> complaining their desktop doesn't work after an update can be ignored.
Wrong. KDE upstream requires restarting KDE after upgrading, there is
nothing Fedora can do about it, and not pushing any KDE bugfixes just to
prevent this minor inconvenience would be a disservice to many more users.
For the vast majority of our users, restarting KDE is not a big deal at all
(in fact I don't remember having received more than that one single
complaint about it, out of thousands of users). That I happen not to mind
this personally is entirely irrelevant.
> . Kevin likes lots of updates, and having them forced onto others so
> they get tested for him, so anything that provides more updates is good
> and anything that slows them down for testing is bad.
Wrong. That "having them forced onto others so they get tested for him" part
is complete nonsense. I update very often, so other users of the stable
updates are NOT testing things for me, they're getting them no sooner than I
do. Sure, users of updates-testing are testing things for me and many other
people, but that's what they voluntarily signed up to, so I fail to see the
problem.
And the really bad thing about your proposal is that it does NOT slow down
the updates *for testing*, but for very long periods of time which have
nothing to do with testing anymore. In particular, the second, third etc.
update to a package requires no more testing time than the first. (This is
the major flaw in your proposal, yet you see this as an essential feature
and fail to realize it doesn't make sense.)
> ...if only someone had let me know that Fedora had become your personal
> distro.
It's not. I just don't see why I should be expected to support things that
don't work and can't work.
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
