Also, don't forget that Ignasi is in a very different timezone from most of us.
You're in Barcelona, right Ignasi? Everett On Jun 20, 2013, at 2:00 AM, Ignasi wrote: > 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 >>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >>
