Rahul Sundaram wrote:
Hans de Goede wrote:
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!
Adding that step in the wiki can be done by anyone and addition to help
improve quality are a good thing.
You know very well that I was not talking about the adding to the wiki, but
about the to large number of steps needed to get a package in.
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,
If the package has a small audience then surely it can wait for a
limited timeout in updates-testing
I'm not saying it has a small audience (it might) I'm saying that the
cross-section of potential users and those with updates-testing enabled is most
likely small.
And for some reason nobody is responding to my point that when in
updates-testing a package cannot be in comps and thus is invisible to those
using the tools we advice them to use!
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.
If QA can be bypassed then that reduces the incentive to form the team
in the first place.
I'm not saying QA should be bypassed, I'm saying that delaying packages for a
week to allow testing by a non existent team is silly.
Not true many reviewers review on the latest stable, it says nowhere
that a review should be done on rawhide.
Review is about guidelines and nowhere in the guideline does it even say
that the fucntionality of the package should be tested. When I suggested
that it be added I got back a knee jerk reaction to participate in
reviews myself.
Maybe that reaction was solicited because it seems that those making the rules
seem to be disconnected from those doing the work? A typical case of manager
syndrome.
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.
It is not all about freedom though. There are several other factors that
influence a decision.
Factors such as? I thought freedom was the great good which we are all working for.
Regards,
Hans
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
