Matt, I haven't had time until today to address your comments (and it's been only around a day, I didn't intend to ignore them :)).
Thanks for taking care of updating the guide in the meanwhile! El 20/06/2013 07:09, "Matt Stephenson" <[email protected]> escribió: > Yeah, looks like moinmoin was case sensitive on my login. Pinged > silkysun@who was up and she managed to fix it. I foolishly didn't > follow > instructions when I setup my login, I guess I'll need to find out how to > fix that at some point. > > > On Wed, Jun 19, 2013 at 9:48 PM, Andrew Bayer <[email protected] > >wrote: > > > I'm able to edit it, fwiw. > > > > A. > > > > On Wed, Jun 19, 2013 at 9:18 PM, Matt Stephenson <[email protected] > > >wrote: > > > > > Ignasi, > > > This page you created is immutable and I cannot edit it. Please make > it > > > writeable to admins. I would like to clean it up since you're not > > > responding to my feedback. > > > > > > Matt > > > > > > > > > On Tue, Jun 18, 2013 at 3:47 PM, Matt Stephenson < > [email protected] > > > >wrote: > > > > > > > Sigh, it's so irritating that we're always writing "Git 101" docs for > > > > contributor/committer docs. > > > > > > > > Lets link to these instead, they're way more instructive : > > > > https://help.github.com/articles/set-up-git > > > > https://help.github.com/articles/fork-a-repo > > > > > > > > > > > > > > > > On Tue, Jun 18, 2013 at 3:25 PM, Matt Stephenson < > > [email protected] > > > >wrote: > > > > > > > >> Also, since we're Commit Then Review, committers don't follow the > same > > > >> process as contributors for making changes. > > > >> > > > >> > > > >> On Tue, Jun 18, 2013 at 3:23 PM, Matt Stephenson < > > [email protected] > > > >wrote: > > > >> > > > >>> 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 > > > >>>> >>> > > > >>>> >> > > > >>>> > > > >>> > > > >>> > > > >> > > > > > > > > > >
