Re: Proposed policy change: Don't require CLA from contributos
That sounds great. Lowering the barrier of entry is always good! One thing that I am working on with the TODO Group is a tool for ensuring compliance to repo rules (like Copyright headers): https://github.com/todogroup/repolinter Might be useful here if we could tie it in somehow. On Wed, Jun 21, 2017 at 3:47 AM, Daniel Dekany wrote: > Currently we strictly require a CLA (by which I mean an ICLA or CCLA) > for any contributions to be accepted, as > http://freemarker.org/contribute.html says. > > This practice was inherited from the pre-ASF times, when without > lawyers available, we tried to be on the safe side. But based on > https://issues.apache.org/jira/browse/LEGAL-156 and > https://wiki.apache.org/couchdb/CommitPolicy and some other mails we > can make things simpler for contributors (not to be confused with > committers). > > So I propose that we say that: > > - People sending contributions with GitHub pull requests need no CLA. > But, before merging, we must check that: > - The mail about the pull request was received to > notificati...@freemarker.incubator.apache.org, so that there's > a record of this even in the ASF infrastructure. > - The files in the pull request has the standard ASF copyright > headers, or no copyright headers in files where that's normally > not present. There's no other conflicting copyright information > included either (like a such LICENSE file). > - People sending in patches as attachment to FreeMarker Jira issues > need no CLA. But, before merging, we must check that: > - It's clear from the wording of the issue that the user wishes to > contribute (as opposed to, for example, just showing an example). > - Copyright headers are in order, just as with GitHub pull request. > > If someone contributes a bigger feature, yet they isn't a committer, > we might still ask a CLA though. But that can be dealt with when such > thing happens. > > -- > Thanks, > Daniel Dekany > -- Trevor Lalish-Menagh about.me/trevmex
Re: [FM3] Call syntax, positional and named parameters
Friday, June 16, 2017, 8:41:37 PM, Daniel Dekany wrote: > A problem in FM2 is that when calling a directive (as a macro), either > all parameters are positional (`<@message "Hi" 2 />`), or all > parameters are named (`<@message content="Hi" height=2 />`); you can't > mix the two (`<@message "Hi" height=2 />`). Also you can't use named > parameters for functions/methods, only for directives. Worse, core > directives don't even use named parameters, but some keyword like > `as`, `using`... their syntax is hard coded into the parser, which is > not nice, and will be a problem for the custom dialects feature. > > I think that with the exception of a few core directives (see them > later) all directive calls should be like this, if for now (in this > thread) we ignore loop variables: > > <#name posPar1 posPar2 namedPar1Name=namedPar1Value > namedPar2=namedPar2Value> An adjustment to the above... I think that we should require comma between positional arguments (but not between positional and named arguments and between named arguments): <#name posPar1, posPar2 namedPar1Name=namedPar1Value namedPar2=namedPar2Value> FM2 supports both the <@foo 1, 2, 3 /> and <@foo 1 2 3 /> variation (and has no core directive with more the one positional argument, hence I demonstrated it with a custom directive). I believe it's better stick to one syntax or the other in FM3, not supporting both. Question is, which one. While <@foo 1 2 3 /> fits HTML style better, it can be ambiguous. Consider: - In `<@foo x - 1 />` is the argument `x - 1`, or we have an `x` and a `-1` argument? - In `<@foo x! 1 />` is the argument `x!1`, or we have an `x!` and a `1` argument? Technically, you can make whitespace significant, so that `<@foo x -1 />` and `<@foo x - 1 />` has different meaning, but its a quite extreme syntax design, and when you writing templates, I doubt many users will even realize that such subtle rules exist. With comma, it's obvious to do (`<@foo x - 1 />` VS `<@foo x, -1 />`, or even `<@foo x, - 1 />`). It looks a bit odd next to named parameters, but certainly by far the most common application of mixed positional and named parameters is when you have only one positional parameters (<@launch rocket1 delay=3 />), in which case the comma doesn't appear anyway. For function calls, which follow typical C-ish expression syntax, using commas even between named parameters is the natural thing (as in `f(1, 2, foo=3, bar=4)`), so I would stick to that. [snip] > parameters is `<#ftl outputFormat='RTF'>`. So far it's the same as in > FM2. But now we could have both in once call, such as > `<#visit node handlers=myNamespace>` (regular syntax), which was > `<#visit node using myNamespace>` in FM2 (irregular syntax hard coded > into the parser). [snip] For completeness, let's see what other non-regular core directives we have. - For #import I would switch to assignment-like approach: FM2: <#import "foo.ftl" as f> <#import "bar.ftl" as b> FM3: <#import f="foo.ftl" b="bar.ftl"> - #escape doesn't mater, as it will be removed (in favor of output formats introduced in 2.3.24). - #assign has this `in` thing, like `<#assign x = 1 in ns>`. We will want to allow <#assign ns.x = 1> (actually, #set) anyway, so that won't mater either. -- Thanks, Daniel Dekany
Re: Is Freemarker becoming too process heavy? (was Re: Proposed policy change: Don't require CLA from contributos)
Wednesday, June 21, 2017, 2:52:08 PM, John D. Ament wrote: > All, > > I'm concerned with some of these threads I'm seeing w/r/t Freemarker. > While I'm not a mentor on the project, I've been a user for a while and > have been curious about Freemarker at Apache. > > I would not cite a CouchDB process from their old wiki. First, its not > clear if this is the most recent version (it mentions a migration to the > new wiki and an external website which are red flags to me). (It's not in their new Wiki... But then let's ignore it. There's still LEGA-156.) > Second, CouchDB has a much different model and contributor set than > other projects do. > > I would cite a legal JIRA, and as far as I know everyone was already > following this guide. > > I would also cite our legal guidelines > https://www.apache.org/licenses/#clas in > particular where it makes sense to expect an ICLA on file. In general, ASF > expects ICLAs for large enough contributions. The size is at the > discretion of the PMC receiving the contribution. We do require ICLAs for > committers to join a project (to receive an account, to receive write > access) and many projects simply follow that model - you need an ICLA at > that point in time. I think what I'm proposing is pretty much the same, only it tells more concrete details (which I believe is good for Committers who has to merge stuff; or at least I find the ASF documentations pretty scattered and at some places superficial). What am I missing? As of https://www.apache.org/licenses/#clas, it says that: The ASF desires that all contributors of ideas, code, or documentation to any Apache projects complete, sign, and submit via email an Individual Contributor License Agreement (ICLA). I doesn't talk about exceptions where an ICLA is not needed. But, today I saw a thread on members@ where someone said ICLA is not needed for mere contributors, only for Committers, and that led me to https://issues.apache.org/jira/browse/LEGAL-156, where Legal says no ICLA is needed for GitHub pull requests, etc. > I would encourage Freemarker to keep things simple, especially since the > total number of contributors is at 13. But that's exactly why I wanted this. It is simpler for contributors if they can just do a PR, without any paper work. What do you mean by FM becoming process heavy? Which other threads do you find concerning? > John > > On Wed, Jun 21, 2017 at 6:48 AM Daniel Dekany wrote: > >> Currently we strictly require a CLA (by which I mean an ICLA or CCLA) >> for any contributions to be accepted, as >> http://freemarker.org/contribute.html says. >> >> This practice was inherited from the pre-ASF times, when without >> lawyers available, we tried to be on the safe side. But based on >> https://issues.apache.org/jira/browse/LEGAL-156 and >> https://wiki.apache.org/couchdb/CommitPolicy and some other mails we >> can make things simpler for contributors (not to be confused with >> committers). >> >> So I propose that we say that: >> >> - People sending contributions with GitHub pull requests need no CLA. >> But, before merging, we must check that: >> - The mail about the pull request was received to >> notificati...@freemarker.incubator.apache.org, so that there's >> a record of this even in the ASF infrastructure. >> - The files in the pull request has the standard ASF copyright >> headers, or no copyright headers in files where that's normally >> not present. There's no other conflicting copyright information >> included either (like a such LICENSE file). >> - People sending in patches as attachment to FreeMarker Jira issues >> need no CLA. But, before merging, we must check that: >> - It's clear from the wording of the issue that the user wishes to >> contribute (as opposed to, for example, just showing an example). >> - Copyright headers are in order, just as with GitHub pull request. >> >> If someone contributes a bigger feature, yet they isn't a committer, >> we might still ask a CLA though. But that can be dealt with when such >> thing happens. >> >> -- >> Thanks, >> Daniel Dekany >> >> -- Thanks, Daniel Dekany
Is Freemarker becoming too process heavy? (was Re: Proposed policy change: Don't require CLA from contributos)
All, I'm concerned with some of these threads I'm seeing w/r/t Freemarker. While I'm not a mentor on the project, I've been a user for a while and have been curious about Freemarker at Apache. I would not cite a CouchDB process from their old wiki. First, its not clear if this is the most recent version (it mentions a migration to the new wiki and an external website which are red flags to me). Second, CouchDB has a much different model and contributor set than other projects do. I would cite a legal JIRA, and as far as I know everyone was already following this guide. I would also cite our legal guidelines https://www.apache.org/licenses/#clas in particular where it makes sense to expect an ICLA on file. In general, ASF expects ICLAs for large enough contributions. The size is at the discretion of the PMC receiving the contribution. We do require ICLAs for committers to join a project (to receive an account, to receive write access) and many projects simply follow that model - you need an ICLA at that point in time. I would encourage Freemarker to keep things simple, especially since the total number of contributors is at 13. John On Wed, Jun 21, 2017 at 6:48 AM Daniel Dekany wrote: > Currently we strictly require a CLA (by which I mean an ICLA or CCLA) > for any contributions to be accepted, as > http://freemarker.org/contribute.html says. > > This practice was inherited from the pre-ASF times, when without > lawyers available, we tried to be on the safe side. But based on > https://issues.apache.org/jira/browse/LEGAL-156 and > https://wiki.apache.org/couchdb/CommitPolicy and some other mails we > can make things simpler for contributors (not to be confused with > committers). > > So I propose that we say that: > > - People sending contributions with GitHub pull requests need no CLA. > But, before merging, we must check that: > - The mail about the pull request was received to > notificati...@freemarker.incubator.apache.org, so that there's > a record of this even in the ASF infrastructure. > - The files in the pull request has the standard ASF copyright > headers, or no copyright headers in files where that's normally > not present. There's no other conflicting copyright information > included either (like a such LICENSE file). > - People sending in patches as attachment to FreeMarker Jira issues > need no CLA. But, before merging, we must check that: > - It's clear from the wording of the issue that the user wishes to > contribute (as opposed to, for example, just showing an example). > - Copyright headers are in order, just as with GitHub pull request. > > If someone contributes a bigger feature, yet they isn't a committer, > we might still ask a CLA though. But that can be dealt with when such > thing happens. > > -- > Thanks, > Daniel Dekany > >
Proposed policy change: Don't require CLA from contributos
Currently we strictly require a CLA (by which I mean an ICLA or CCLA) for any contributions to be accepted, as http://freemarker.org/contribute.html says. This practice was inherited from the pre-ASF times, when without lawyers available, we tried to be on the safe side. But based on https://issues.apache.org/jira/browse/LEGAL-156 and https://wiki.apache.org/couchdb/CommitPolicy and some other mails we can make things simpler for contributors (not to be confused with committers). So I propose that we say that: - People sending contributions with GitHub pull requests need no CLA. But, before merging, we must check that: - The mail about the pull request was received to notificati...@freemarker.incubator.apache.org, so that there's a record of this even in the ASF infrastructure. - The files in the pull request has the standard ASF copyright headers, or no copyright headers in files where that's normally not present. There's no other conflicting copyright information included either (like a such LICENSE file). - People sending in patches as attachment to FreeMarker Jira issues need no CLA. But, before merging, we must check that: - It's clear from the wording of the issue that the user wishes to contribute (as opposed to, for example, just showing an example). - Copyright headers are in order, just as with GitHub pull request. If someone contributes a bigger feature, yet they isn't a committer, we might still ask a CLA though. But that can be dealt with when such thing happens. -- Thanks, Daniel Dekany