Re: New Committers - community

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

Re: New Committers - community

michaelo
Am 2018-12-24 um 17:21 schrieb Karl Heinz Marbaise:

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

This is something I exprience myself, in the last couple of months I
bare had time to do anything for Maven. I do not intend to briskly pass
an PR. Many PRs require deep understanding of the code as well as the
issue and the proposed fixed. It may take several days to assess that.

It'd be great if we could have at least one paid dev just like Mark
Thomas for Tomcat.

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

Absolutely, it pretty much seems that people take Maven for granted
because there are some other "idiots" who will solve my build problem.
I can give an example, my employer has 300 000+ employees, thousands of
devs, a lot of them are using Maven and other ASF stuff, I am one of a
few who are contributing to ASF code. That's pretty weak. I guess this
applies to most companies from the "old" world.

Michael


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

Mickael Istria-2
On Mon, Dec 24, 2018 at 5:21 PM Karl Heinz Marbaise <[hidden email]>
wrote:

> Hi Mickael,
>

Hi,

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

I understand that, and I hope I was explicit enough when I was talking
about the *perception* of contributions receiving low interest, as opposed
to the reality you mention which is about lack of resources compared to
backlog.
In this case, some time ago, when Eclipse was in a similar position, we did
collectively decide to make external contributions higher priority than our
own work for a few months. This did have a very positive impact in growing
the community, recruiting more developers, more committers, and also
changing the mindset of most current committers to think more and more
about incoming contributors and plan some time for the reviews, and
prioritize community over development in some cases; because ultimately,
the community makes the project alive more than its feature set.



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

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.


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

I know that. It's also something we hear often in Eclipse and I guess
something the majority of serious OSS projects face often.
But it's OSS, people who need a fix should be ready to invest in it; and
someone who's finding a bug long to fix is actually someone that can be
turned as a contributor for their own bug ;)

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

Same as above ;)

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

I have good hope it's worth it ;)
--
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>
Reply | Threaded
Open this post in threaded view
|

Re: New Committers - community

Enrico Olivelli
In reply to this post by michaelo
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]

Reply | Threaded
Open this post in threaded view
|

Re: New Committers - community

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

The committer goes to Jenkins and clicks the build button on the PR job
(which is sitting there ready and waiting), done.

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.



>
> 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
Reply | Threaded
Open this post in threaded view
|

Re: New Committers - community

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

We could maybe hijack approval state... but that allows merging by the
author.


>
>
>>
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: New Committers - community

stephenconnolly
On Sat, 29 Dec 2018 at 20:41, Mickael Istria <[hidden email]> wrote:

> I'mglad to see that PR build/merge discussed, it seems to have a good
> potential value for many in simplifying it.
>
> FWIW, at Eclipse Foundation, similar questions were faced and risks
> identified. The result is that at the moment, all PRs from anyone can be
> built on Eclipse infra without much visible restriction. The Foundation
> might have extra guards under the hood but it's not something we developers
> need to care about.
> While this is probably unsafe, it's so far so good. We weren't warned by
> the Foundation about malicious usage of this permissive access to build
> machines.
>

As one of the primary developers of Jenkins and as a member of the Jenkins
CERT team I cannot and do not endorse that viewpoint. Unless and until ASF
infra has throw-away build machines, I do not recommend running CI builds
of PRs from unknown actors (it being trivial to set up a throw-away GitHub
account) on the ASF dedicated build agents. Eclipse is being fools if they
are allowing similar.


> AFAIK, there is no issue from developer POV about GitHub API rates limit.
> I suggest the Apache infra team gets in touch with Eclipse Foundation one
> to sort out whether similar configurations could be implemented in a
> safe-enough way.
>
> The GitHub PR builder plugin already has support for whitelisting users and
> giving them ability to trigger a build from a non-whitelidsted contributor
> with a single «test PR» comment or similar.
> Then build progress and report are reported as expected.
> And, again, TravisCI also does the same in a decent way, with the benefit
> of worrying less about underlying infra and security, and only drawback of
> being discoupled from a specific infra (is it really a drawback?)
>

I think we could easily use TravisCI or one of the cloud CI vendors to
perform trial builds of PRs on GitHub. What is of importance to the ASF is
that the build of ASF hosted code are on ASF hosted hardware... until the
PR is merged it is not ASF hosted code, it exists only on GitHub.


>
> Cheers,
>
>
> --
> Mickael Istria
> Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
> developer, for Red Hat Developers <https://developers.redhat.com/>
>
Reply | Threaded
Open this post in threaded view
|

Re: New Committers - community

Vladimir Sitnikov
In reply to this post by stephenconnolly
Stephen > Are you sure?

I've just created a dummy account and "approval" does not make merge button magically appear.

If you have a couple of minutes, please make a PR (I'll approve it shortly) to https://github.com/vlsi/KE-complex_modifications
Note: you can click "edit" button in GitHub UI for a random file, so you don't really need to clone the project.

I've attached no_merge.png which is a screenshot of GitHub UI for PR author. Apparently, there's no merge button.

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

Mickael Istria-2
In reply to this post by stephenconnolly
On Saturday, December 29, 2018, Stephen Connolly <
[hidden email]> wrote:
>
> I think we could easily use TravisCI or one of the cloud CI vendors to
> perform trial builds of PRs on GitHub.


Good. So at this point, it's only a matter of writing a .travis.yaml file
in the repo, or is there anything else missing?


> What is of importance to the ASF is
> that the build of ASF hosted code are on ASF hosted hardware... until the
> PR is merged it is not ASF hosted code, it exists only on GitHub.
>

From contributor and user POV, I think where the software is built and
where the code is hosted isn't important. So no issue if it's on ASF
Jenkins and hardware, but for PR trials, it seems like a constraint it'd be
sane to get rid of.


--
Mickael Istria
Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
developer, for Red Hat Developers <https://developers.redhat.com/>
Reply | Threaded
Open this post in threaded view
|

Re: New Committers - community

Enrico Olivelli
Il giorno mer 2 gen 2019 alle ore 15:12 Vladimir Sitnikov
<[hidden email]> ha scritto:
>
> Enrico> Probably Travis won't be able to run our ITs, at least the free
> version
>
> Why do you think so?

Because Maven CI jobs are huge. For instance maven-surefire
integration tests take 2 hours.
In general I see Travis (free edition) does not offer many resources.

I would like to try to setup Travis for some "small" plugin and make
some test, at least testing java 11 + Linux

Enrico

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

Vladimir Sitnikov
Enrico> For instance maven-surefire
integration tests take 2 hours.
In general I see Travis (free edition) does not offer many resources.

Each Travis job is limited by 50 minutes, however one can split tests into
multiple jobs, so it will run fine.

Vladimir
Reply | Threaded
Open this post in threaded view
|

Re: New Committers - community

Enrico Olivelli
Il giorno mer 2 gen 2019 alle ore 15:34 Vladimir Sitnikov
<[hidden email]> ha scritto:
>
> Enrico> For instance maven-surefire
> integration tests take 2 hours.
> In general I see Travis (free edition) does not offer many resources.
>
> Each Travis job is limited by 50 minutes, however one can split tests into
> multiple jobs, so it will run fine.

I guess it won't be easy.
Maven integration testing is very complex, it's Maven launching Maven itself.
We will need to improve maven-invoker plugin, I don't know if there is
support for something like JUnit categories.
We can run only "unit tests" and this will be a minimal "feedback" for
the contributor.
For simpler plugins, like "checkstyle", I think Travis would be a good
choice, at least I would give it a try

Enrico

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

Mickael Istria-2
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.
Can the GitHub PR builder plugin be enabled on Maven Core ? Committers
would be allowed to trigger a test with a single comment once they checked
it doesn't cause a security flaw.

Cheers,
Reply | Threaded
Open this post in threaded view
|

Re: New Committers - community

Enrico Olivelli
Il gio 3 gen 2019, 21:52 Tibor Digana <[hidden email]> ha scritto:

> I already lost the point of this thread.
>

We are trying to figure out how to give better support for new
contributions, the first point is to give feedback as soon as possible (an
automatic build is the top)

Enrico


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


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

Re: New Committers - community

stephenconnolly
In reply to this post by Mickael Istria-2
On Thu 3 Jan 2019 at 21:37, Tibor Digana <[hidden email]> wrote:

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


1. The current branch source only discovers branches in gitbox, it doesn’t
discover PRs on GitHub.

2. PRs on GitHub can have “untrusted” code, which shouldn’t be run within
the ASF hardware without review by a committer.

#1 can be solved by me enhancing the Jenkins plugin we use

#2 either means asking committers to trigger builds after reviewing (which
is a manual step and manual steps get forgotten)

So instead we get Travis to do a first round CI for the PRs on GitHub. Then
we can still have #1 and #2 as final pre-merge confirmation... but Travis
gives the contributor immediate feedback on their contribution and that
helps grow the community.


>
> 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
> >
>
--
Sent from my phone