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
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
