James Antill wrote:
> Users don't get a constant firehose of updates they are basically
> forced to install, a lot more packages should spend a lot more time in
> testing (thus. the user can choose to get the updates or updates-testing
> versions).
> How is that not more choice than "here's rawhide-12, you are now forced
> to test it for me"?
Well, I see where you're getting to now, but this is really not what
updates-testing is for! Updates-testing is for TESTING updates, not for
being used as production by some users, even those who want more updates. I
want many updates, but I don't want to be the guinea pig for updates which
just hit testing, and I also don't want to have to selectively update
because it's a mess.
Our current stable updates are NOT "rawhide-12", your proposed use of
updates-testing would be more like that, and the stable updates would become
useless (especially with your strange way of accumulating DSUT, but lets
come to that later).
> I think may have also missed the fact that DSUT _increases_ (to stop
> the practice of having 1 update a month for a package, so the user is
> forced to get them all or none) with each push from "updates-testing" to
> "updates". I find it less believable that packagers will follow that
> (esp. considering the above).
Indeed, I overread or misunderstood this part of your proposal, and this
makes no sense whatsoever to me (and in fact this subtle detail changes your
proposal from something I consider excess bureaucracy, but could live with
to something entirely unacceptable).
This effectively makes some updates sit in testing forever, even if they're
just bugfixes. For example, KDE bugfix releases get pushed once a month. Why
do you want to ban this? Do you want users of stable to suffer through KDE
bugs or be forced to use testing? You're effectively forcing everybody to
use testing, leading users to a LESS tested Fedora rather than a more tested
one. The thing is, testing is supposed to be a place where updates get
TESTED, not a way to distinguish between a conservative update stream and
one with new versions. So the goal of any "minimum DSUT" proposal should be
to make the packages require enough total DSUT to be effectively tested, not
to be some arbitrary holdup time. And that time only depends on what a given
update changes compared to the version which is currently stable. Anything
prior to that is history and completely irrelevant.
Your proposal is abusing testing for something it's not designed to be and
in the end just making things worse for everyone. If people really want a
conservative update stream, Adam Williamson's proposal makes a lot more
sense (but I'm against that one too, I'd just pick it over yours any day).
> You have 21 days of testing for the first update, and over a month for
> the second ... really?
No.
> Again, that's over a month for the first update and about 3 months for
> the second ... I find it hard to believe you are willingly that
> conservative.
No.
The DSUT numbers I gave are total numbers of DSUT for any given update, they
don't get a constant 4 added, they don't get accumulated from one update to
the next, they don't get doubled or anything IMHO silly like that. In my
list, a package which requires 7 DSUT total always requires 7 DSUT total
(i.e. it will sit at least a week in testing, usually at most 2 weeks),
whether it's the first, the second or the 10000000th update. I don't see how
the fact of this being the n-th update would change anything to the amount
of testing required (and that's what updates-TESTING is for, not as a place
for updates to linger in indefinitely).
Kevin Kofler
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
