incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: Challenges using Gitbox
Date Wed, 11 Apr 2018 19:56:50 GMT
Hi -


> On Apr 11, 2018, at 11:11 AM, Maxime Beauchemin <maximebeauchemin@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?

Yes - make people committers to have access. People will do the correct thing and work in
their area. If someone doesn’t then it is an SCM and the changes can be reverted.

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

Projects typically have a commits@ or issues@ ML and you can redirect there. Your PPMC members
should follow that list.

The dev@ list is critical for recording decisions.

> 
> 3. The mailing list is a bit dated. I'm saying "a bit" here as an attempt
> to be polite. Maintainers have to sort through spam (AI had solved this a
> decade ago!), it's hard to know how many people and who are signed up, no
> weekly or daily digest-type features, SEO is bad and the list aren't very
> searchable. Something like Google Groups would be a huge step forward here.

Have a look at lists.apache.org <http://lists.apache.org/> which is a searchable archive
of every Apache Mailing list.

The lists are permanent records of the ASF and the Foundation has to maintain these. Relying
on third parties is not within policy.

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

You should have a discussion with Infra about what privileges you are missing and if it is
possible for these to be enabled through GitBox. Perhaps the distinction could be made between
Committer and PPMC member within the LDAP, but I really don’t know.

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

At a minimum the ASF requires that the Apache License is used and that everything is compliant.
This can be difficult. We also have minimal rules for how Releases are done to our shared
and consistent Infrastructure. Once released the software is held by the Foundation for the
public good in perpetuity.

> 
> I hear other software foundations are less opinionated in terms of tooling,
> is that something the ASF should consider? What are the constraints?

The code must be able to be part of the ASF maintained infrastructure. Many years and much
discussion was done in order to accept GitHub.

Infrastructure supports over 250 projects and podlings, consistency is required. Anything
non-standard must be supported by the project. Infra has a quota of one VM per project.

Regards,
Dave


> 
> Cheers!
> 
> Max


Mime
View raw message