Date: Fri, 16 Jun 2017 09:30:26 +0200
From: Natanael Copa <ncopa@alpinelinux.org>
To: Fabian Affolter <fabian@affolter-engineering.ch>
Cc: alpine-devel@lists.alpinelinux.org
Subject: Re: [alpine-devel] aports workflow
Message-ID: <20170616093026.340c1043@ncopa-desktop.copa.dup.pw>
In-Reply-To: <2bea5856-be8d-385c-1e3c-f750e7454db5@affolter-engineering.ch>
References: <2bea5856-be8d-385c-1e3c-f750e7454db5@affolter-engineering.ch>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

Hi Fabian.

Sorry for late response.

On Fri, 2 Jun 2017 08:15:59 +0200
Fabian Affolter <fabian@affolter-engineering.ch> 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.

-nc


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?



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---