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.

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.

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.

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.

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.

Kind regards,

Fabian

Hi,

> On 2 Jun 2017, at 08:15, 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.

The continuous integration is really nice IMO, and definitely a big upside.
I’m personally a big fan of GitHub PRs for contributions as they significantly
lower the bar for new and continuous contributions.

> 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.

Some perspective on this: when I started working on them we steadied them at
around 100. It’s mostly because of the release stuff the past few weeks that
they seem to have jumped much higher. I don’t have much historical data though,
so maybe that lower number was just a fluke. :)

> 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.
> 
> 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.

I entirely agree with this, and bypassing existing work is somewhat of an
issue and doesn’t do much to help the community. I think maintainers and
developers should be trained to look at existing PRs FIRST, and only then
try to do stuff that scratches their itch themselves.

Otherwise, it just makes Alpine feel like a private club of people doing
their own stuff which you are ~allowed~ to contribute to if they feel
like it, instead of a community, as is intended with the community and
testing repos at the very least.

I’ll admit that the recent release rush has been kind of tiring in the
sense that I did not feel like looking at PRs aside from the other work
that was happening. Maybe there’s room for different tasks there? Maybe
we need to branch 3.6 earlier and work on there, while still being able
to merge new stuff/updates that are too late for 3.6 in edge?

> 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.

Aside from what I said above, I’d like to see input from others as well
how we could best address this. Now that 3.6 is out of the door, we should
be able to focus more on reviewing and merging contributions again instead
of rushing work to get done in time.

> Kind regards,
> 
> Fabian

Thanks for airing your grievances, I’m sorry that they weren’t properly
heard on IRC. We can only improve as a project by looking critically at
ourselves.

- Shiz

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
---

Hi

On Fri, Jun 02, 2017 at 08:15:59AM +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 ;-)
 
I don't say that everything is fine, but the mailinglist/patchwork
workflow is just awesome. I never have to wait long for an answer and
everything rolls smooth. Probably the best experience I had in any
foss-project. 

I maintain about 10 packages, that means I have urlwatch-cron-scripts
running for these packages, which will send me mails, when there is an
update.

It seems like github is aside of the main development. I do all my
work: professional and personal on github. While it is great, I would
change to use the mailinglist/patchwork approach in a second. At
least for very active projects. Again I don't say don't do github, but
for the kind of workflow Alpine does, patchwork seems to fit better.

!! I also have to say I never used patchwork as a commiter, only a
submitter.

I just wanted to say how happy I am, to add another piece of
information to this discussion.

Best,
    Jean-Louis

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
---