Precedence: list
MIME-Version: 1.0
In-Reply-To: <2bea5856-be8d-385c-1e3c-f750e7454db5@affolter-engineering.ch>
References: <2bea5856-be8d-385c-1e3c-f750e7454db5@affolter-engineering.ch>
From: William Pitcock <nenolod@dereferenced.org>
Date: Fri, 2 Jun 2017 13:56:07 -0500
Message-ID: <CA+T2pCFW_v002avKgeN=d+2R-sJXEp16mJcZgK8yVf+dC6=bXA@mail.gmail.com>
Subject: Re: [alpine-devel] aports workflow
To: Fabian Affolter <fabian@affolter-engineering.ch>
Cc: alpine-dev <alpine-devel@lists.alpinelinux.org>
Content-Type: text/plain; charset="UTF-8"

Hi,

On Fri, Jun 2, 2017 at 1:15 AM, 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 ;-)

I apologize for not noticing, I have been busy the past few months.

> 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.
>
> 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.

alpine-aports is mostly dead, github has largely taken over for reviews.
I don't personally like that situation, as it means we are dependent
on a third party for reviews, but will concede that the testing
provided by Travis CI is useful.

> 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.
>
> 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.

We are working on a policy extension that will allow package
maintainers to express their wishes more directly on other
contributors modifying their packages.  Stay tuned on that.

> 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.

In some ways, it's intentional.  We want more people to actually go
through the process of becoming a developer.  We do not intend to
devalue their work, however.

The problem is this hasn't really been documented very effectively.
A good way to go would be to find some pre-existing developer and ping
them in IRC to review and commit your patches.
By working with a specific developer, they can recommend that you are
given developer privileges over time.

> 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.
>
> 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.

The future of Alpine is that there's more people with write access.
It is just a matter of refining the current process to get people into
the funnel of becoming developers.

William


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---