Don't put new packages through updates-testing

[Hans de Goede]

Jesse Keating wrote:
> On Friday 01 June 2007 09:14:23 Hans de Goede wrote:
>> As already discussed on then maintainers list (using devel list for this as
>> I see no reason to keep this on maintainers), the plan all of a sudden is
>> to let new packages go through updates-testing.
> 
> Not so much "all of a sudden".  The "sudden" part is using bodhi at all for 
> new packages to released platforms.  I may not have been mentioned loudly but 
> updates-testing for said new packages was the idea all along.

It was never mentioned, I've been digging the archives because AFAIK the 
opisite has actually been promised, new packages would go out as updates, but 
would not need to go through updates-testing, unfortunately I cannot find the 
thread where this was promised, nor did I find any thread which says that: 
"updates-testing for said new packages was the idea all along"

Also there is nothing about updates at all under:
http://fedoraproject.org/wiki/ReleaseEngineering[/*]

Don't get me wrong, I don't want to be bitching all the time, I think that the 
merge is great, that having updates-testing and good QA is great too, actually 
in the past I've done updates where I wished I had an testing area to put them 
first (before actually pushing them, sofar in retrospective they all were fine)

But going through updates testing for each and every bugfix / update is just 
adding unnecessary burden and delays. Why can't this just be left to the 
packagers discretion? I think I've done enough for Fedora to deserve some 
discretion.

>> I'm very much against this, as it adds one more step to already long
>> process of getting new packages in, the current wiki page describing the
>> process divides it into 14 steps and it is lacking the add to comps step
>> (and in my case the update SIG wiki pag, twice once to add it to the list
>> of packages undergoing review, once more to remove).
>>

Please respond to this very imporant point!

>> It removes much of the satisfaction of after completing the review having
>> the package into the hands of the end users, the ones for which I do this.
>> As it adds yet another delay.
> 
> You can still get your new package into rawhide immediately (or rather with 
> the next rawhide push).  There is instant satisfaction there.  Bringing a 
> brand new package to a supposedly stable released platform should be done 
> with some caution and thought, and with letting a wider audience poke at it 
> first in updates-testing before letting it loose upon the masses.
> 

1) There will be no wide audience, even if they have updates-testing enabled 
they will not automatically install the new packages let alone use it, the only 
way to get a wide audience is to put it in updates and in comps, so that people 
can install it through "add/remove software". For the majority of users, if it 
isn't in comps it doesn't exist, since updates-testing has no comps *, the 
package doesn't exist and thus will not get tested.

* and if it will, that means yet more work to get a package out


>> The arguments made in favor of this is that it will be good for QA, however
>> relatively few users will have updates testing enabled 
> 
> And your data set is where?  Perhaps we should query Mike McGraths statistics 
> stuff to see how many unique IPs are hitting the mirror list for 
> updates-testing.  It may be small, it may be large, but I'm not going to just 
> pull an observation out of my posterior. 
> 

I said relatively small, as compared to the total of Fedora users. You still do 
not seem to be getting the point, that the problem is that even if the new 
package is in updates-testing, it won't get installed let alone used all of a 
sudden. For all but the top 100 popular new packages, being in updates-testing 
thus adss no additional testing as no-one will install it.


>> and new packages 
>> will not automatically get installed let alone used by those users. 
> 
> There is no reason why a QA team couldn't specifically target new packages to 
> the distribution as seen through updates-testing to ensure proper 
> functionality on a disparate set of hardware/software configurations.  To 
> just blanket claim that it won't happen is laughable.  We've never done this 
> for Extras, and in Core it was very very difficult to get approval to 
> introduce a new package.  Lets give it a try and see what our growing QA team 
> can come up with to make it worth while.
> 

Repeating myself, then first get such a QA time organized up and running and 
then, and only then, make updates-testing mandatory, if I get usefull feedback 
from this, you've won me over. But formulations like: "There is no reason why 
...." to me actually read like: "today this serves no purpose other then to 
hinder you, but maybe in a future far away this will be actually usefull"

Which results in me saying, fine, then when that future is upon us, do thinks 
like that, but not now.

> That is if you even care about trying to maintain a stable release for users.  
> I know I do.
> 

There is no reason to suggest that I do not promote stability, see my many 
attempts to start a bug fixing squad (not triaging but actual fixing) and my 
many offers of help with bugs.

> *cough* The review is for rawhide, where the platform could be drastically 
> different than that of a stable tree.  Just saying something worked on 
> rawhide and expecting it to work on previous release, or previous release -1 
> is obtuse.
> 

Not true many reviewers review on the latest stable, it says nowhere that a 
review should be done on rawhide.

>> Yet another argument against making new-packages go through updates-testing
>> is the fact that even if there were a QA team testing them, I wonder how
>> they would test my latest batch of packages:
>> avr-binutils
>> avr-gcc
>> avr-libc
>> arm-gp2x-linux-kernel-headers
>> arm-gp2x-linux-binutils
>> arm-gp2x-linux-gcc
>> arm-gp2x-linux-glibc
>>
>> Do they happen to have an avr microcontroller development kit handy for
>> testing or a gp2x handheld? Any experience with programming those?
>>
>> Making package like these goto updates-testing is ridiculous.
> 
> So you're using one corner case package set with a limited user base to throw 
> out the entire idea of getting some larger audience testing on new packages 
> to a stable release.  Sounds like a great argument to me...
> 

A niche package which requires specific domain knowledge to test is not a 
corner case, there are many many niche packages in Fedora and more being added 
every day. Also there is this thing called libraries, which cannot be tested 
without apps using them, but which very well can be packaged and published 
without apps, be it for future use by planned apps, or for use by some non 
Fedora distributabe apps.

---

All I'm asking for is to leaving this to the packagers discretion, isn't Fedora 
supposed to be all about freedom? Then why put me in a straight jacket.


Regards,

Hans