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 : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136
signature.asc
Description: PGP signature
