svn commit: r347539 - in head: biology/genpak biology/rasmol cad/chipmunk databases/typhoon databases/xmbase-grok devel/asl devel/flick devel/happydoc devel/ixlib devel/p5-Penguin-Easy editors/axe ...

[Alexey Dokuchaev]

On Thu, Mar 27, 2014 at 02:22:59PM +0100, John Marino wrote:
> On 3/27/2014 14:18, Alexey Dokuchaev wrote:
> > On Thu, Mar 27, 2014 at 01:57:01PM +0100, John Marino wrote:
> >> On 3/27/2014 13:51, Alexey Dokuchaev wrote:
> >>> However, I do believe that we need to have a more formal set of rules when
> >>> it comes to ports deprecation (and subsequent removal), esp. given how
> >>> small is probation period now (typically one or two months).
> >>
> >> why is short probation period a problem?
> > 
> > Because I feel that two months still lie within three sigmas, while six
> > months is safe enough.
> 
> Safe enough from what exactly?

I mean it gives more time for someone, or one of the Kato's slaves to come
around and fix it.

> If you give people 3 extra months, they just squander 3 extra months.
> There is zero long term impact.  You keep conveniently not acknowledging
> that most of the candidates on the deprecation list fully deserve to be
> on that list and have been ignored for years.

I am acknowledging this fact; I just don't see a point of removing ports
that build and package fine just because they are unmaintained.  I am not
saying that all of those ports are useful for me, but once in a while I'm
faced with the fact that port I need right now was deprecated and removed
for no real reason.  I don't like that.

And just to end this argument (I know we've been through this before): I
guess two months of probation is fine with me for *broken* ports, and while
I'd be more comfortable with six, I won't eat my heart over it.

./danfe