Received: from magnesium.8pit.net (magnesium.8pit.net [45.76.88.171]) by nld3-dev1.alpinelinux.org (Postfix) with ESMTPS id CF01D781BAC for <~alpine/devel@lists.alpinelinux.org>; Sun, 27 Oct 2019 16:15:28 +0000 (UTC) Received: from localhost (ip4d14d438.dynamic.kabel-deutschland.de [77.20.212.56]) by magnesium.8pit.net (OpenSMTPD) with ESMTPSA id d28ecc91 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:YES) for <~alpine/devel@lists.alpinelinux.org>; Sun, 27 Oct 2019 17:15:28 +0100 (CET) Date: Sun, 27 Oct 2019 17:15:24 +0100 To: ~alpine/devel@lists.alpinelinux.org Subject: Re: Alpine community governance From: =?UTF-8?Q?S=C3=B6ren?= Tempel References: <5152c7bd5e788aadfb987281a47107a4f3959860.camel@cogitri.dev> In-Reply-To: <5152c7bd5e788aadfb987281a47107a4f3959860.camel@cogitri.dev> Message-Id: <2HW3TY8QZIYUE.3N08DKW6AEFNN@8pit.net> User-Agent: Mutt/1.6.0.1 (2016-04-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Rasmus Thomsen wrote: > Hm, although that does sound like it'd significantly lessen the > workload on core member I dislike this approach, at least with how we > currently handle maintainership of packages. To move my discussion contribution from the IRC to the ML: IMHO we should rethink the aport maintainer role in general. Many package maintainer comments are horribly outdated and contain contact information of people who haven't committed in the past few years. Some packages (even in main/ and community/) don't even have a maintainer comment. Even packages with accurate maintainer comments are often poorly maintained, by the person maintained in the maintainer comment, i.e. updates are done by different developers et cetera. In my ideal scenario package upgrades would always be done by the maintainer (would also reduce the patch queue as trivial package upgrades are no longer part of it). It should also be possible to contact the maintainer regarding issues with the aport and the maintainer should be responsible for reviewing patches submitted to GitLab/GitHub/Patchwork. Currently, the maintainer is just some person who added their contact information to the aport at some point in time. Debian, for instance, has a very elaborate process for this sort of thing which might help avoiding some of these pitfalls [0]. > Maybe just having somewhat strict CI rules and only allowing a merge > if CI passes would do the trick to ensure QA is done though. I disagree, I don't think CI rules can ever be good enough to catch any sort of mistakes that a manual review might find. Also consider malicious patches added to an aport, et cetera. Cheers, S=C3=B6ren [0]: https://wiki.debian.org/DebianMaintainer#Becoming_a_Debian_Maintainer