On Wed, Jan 16, 2019 at 11:25:31PM +0100, gregor herrmann wrote:
> On Wed, 16 Jan 2019 22:15:21 +0200, Niko Tyni wrote:
> > On Sun, Jan 13, 2019 at 03:14:53PM +0100, gregor herrmann wrote:
> > > I'm a bit ambiguous; in cases which are broken in sid
> > > (libextutils-parsexs-perl) just removing them makes sense of course.
> > Cool. I'll request removal of libextutils-parsexs-perl soon unless
> > somebody objects.
> Great, thanks.
> > > In all other cases I consider the cost of keeping them minimal enough
> > > to not jump through current or future hoops, at least if there are
> > > signs of activity and a trace of needing newer versions.
> > Works for me if we can come up with an activity threshold so we don't
> > have to have this discussion every time.
> > > So from an activity and upstream maintenance point of view,
> > > libio-socket-ip-perl (Paul), libsocket-perl (Paul), libtest-harness-perl
> > > (Leon) (and maybe libmodule-metadata-perl) might be candidates for
> > > keeping.
> > This feels about right to me.
> Ok; are going the file RM bugs for the other packages from your list
> as well or would you like to leave this to someone else?
> > > For the future (as we face the same question before each release)
> > > maybe we can (at a sprint?) come up with some guidelines?
> > > Like "no release in the last 2 years" or something?
> > Works for me; I propose we set policy at that and revisit it
> > later if needed?
> Sounds good. Let's wait a bit and then write it down?
I agree with this proposal.