I don't see how it's beneficial to the audience though, and if I'm looking
for that as a committer, I'd rather not scroll to the bottom.  I'd rather
just search for committer guide or something, not contributing.


On Tue, Jun 18, 2013 at 2:34 PM, Ignasi <[email protected]> wrote:

> Thanks for reviewing Matt!
>
> Agree. Modified the text to only require the rebase but leave the
> squash as an optional step.
>
> Regarding the commiters stuff, I personally think it is good to have
> just one guide. Commiters specific steps are only at the very end of
> the document, and I see no point in having a separate document for
> them. I also like the idea of transparency, and I think it is good
> that people know how we are going to merge their contributions.
> Anyway, this is something we can discuss and take the preferred option
> :)
>
> On 18 June 2013 17:03, Matt Stephenson <[email protected]> wrote:
> > I wouldn't include that all commits need to be squashed, but agree with
> > rebasing to master.
> > On Jun 18, 2013 8:00 AM, "Matt Stephenson" <[email protected]>
> wrote:
> >
> >> I'd split the committer's section out  to another page.  If we want a
> page
> >> that gets a contributor to the point of having a PR, then just do that.
> >> The rest is for another audience.
> >> On Jun 18, 2013 6:16 AM, "Ignasi" <[email protected]> wrote:
> >>
> >>> I understood that from an email thread where this was discussed. It
> >>> was opened in the private list so I can't paste the link here, but
> >>> your recommendations were:
> >>>
> >>> "Oliver: As long as the contribution is attached to a jira I consider
> >>> implicit
> >>> the contributor agree on the Apache license for the code he provide.
> >>> Perso, when the patch/contribution is very huge (don't ask me figures
> >>> in term of lines of code :-) )."
> >>>
> >>> "David: As a general rule submissions to the project (mailing list,
> >>> Jira, pull request, etc.) are assumed under the terms of the ASL to be
> >>> offered under the same license unless explicitly stated otherwise.
> >>> Major contributions might need a CLA, but most patches won't rise to
> >>> this level in my experience."
> >>>
> >>>
> >>> I understand then, that by default, there is no need to sign the CLA.
> >>> I'll remove that section from the guide :)
> >>>
> >>> Thanks for checking!
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On 18 June 2013 14:54, David Nalley <[email protected]> wrote:
> >>> >> == Contributor license agreement ==
> >>> >>
> >>> >> Before contributing, you may have to sign the [[
> >>> http://www.apache.org/licenses/#clas|Apache ICLA]]. All contributions
> >>> and patches attached to a [[
> >>> https://issues.apache.org/jira/browse/JCLOUDS|JIRA]] issue are assumed
> >>> to be under the agreement, so even if small patches and changes may not
> >>> require an explicit signature, it is always a good idea to have it in
> place.
> >>> >>
> >>> >
> >>> > A signed CLA isn't required by the ASF for patches - is there a
> reason
> >>> > the project wishes to require them?
> >>> >
> >>> > --David
> >>>
> >>
>

Reply via email to