On Wed, Apr 11, 2018 at 11:11 AM, Maxime Beauchemin <
maximebeauche...@gmail.com> wrote:
> Hi general@incubator!
>
> This is an email discussing the challenges we are facing while using Github
> / Gitbox for our ASF project and wanted to start a thread to discuss
> solutions and ways we can mitigate.
>
> We're very grateful for Gitbox, but here are the challenges we're facing
> with it:
>
> 1. Our PMs are not committers, so they can't do simple things as labeling
> issues, closing issues and assigning issues to people. We need either for
> them to have write access to Github, or for them to get some sort of
> special committer status so they can get write access. Is voting PMs as
> committers the solution here?
>
Why not make them committers?
Seriously. It sounds like the project needs and wants them to do stuff that
requires committer-fu. What possible reason is there not to give it to them?
> 2. From what I gather using Github issues as a replacement for Jira is ok
> as long as we set Github notifications to be sent to the mailing list. The
> problem is that this makes our mailing list unusable for other purposes
> than getting spammed out of our minds with Github notifications. I think
> the solution would be to standardize on 2 mailing lists:
> `github-notifications@{project}.apache.org` and the good old `dev@`.
> Though
> for early adopters `dev@` is probably busted as people have filters set up
> against it already. So is the solution to create another list and get
> everyone to sign up for it?
>
Can't you tone down the notifications to dev@ and arrange for all
notifications to be sent to notifications@?
I am asking because I don't know if it is possible.
> 3. The mailing list is a bit dated.
Totally true. Pony helps a bit: https://lists.apache.org/
But not all that much.
Spam shouldn't be much of a problem (it isn't on other lists that I have
been part of). Aside from self-inflicted spam like notifications, that is.
SE is definitely poor. Pony makes the list more searchable, but not as well
as a Google thing.
> 4. Github ecosystem services (build systems, code quality services, code
> coverage services, version manager, ...) are hard and sometimes impossible
> to setup (without admin Github privileges), forcing us to open INFRA Jira
> tickets for this. I understand the limitations here, and a lot of it is on
> the Github side, but would like to think of ways to mitigate this, perhaps
> by using specified "main-forks" where committers have more control? Just a
> list of "Apache Approved Github-services" would help.
>
Ask infra. My experience is that this stabilizes pretty quickly with
limited requests after a break-in period.
That means that the current infra-centric arrangement is painful a bit at
first, but it declines in prominence pretty quickly.
> The ASF is all about helping growing communities, and making committers as
> productive as can be should be a top priority. Joining the ASF shouldn't
> make governance harder.
>
Well.... actually ASF is, in many ways, all about certain downstream
consumers of software and, in particular, about certain governance
guarantees. The support of communities is a derived goal because the
downstream is best served by having robust communities.
As such, joining ASF is *absolutely* going to make some aspects of
governance considerably harder.
That said, the tooling shouldn't be vastly harder.
I hear other software foundations are less opinionated in terms of tooling,
> is that something the ASF should consider? What are the constraints?
The core constraints are (roughly, probably not quite complete):
1) downstream consumers of source code releases have comfort around
dependency risks and licensing
2) Apache has "good enough" provenance on essentially every line of code.
3) Apache is open and historically transparent with respect to decision
making. Open across time zones and presence.
4) Failures or adverse takeovers of non-Apache entities will not compromise
the mission of Apache
5) Apache doesn't run with professional fundraisers out beating the bushes
(this isn't really an axiom as much as a consequence)
6) Contributors, committers and members are all individuals and participate
as such. This is in contrast to foundations where corporations are members.
It also relates to the fact that Apache is a charity rather than a trade
organization.
Item (1) is where the licensing limitations and signing and release
policies come from.
Item (2) was one of the major sticking points with github because it was
hard to understand how much confidence we could have about who checked in
code.
Item (3) is where the mailing list rules and voting practices come from.
Item (4) is where the reticence about using external services for mailing
lists and ticketing comes from.
Item (5) limits the bandwidth and special purpose tooling that any single
project can expect to have created and maintained.
Item (6) is why a company has trouble getting things done if the committers
on a project don't work for them any more.
I don't think that this is as detailed as you need, but I think it might
help make things make more sense.
