Don't put new packages through updates-testing

Jesse Keating jkeating at
Fri Jun 1 13:47:31 UTC 2007

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.  In the past, 
the only way we had to "test" things with a wider audience was to use 
rawhide, but that isn't a good test as rawhide doesn't equal the released 
platforms, and there are issues on said platforms that will be different.

> 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).
> 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.

> 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. 

> 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.

> Then 
> the argument in favor becomes that once we have a QA team up and running,
> we could build QA infra which autamatically installs new packages from
> updates-testing for the QA team (running still would be a manual thing).
> However currently all that infra doesn't exist, so can we please short
> circuit updates-testing for new packages, and revisit this discussion once
> that infra actually is there?

Why would the infra be there if there is no new packages to test?  It doesn't 
take much effort to enable updates-testing and target a new package.  There 
doesn't need to be any infrastructure in place, things can be done manually 
right now, today, and you could get valuable feed back, right now, today.  
That is if you even care about trying to maintain a stable release for users.  
I know I do.

> IOW first show that updates-testing actually is usefull (esp. for new
> packages) and then make new packages go through there.
> Last but most certainly not least new packages have already had lots of QA
> they have just been reviewed! To me this forcing new packages to go through
> updates-testing is a vote of no confidence into me as a packager and a
> reviewer, and since I sink a lot of time, effort and skill into Fedora that
> hurts!

*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.

> 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...

Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <>

More information about the fedora-devel-list mailing list