So what about creating an "Untested" repository or something? Make the
packages available to those willing to use untested packages (don't
waste the effort already put into it) without putting untested packages
with potential problems in with the tested and supposedly trustworthy
packages.
Will.
Pekka Savola wrote:
On Sat, 27 Aug 2005, William Stockall wrote:
If no one is interested in testing the patch, doesn't that sort of
imply no one really needs it? Why release untested software? If
someone actually IS using the package, maybe they can QA it.
Otherwise it shouldn't be released. It might be possible to add some
code word to the bug and close it due to disinterest or something.
The problem with this approach is that it wastes resources: a
significant amount of time and energy is spent on the following steps:
a) identifying the issues and putting them in bugzilla,
b) creating packages for all the distros with patches,
c) getting enough PUBLISH QA votes for the packages,
d) rebuilding the packages in mach (often there are build issues)
and releasing in updates-testing,
e) getting the sufficient VERIFY votes
f) releasing the packages in updates testing [trivial]
At the moment, if we find a package like squid or rp-pppoe which don't
get verifies, we'll notice it at step e). The energy/time has already
been spent in steps a) - d). At step a), it is difficult if not
impossible to figure out if e) would actually happen.
We don't want to waste time and resources, particularly because the
folks doing Fedora Legacy stuff CAN and DO get frustrated when nothing
happens and the work already done is flushed down the toilet.
Thus, "just abandon the work at e)" is NOT an option (as we are de-facto
doing now). Something needs to change. For example,
1) identifying folks earlier who'd commit to providing at least one
VERIFY, so the effort is not wasted, or
2) the policy which allows releasing non-VERIFYed packages
after a (longish) timeout.
Because 1) is more work to the process as it is, as I've said earlier, I
find 2) better.. but I'm open to hearing concrete suggestions.
--
fedora-legacy-list@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/fedora-legacy-list
