Fedora Legacy Test Update Notification: rp-pppoe

[William Stockall]

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.
>