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
Hi David,
I mostly agree with you, but I think that 2 weeks is too long time (consider security fixes). However, now I wanted to comment on something else from your email.
> 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.
That’s specifically why a maintainer should always add documentation comments into APKBUILD! If you, as a maintainer, have a knowledge of some non-standard/unexpected and non-obvious thing important for the future upgrades, you should document it (for example [1]). Also, if some dependencies are tightly coupled, you should specify the required version range (e.g. `depends="foo>=3.5.0"` or `depends="foo=~3.5.5"`).
Maintainers should share important knowledge (comments in APKBUILD) and document all non-obvious changes (commit messages), not keep it for themselves.
Jakub J.
[1]: https://gitlab.alpinelinux.org/alpine/aports/-/blob/1652cb6a8c604406ec9fd525b9cd4a80185b9558/community/kea/APKBUILD#L6-8
On 5/3/21 11:12 AM, David Demelier wrote:
> 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.>
On Mon, May 03, 2021 at 12:37:15PM +0200, Jakub Jirutka wrote:
> Hi David,> > I mostly agree with you, but I think that 2 weeks is too long time
I think this could be discussed but two weeks can be very short too. If
someone is on a vacation it may not have any kind of time to review a
merge request depending on the change.
Perhaps we can set a number of timeout depending on the nature of the
merge request.
> That’s specifically why a maintainer should always add documentation> comments into APKBUILD! If you, as a maintainer, have a knowledge of> some non-standard/unexpected and non-obvious thing important for the> future upgrades, you should document it (for example [1]). Also, if> some dependencies are tightly coupled, you should specify the required> version range (e.g. `depends="foo>=3.5.0"` or `depends="foo=~3.5.5"`).> > Maintainers should share important knowledge (comments in APKBUILD)> and document all non-obvious changes (commit messages), not keep it> for themselves.
You're entirely right on that point. I'll also update my APKBUILD to
include any useful notes too.
PS: you seemed have replied only to me so I add a CC to the list because
you've shared interesting points as well.
--
David