On Wed, Nov 30, 2016 at 3:49 AM, John D. Ament wrote:
> .. should we just drop the
> current "policy" document and make the guides the policy documents?...
Clearly separating policy from everything else sounds good to me, but
the policy docs should then be as concise as possible.
Dunno if that c
Ok, just wanted to make sure...
Why isn't my memory updated with "svn commit" ?? Yeah, the CCLA was updated
in 2005 with the appendix to make the grant specific.
Never mind...
On Wed, Nov 30, 2016 at 12:13 PM, Craig Russell
wrote:
> Hi Niclas,
>
> The CCLA is sufficient as a code grant for new
The Apache Gearpump team would like to announce the release of Apache
Gearpump 0.8.2-incubating.
Apache Gearpump (incubating) is a reactive real-time streaming engine based
on the micro-service Actor model. It provides extremely high performance
stream processing while maintaining millisecond late
In my experience, the CCLA is too 'strong' for many corporate types since
it delegates decision making waaay down in the pecking order with no
recourse.
On Wed, Nov 30, 2016 at 1:13 PM, Craig Russell
wrote:
> Hi Niclas,
>
> The CCLA is sufficient as a code grant for new code bases coming into
Hi Niclas,
The CCLA is sufficient as a code grant for new code bases coming into Apache.
Of course, committers must submit their own ICLA as well.
Why do you consider the CCLA a ‘weak’ agreement?
Craig
> On Nov 29, 2016, at 8:04 PM, Niclas Hedhman wrote:
>
> I am seeing on
> http://incubator
I would be delighted if the answer became cut and dry, modulo the fact
that if the cut-and-dry document became a laundry list for everyone's
favorite thing, that could move the goalposts pretty far for existing
podlings.
On Tue, Nov 29, 2016 at 6:49 PM, John D. Ament wrote:
> So personally I thin
Hi Niclas,
> On Nov 29, 2016, at 8:04 PM, Niclas Hedhman wrote:
>
> I am seeing on
> http://incubator.apache.org/guides/mentor.html#initial-import-code-dump
> that the CCLA is adequate for new codebases coming in via the Incubator. Is
> that really the case? It seems to me to be a rather 'weak'
I am seeing on
http://incubator.apache.org/guides/mentor.html#initial-import-code-dump
that the CCLA is adequate for new codebases coming in via the Incubator. Is
that really the case? It seems to me to be a rather 'weak' agreement for
something that substantial.
Cheers
--
Niclas Hedhman, Softwa
So personally I think its great to get input from current podlings on a
subject like this.
I've made some proposed changes on a separate thread, but I almost think
between your comments and Roman's comments... should we just drop the
current "policy" document and make the guides the policy documen
All,
Based on some of the feedback received, i think we should start putting
together some revisions to the Incubator's policy document. The document
in reference is at
http://incubator.apache.org/incubation/Incubation_Policy.html
- Acceptance by Incubator
Rephrase the first few lines as:
If t
Seemed like the discussion is calming down
Will send VOTE thread end of day tomorrow.
Thanks,
Henry
On Wed, Nov 23, 2016 at 3:30 PM Henry Saputra
wrote:
> Hi All,
>
> As the champion for Griffin, I would like to bring up discussion to
> bring the project as Apache incubator podling.
>
> Here i
All,
Based on some variations in process, there's some initial talk to moving
podling bootstrapping from an infra standpoint to a dedicated form. This
form would potentially gather:
- Podling name
- JIRA
- Confluence
- Mailing lists
- Git Repositories
- Travis CI
- Coveralls
other things as time
+1
++
Chris Mattmann, Ph.D.
Principal Data Scientist, Engineering Administrative Office (3010)
Manager, Open Source Projects Formulation and Development Office (8212)
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 180-5
Thanks for the feedback.
How does Ratis (Latin for raft) sound for the name? A quick search in
google doesn¹t show it is used. If this is acceptable, I will update the
proposal.
We are working on documentation for the user api's as well as the design.
We didn¹t consider TLP as the project is very
Thanks all.
This vote passes with 8 binding +1s, 9 non-binding +1s, and no -1.
--
Binding +1 votes:
Niclas Hedhman
Stian Soiland-Reyes
John D. Ament
Bertrand Delacretaz
Willem Jiang
Luke Han
Stephan Ewen
Henry Saputra
Non-binding +1 votes:
Xiaorui Wang
Feng Jia
Feng Longda
Xinyu Zhou
Hust Fxj
> You can just make the release on a branch rather than in a fork/mirror.
This is what Impala did and Github still happily treats those
off-master-branch tags as "releases".
-
To unsubscribe, e-mail: general-unsubscr...@incubator
The discussion has moved to legal-discuss. I would encourage everyone to
join the discussion there
https://lists.apache.org/thread.html/db78e1f8fc121d8e6b016d2f61d06ccafebf9fd30b4ec00883c78557@%3Clegal-discuss.apache.org%3E
On Tue, Nov 29, 2016 at 3:11 PM Tom Barber wrote:
> Yeah but the probl
Yeah but the problem there harks back to SVN-land where you'd push a tag to
run the builds and tests from for VOTE acceptance. Of course a tag in Git
is just a hash, so you could just quote a hash instead, but still,
personally I think its easier for users to have the tag in place to grab
and buil
The subject is a bit odd, but isn't https://github.com/apache an official
Apache Software Foundation repository?
And https://github.com/apache/incubator-joshua/releases with the big blue
Releases button seems suggestive (or confusing) to downstream users.
The solution, due to GitHub's quirk, is t
Personally I think thats over doing it a bit on the T&C's, the PPMC hasn't
created the artifact, I could create a release of any project and slap it
on github and people could download it, doesn't make it "official" though,
its just those faux-releases are generated by github themselves not a user.
On Tue, Nov 29, 2016 at 2:51 PM Jim Apple wrote:
> I am not subscribed to that list.
>
> Can you elaborate on the process of moving release votes to a
> different mirror/fork? Our votes, of course, happen on the mailing
> list. The tagging happens in the official git repo. We do not have any
> of
Hi,
> IMHO, the tags on github are not formal releases.
The tags may not be but it does creates a release artefact that someone can
download.
> So its not a violation of ASF release process.
How so? It’s creating an artefact that the general public can access and
download before the vote is
I am not subscribed to that list.
Can you elaborate on the process of moving release votes to a
different mirror/fork? Our votes, of course, happen on the mailing
list. The tagging happens in the official git repo. We do not have any
oficially-recognized-yet-unofficial mirrors, and the idea that w
IMHO, the tags on github are not formal releases. The fact that github
marks it as a release is just an unfortunate side effect of how github
works. So its not a violation of ASF release process. May be good to
start a discussion on legal-discuss. Let me know if you're subscribed, we
can talk m
> Also the 6.1 release has already been tagged and it available for public
> download on github [4] before this vote is finished. This is IMO against
> Apache release policy [3] please remove.
> 3. http://www.apache.org/dev/release.html#what
> 4. https://github.com/apache/incubator-joshua/releas
Hi,
> RE: the language packs, they aren't officially Apache released as of now -
> they are simply on Matt Post's JHU website.
While they are hosted externally I see them listed on a download page on your
site [1] without any clear indication that they are not offical releases.
Thanks,
Justin
Justin thanks for your thorough comments. Lewis, Matt & team we should take
these back onto dev@j.i.a.o and address them.
RE: the language packs, they aren't officially Apache released as of now - they
are simply on Matt Post's JHU website. Eventually we would like them to be
Apache released, b
27 matches
Mail list logo
