Mail archive

Re: [alpine-devel] aports workflow

From: Natanael Copa <>
Date: Fri, 16 Jun 2017 09:30:26 +0200

Hi Fabian.

Sorry for late response.

On Fri, 2 Jun 2017 08:15:59 +0200
Fabian Affolter <> wrote:

> Hi all,
> A while ago I brought this topic up on IRC but I go pretty much ignored.
> Well, my frustration raised again to a certain level ;-)
> It's about the aports and the workflow for people with no write access.
> I like Github's PR approach and to have some kind of QA with Travis.
> Especially if your not always on top of what's changed in AL, switching
> between distributions and their packaging mechanisms, and your build env
> is not always as clean as it should be.

How about a disposable build env (with docker?)

We are also working on being able to build a package in a chroot
(abuild rootbld). That project is blocking no me :-/

> There are over 200 open PRs (sure, some are no obsolete in the meantime
> as they are open for over 6 months). I don't how it looks like on the
> alpine-aports mailing list.

Yes. We are having problem with keeping up.

Specially right before we did the 3.6 release I simply stopped merge
things in testing because we were making release.

The patch queue should been cleaned up a bit now.

> My problem with the current approach is that I do the work, then
> nothing happens, and at the end it must be discarded because somebody
> with write access commited his/her work directly.

Yes, this is not good.

Problem here is that it takes a certain amount of work to maintain
1000+ packages. If you for every package you want upgrade need to first
check github PR and alpine-aports mailinglist before you upgrade
anything, then, well, the work increases.

I am trying to check those before I upgrade anything, but sometimes i
miss. Sorry.

> Sure, one could say that you should keep your hands of packages which
> don't contain your name as maintainer. If that thought crossed your mind
> then...let me stop here before I say something I will regret later about
> community, open source, common goal, etc.
> A fact is that the current state is massively devaluing the work of the
> community and pushing the two class society (write access/no write
> access) further.
> Just to be clear this is not a one-time thing and I doubt that I'm the
> only one that's affected. Think about how you would feel when we would
> switch places and the only response you will get is "was already done"
> or something similar to that while the time line shows that you did the
> work first.

Yes. This is not good. I fully understand that it is demotivating.
> Complaining is easy but without complaining there is no progress. As a
> person with write access you may see the whole thing differently but
> change your perspective for a minute and think about how the impact on
> the future of Al could be.

Any suggestions how to improve things?

A few things that comes to my mind:

- add more people with git push access

- tag maintainer patches (maintainers without git push access) so they
  are visible and can be fast tracked.

- tag trivial/minor updates so they can be fast-tracked.

- have some script that automatically merges "fast-tracked" patches
  into a separate branch. That way the committer can pull everything in
  one pull instead of clicking himself to deatch for dealing with 100+
  individiaul PRs. (i spent 2 days clicking myself in the slow github
  web if to merge the ~100 "modernize" PRs)

In any case. I am very thankful that you are willing to help us
maintain a lot of packages.


PS. i kinda liked when you sent a PR with a long list of commits
instead of dealing with 1 PR per commit. I know others may disagree and
want do more careful review. Maybe a middle ground could be group your
PRs a bit, so there are groups of 5-10 commies per PR?

Received on Fri Jun 16 2017 - 09:30:26 UTC