[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Don't put new packages through updates-testing



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]