FESCo wants to ban direct stable pushes in Bodhi (urgent call for feedback)

[Kevin Kofler]

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