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
Attachment:
pgpY9FQuQddfB.pgp
Description: PGP signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
