On Sun, Dec 13, 2015 at 11:28 PM, Peter Robinson <pbrobinson(a)gmail.com>
wrote:
On Mon, Dec 14, 2015 at 3:16 AM, Ken Dreyer
<ktdreyer(a)ktdreyer.com> wrote:
> On Sat, Dec 12, 2015 at 7:34 PM, Peter Robinson <pbrobinson(a)gmail.com>
wrote:
>> 2) Automatic unpushing of updates that haven't gone stable after X
>> time (I propose 3 months/90 days here). That should be ample time to
>> know if it's good/bad.
>
> Could we make it go the other way, and submit the update to stable if
> it's received no feedback for 90 days?
No, because on two of the 3 I referenced there was bad karma and no
response from the "maintainer" to the feedback.
> Often I'll let my update sit in epel-testing for a long time because I
> want to give users a large window of opportunity to test the update.
> It's not that it's abandoned, it's just that it's not an urgent
> update, so why rush it? If the update hits the karma threshold earlier
> than I expected, so much the better.
I think 90 days is enough to let people test it, ultimately the
maintainer should have done the testing and know the vast majority of
it is good, it should be more to get non standard use cases, corner
cases etc.
In theory yes, but the real world is far messier than that. There are a few
packages that I maintain in EPEL because a package I needed depend on it,
but I don't use the functionality. So I know the package I use works but
I've never exercised/tested the functionality of the depended on package. I
wish that I had time for that to not be the case, but sadly that's just the
reality of the situation.