| 1 |
On Thu, Mar 28, 2019 at 03:53:37PM +0100, Michał Górny wrote: |
| 2 |
> Hello, |
| 3 |
> |
| 4 |
> In context of the recent plan of disbanding the Samba team, I'd like to |
| 5 |
> ask for better ideas on how to deal with projects that technically make |
| 6 |
> sense but are currently dead/defunct. This means that either they have |
| 7 |
> no members, all their members are inactive or simply don't want to work |
| 8 |
> on the specific project anymore. |
| 9 |
> |
| 10 |
> Of course, the first step is to look for new project members. However, |
| 11 |
> let's assume we've already done that and unsuccessfully. What should |
| 12 |
> happen next? |
| 13 |
> |
| 14 |
> So far I've been leaning towards disbanding the project and moving |
| 15 |
> packages to maintainer-needed. This has the advantage of clearly |
| 16 |
> indicating that those packages are unmaintained, with all the common |
| 17 |
> implications of that. |
| 18 |
> |
| 19 |
> However, it also has been pointed out that this frequently 'ungroups' |
| 20 |
> packages while being maintained by a single project makes sense for |
| 21 |
> them. I don't really have a strong opinion on this -- especially that |
| 22 |
> sometimes this actually helped people decide to take at least some of |
| 23 |
> the packages. On the other hand, Ada is an example of project that has |
| 24 |
> been recreated after being disbanded. |
| 25 |
> |
| 26 |
> Do you have any suggestions how we could effectively achieve the effect |
| 27 |
> similar to 'maintainer-needed' without disbanding projects? |
| 28 |
There's 2 separate but unfortunately intertwined things I see happening, |
| 29 |
and it has somewhat of a historical reason. |
| 30 |
|
| 31 |
TL;DR: |
| 32 |
- A 'collection' of packages that crosses categories is still useful, |
| 33 |
even that entire collection is presently maintainer-needed |
| 34 |
- Projects with no members or are inactive should probably be shut down |
| 35 |
and have their package collections marked as maintainer needed. |
| 36 |
|
| 37 |
Longer stuff: |
| 38 |
|
| 39 |
Here's the history of things as I remember it: |
| 40 |
|
| 41 |
In the very beginning, there were packages, and no categories, and no |
| 42 |
CVS. I don't have any tarballs of what the tree looked like at this |
| 43 |
point, but only some old records. I'd love a tarball if you have one. It |
| 44 |
would be before 2000/07/30. |
| 45 |
|
| 46 |
Categories came in next, before CVS. I don't have good logs on when. |
| 47 |
|
| 48 |
CVS was introduced 2000/07/30, the first package imported to CVS was |
| 49 |
net-mail/mutt, followed by Portage itself. |
| 50 |
|
| 51 |
If you wanted to ask about touching a package, you checked the CVS logs |
| 52 |
and the ChangeLog file. Or more frequently you just changed it anyway, |
| 53 |
which mostly went OK, but had some fantastic breakages (e.g. leading to |
| 54 |
the creation of revdep-rebuild). |
| 55 |
|
| 56 |
Projects existed, but weren't formally defined or strongly tied to |
| 57 |
packages. Projects had mail aliases and/or mailing lists. |
| 58 |
|
| 59 |
GLEP4 was proposed around 2003/06/24, and quickly passed, formally |
| 60 |
defining projects. |
| 61 |
|
| 62 |
metadata.xml & herds.xml were introduced 2003/07/02: |
| 63 |
https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/misc/herds.xml?hideattic=0&revision=1.1&view=markup |
| 64 |
|
| 65 |
They weren't defined by GLEP, but were on the old site docs. |
| 66 |
|
| 67 |
A herd was originally a collection of packages, potentially spanning |
| 68 |
categories, which had one or more maintainers. Herds had a mail alias to |
| 69 |
reach the maintainers responsible for the collection of packages. |
| 70 |
|
| 71 |
GLEP39 replaced GLEP4 as of 2005/09, and added a specification for |
| 72 |
projects: |
| 73 |
https://www.gentoo.org/glep/glep-0039.html#specification |
| 74 |
This started the conflating of Projects vs Herds ("Herds" appears only |
| 75 |
once, as a remark about them being understaffed). |
| 76 |
|
| 77 |
The biggest gain was that the mail aliases that herds were behind, and |
| 78 |
didn't give much transparency of which maintainers were responsible for |
| 79 |
a herd. Projects made that explicit in public XML instead. |
| 80 |
|
| 81 |
Over time, with some pushing, most herds were moved and/or shoe-horned |
| 82 |
into Projects. |
| 83 |
|
| 84 |
Some of those Herds that became Projects, such as net-mail & pam, were |
| 85 |
never really cohesive groups of maintainers, because the packages, while |
| 86 |
related in some way, could be very different (e.g. qmail was a subherd |
| 87 |
of net-mail, but people who touch the postfix codebase don't want to |
| 88 |
touch the qmail codebase, and I don't blame them as one of the former |
| 89 |
qmail maintainers). |
| 90 |
|
| 91 |
So what should the future be? |
| 92 |
- find a way to keep groups of packages together because it's still |
| 93 |
useful. |
| 94 |
- find a way to mark that the entire group needs a maintainers |
| 95 |
- disband inactive/empty projects |
| 96 |
|
| 97 |
-- |
| 98 |
Robin Hugh Johnson |
| 99 |
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer |
| 100 |
E-Mail : robbat2@g.o |
| 101 |
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 |
| 102 |
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 |
Archives