New Committers - community

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

New Committers - community

Karl Heinz Marbaise-3
Hi Mickael,

I have separated this thread from the previous one cause this will mixup
things...

On 24/12/18 15:40, Mickael Istria wrote:

> Hi,
>
> On Sunday, December 23, 2018, Stephen Connolly <
> [hidden email]> wrote:
>>
>> If we have good reliable tooling, then we hope to be able to encourage
>> contributions (as you don’t need a CLA for an “obvious” ~10-15 line patch -
>> intent to submit is sufficient) and get the code base more energised.
>>
>
> As a tentative new contributor, I'd like to voice that it seems to me that
> the issues in getting more contributors are not first about code style or
> technologies. (This is based on my experience.in the Eclipse IDE project
> where some components were in a bad shape in term of community activity,
> comparable to how Maven is right now, and managed to get better.)


> While cleaner more modern and more «inclusive» code helps, adapting to
> another code style or older code is still a simple enough exercise for
> contributors to keep motivated and providing code.

> What I feel missing in Maven project to make contributors feel more welcome
> is reactivity and guidance of the core developers towards contributions: it
> takes a lot of time to get feedback on a Jira and a PR, and I had to ping
> contributors to get feedback. I still don't get why my patches are not yet
> merged while feedback seems good.

 > Being that insisting isn't something many
> people can afford or like or dare to do. This lack of apparent interest in
> external contributions is what can kill any open-source project.

I have to summarize this simply.

This is no lack of interest in any kind. It is simply a lack of time of
the committers...cause there is very limited number of committers...


> It also seems like reviewing and testing PRs is not trivial, and that more
> automation could help developers to trust incoming changes and deal with
> reviews.

We already made a large steps into the right direction but this does not
mean to make more of them...

What kind of ideas do you have? To be honest reviewing a PR takes time
and based on my experience no (other) automation will help there..but If
you have ideas please share them...


> So it you want more contributors in Maven,I think the #1 item by far is to
> make sure PRs are reviewed and merged promptly and then that the «time to
> market» between a patch and a release is short enough to not leave time to
> contributors to consider competitve technologies or workarounds they'll
> never contribute back.

> This goes by having a mindset that makes core developers main task to grow
> the community rather than fixing bugs or adding features.

That contradicts some of the feedback we got, cause we get feedback
saying why does it take so long to fix a bug etc...

But of course I do understand your point which is the right direction to
go...


>
> About Maven 4.0, I don't have an opinion and am not enthusiast (that's my
> natural reaction to revolutions over simple evolution). I'm curious about
> what's the added value to produce and whether it's worth the risk and
> effort.

> But again, from my experience with Eclipse IDE,I think it's fundamental to
> get a vibrant and flawless developer community before starting such a
> revolution; and I don't have the impression current Maven community is big
> and agile enough to sustain big changes.

The user community is very big but unfortunately the people who are
willing to help is not that big...

>
> That said, I think Maven already enables some important success criteria,
> like being on GitHub. So I'm confident things can and will improve to grow
> the community.

Over the time it already evolved/grown in several aspects. Maybe not in
the speed we wish it had...

But it takes time...

Kind regards
Karl Heinz Marbaise

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: New Committers - community

Enrico Olivelli
Il sab 29 dic 2018, 12:19 Karl Heinz Marbaise <[hidden email]> ha
scritto:

> Hi Mickael,
>
> On 29/12/18 09:57, Mickael Istria wrote:
> > On Mon, Dec 24, 2018 at 5:21 PM Karl Heinz Marbaise <[hidden email]>
> > wrote:
> >
> >> Hi Mickael,
> >>
> >
> > Hi,
> >
> > I have to summarize this simply.
> >
> > I was confused about how automated tests are running or not. If I look at
> > https://github.com/apache/maven/pull/194 , I do not see any build/test
> > report on the issue. I imagine this requires someone to manually trigger
> > the tests, doesn't it?
> > If it is so, then it could be one step to remove on the review process,
> and
> > the automated build feedback would allow contributors to fix their PRs by
> > themselves before wasting time of a reviewer.
>
> I have started to discuss this with ASF Infra team ...
>
> Lets see if we find a solution...I see currently the issue in the amount
> of repos we have...but lets see...
>

We could use the github pr builder plugin but without automatic trigger, qe
can enable only the 'trigger phrase' so that is it enough for a commiter to
add a comment like 'test this please' in order to start the build and have
immediate feedback on github

Enrico


> Kind regards
> Karl Heinz Marb aise
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --


-- Enrico Olivelli
Reply | Threaded
Open this post in threaded view
|

Re: New Committers - community

Hervé BOUTEMY
In reply to this post by Karl Heinz Marbaise-3
Le samedi 29 décembre 2018, 12:40:20 CET Enrico Olivelli a écrit :

> Il sab 29 dic 2018, 12:37 Mickael Istria <[hidden email]> ha scritto:
> > On Sat, Dec 29, 2018 at 12:01 PM Hervé BOUTEMY <[hidden email]>
> >
> > wrote:
> > > But in both cases, currently, there is no automatic GitHub PR
> >
> > integration:
> > > Maven committers need to create a branch in the official repository to
> > > benefit
> > > from ASF Jenkins build
> >
> > Ah ok, I wasn't aware the GitHub repo was "unofficial" and couldn't be
> > used
> > to trigger builds. That sucks...
>
> Maven migrated to gitbox so actually github is an official repo for Maven.
> I see the same setup in Zookeeper and Bookkeeper and github pr plugin works
> like a charm (and I partecipated in setting it up)
oh great, that would be nice to have the same setup for Maven repos!

>
> Enrico
>
> > Any idea how we could have GitHub PR reviews without this branch creation
> >
> > > by
> > > committers, be it at ASF or somewhere else?
> >
> > Using TravisCI could be a solution.





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: New Committers - community

stephenconnolly
There is a security issue with building PRs automatically.

I can see about adding PR discovery to the existing ASF gitbox plugin, but
we’d need committers to ok the build and have reviewed the code as the PR
could contain attacks to be run from ASF hardware... which is why we don’t
build PRs at present.

Other projects at ASF probably missed this point in the video series
chronicling the development of the plugin...

On Sat 29 Dec 2018 at 13:10, Enrico Olivelli <[hidden email]> wrote:

> Hervè,
> This is the plugin
>
> https://wiki.jenkins.io/display/JENKINS/GitHub+Branch+Source+Plugin?desktop=true&macroName=unmigrated-inline-wiki-markup
>
> I see our "maven-box" is using some special "Scan Apache Hosted Git
> Folder Triggers" source
> (https://builds.apache.org/job/maven-box/configure)
> In the Jenkins of my company in a "Multibranch Pipeline" I have a
> "Branch Sources" box with a "GitHub" option which lets me trigger
> builds by using PRs
>
>
> Enrico
>
> Il giorno sab 29 dic 2018 alle ore 13:43 Hervé BOUTEMY
> <[hidden email]> ha scritto:
> >
> > Le samedi 29 décembre 2018, 12:40:20 CET Enrico Olivelli a écrit :
> > > Il sab 29 dic 2018, 12:37 Mickael Istria <[hidden email]> ha
> scritto:
> > > > On Sat, Dec 29, 2018 at 12:01 PM Hervé BOUTEMY <
> [hidden email]>
> > > >
> > > > wrote:
> > > > > But in both cases, currently, there is no automatic GitHub PR
> > > >
> > > > integration:
> > > > > Maven committers need to create a branch in the official
> repository to
> > > > > benefit
> > > > > from ASF Jenkins build
> > > >
> > > > Ah ok, I wasn't aware the GitHub repo was "unofficial" and couldn't
> be
> > > > used
> > > > to trigger builds. That sucks...
> > >
> > > Maven migrated to gitbox so actually github is an official repo for
> Maven.
> > > I see the same setup in Zookeeper and Bookkeeper and github pr plugin
> works
> > > like a charm (and I partecipated in setting it up)
> > oh great, that would be nice to have the same setup for Maven repos!
> >
> > >
> > > Enrico
> > >
> > > > Any idea how we could have GitHub PR reviews without this branch
> creation
> > > >
> > > > > by
> > > > > committers, be it at ASF or somewhere else?
> > > >
> > > > Using TravisCI could be a solution.
> >
> >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> --
Sent from my phone
Reply | Threaded
Open this post in threaded view
|

Re: New Committers - community

stephenconnolly
On Sat 29 Dec 2018 at 17:16, Enrico Olivelli <[hidden email]> wrote:

> Il sab 29 dic 2018, 17:25 Stephen Connolly <
> [hidden email]>
> ha scritto:
>
> > On Sat 29 Dec 2018 at 16:20, Stephen Connolly <
> > [hidden email]> wrote:
> >
> > >
> > >
> > > On Sat 29 Dec 2018 at 15:18, Enrico Olivelli <[hidden email]>
> > wrote:
> > >
> > >> Il sab 29 dic 2018, 15:17 Stephen Connolly <
> > >> [hidden email]>
> > >> ha scritto:
> > >>
> > >> > There is a security issue with building PRs automatically.
> > >> >
> > >> > I can see about adding PR discovery to the existing ASF gitbox
> plugin,
> > >> but
> > >> > we’d need committers to ok the build and have reviewed the code as
> the
> > >> PR
> > >> > could contain attacks to be run from ASF hardware... which is why we
> > >> don’t
> > >> > build PRs at present.
> > >> >
> > >>
> > >> Now I have to review and then push to ASF repo and I have to tell to
> the
> > >> contributor that I will make CI start.
> > >> IMHO a good tradeoff is:
> > >> - a committer adds a 'test this please' comment, or '@asfbot test this
> > >> please' and then a CI job start
> > >> - this job updates the status line of the PR, with a link to the logs
> > and
> > >> the status of the job
> > >>
> > >> How does it sounds to you?
> > >
> > >
> > > Like it’ll burn through the GitHub api rate limit like crazy.
> >
>
> I did not think we have 100 repos
>
> > >
> > > The committer goes to Jenkins and clicks the build button on the PR job
> > > (which is sitting there ready and waiting), done.
> > >
> >
> > Oh and before I forget, clicking build now I’m Jenkins will update the CI
> > status in GitHub for the PR to say in progress and then provide the
> result
> > when available.
> >
> >
> > > Searching through comments on PRs to find commits with a magic comment
> > > string that haven’t been built by Jenkins is certainly what would be
> > > lovely... but right now it would burn the GitHub rate limit (which is
> > 5,000
> > > requests per hour across the whole ASF) right through.
> > >
> >
> > To be clear, the hard part is efficiently finding “missed” comments and
> > associating with the commit hash they belong to. We don’t want an
> approval
> > to allow attack via an update pushed to the PR. So you have to walk all
> the
> > comments and associate with the commit hash they applied to... gets
> tricky.
> >
>
> Yep, I understand, you are right.
>
> Another option is to have a script to launch:
>
> import-pr maven-assembly-plugin #567
>
> Then the script + Jenkins:
> - bind the pr to a JIRA by scanning git log
> - push to ASF (changing 'committer') with a standard name (JIRA id)
> - start a job
> - add a github status line with a link to the logs
> - bonus: the job will change the status line with green/red light
>
> I already have such kind of script in my company (but for
> bitbucket/JIRA/Jenkins and not for such a complex system like Maven CI),
> but the hard part is the job which has to write the status line
>
> Enrico
>
>
> > We could maybe hijack approval state... but that allows merging by the
> > author.
> >
>
> This part is not clear to me. Only 'commiters' can push to the repo.


Nah. Once committers have approved the PR then the PR can be merged by the
creator of the PR even if not a committer... at least that’s the default
way GitHub PRs work. GitBox *may* be enforcing a stricter permissions
model... but I suspect not (because it makes contributions harder... and
the goal of gitbox was to make working from GitHub a first class experience)




>
>
>
> >
> > >
> > >
> > >>
> > >> Enrico
> > >>
> > >>
> > >> > Other projects at ASF probably missed this point in the video series
> > >> > chronicling the development of the plugin...
> > >> >
> > >> > On Sat 29 Dec 2018 at 13:10, Enrico Olivelli <[hidden email]>
> > >> wrote:
> > >> >
> > >> > > Hervè,
> > >> > > This is the plugin
> > >> > >
> > >> > >
> > >> >
> > >>
> >
> https://wiki.jenkins.io/display/JENKINS/GitHub+Branch+Source+Plugin?desktop=true&macroName=unmigrated-inline-wiki-markup
> > >> > >
> > >> > > I see our "maven-box" is using some special "Scan Apache Hosted
> Git
> > >> > > Folder Triggers" source
> > >> > > (https://builds.apache.org/job/maven-box/configure)
> > >> > > In the Jenkins of my company in a "Multibranch Pipeline" I have a
> > >> > > "Branch Sources" box with a "GitHub" option which lets me trigger
> > >> > > builds by using PRs
> > >> > >
> > >> > >
> > >> > > Enrico
> > >> > >
> > >> > > Il giorno sab 29 dic 2018 alle ore 13:43 Hervé BOUTEMY
> > >> > > <[hidden email]> ha scritto:
> > >> > > >
> > >> > > > Le samedi 29 décembre 2018, 12:40:20 CET Enrico Olivelli a
> écrit :
> > >> > > > > Il sab 29 dic 2018, 12:37 Mickael Istria <[hidden email]>
> > ha
> > >> > > scritto:
> > >> > > > > > On Sat, Dec 29, 2018 at 12:01 PM Hervé BOUTEMY <
> > >> > > [hidden email]>
> > >> > > > > >
> > >> > > > > > wrote:
> > >> > > > > > > But in both cases, currently, there is no automatic GitHub
> > PR
> > >> > > > > >
> > >> > > > > > integration:
> > >> > > > > > > Maven committers need to create a branch in the official
> > >> > > repository to
> > >> > > > > > > benefit
> > >> > > > > > > from ASF Jenkins build
> > >> > > > > >
> > >> > > > > > Ah ok, I wasn't aware the GitHub repo was "unofficial" and
> > >> couldn't
> > >> > > be
> > >> > > > > > used
> > >> > > > > > to trigger builds. That sucks...
> > >> > > > >
> > >> > > > > Maven migrated to gitbox so actually github is an official
> repo
> > >> for
> > >> > > Maven.
> > >> > > > > I see the same setup in Zookeeper and Bookkeeper and github pr
> > >> plugin
> > >> > > works
> > >> > > > > like a charm (and I partecipated in setting it up)
> > >> > > > oh great, that would be nice to have the same setup for Maven
> > repos!
> > >> > > >
> > >> > > > >
> > >> > > > > Enrico
> > >> > > > >
> > >> > > > > > Any idea how we could have GitHub PR reviews without this
> > branch
> > >> > > creation
> > >> > > > > >
> > >> > > > > > > by
> > >> > > > > > > committers, be it at ASF or somewhere else?
> > >> > > > > >
> > >> > > > > > Using TravisCI could be a solution.
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> ---------------------------------------------------------------------
> > >> > > > To unsubscribe, e-mail: [hidden email]
> > >> > > > For additional commands, e-mail: [hidden email]
> > >> > > >
> > >> > >
> > >> > >
> > ---------------------------------------------------------------------
> > >> > > To unsubscribe, e-mail: [hidden email]
> > >> > > For additional commands, e-mail: [hidden email]
> > >> > >
> > >> > > --
> > >> > Sent from my phone
> > >> >
> > >> --
> > >>
> > >>
> > >> -- Enrico Olivelli
> > >>
> > > --
> > > Sent from my phone
> > >
> > --
> > Sent from my phone
> >
> --
>
>
> -- Enrico Olivelli
>
--
Sent from my phone
Reply | Threaded
Open this post in threaded view
|

Re: New Committers - community

stephenconnolly
On Sat, 29 Dec 2018 at 18:56, Vladimir Sitnikov <[hidden email]>
wrote:

> Stephen> Well on other GitHub orgs i’ve seen PR author has Merge
> button once PR is
> Stephen> approved by someone with push rights to the repo... until
> they add a commit
> Stephen> or the merge result changes
>
> It does not work the way you describe.
>
> 1) By default GitHub defaults to "Base permissions" == "read".
> Administrator can set even "base permissions == admin", however that
> is not something that comes by default.
> 2) Repository administrator can configure a branch so it requires a PR
> approval before merge (see
>
> https://help.github.com/articles/enabling-required-reviews-for-pull-requests/
> )
>
> It might happen so that "author has Merge button" is a case when
> repository was configured with "default=write" permissions + "require
> PR approval".
> Indeed that should produce (I have not checked) the behavior you
> describe, however it was never a default mode for GiHub.
>
>
Are you sure? I have lots of repos on different orgs that I am in and for
almost all of them, if the repo is one where I only have read access I can
create the PR but the merge button is unavailable... until the PR is
approved by somebody *who has write permission*... at which point the merge
button magically becomes available to me...

Now you have to know to look out for it, because typically the owner of the
repo approves and then merges the PR in one go... and if I add a new commit
or resolve a merge conflict I lose the merge button until re-approved.

But for some organizations I am involved with, we have the culture of
allowing you to self-merge.

Oh and I know for a fact that these are at least some repos that do not
have branch protection turned on.


> Vladimir
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: New Committers - community

Tibor Digana
In reply to this post by Karl Heinz Marbaise-3
Why the build cannot be triggered on GitHub or PR?
It's only a URL.
If you see the frequency of PRs in Surefire, 1 or 2 PRs/month, this should
not be a problem since the Windows build takes 1.5 hour and Linux 1 hour.
Taking JDK 7 and 11, and one Maven version (3.5) is usually enough on Git
branches and should be fine for PRs as well.

On Thu, Jan 3, 2019 at 10:19 PM Stephen Connolly <
[hidden email]> wrote:

> On Thu 3 Jan 2019 at 20:52, Tibor Digana <[hidden email]> wrote:
>
> > I already lost the point of this thread.
> > Still the disk space problem on Windows executors in ASF Jenkins?
> > If it's this issue, then why the workspace is not investigated directly
> on
> > the system with remote access?
> > Jenkins is very good tool and I do not want to use Travis but Travis is
> one
> > step after finding the root cause.
>
>
> We’re not going to be able to use Travis for Surefire (unless we have a
> “fast” suite of tests)
>
> That doesn’t mean we cannot use Travis for the 90 other repos we have in
> order to get test results of PRs from non-committers.
>
>
> > T
> >
> > On Thu, Jan 3, 2019 at 8:39 PM Stephen Connolly <
> > [hidden email]> wrote:
> >
> > > On Thu 3 Jan 2019 at 18:03, Enrico Olivelli <[hidden email]>
> wrote:
> > >
> > > > Il gio 3 gen 2019, 17:38 Mickael Istria <[hidden email]> ha
> > scritto:
> > > >
> > > > > Hi,
> > > > >
> > > > > I think this discussion is diverging into "trying TravisCI for some
> > > > > plugins" and is loosing focus on the initial question of how to
> > improve
> > > > the
> > > > > build+test flow to get faster feedback as a contributor or as a
> > > reviewer.
> > >
> > >
> > > Travis will get the build+test flow faster for non-committers.
> > >
> > >
> > > > > Can the GitHub PR builder plugin be enabled on Maven Core ?
> > >
> > >
> > > No, it’s not compatible with how we build, as currently we only build
> > from
> > > gitbox not from GitHub so there is no link for Jenkins to see
> > >
> > >
> > > Committers
> > > > > would be allowed to trigger a test with a single comment once they
> > > > checked
> > > > > it doesn't cause a security flaw.
> > > > >
> > > >
> > > > It turns out that it is not simple as it could seem because we have
> > > custom
> > > > Jenkins plugins to scan all the repos and have a common
> configuration,
> > so
> > > > in order to achieve such goal we need to enhance that plugin, please
> > > > Stephen correct me if I am wrong.
> > >
> > >
> > > Yep I need to enhance the plugin a little... just trying to clear stuff
> > off
> > > my plate
> > >
> > >
> > > > Travis jumped on this train because it is easy to enable and it is
> very
> > > > widespread, and it leaves security problems out of ASF infra.
> > > > But a check with Travis won't ever cover all jobs we are actually
> > > starting
> > > > per-branch.
> > > > It can be a good compromise to start, but if we have resources to
> > improve
> > > > current integration this will be the best choice for the mid term.
> > > >
> > > > Enrico
> > > >
> > > > >
> > > > > Cheers,
> > > > >
> > > > --
> > > >
> > > >
> > > > -- Enrico Olivelli
> > > >
> > > --
> > > Sent from my phone
> > >
> >
> --
> Sent from my phone
>