Date: Mon, 3 May 2021 11:12:59 +0200
From: David Demelier <markand@malikania.fr>
To: ~alpine/devel@lists.alpinelinux.org
Subject: Maintainer merge-request policy needed
Message-ID: <20210503091256.GA5119@raspberrypi>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.10.1 (2018-07-13)

Hi there,

I'm the maintainer of several packages inside the aports tree (mostly in
gaming and audio).

For several times now, I figured out that some of my packages were
modified without my approval nor notifications. To my understanding it
looks like there are no policy regarding what Alpine developers should
do when a merge request is submitted by someone else than the maintainer
itself.

It's definitely fine that someone else provide a merge request for a
package that it is not maintaining, that's the power of opensource
world. It's no longer okay when the maintainer has no words to say, no
way to simply ACK for the modifications.

I'm talking about this merge request:

https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20220

It was submitted on April 6, 10:51 PM and was merged on April 7, 10:14
AM. As you may guess in this very small room I was unable to even have a
look to the request. And as you may know, people do have a life so it's
not on my day-to-day routine to ^F5 the merge requests page in an
infinite loop.

You may say that the merge request is "small enough" to be accepted
as-is but that's not true. Not all upstream developers are following
sane semantic versioning schemes. And even minor upgrades can impact
other sibling packages. This merge request for instance did not
integrate the upgrade of several other RetroArch components such as
retroarch-assets and retroarch-joypad-autoconfig. The upstream team
develop projects separately but they are still coupled together and
that's specifically why a maintainer should always have the final word.
An other example is the couple mercurial/tortoisehg: they do work
together with a same version, this means that the maintainer of
mercurial should be notified and prepared when someone sends a new
version for it because then it can tell to tortoisehg's maintainer to
update its package too (actually I didn't verify if they are different,
but you get the idea).

Later, someone provided a new merge request including a patch to modify
the source code:

https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/20315

Again, no notifications, no approval. Merged without asking me.

I think we need a policy and/or an automatic mail request to the
maintainer when a merge request was sent from someone else (like FreeBSD
does). We also need education about that policy for members who have
write access. Then, we may allow a maintainer-timeout authorization to
merge the request in lack of response. But as-is, if there are no policy
I don't think I'll keep maintaining my packages. One does not simply add
a name into an APKBUILD header.

Now I'd propose to make a maintainer-timeout of two weeks by default
unless an APKBUILD header specifically mentions the opposite. So a merge
request can be accepted if there was no response from the maintainer.

I know there was some discuss on the IRC channel once I stated my
question about my packages but didn't receive any news so far.

Best regards.

-- 
David