Moving Groovy to a Foundation

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
199 messages Options
1 ... 17181920
Reply | Threaded
Open this post in threaded view
|

Re: Moving Groovy to a Foundation

Emmanuel Lecharny


On Tue, Mar 3, 2015 at 9:23 PM, Paco Zarate <[hidden email]> wrote:
For the foundation (Apache/Eclipse) guys, i would have another question:

One of the concerns that I had with any project joining a Foundation (in particular for a project coming from a Company) is that the Foundation can be seen as a "retirement home".

At the ASF, as you have to go through incubation, you can be sure that a stalled project will never make it to the TLP nirvana.


I think that the fact that Groovy has been working as an open source project for years helps to be in good shape in this transition. And I see now that joining a  Foundation is an excellent way of maximizing the opportunities to stay as a healthy project. But what do you recommend to the projects that do this change? Do you do some tasks to identify stalled projects?

Incubator is a good test bed.
 
how to promote the projects to have new committers?

If your project is already established, then it's not really a problem : your communication channels are already existing, I don't see that as such a problem.
 
Do the committers should be now apache/eclipse committers?

That's the existing Groovy commiter's choice. They provide a list of those who deserves to be Apache Committer, and if they accept, they are made committers.
 
or keep the Github way? (i would strongly suggest to keep the Github process working and make it clear that Github will be still the place to receiving changes)

I think this question has been answered previously.
Reply | Threaded
Open this post in threaded view
|

Re: Moving Groovy to a Foundation

Roman Shaposhnik
Content-Type: text/plain; charset=UTF-8

Just to pile on top of the excellent answer by Emmanuel:

On Tue, Mar 3, 2015 at 3:40 PM, Emmanuel Lecharny <[hidden email]> wrote:

> On Tue, Mar 3, 2015 at 9:23 PM, Paco Zarate <[hidden email]>
>> I think that the fact that Groovy has been working as an open source
>> project for years helps to be in good shape in this transition. And I see
>> now that joining a  Foundation is an excellent way of maximizing the
>> opportunities to stay as a healthy project. But what do you recommend to the
>> projects that do this change? Do you do some tasks to identify stalled
>> projects?
>
>
> Incubator is a good test bed.

And in steady state all TLPs are submitting reports to the ASF board directors.
The board takes project health very, very seriously.

Thanks,
Roman.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Moving Groovy to a Foundation

Thibault Kruse
By the way, it seems right that the github "mirror" repo for Groovy
might better remain as is, instead of having groovy on github hosted
under the apache organisation:

http://apache-wicket.1842946.n4.nabble.com/core-devs-cannot-close-PRs-on-github-td4669946.html

This is independent of the "true" hosting at Apache.


On Wed, Mar 4, 2015 at 2:19 AM, Roman Shaposhnik <[hidden email]> wrote:

> Content-Type: text/plain; charset=UTF-8
>
> Just to pile on top of the excellent answer by Emmanuel:
>
> On Tue, Mar 3, 2015 at 3:40 PM, Emmanuel Lecharny <[hidden email]> wrote:
>> On Tue, Mar 3, 2015 at 9:23 PM, Paco Zarate <[hidden email]>
>>> I think that the fact that Groovy has been working as an open source
>>> project for years helps to be in good shape in this transition. And I see
>>> now that joining a  Foundation is an excellent way of maximizing the
>>> opportunities to stay as a healthy project. But what do you recommend to the
>>> projects that do this change? Do you do some tasks to identify stalled
>>> projects?
>>
>>
>> Incubator is a good test bed.
>
> And in steady state all TLPs are submitting reports to the ASF board directors.
> The board takes project health very, very seriously.
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Moving Groovy to a Foundation

Jochen Theodorou
Am 16.03.2015 16:21, schrieb Thibault Kruse:
> By the way, it seems right that the github "mirror" repo for Groovy
> might better remain as is, instead of having groovy on github hosted
> under the apache organisation:
>
> http://apache-wicket.1842946.n4.nabble.com/core-devs-cannot-close-PRs-on-github-td4669946.html
>
> This is independent of the "true" hosting at Apache.

uh, we can't close pull requests on our own anymore then? That's indeed
a problem. Afaik we have to move the repo under the apache organization.

bye blackdrag

--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Moving Groovy to a Foundation

Jochen Theodorou
Am 16.03.2015 16:46, schrieb Jochen Theodorou:

> Am 16.03.2015 16:21, schrieb Thibault Kruse:
>> By the way, it seems right that the github "mirror" repo for Groovy
>> might better remain as is, instead of having groovy on github hosted
>> under the apache organisation:
>>
>> http://apache-wicket.1842946.n4.nabble.com/core-devs-cannot-close-PRs-on-github-td4669946.html
>>
>>
>> This is independent of the "true" hosting at Apache.
>
> uh, we can't close pull requests on our own anymore then? That's indeed
> a problem. Afaik we have to move the repo under the apache organization.

see https://help.github.com/articles/closing-issues-via-commit-messages/

bye blackdrag


--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Moving Groovy to a Foundation

Winnebeck, Jason
In reply to this post by Jochen Theodorou
The reply did say if the pull request was done in the "git way" that the PR would be automatically closed. I am hoping that means if it's gone with a git pull (so that the changesets are actually merged in), then it works, whereas if the changes were manually copied over and applied it wouldn't work because Github wouldn't know that the changesets made it in.

I suppose the workflow that wouldn't be supported is when a contributor does a PR but the project team doesn't like it, but likes the idea, so project team re-implements the change in a different way and closes PR manually rather than merge in. In the Apache case, the project team would have to ask the contributor to manually close their PR as they couldn't do it for them. This would apply to PRs on the official Apache mirror.

Jason

-----Original Message-----
From: Jochen Theodorou [mailto:[hidden email]]
Sent: Monday, March 16, 2015 11:46 AM
To: [hidden email]
Subject: Re: [groovy-user] Re: Moving Groovy to a Foundation

Am 16.03.2015 16:21, schrieb Thibault Kruse:
> By the way, it seems right that the github "mirror" repo for Groovy
> might better remain as is, instead of having groovy on github hosted
> under the apache organisation:
>
> http://apache-wicket.1842946.n4.nabble.com/core-devs-cannot-close-PRs-
> on-github-td4669946.html
>
> This is independent of the "true" hosting at Apache.

uh, we can't close pull requests on our own anymore then? That's indeed a problem. Afaik we have to move the repo under the apache organization.

bye blackdrag

--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc For Groovy programming sources visit http://groovy-lang.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



----------------------------------------------------------------------
This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.
Reply | Threaded
Open this post in threaded view
|

Re: Moving Groovy to a Foundation

Jochen Theodorou
Am 16.03.2015 16:54, schrieb Winnebeck, Jason:
> The reply did say if the pull request was done in the "git way" that the PR would be automatically closed. I am hoping that means if it's gone with a git pull (so that the changesets are actually merged in), then it works, whereas if the changes were manually copied over and applied it wouldn't work because Github wouldn't know that the changesets made it in.

if the hashes of the commits match, then github can recognize the issue
as closed, since it sees the commit as applied.

> I suppose the workflow that wouldn't be supported is when a contributor does a PR but the project team doesn't like it, but likes the idea, so project team re-implements the change in a different way and closes PR manually rather than merge in. In the Apache case, the project team would have to ask the contributor to manually close their PR as they couldn't do it for them. This would apply to PRs on the official Apache mirror.

that's where I found this one:
https://help.github.com/articles/closing-issues-via-commit-messages/

So it is still possible.

bye blackdrag

--
Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Moving Groovy to a Foundation

Thibault Kruse
Yes, auto-close works if the PR is merged as-is (which would be the
"github way"), either via github or by adding the commits without
changes / rebases. But if it is changed/rebased before merging (a
practice some people like, some people don't), then auto-close will
not work. E.g. adding the commits to another branch when the PR was
done to an undesired branch would cause this to fail.

Also note that further restrictions apply according to
https://help.github.com/articles/permission-levels-for-an-organization-repository/

such as moderating the PR discussion threads.

On Mon, Mar 16, 2015 at 5:03 PM, Jochen Theodorou <[hidden email]> wrote:

> Am 16.03.2015 16:54, schrieb Winnebeck, Jason:
>>
>> The reply did say if the pull request was done in the "git way" that the
>> PR would be automatically closed. I am hoping that means if it's gone with a
>> git pull (so that the changesets are actually merged in), then it works,
>> whereas if the changes were manually copied over and applied it wouldn't
>> work because Github wouldn't know that the changesets made it in.
>
>
> if the hashes of the commits match, then github can recognize the issue as
> closed, since it sees the commit as applied.
>
>> I suppose the workflow that wouldn't be supported is when a contributor
>> does a PR but the project team doesn't like it, but likes the idea, so
>> project team re-implements the change in a different way and closes PR
>> manually rather than merge in. In the Apache case, the project team would
>> have to ask the contributor to manually close their PR as they couldn't do
>> it for them. This would apply to PRs on the official Apache mirror.
>
>
> that's where I found this one:
> https://help.github.com/articles/closing-issues-via-commit-messages/
>
> So it is still possible.
>
>
> bye blackdrag
>
> --
> Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
> blog: http://blackdragsview.blogspot.com/
> german groovy discussion newsgroup: de.comp.lang.misc
> For Groovy programming sources visit http://groovy-lang.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Moving Groovy to a Foundation

Cédric Champeau
Manual closing is not a problem, we do that already (for some squashed
commits or cherry picks for example). The issue is more if we cannot
click the button, implying a dummy commit to be able to close. It is
manageable in any case, there will be some annoyances for us, but it is
manageable.

On 16/03/2015 17:31, Thibault Kruse wrote:

> Yes, auto-close works if the PR is merged as-is (which would be the
> "github way"), either via github or by adding the commits without
> changes / rebases. But if it is changed/rebased before merging (a
> practice some people like, some people don't), then auto-close will
> not work. E.g. adding the commits to another branch when the PR was
> done to an undesired branch would cause this to fail.
>
> Also note that further restrictions apply according to
> https://help.github.com/articles/permission-levels-for-an-organization-repository/
>
> such as moderating the PR discussion threads.
>
> On Mon, Mar 16, 2015 at 5:03 PM, Jochen Theodorou <[hidden email]> wrote:
>> Am 16.03.2015 16:54, schrieb Winnebeck, Jason:
>>> The reply did say if the pull request was done in the "git way" that the
>>> PR would be automatically closed. I am hoping that means if it's gone with a
>>> git pull (so that the changesets are actually merged in), then it works,
>>> whereas if the changes were manually copied over and applied it wouldn't
>>> work because Github wouldn't know that the changesets made it in.
>>
>> if the hashes of the commits match, then github can recognize the issue as
>> closed, since it sees the commit as applied.
>>
>>> I suppose the workflow that wouldn't be supported is when a contributor
>>> does a PR but the project team doesn't like it, but likes the idea, so
>>> project team re-implements the change in a different way and closes PR
>>> manually rather than merge in. In the Apache case, the project team would
>>> have to ask the contributor to manually close their PR as they couldn't do
>>> it for them. This would apply to PRs on the official Apache mirror.
>>
>> that's where I found this one:
>> https://help.github.com/articles/closing-issues-via-commit-messages/
>>
>> So it is still possible.
>>
>>
>> bye blackdrag
>>
>> --
>> Jochen "blackdrag" Theodorou - Groovy Project Tech Lead
>> blog: http://blackdragsview.blogspot.com/
>> german groovy discussion newsgroup: de.comp.lang.misc
>> For Groovy programming sources visit http://groovy-lang.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>      http://xircles.codehaus.org/manage_email
>
>
>
>


--
Cédric Champeau
Groovy language developer
http://twitter.com/CedricChampeau
http://melix.github.io/blog


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


1 ... 17181920