How to deal with defunct projects (whose purpose makes sense)?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

How to deal with defunct projects (whose purpose makes sense)?

Michał Górny-5
Hello,

In context of the recent plan of disbanding the Samba team, I'd like to
ask for better ideas on how to deal with projects that technically make
sense but are currently dead/defunct.  This means that either they have
no members, all their members are inactive or simply don't want to work
on the specific project anymore.

Of course, the first step is to look for new project members.  However,
let's assume we've already done that and unsuccessfully.  What should
happen next?

So far I've been leaning towards disbanding the project and moving
packages to maintainer-needed.  This has the advantage of clearly
indicating that those packages are unmaintained, with all the common
implications of that.

However, it also has been pointed out that this frequently 'ungroups'
packages while being maintained by a single project makes sense for
them.  I don't really have a strong opinion on this -- especially that
sometimes this actually helped people decide to take at least some of
the packages.  On the other hand, Ada is an example of project that has
been recreated after being disbanded.

Do you have any suggestions how we could effectively achieve the effect
similar to 'maintainer-needed' without disbanding projects?

--
Best regards,
Michał Górny


signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: How to deal with defunct projects (whose purpose makes sense)?

Aaron Bauman-2
On Thu, Mar 28, 2019 at 03:53:37PM +0100, Michał Górny wrote:

> Hello,
>
> In context of the recent plan of disbanding the Samba team, I'd like to
> ask for better ideas on how to deal with projects that technically make
> sense but are currently dead/defunct.  This means that either they have
> no members, all their members are inactive or simply don't want to work
> on the specific project anymore.
>
> Of course, the first step is to look for new project members.  However,
> let's assume we've already done that and unsuccessfully.  What should
> happen next?
>
> So far I've been leaning towards disbanding the project and moving
> packages to maintainer-needed.  This has the advantage of clearly
> indicating that those packages are unmaintained, with all the common
> implications of that.
>
> However, it also has been pointed out that this frequently 'ungroups'
> packages while being maintained by a single project makes sense for
> them.  I don't really have a strong opinion on this -- especially that
> sometimes this actually helped people decide to take at least some of
> the packages.  On the other hand, Ada is an example of project that has
> been recreated after being disbanded.
>
> Do you have any suggestions how we could effectively achieve the effect
> similar to 'maintainer-needed' without disbanding projects?
>
> --
> Best regards,
> Michał Górny
>
While I am not addressing your specific request... I would like to offer
that I think that disbanding projects is working thus far.  Of course,
some packages should be kept together, but anyone stepping up to
maintain those packages should know that and continue maintenance as
such.

Aside from this, the disbandonment efforts have proven, from my
perspective, to open the door for others to fix packages which have
outstanding bugs open.

Keep doing it...

--
Cheers,
Aaron

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: How to deal with defunct projects (whose purpose makes sense)?

Robin H. Johnson-2
In reply to this post by Michał Górny-5
On Thu, Mar 28, 2019 at 03:53:37PM +0100, Michał Górny wrote:

> Hello,
>
> In context of the recent plan of disbanding the Samba team, I'd like to
> ask for better ideas on how to deal with projects that technically make
> sense but are currently dead/defunct.  This means that either they have
> no members, all their members are inactive or simply don't want to work
> on the specific project anymore.
>
> Of course, the first step is to look for new project members.  However,
> let's assume we've already done that and unsuccessfully.  What should
> happen next?
>
> So far I've been leaning towards disbanding the project and moving
> packages to maintainer-needed.  This has the advantage of clearly
> indicating that those packages are unmaintained, with all the common
> implications of that.
>
> However, it also has been pointed out that this frequently 'ungroups'
> packages while being maintained by a single project makes sense for
> them.  I don't really have a strong opinion on this -- especially that
> sometimes this actually helped people decide to take at least some of
> the packages.  On the other hand, Ada is an example of project that has
> been recreated after being disbanded.
>
> Do you have any suggestions how we could effectively achieve the effect
> similar to 'maintainer-needed' without disbanding projects?
There's 2 separate but unfortunately intertwined things I see happening,
and it has somewhat of a historical reason.

TL;DR:
- A 'collection' of packages that crosses categories is still useful,
  even that entire collection is presently maintainer-needed
- Projects with no members or are inactive should probably be shut down
  and have their package collections marked as maintainer needed.

Longer stuff:

Here's the history of things as I remember it:

In the very beginning, there were packages, and no categories, and no
CVS. I don't have any tarballs of what the tree looked like at this
point, but only some old records. I'd love a tarball if you have one. It
would be before 2000/07/30.

Categories came in next, before CVS. I don't have good logs on when.

CVS was introduced 2000/07/30, the first package imported to CVS was
net-mail/mutt, followed by Portage itself.

If you wanted to ask about touching a package, you checked the CVS logs
and the ChangeLog file. Or more frequently you just changed it anyway,
which mostly went OK, but had some fantastic breakages (e.g. leading to
the creation of revdep-rebuild).

Projects existed, but weren't formally defined or strongly tied to
packages. Projects had mail aliases and/or mailing lists.

GLEP4 was proposed around 2003/06/24, and quickly passed, formally
defining projects.

metadata.xml & herds.xml were introduced 2003/07/02:
https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/misc/herds.xml?hideattic=0&revision=1.1&view=markup

They weren't defined by GLEP, but were on the old site docs.

A herd was originally a collection of packages, potentially spanning
categories, which had one or more maintainers. Herds had a mail alias to
reach the maintainers responsible for the collection of packages.

GLEP39 replaced GLEP4 as of 2005/09, and added a specification for
projects:
https://www.gentoo.org/glep/glep-0039.html#specification
This started the conflating of Projects vs Herds ("Herds" appears only
once, as a remark about them being understaffed).

The biggest gain was that the mail aliases that herds were behind, and
didn't give much transparency of which maintainers were responsible for
a herd. Projects made that explicit in public XML instead.

Over time, with some pushing, most herds were moved and/or shoe-horned
into Projects.

Some of those Herds that became Projects, such as net-mail & pam, were
never really cohesive groups of maintainers, because the packages, while
related in some way, could be very different (e.g. qmail was a subherd
of net-mail, but people who touch the postfix codebase don't want to
touch the qmail codebase, and I don't blame them as one of the former
qmail maintainers).

So what should the future be?
- find a way to keep groups of packages together because it's still
  useful.
- find a way to mark that the entire group needs a maintainers
- disband inactive/empty projects

--
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : [hidden email]
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: How to deal with defunct projects (whose purpose makes sense)?

Pacho Ramos
In reply to this post by Michał Górny-5
El jue, 28-03-2019 a las 15:53 +0100, Michał Górny escribió:

> Hello,
>
> In context of the recent plan of disbanding the Samba team, I'd like to
> ask for better ideas on how to deal with projects that technically make
> sense but are currently dead/defunct.  This means that either they have
> no members, all their members are inactive or simply don't want to work
> on the specific project anymore.
>
> Of course, the first step is to look for new project members.  However,
> let's assume we've already done that and unsuccessfully.  What should
> happen next?
>
> So far I've been leaning towards disbanding the project and moving
> packages to maintainer-needed.  This has the advantage of clearly
> indicating that those packages are unmaintained, with all the common
> implications of that.
>
> However, it also has been pointed out that this frequently 'ungroups'
> packages while being maintained by a single project makes sense for
> them.  I don't really have a strong opinion on this -- especially that
> sometimes this actually helped people decide to take at least some of
> the packages.  On the other hand, Ada is an example of project that has
> been recreated after being disbanded.
>
> Do you have any suggestions how we could effectively achieve the effect
> similar to 'maintainer-needed' without disbanding projects?
>
Personally I would keep moving them to maintainer-needed. If some packages
really need to be bumped in sync, we can add a comment to the affected ebuilds
to remember it for any developer taking the package or going to fix some issue
for it.

About recreating the project after, it's ok for me as soon as the new project
has active people for it.

Regards

signature.asc (235 bytes) Download Attachment