Aw: Re: Tying Dockerhub into development and release management

[Jochen Theodorou]

> Gesendet: Freitag, 08. Februar 2019 um 04:58 Uhr
> Von: "Dave Fisher" 
> An: general@incubator.apache.org
> Betreff: Re: Tying Dockerhub into development and release management
[...]
> > On Feb 7, 2019, at 7:51 PM, Chris Lambertus  wrote:
[...]
> >> On Feb 7, 2019, at 6:47 PM, Justin Mclean  wrote:
> >> 
> >> Hi,
> >> 
> >>> Infra does not police what projects deploy on their dockerhub repos. Do 
> >>> we need to?
> >> 
> >> Well from a casual glance I can see several projects that seem to be 
> >> putting releases constructed from unapproved source code up there. I’ve 
> >> not looked in detail so may be mistaken. I guess sit depends if that 
> >> concerns you or not.
> > 
> > I hear you loud and clear. It’s not a question of if it concerns “me” i.e. 
> > Infra, but more if it concerns Legal. Based on 
> > www.apache.org/legal/release-policy.html it seems like Infra may need to 
> > clamp down on what’s going on with the dockerhub repos and builds. As I 
> > alluded to before, we’ve generally left this to the good will of the 
> > project. If it’s being abused and the project is “releasing” artifacts via 
> > dockerhub that have not been vetted through the ASF release policy, then we 
> > do need to take action. Thanks for bringing this to our attention. Could 
> > you please send a list of any “offenders” that you’ve found to 
> > private@infra?

Question: "releasing artifacts that have not been vetted through the ASF 
release policy" does also include Docker images based on official releases? (I 
know the thread also talked about nightlies and such, that is why it is not 
100% clear to me here)

bye Jochen

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

apache at bintray

[Jochen Theodorou]

Hi all,

I was pointed at https://bintray.com/apache. Is that an "official" 
bintray account for apache? Are projects publishing convenience 
artifacts on bintray supposed to use that?


bye Jochen

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache NetBeans 9.0 Beta (incubating) rc2

[Jochen Theodorou]

Am 22.01.2018 um 11:01 schrieb Geertjan Wielenga:

I am not sure what the point is of spending time on putting rat exclusions
together if they’re simply going to be ignored when it comes to IPMC
members evaluating a release. Yes, we can of course discuss those rat
exclusions. No, they cannot simply be ignored and we cannot be confronted
with a very long list of issues in the IPMC vote thread primarily based on
the fact that our rat exclusions have been ignored.


sorry for jumping in here, I only know half what those files are about, 
so I might be wrong. It seemed to me those are java files, that are test 
files. If you make an IDE for a language, you will want tests, that 
basically consist of code and are test data. And since they are test 
data, they have been excluded. Since they are also code, this produces 
an edge case conflict.


Now in Groovy we have also test data as code, but our tests have the 
test data either embedded and sue them directly from in-memory or will 
write them to disk or even produce them. Those tests then of course have 
the right header and do not need to be excluded. Is that no way forward 
for NetBeans?


bye Jochen

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Project informal discussion

[Jochen Theodorou]

On 18.07.2017 02:53, Harrison & Wells wrote:

# I'm just a beginner here, please ignore any stupidities
So guys, you told me to discuss my project here first.
Well, I have an idea of making a source code generator.
There really isn't a source code generation library.And it can be done.
It is really useful,just like BCEL, I think there should be one for source.

For example, when one is making a compiler compiler,it will be quite handy.
I haven't written any source at the moment, but when I do,can I start my
packages with org.apache.
Because,it's gonna be real cool.



I think you will have to give this a lot more flesh. Right now I can 
imagine everything from a simple templating engine up to a compiler 
generator like antlr


bye Jochen

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [PROPOSAL] Pulsar - proposal for Apache Incubation

[Jochen Theodorou]

On 26.04.2017 23:19, Joe Francis wrote:


Dear Apache Incubator Community,


We would like to submit the Pulsar proposal to the incubator.  Our draft is
available at:
https://wiki.apache.org/incubator/PulsarProposal

A quick overview of Pulsar:

Pulsar is a highly scalable, low latency messaging platform running on
commodity hardware. It provides simple pub-sub semantics over topics,
guaranteed at-least-once delivery of messages, automatic cursor management for
subscribers, and cross-datacenter replication.


Without really knowing the details of a messaging platform and even with 
the danger of comparing apples and oranges... how would you compare for 
example hazelcast based messaging to pulsar?


bye Jochen

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: GitHub workflows?

[Jochen Theodorou]

On 06.03.2017 04:56, Niclas Hedhman wrote:

Everyone,
I need to get an understanding of the use of GitHub workflows on Apache
projects.

In GH, it is possible to comment on commits and pull requests. Are those
captured by infra@ and replicated somewhere, or is this "lost data" (I
suspect) in case GitHub goes out of business?


you can set GH to send the comments messages to dev, then they are not lost

bye Jochen

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Release Process [was: [VOTE] Drop incubating requirement of Maven artifacts]

[Jochen Theodorou]

On 09.01.2017 00:54, Niclas Hedhman wrote:
[...]

Probably after our
next release, we will publish reusable Gradle components for the Apache
release process for other Gradle based projects to benefit from. We'll see
exactly how we do this.


In Groovy we are working on something gradle based too, maybe some parts 
could be reused. I will post to this list once we made our first 
successful release using that new mechanic


bye Jochen

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Drop incubating requirement of Maven artifacts

[Jochen Theodorou]

On 06.01.2017 17:32, Wade Chandler wrote:
[]

It's not a big deal YET, but http://codehaus.org is not reachable anymore.


yes, Ben told me he does not want to give the domain away right now. 
When the time comes, he will think about donating it to the ASF. when 
this will be I do not know


[...]

Too many projects based off of
it. The domain is being donated to Apache though AFAIK, but still, end
users shouldn't have to change so many sources or break other dependencies,
which may not be using the new package names, just because the package
names are org.netbeans and someone thinks they should be
org.apache.netbeans unless there is a true legal reason, and that would be
rare, but a different email thread I imagine, but way more complicated than
just changing the package name in the case of Groovy or NetBeans because we
are talking about whole ecosystems and dependency graphs.


oh, it is not only the package name for Groovy, it is the maven group-id 
as well.


bye Jochen


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Drop incubating requirement of Maven artifacts

[Jochen Theodorou]

On 04.01.2017 07:28, Mark Struberg wrote:
[...]

I'm a bit surprised that groovy still uses the org.codehaus groupId, but I 
guess they have a deal with Ben (the former owner and thus (former?) copyright 
holder of 'Codehaus').
So while this will work for now I guess that even groovy will move to 
org.apache.groovy in the long term (maybe with a new major version).


A new major version is a big thing for Groovy, but yes. In our view it 
is the only realistic way, since people can expect breaking changes 
between major versions and that includes in our view package names as 
well as group ids.



It's not a big deal YET, but http://codehaus.org is not reachable anymore. And 
if anyone buys this domain he will have a much better position regarding 
trademarks than we do.
What if someone buys the codehaus.org domain and publishes own artifacts under 
org.codehaus.groovy? Can we even prevent someone else to e.g publish 
org.codehaus.groovyng artifacts?


Assume we change and 2 months later somebody does that? How is the 
situation then any better?


Actually I wonder if Ben would donate the domain to the ASF...

bye Jochen

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: JSON License and Apache Projects

[Jochen Theodorou]

is that library able to deal with the jdk9 module system?

On 24.11.2016 02:16, James Bognar wrote:

Shameless plug for Apache Juneau that has a cleanroom implementation of a
JSON serializer and parser in context of a common serialization API that
includes a variety of serialization languages for POJOs.

On Wed, Nov 23, 2016 at 8:10 PM Ted Dunning  wrote:


The VP Legal for Apache has determined that the JSON processing library
from json.org  is not usable as a
dependency by Apache projects. This is because the license includes a line
that places a field of use condition on downstream users in a way that is
not compatible with Apache's license.

This decision is, unfortunately, a change from the previous situation.
While the current decision is correct, it would have been nice if we had
had this decision originally.

As such, some existing projects may be impacted because they assumed that
the json.org dependency was OK to use.

Incubator projects that are currently using the json.org library have
several courses of action:

1) just drop it. Some projects like Storm have demos that use twitter4j
which incorporates the problematic code. These demos aren't core and could
just be dropped for a time.

2) help dependencies move away from problem code. I have sent a pull
request to twitter4 j, for
example, that eliminates the problem. If they accept the pull, then all
would be good for the projects that use twitter4j (and thus json.org)

3) replace the json.org artifact with a compatible one that is open
source.
I have created and published an artifact based on clean-room Android code
 that replicates the most important
parts of the json.org code. This code is compatible, but lacks some
coverage. It also could lead to jar hell if used unjudiciously because it
uses the org.json package. Shading and exclusion in a pom might help. Or
not. Go with caution here.

4) switch to safer alternatives such as Jackson. This requires code
changes, but is probably a good thing to do. This option is the one that is
best in the long-term but is also the most expensive.


-- Forwarded message --
From: Jim Jagielski 
Date: Wed, Nov 23, 2016 at 6:10 AM
Subject: JSON License and Apache Projects
To: ASF Board 


(forwarded from legal-discuss@)

As some of you may know, recently the JSON License has been
moved to Category X (https://www.apache.org/legal/resolved#category-x).

I understand that this has impacted some projects, especially
those in the midst of doing a release. I also understand that
up until now, really, there has been no real "outcry" over our
usage of it, especially from end-users and other consumers of
our projects which use it.

As compelling as that is, the fact is that the JSON license
itself is not OSI approved and is therefore not, by definition,
an "Open Source license" and, as such, cannot be considered as
one which is acceptable as related to categories.

Therefore, w/ my VP Legal hat on, I am making the following
statements:

 o No new project, sub-project or codebase, which has not
   used JSON licensed jars (or similar), are allowed to use
   them. In other words, if you haven't been using them, you
   aren't allowed to start. It is Cat-X.

 o If you have been using it, and have done so in a *release*,
   AND there has been NO pushback from your community/eco-system,
   you have a temporary exclusion from the Cat-X classification thru
   April 30, 2017. At that point in time, ANY and ALL usage
   of these JSON licensed artifacts are DISALLOWED. You must
   either find a suitably licensed replacement, or do without.
   There will be NO exceptions.

 o Any situation not covered by the above is an implicit
   DISALLOWAL of usage.

Also please note that in the 2nd situation (where a temporary
exclusion has been granted), you MUST ensure that NOTICE explicitly
notifies the end-user that a JSON licensed artifact exists. They
may not be aware of it up to now, and that MUST be addressed.

If there are any questions, please ask on the legal-discuss@a.o
list.

--
Jim Jagielski
VP Legal Affairs





-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Proposing Griffin for Apache incubator

[Jochen Theodorou]

just a remark on the name. Griffin is used in a lot of company names and 
is a family name. That may induce trademark problems, but I did not do 
any research on that.


Well and I am not happy about Griffin and Griffon being so near 
together, even though the later project most likely has no trademark as 
such.


On 24.11.2016 00:30, 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 is the direct quote from the abstract:

"
Griffin is a Data Quality Service platform built on Apache Hadoop and
Apache Spark. It provides a framework process for defining data
quality model, executing data quality measurement, automating data
profiling and validation, as well as a unified data quality
visualization across multiple data systems. It tries to address the
data quality challenges in big data and streaming context.
"

Here is the link to the proposal:
https://wiki.apache.org/incubator/GriffinProposal

I have copied the proposal below for easy access


Thanks,

- Henry


Griffin Proposal

Abstract

Griffin is a Data Quality Service platform built on Apache Hadoop and
Apache Spark. It provides a framework process for defining data
quality model, executing data quality measurement, automating data
profiling and validation, as well as a unified data quality
visualization across multiple data systems. It tries to address the
data quality challenges in big data and streaming context.

Proposal

Griffin is a open source Data Quality solution for distributed data
systems at any scale in both streaming or batch data context. When
people use open source products (e.g. Apache Hadoop, Apache Spark,
Apache Kafka, Apache Storm), they always need a data quality service
to build his/her confidence on data quality processed by those
platforms. Griffin creates a unified process to define and construct
data quality measurement pipeline across multiple data systems to
provide:

Automatic quality validation of the data
Data profiling and anomaly detection
Data quality lineage from upstream to downstream data systems.
Data quality health monitoring visualization
Shared infrastructure resource management

Overview of Griffin

Griffin has been deployed in production at eBay serving major data
systems, it takes a platform approach to provide generic features to
solve common data quality validation pain points. Firstly, user can
register the data asset which user wants to do data quality check. The
data asset can be batch data in RDBMS (e.g.Teradata), Apache Hadoop
system or near real-time streaming data from Apache Kafka, Apache
Storm and other real time data platforms. Secondly, user can create
data quality model to define the data quality rule and metadata.
Thirdly, the model or rule will be executed automatically (by the
model engine) to get the sample data quality validation results in a
few seconds for streaming data. Finally, user can analyze the data
quality results through built-in visualization tool to take actions.

Griffin includes:

Data Quality Model Engine

Griffin is model driven solution, user can choose various data quality
dimension to execute his/her data quality validation based on selected
target data-set or source data-set ( as the golden reference data). It
has a corresponding library supporting it in back-end for the
following measurement:

Accuracy - Does data reflect the real-world objects or a verifiable source
Completeness - Is all necessary data present
Validity - Are all data values within the data domains specified by the business
Timeliness - Is the data available at the time needed
Anomaly detection - Pre-built algorithm functions for the
identification of items, events or observations which do not conform
to an expected pattern or other items in a dataset
Data Profiling - Apply statistical analysis and assessment of data
values within a dataset for consistency, uniqueness and logic.

Data Collection Layer

We support two kinds of data sources, batch data and real time data.

For batch mode, we can collect data source from Apache Hadoop based
platform by various data connectors.

For real time mode, we can connect with messaging system like Kafka to
near real time analysis.

Data Process and Storage Layer

For batch analysis, our data quality model will compute data quality
metrics in our spark cluster based on data source in Apache Hadoop.

For near real time analysis, we consume data from messaging system,
then our data quality model will compute our real time data quality
metrics in our spark cluster. for data storage, we use time series
database in our back end to fulfill front end request.

Griffin Service

We have RESTful web services to accomplish all the functionalities of
Griffin, such as register data asset, create data quality model,
publish metrics, retrieve metrics, add subscription, etc. So, the
developers can develop their own user interface based on these web
services.

Background

At eBay, 

Re: Preliminary NetBeans cost findings

[Jochen Theodorou]

On 26.09.2016 17:04, Bertrand Delacretaz wrote:
[...]

b) We vote on the NetBeans proposal without waiting, and the podling
assumes the risk of having to wait for budget or technical solutions
to run plugins.netbeans.org at or via the ASF.


won't plugins.netbeans.org run for another few months with Oracle 
infrastructure? If it does, is it urgent enough to block incubation? For 
me it does not look that way.


bye Jochen

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Preliminary NetBeans cost findings

[Jochen Theodorou]

Hi Wade,

first of all, don't worry too much at this point, having discussions and 
trying to grasp the scope and what we get into is very normal at this 
point.


more comments inline...

On 25.09.2016 05:03, Wade Chandler wrote:
[...]

Do no other Apache projects have plugins or distribution needs?


* open office which actually gets helped here by sourceforge
* maven with maven central, which also not hosted at hte ASF
* ??


Other than build servers, what can't be
consolidated? What about monetary donations to projects or specific Apache
line items? Has there been any such talk?


You can donate to the ASF, not a specific project.. unless the project 
sets something up on its own.



How many other OSS Java IDEs are their? Seem only 2 at the Eclipse and
NetBeans level.


VS Code not? Sorry haven't really looked at it


Having them both exist makes the entire ecosystem healthier
in my opinion.


especially with hte bad mood towards eclipse these days


It would be a shame to not have one of the real open source
Java IDEs exist as an Apache project IMO.


It would be good to find a possible solution on the downloads. I mean 
(Groovy project) do have most of our downloads outside ASF to save cost 
(and to handle our somewhat complicated release logic) as well... and of 
course Netbeans has even more downloads


bye Jochen

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Jochen Theodorou]

On 25.09.2016 08:59, John McDonnell wrote:
[...]

I have contributed defect fixes for JClouds in the past, and from what
I see on this project is that there's an GitHub repo that allows
people to contribute PR's, but theres also a ASF repo, which the
contributors actually merge in the PRs from GitHub into the "hidden"
ASF repo...   Is this how every ASF project runs? and is this how
Apache Netbeans would run? Because if so, do you want to give a wide
list of committers initially?


In the end this is a decision of the project. The ASF has some 
constraints though. So currently the git repo is at apache, the github 
one is a mirror. You can still make pull request, but they have to be 
merged to the ASF repo instead of github. To merge you have to have 
commit rights at the ASF of course. Why you would want a small list of 
committers because of that escapes me though. Of course there is a trust 
kevel involved, but Apache is all about being open (for me)



I would have thought it would make sense to keep the number to a group
of trusted people that Netbeans/GJ trust up front to commit PRs into
the main repo, and to make short term decisions.  Then if a
developer/contributor shows themselves to be a useful part of the
community then you can quickly vote to change their status...


Well, to avoid bad blood anyone how contributed in the past reasonably 
and wants to be on the list should be considered. Once you started 
incubation things can be done like you describe - or different - really 
depends on the project


bye Jochen


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Jochen Theodorou]

On 24.09.2016 15:10, Geertjan Wielenga wrote:

On Sat, Sep 24, 2016 at 2:59 PM, Jochen Theodorou

For me the problem is that without plugins you have only the bare plattform

and no IDE.



No, that's not true at all. The NetBeans plugins are of various kinds.
There are plugins that are listed in the Plugin Manager by default, these
are the standard functionalities of NetBeans IDE, i.e., these are all from
the NetBeans source code and will be part of the Apache donation.



ok, wrong knowledge on my side. From hat I have seen in the repository 
it should be fine then. I have also seen some possibly license critical 
stuff there, but that is for during incubation to sort out


bye Jochen

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Jochen Theodorou]

On 24.09.2016 05:34, Wade Chandler wrote:
[...]

I ask these obvious rhetorical questions to get to this point: Would it be
feasible for NetBeans to succeed among competing projects with such a
stipulation that all hosted or distributed plugins be contributed to Apache
or licensed the same? Without an ecosystem and infrastructure that doesn't
force everyone into the same model, which is why the Apache license has
been so successful on a different level IMO, and Maven and Gradle on a
similar level, then I don't see such a project succeeding considering its
user base and use cases.


For me the problem is that without plugins you have only the bare 
plattform and no IDE.If you want to still be able to distribute an IDE 
with the same plugins as today, you will need to relicense some of the 
(L)GPled plugins to apache or rewrite them. The "All" version according 
to https://netbeans.org/downloads/ comes with Java, HTML5/Javascript, 
PHP, C/C++ and Groovy. And already for those plugins we have a good mix 
of GPL, LGPL and CDDL. I will become a problem if there will be an 
netbeans IDE download that mixes these through.


I really only want to hear, that these plugins will be migrated as part 
of netbeans incubation as well, or what the plans for these are.


I am sure there will be a solution for the hosting of the plugins.

bye Jochen


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Jochen Theodorou]

Hi,

I actually have a question regarding the plugins. Maybe I missed it in 
the discussion so far, but what will happen with all of those? I mean 
some are part of the binary download by default. Will they all move to 
apache license and then be hosted at apache if possible too, or will 
this become a plugin-per-plugin decission? What for example with all the 
plugins you are owner of?


bye Jochen


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Jochen Theodorou]

On 17.09.2016 10:23, Geertjan Wielenga wrote:

Nightly builds is all that's needed, indeed, no one needs to announce them,
they should simply be available. Agreed it's important to distinguish
between nightly builds and official releases, that's exactly how NetBeans
works currently. The #1 requirement here is that there should be nightly
builds and that is supported, from your response here.


may I ask for whom and what the nightly builds are in your case? If it 
is for developers only there should be no problem.


bye Jochen


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Jochen Theodorou]

On 16.09.2016 00:36, Geertjan Wielenga wrote:
[...]

Public servers:
- www.netbeans.org: ...
- hg.netbeans.org: ...
- deadlock.netbeans.org: ...
- bits.netbeans.org: ...
- updates.netbeans.org: ...
- statistics.netbeans.org: ...
- plugins.netbeans.org: ...
- forums.netbenas.org: ...
- services.netbeans.org: ...


I am wondering... is having several subdomains a problem for infra?

I did hear things in this direction, but since I was not directly 
involved I may have missed the important detail. Maybe someone from 
infra reads this and can answer?


bye Jochen


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Namespacing of subproject Docker images vs. Incubator policy

[Jochen Theodorou]

thx

On 01.09.2016 21:04, John D. Ament wrote:

Reach out to infra.  You can create a JIRA ticket.

John

On Thu, Sep 1, 2016 at 2:52 PM Jochen Theodorou <blackd...@gmx.org> wrote:


Only partially related to the namespacing problem...

But does somebody here know who to contact if I wanted to have a docker
image on https://hub.docker.com/u/apache/ ?

bye Jochen

On 29.08.2016 01:21, Mike Jumper wrote:

Hello all,

We, Apache Guacamole (incubating), would like to migrate our project's
Docker images to something beneath the ASF, but I am unsure how to
proceed, nor the form that this migration would best take.

We currently have two repositories which provide Docker images:
incubator-guacamole-client [1] and incubator-guacamole-server [2].
Prior to acceptance into the Apache Incubator, these repositories were
used to produce the "glyptodon/guacamole" [3] and "glyptodon/guacd"
[4] images respectively.

As there is already an "apache/*" organization defined at Docker Hub
(albeit a virtual desert) [5] and there was positive discussion
regarding including the images of incubating projects under that
organization [6], it seems that would be the logical and
straightforward choice ... but because one of those images ("guacd")
would not be namespaced by the project's own name, I'm unsure if this
is actually possible/allowed.

Ideally we would end up with a mapping like:

  incubator-guacamole-client -> apache/guacamole
  incubator-guacamole-server -> apache/guacd

Or, since we're incubating, perhaps:

  incubator-guacamole-client -> apache/incubator-guacamole
  incubator-guacamole-server -> apache/incubator-guacd

But again, I'm not sure if "apache/incubator-guacd" would be a
violation of policy.

Alternatively, a cleaner approach could be to define a Docker Hub
organization specific to the project, as that would provide a nice
analogy to the project/subproject relationship that exists between
Apache Guacamole the "guacamole" and "guacd" applications:

  incubator-guacamole-client -> guacamole/guacamole
  incubator-guacamole-server -> guacamole/guacd

But I'm not sure if THAT would be a violation of policy. Further,
after creating exactly such an organization for the sake of testing,
I've found that I can't set up the necessary linkage for enabling
automatic builds (the organization would need to be owned by a user
with sufficient access rights to the Apache GitHub mirrors).

Any suggestions?

Thanks,

- Mike

[1] https://github.com/apache/incubator-guacamole-client
[2] https://github.com/apache/incubator-guacamole-server
[3] https://hub.docker.com/r/glyptodon/guacamole/
[4] https://hub.docker.com/r/glyptodon/guacd/
[5] https://hub.docker.com/r/apache/
[6]

http://mail-archives.apache.org/mod_mbox/incubator-general/201604.mbox/%3CCANyrgvfAWifLkkvAccAV22Q9uyo8g3so=BJ0JFZ8oV16Bt=k...@mail.gmail.com%3E


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org







-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Namespacing of subproject Docker images vs. Incubator policy

[Jochen Theodorou]

Only partially related to the namespacing problem...

But does somebody here know who to contact if I wanted to have a docker 
image on https://hub.docker.com/u/apache/ ?


bye Jochen

On 29.08.2016 01:21, Mike Jumper wrote:

Hello all,

We, Apache Guacamole (incubating), would like to migrate our project's
Docker images to something beneath the ASF, but I am unsure how to
proceed, nor the form that this migration would best take.

We currently have two repositories which provide Docker images:
incubator-guacamole-client [1] and incubator-guacamole-server [2].
Prior to acceptance into the Apache Incubator, these repositories were
used to produce the "glyptodon/guacamole" [3] and "glyptodon/guacd"
[4] images respectively.

As there is already an "apache/*" organization defined at Docker Hub
(albeit a virtual desert) [5] and there was positive discussion
regarding including the images of incubating projects under that
organization [6], it seems that would be the logical and
straightforward choice ... but because one of those images ("guacd")
would not be namespaced by the project's own name, I'm unsure if this
is actually possible/allowed.

Ideally we would end up with a mapping like:

 incubator-guacamole-client -> apache/guacamole
 incubator-guacamole-server -> apache/guacd

Or, since we're incubating, perhaps:

 incubator-guacamole-client -> apache/incubator-guacamole
 incubator-guacamole-server -> apache/incubator-guacd

But again, I'm not sure if "apache/incubator-guacd" would be a
violation of policy.

Alternatively, a cleaner approach could be to define a Docker Hub
organization specific to the project, as that would provide a nice
analogy to the project/subproject relationship that exists between
Apache Guacamole the "guacamole" and "guacd" applications:

 incubator-guacamole-client -> guacamole/guacamole
 incubator-guacamole-server -> guacamole/guacd

But I'm not sure if THAT would be a violation of policy. Further,
after creating exactly such an organization for the sake of testing,
I've found that I can't set up the necessary linkage for enabling
automatic builds (the organization would need to be owned by a user
with sufficient access rights to the Apache GitHub mirrors).

Any suggestions?

Thanks,

- Mike

[1] https://github.com/apache/incubator-guacamole-client
[2] https://github.com/apache/incubator-guacamole-server
[3] https://hub.docker.com/r/glyptodon/guacamole/
[4] https://hub.docker.com/r/glyptodon/guacd/
[5] https://hub.docker.com/r/apache/
[6] 
http://mail-archives.apache.org/mod_mbox/incubator-general/201604.mbox/%3CCANyrgvfAWifLkkvAccAV22Q9uyo8g3so=BJ0JFZ8oV16Bt=k...@mail.gmail.com%3E

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Groovy 2.4.5-incubating

[Jochen Theodorou]

Am 21.09.2015 13:29, schrieb Paul King:

On Mon, Sep 21, 2015 at 3:37 PM, Jochen Theodorou <blackd...@gmx.org> wrote:


Am 21.09.2015 01:17, schrieb Justin Mclean:
[...]


- The file LineColumnCheck.txt looks like it's source code and is missing
an header. Is it Apache licensed or generated?



The file provides test data. It contains sample scripts which are compiled
and the line/column information that the test will check against. In the
repository the file has a header, but using == as comment marker. I have no
idea what in our build is removing the header. We have to investigate this

[...]

The  header is in master but not 2.4.5 though it looks like it is set
up for manual running - so we'll have to check it still works with such a
header in place and doesn't muck up the line/column information that the
test needs.


I created https://issues.apache.org/jira/browse/GROOVY-7596 for tracking 
this. But yes, I made the mistake of looking at master not the branch... 
silly me


bye blackdrag


--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Groovy 2.4.5-incubating

[Jochen Theodorou]

Am 21.09.2015 01:17, schrieb Justin Mclean:
[...]

Some other things you may want to consider:
- The convenience binaries are missing incubating from their name.


so far we have not done this, because our pre-apache binaries did not 
have the incubating. It produces a problem for things, that 
automatically download those... Needs a bit longer to be changed.


[...]

- The file LineColumnCheck.txt looks like it's source code and is missing an 
header. Is it Apache licensed or generated?


The file provides test data. It contains sample scripts which are 
compiled and the line/column information that the test will check 
against. In the repository the file has a header, but using == as 
comment marker. I have no idea what in our build is removing the header. 
We have to investigate this


bye Jochen

--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Permissive UI Libraries

[Jochen Theodorou]

Tk is a bit difficult to make not look like motif. It can be made look 
modern, no question, but it takes effort. And the lack of interest in 
the recent years made it a bit outdated with regards to accessibility 
and i18n. No question, you can fix all those. But is that a good base 
for an apache project with a few developer cycles?


Am 08.09.2015 18:11, schrieb Dennis E. Hamilton:

And let us not forget Tk, .

  - [;<).

-Original Message-
From: Dennis E. Hamilton [mailto:dennis.hamil...@acm.org]
Sent: Tuesday, September 8, 2015 08:12
To: general@incubator.apache.org
Subject: Permissive UI Libraries (was RE: [NOTICE] corinthia ...)

[ ... ]

-Original Message-
From: Greg Stein [mailto:gst...@gmail.com]
Sent: Monday, September 7, 2015 02:38
To: general@incubator.apache.org
Subject: Re: [NOTICE] corinthia PPMC+committer -= dortef, franz, gbg, ianc, 
jani, louis, pmkelly

[ ... ]
Given the UI landscape, and its licensing, I can see why Corinthia would
like to host elsewhere. One day, we'll see some permissive UI libraries

Cheers,
-g


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [NOTICE] corinthia PPMC+committer -= dortef, franz, gbg, ianc, jani, louis, pmkelly

[Jochen Theodorou]

Am 07.09.2015 03:11, schrieb Dennis E. Hamilton:

I can speak to the specific case.

The desire is to adopt Qt as the best-choice, most-cross-platform GUI
framework for Corinthia on the desktop.  The non-commercial,
open-source license for Qt is LGPL/GPL.  See
.

As I understand it, a second-thought alternative to full-up
dependence on Qt is to make an experimental implementation that
employs a wrapper API under which a Qt-specific integration layer is
introduced.  The Qt integration layer is meant to be optionally
replaceable by an alternative one and corresponding framework under
the wrapper API.  The wrapper API and integration layer for any
functionally-equivalent integration/replacement is TBD.  A cautionary
concern was raised about the prudence of having an
optional-replacement of an LGPL dependence rather than an
optionally-employable LGPL dependence.

No specific proposal or request for any sort of exception is at
legal-discuss or the LEGAL JIRA.


I am not sure that approach is realistic. I mean, if you say it must be 
optional and not required, then there must be an existing alternative. 
And that alternative must be not LGPL. If there is such a toolkit, then 
why not go with that right away? The project has to manage its resources 
well.


Also I am not fully understanding the problem I guess. It can't be 
source problem, as long as the LGPL source is not included. compiling 
against an public available LGPL source for dynamic linking itself can 
also not be the problem. I do see a problem in the distribution of the 
dynamic linked library. But if you do not distribute it and expect the 
system to have it, then it should be no deal breaker. I mean otherwise 
you could not compile against glibc or example.


And thinking this further... assuming QT is optional somehow. Why is it 
then suddenly ok to distribute it in the convenience binary? Imho it is 
not, even then.


Legal makes a difference for language/platform lgpl code. But why I 
don't understand. A ticket for LEGAL in that matter would be good, but I 
think that should be done by a member of the corinthia project. As I 
know legal, it will depend on the special case and there won't be a 
general answer.


bye blackdrag

--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [NOTICE] corinthia PPMC+committer -= dortef, franz, gbg, ianc, jani, louis, pmkelly

[Jochen Theodorou]

Am 06.09.2015 19:43, schrieb Peter Kelly:

On 6 Sep 2015, at 11:22 pm, Jochen Theodorou <blackd...@gmx.org>
wrote:

Am 06.09.2015 04:22, schrieb Dave Fisher: [...]

Also Apache needs a release policy for binaries that would allow
the best UX/UI API for the platform to be used even if it is GPL.
If you have subscribed to legal-discuss the last few months you
know why that discussion was impossible. If that can be worked
out then at least it would help other projects.


can you explain the case a bit? Do you link statically? What is the
license?


We wanted to use Qt, the open source version of which is LGPL. All
other suitable candidates we could find were similar; GTK is LGPL,
and wxWidgets has a license that is very close to LGPL. We also
needed to use WebKit, regardless of the toolkit involved, and that is
(mostly I think) LGPL also.


I would have thought about wxWidgets as well... true the license is 
basically LGPL, but "works in binary form may be distributed on the 
user's own terms" (https://en.wikipedia.org/wiki/WxWidgets#License). I 
would assume that allows the binary to be Apache Licensed for example. 
But Webkit blows it up again, yes.




There was some debate about whether or not it was ok to write an
application which used Qt, though we did not propose including any of
the actual Qt source code in the release artefacts. It would be used
as an external library, dynamically linked, similar to how many
programs use glibc.


my position on this is, it is ok as long as qt is not part of the 
binary, since then it has to be part of the system... And I think you 
mean this as well. Though, I doubt that works for QT under windows. GTK+ 
maybe, once the windows runtime becomes available again.



An assertion was made in the discussion that if we cannot develop our
app without using Qt, it should not be part of the project (I assume
this same argument would have been made if we had chosen one of the
others above). Given that this app was a major component (though by
no means all) of what we planned to do, it seemed that if that
argument was valid (and I don’t think it was, but I’m still not
sure), we would have to do so outside of ASF.


I think it would be bad to have the UI and the functionality separate - 
even if the UI part would be so much bigger. But that would allow other 
applications to use it as library independent of the editor. But given, 
that you are supposed to build a community and that the community most 
likely will want to use the editor in the beginning... I find that 
decision reasonable. Is licensing the project under LGPL an option? 
Afaik apache does not like that very much, but could allow it.



There were numerous other factors involved with our design to resign,
mostly involving personal disputes among PPMC members which I won’t
get into here out of respect for all involved. But the discussion
about licensing and implications for the project was one of the
factors, and certainly caused a division in the community.


Personal disputes will happen, just belongs to life imho. For me the 
licensing problem would be enough to move away from apache in your 
case... if LPGPL is not option for the project.


[...]
bye blackdrag



--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [NOTICE] corinthia PPMC+committer -= dortef, franz, gbg, ianc, jani, louis, pmkelly

[Jochen Theodorou]

Am 06.09.2015 04:22, schrieb Dave Fisher:
[...]

Also Apache needs a release policy for binaries that would allow the best UX/UI 
API for the platform to be used even if it is GPL. If you have subscribed to 
legal-discuss the last few months you know why that discussion was impossible. 
If that can be worked out then at least it would help other projects.


can you explain the case a bit? Do you link statically? What is the license?

bye blackdrag

--
Jochen "blackdrag" Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: apache binary distributions

[Jochen Theodorou]

Am 18.08.2015 18:46, schrieb Marvin Humphrey:

On Tue, Aug 18, 2015 at 2:02 AM, Kalle Korhonen


So what if a project (members) does not vote but unofficially
releases binary executable packages, perhaps along with source to some
other location than /dist/? Clearly, it's not an official release by Apache
policy but there the bits are in the wild anyway.


At Apache, software that is published beyond the group that develops it must
be assembled, vetted and voted in accordance with Release Policy and
distributed in accordance with Release Distribution Policy.

   http://www.apache.org/dev/release
   http://www.apache.org/dev/release-distribution


does this extend to convenience binaries and binaries not produced by 
the project itself?... let's say for example a windows installer



Apache is deliberately decentralized in that technical decisions are
officially delegated to a PMC, but projects are still obligated to follow
Foundation policy with regards to project governance, IP diligence, etc.  A
primary function of the Incubator is to prepare projects to self-govern in
accordance with Apache policy and traditions.


And a project could choose to just tolerate this such binaries, right?
[...]

bye blackdrag

--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: apache binary distributions

[Jochen Theodorou]

Am 17.08.2015 10:45, schrieb Branko Čibej:
[...]

So wait ... If the Subversion PMC releases source, and, say, Debian
creates a binary package called 'subversion-x.y.z' ... you're saying
that's trademark infringement and we should be telling all the people
who produce binary packages to stop using our registered trademark? Really?

Producing binaries is different from creating a derived work. Even if
packagers change the sources (which they often do, in minor ways, to
tune the build to their platform), it's less than sane to tell them they
should rename the packages because of that.

It would be different if their changes resulted in changed
functionality, but that's not what's happening.


My take so far is: The PMC decides upon if they want to allow for that 
or not. So the Subversion PMC could forbid the redistribution of 
packages named subversion-x.y.z... But that does not mean they have to. 
Where the PMC should get active in such matters is if something claims 
to be subversion, but really is not. But again the PMC is responsible 
for that.


bye blackdrag

--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: apache binary distributions

[Jochen Theodorou]

Am 07.08.2015 02:50, schrieb Roman Shaposhnik:

On Thu, Aug 6, 2015 at 1:15 AM, Jochen Theodorou blackd...@gmx.org wrote:

[...]

The assumption  that you're making is a reasonable one: only PMC is
authorized to make work available (which will mean that everything
else is derived work). That said, I'd appreciate if somebody can
point out to me the basis on which we make an assertion that
only PMC is authorized to produce releases of apache projects.


Official releases are released releases in the apache sense, meaning 
there has been a voting and in that the PMC votes are binding. For me 
that authorizes the PMC to produce official releases of apache projects. 
Of course unreleased releases can in theory be made by everyone.


[...]

IOW, what makes a binary convenience artifact an official ASF
artifact is not whether it got designated as such, but whether it
corresponds to an official source release produced by the PMC.


ok, noted

[...]

Then again nightly builds should be ok, if they will have the
same disclaimer?


No. Nightly builds are special precisely because they don't
correspond to an official source release.


understood


Or is it ok if the nightly build comes from
non-apache?


It is ok, but at that point it becomes 3d party artifact and as
such can't be promoted as part of ASF project.


can't be promoted means no link or description on the web page? Not even 
with disclaimer?


[...]

As I said -- that person(*) (even a PMC member of the project) as
a person has even more rights than a PMC does, except in one
crucial area -- that person can NOT speak on behalf of the project
(and that includes linking to that person's artifacts from the PMC
managed assets: website, wiki, etc.).

Other than that, that person is absolutely free to:
#1 produce maven binaries based on, really anything,
 including but not limited to snapshot of source tree
#2 distribute those binaries however he/she sees fit
 provided they can't be confused with project's binaries.
 Modifying versionID while leaving everything else
 as-is is considered acceptable.

#2 of course may be subject to constraints of distribution
channel. An example is a recently  cited Maven Central
policy where they are NOT allowing to publish SNAPSHOTs
AND they only allow owners of the groupID to publish.
Those constraints, of course, have nothing to do with
ASF or the project -- those are Maven Central constraints.


ok, as long as this is general opinion.

bye blackdrag

--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: apache binary distributions

[Jochen Theodorou]

Am 06.08.2015 02:43, schrieb Roman Shaposhnik:
[...]

As you probably remember we've discussed this issue not that long time
ago: http://thread.gmane.org/gmane.comp.apache.incubator.general/49852

The consensus there is that as long as you're communicating intent
clearly you can let downstream developers test/develop against your
development artifacts. IOW, the definition of developers starts including
downstream developers integrating with your project.


yes, I remember that discussion, but for me the outcome is not as clear 
as it is for you it seems. Especially with regards to communicating that 
intend and if it has to go through the release voting cycle. You usually 
don't do that for SNAPSHOTS or nightly builds and for the nightly builds 
the release guide is quit clear that it must not be communicated beyond 
the dev-list. I read that as: a link on the websites of the project is 
forbidden.



But anyway... le tme phrase some scenarios and question:

Let us assume httpd makes the release 2.4.10, a linux distributor takes the
source, adapts them (for example security patches), compiles packages out of
it and releases it as http://packages.ubuntu.com/vivid-updates/apache2-bin
in source and binary form. Then it means they took a release and made their
own release out of it, while using the apache name.


Correct. At that point it constitutes a derived work. The Apache License is
very permissive that way, but it is considered a good practice to distinguish
the derived work by at leas a version ID.

That is also, how all of the Hadoop ecosystem vendors are creating dervived
works when they distribute Apache Hadoop as part of their products. E.g.
the version string of Cloudera's Hadoop is: ASF_VERSION-CDH_VERSION.
This is in line with most of the Linux packaging guidelines as well.


the difference is that in Ubuntu I do for example:

sudo apt-get install apache2

that's it. No mentioning of a derived version in this at all. apache2 is 
the package name, something like 2.4.10-9ubuntu1.1 only a version 
string, which is maybe not looked at by the user.



The point being here, for the end-user this will be
the official release, not what is found on the apache servers. Why is this
ok?


Because technically it is an artifact that is a derived work.


Of course that makes a difference, but every version from version 
control is a derivative work.



It was also mentioned here, that for example publishing snapshot builds to
maven central is not allowed.


This is where it gets tricky with our current policy. Personally I see
absolutely
no reason to NOT publish Maven artifacts as widely as possible provide
that the version ID or name communicates the intent. It seems, however,
that I'm in a minority here (although truth be told nobody has been able
to communicate a convincing enough argument for why my approach may
be dangerous to the foundation and/or Projects).


Currently I read this thread as following... if a third party publishes 
a snapshot to bintray or wherever, there is not really a problem. But if 
the project does it, then it is. And if the third party is actually not 
a third party, but a contributor things get very very unclear.



What would happen if a third party would do this? Is the project/apache
required to do something about this? I mean if you read this:
http://mail-archives.apache.org/mod_mbox/incubator-general/201506.mbox/%3CD1B01671.4EE90%25rvesse%40dotnetrdf.org%3E
some even see nightly builds, not communicated beyond the dev-list on
non-apache servers already as a problem.


Third party is at complete liberty of doing so. Provide the artifact is marked
in such a way that is can NOT be confused with an official ASF artifact
(IOW it can be called a derived work).


not to be confused with an official ASF artifact... that's the part I am 
trying to extend my understanding. For me it is an official ASF 
artifact, if I download it from an ASF server. But then I have to 
include mirrors. And hat simplified version is already a problem... if I 
give a maven version information on an ASF page, does this make the 
maven package automatically an official ASF artifact, even though the 
download itself is not from ASF infrastructure? Same for links for 
example to docker image distribution servers... or let's say a link to 
an ubuntu package. On the other hand you can put disclaimers on the 
pages stating they are not official... Then again nightly builds should 
be ok, if they will have the same disclaimer? Or is it ok if the nightly 
build comes from non-apache? If that is ok, then why does the release 
document not say this and is instead very strict about not promoting 
anything even beyond the dev-list? It does not make sense for me and I 
am going in circles here.


Of course a third person would be someone unrelated to the project. So 
what they do is of lesser concern, unless they misuse things. But what 
if the person is ASF member, or contributor to that project, maybe even 
in the 

Re: apache binary distributions

[Jochen Theodorou]

Am 06.08.2015 08:22, schrieb Niclas Hedhman:

On Thu, Aug 6, 2015 at 8:43 AM, Roman Shaposhnik ro...@shaposhnik.org
wrote:


I honestly see no problem with that, again provided that the artifact can

NOT

be confused with the one coming from Apache project.


I think the problem lies in Trademarks. Debian's Tomcat7 is labeled
Servlet and JSP engine and its Tomcat8 is labeled Apache Tomcat 8 -
Servlet and JSP engine, yet I don't see Apache Tomcat project
creating/maintaining a Debian dist.

Now, is Debian allowed to call it Tomcat? Is it allowed to call Tomcat8
to BE Apache Tomcat8, when in fact(!) there are changes to the source,
such as the start script in Debian Tomcat is not original of Apache Tomcat,
but instead follows a Debian template for how those scripts should be
written. I am not sure what all the changes are, feel free to check;
http://anonscm.debian.org/cgit/pkg-java/tomcat8.git/tree/debian/patches

IF (like Mozilla) Apache decides to strike down on Debian and not allowing
it to use the same names, _I_ think it is a disservice to the users
(IceWeasel browser), but as it stands, Apache trademark licensing seems to
not really be followed (Perhaps Debian has some permission that was granted
long in the past... I may have missed that).


I think there is nothing in the apache license 2 forbidding the usage of 
the project name or even apache (version 1.1 and 1 have been different 
and did indeed require a permission). The trademark weapon is more one 
of last resort. For example to go against false releases with malicious 
code added and the distributor not willing to take it of the web.


At least I hope no-one has some crazy idea as that ;)

bye blackdrag

--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: apache binary distributions

[Jochen Theodorou]

sorry, I really tried, but it seems google is not a suitable tool to 
search through the incubator general list. It shows by far not all 
results it should show. There is a hint that some results are not shown 
because of privacy protection. Searching for my own name for exmaple 
shows only a single result... I know for sure I had more posts than that ;)


Next time I will archive such mails in my mail program instead. Learned 
something for the future


Am 03.08.2015 17:05, schrieb Alex Harui:

OK, I’ll bite.  Do you have links to where you got this information?

-Alex

On 8/3/15, 2:55 AM, Jochen Theodorou blackd...@gmx.org wrote:


Hi all,

some of the general discussion recently made me wonder about one point
with regards to binary distributions. It was pointed out, that a binary
distribution of a source code release has to be handled like a release
itself, and that there should be no download source of it outside of
apache. This seems to be one motivation for the asf having its own maven
repository.

I seem to misunderstand something here, or why can there be apache maven
artifacts in maven central and package in linux distributions for for
example httpd, if this policy is followed? I mean it was even suggested
to use the trademark to forbid the distribution through third parties. I
am quite irritated about this.

bye blackdrag

--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: apache binary distributions

[Jochen Theodorou]

Am 03.08.2015 21:46, schrieb David Nalley:

On Mon, Aug 3, 2015 at 5:55 AM, Jochen Theodorou blackd...@gmx.org wrote:

Hi all,

some of the general discussion recently made me wonder about one point with
regards to binary distributions. It was pointed out, that a binary
distribution of a source code release has to be handled like a release
itself, and that there should be no download source of it outside of apache.
This seems to be one motivation for the asf having its own maven repository.

I seem to misunderstand something here, or why can there be apache maven
artifacts in maven central and package in linux distributions for for
example httpd, if this policy is followed? I mean it was even suggested to
use the trademark to forbid the distribution through third parties. I am
quite irritated about this.

bye blackdrag



I am not aware of any policy that dictates that (but would love to see links.)


yeah, next time I will do that better. Getting the stuff out of here, 
will require me reading thousands of mails through that stupid web 
interface and google doesn't help either.



I am aware that releases MUST at least be distributed via
dist.apache.org [1], but that isn't exclusive, meaning the PMC is
welcome to distribute _released software_ via other means (PyPy, NPM,
Maven, Docker Registry, CPAN, Bintray, carrier pigeon, etc).

--David
[1] http://www.apache.org/dev/release.html#where-do-releases-go


The problem already starts with that what a release is on 
http://www.apache.org/dev/release.html


I read that as anything that goes beyond the dev-list is to be handled 
as release. It does not say by whom. And there is no mentioning of the 
releasing of released software, only the distribution of releases. But 
anyway... le tme phrase some scenarios and question:


Let us assume httpd makes the release 2.4.10, a linux distributor takes 
the source, adapts them (for example security patches), compiles 
packages out of it and releases it as 
http://packages.ubuntu.com/vivid-updates/apache2-bin in source and 
binary form. Then it means they took a release and made their own 
release out of it, while using the apache name. The PMC might or might 
not be involved in this. Of course this is no released release in the 
sense of ttp://www.apache.org/dev/release.html, since it was never voted 
on in this form and it never appeared in that form on 
www.apache.org/dist or repository.apache.org. The point being here, for 
the end-user this will be the official release, not what is found on the 
apache servers. Why is this ok?


It was also mentioned here, that for example publishing snapshot builds 
to maven central is not allowed. I guess in the release document they 
are basically to be handled as nightly builds and as such not for the 
general public, thus only for the dev-list. It was said, that having the 
SNAPSHOT appendix in the jar name as well as not being able to 
automatically get them via maven without having to add that tag is not 
enough for the end-user to know for, that this is no official release. 
And that if such things are going into the distribution repository, they 
have to be handled as release, including voting and such. For that I 
guess it does not matter if it is the apache repository or something else.


What would happen if a third party would do this? Is the project/apache 
required to do something about this? I mean if you read this: 
http://mail-archives.apache.org/mod_mbox/incubator-general/201506.mbox/%3CD1B01671.4EE90%25rvesse%40dotnetrdf.org%3E 
some even see nightly builds, not communicated beyond the dev-list on 
non-apache servers already as a problem.


Let us put that last part a step up... Let us assume someone takes one 
of the released sources of one of the java projects out there, makes 
maven artifacts out of it and publishes them at maven central. Is that 
ok? I mean that is very near the distributor case, so it should be ok, 
or not?


Oh and by chance I found the marks violation part: 
http://mail-archives.apache.org/mod_mbox/incubator-general/201506.mbox/%3CCAGHyZ6JFqYhozYjR%3DvvGeoRMafi5cgUo7L-tfyxZGVTf%2BgvR3A%40mail.gmail.com%3E



If the Docker Hub page wasn't under the control of the Geode PMC, then 
I'd say it was a marks violation and they'd have to seek out control of 
it or removal.



Personal opinion mostly of course, but that is one of the problem... 
lot's of opinions based on a few fixed rules, that make not always 
sense, since their intend is not documented and thus it cannot be seen 
if their application is as intended.


bye blackdrag

--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

apache binary distributions

[Jochen Theodorou]

Hi all,

some of the general discussion recently made me wonder about one point 
with regards to binary distributions. It was pointed out, that a binary 
distribution of a source code release has to be handled like a release 
itself, and that there should be no download source of it outside of 
apache. This seems to be one motivation for the asf having its own maven 
repository.


I seem to misunderstand something here, or why can there be apache maven 
artifacts in maven central and package in linux distributions for for 
example httpd, if this policy is followed? I mean it was even suggested 
to use the trademark to forbid the distribution through third parties. I 
am quite irritated about this.


bye blackdrag

--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSSION] Graduate Ignite from the Apache Incubator

[Jochen Theodorou]

Am 23.07.2015 05:13, schrieb Ted Dunning:

On Wed, Jul 22, 2015 at 6:54 PM, Valentin Kulichenko 
valentin.kuliche...@gmail.com wrote:


Concerns have been raised about the people behind the actual commits,

that

seems to be left open ?



The identity of the committers is never lost (at least to my knowledge). We
actually have the opposite problem of too many commits happening in
different branches because of our branching policy which requires a
separate branch for every ticket.



How are they preserved when the bug branch is deleted as per guidelines?


just to give the general idea and not claiming that the Ignite people do 
it like that.. normally what you do is the following:


1) create a bug-fix branch based on master
2) commit your changes to the bug-fix branch
3) test/verify by the community and CI
4) merge bug-fix branch to master
5) delete bug-fix branch

In this process there is no loss of commits, the information stays in 
the master branch. In git you normally keep only the branches people 
work on, or you use tags.


Step 4 can be done in multiple ways. Of course normally the first choice 
is the git based merge, but you can also work with a patch set (the 
author/date information is not lost by this) or cherry-pick (which is 
like duplicating the commit on another branch). branching off and 
merging again, can be seen in tools like for example gitk or with for 
example git log --graph. Examples can for example be seen on 
http://stackoverflow.com/questions/1838873/visualizing-branch-topology-in-git 
using different tools. Noteworthy here is that normal commits are 
handled similar to branches. In other words, git does not really know a 
concept like a branch as it was with svn/cvs. Instead it is an 
elementary part of the system, that every commit has a parent and 
possibly a child and from this results a commit graph. A branch is only 
a commit noted as head. Deleting a branch thus means only to delete that 
meta information. And unlike CVS/SVN git is based on a database. Even if 
you do git rm to delete a file, it is still in the database and not 
removed from history.


bye blackdrag

--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

[Jochen Theodorou]

Am 17.07.2015 09:31, schrieb Emmanuel Lécharny:
[...]

Now, I'm a bit scared : why the hell can't we make it easier to cut a
release at Apache for this project ? I mean, the infrastructure should
not be a limitation here : we do have a CI, we most certainly can tune
it to fit Groovy.


that would not change anything. What makes things complicated is points 
of human interaction in the middle of the release process. That won't be 
different with a better tuned CI


[...]

I'd like to remember everyone that each project is quite able to define
the way they do things, as soon as they fits in the Apache process,
which is not that rigid.


Not as rigid... on this list it has been made clear, that anything that 
is even remotely something like a release is to be handled as such. 
Furthermore, it was made clear, that third parties are supposed to be 
prevented to provide their own releases, even if it means to use the 
brand to force things. Even maven central is seen as evil in that sense. 
And of course any apache member is not allowed to do some kind f release 
on its own. This is just to give an example of the things that accompany 
the process. And those are rigid already.


bye blackdrag

--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [RESULT] [VOTE] Release Apache Groovy 2.4.4-incubating

[Jochen Theodorou]

Am 16.07.2015 18:49, schrieb Roman Shaposhnik:

On Thu, Jul 16, 2015 at 1:47 AM, Emmanuel Lécharny elecha...@gmail.com wrote:

Le 16/07/15 10:41, Justin Mclean a écrit :

Hi,


This vote passes with 4 binding +1 votes, no 0 notes, and 2 -1
binding votes.

If you read carefully I think you find there were 3 -1 votes on the binary 
releases.


True. I -1 the binary release. Interesting case : should we release if
we have as many -1 than +1 ?


Personally, I'm disappointed in the podling for not taking
care of feedback that seems really easy to take care of.


but not in time, because the apache process is too slow. What so you 
prefer? A unfixed zero-day vulnerability reported against an apache 
project, or a podling release which is not 100% according to strict 
apache views. We are not a TLP yet after all.


And this release is a special case.

That security fix is the only reason why we did want release ASAP. We 
own it to the community to be able to react to such things fast. And I 
really would not like to explain to our users that we could not do a 
release, because of a minor issue. If the apache process would not be so 
slow, we would of course have made it different. But waiting another 6 
days, while some will be in holidays already, would have been a problem.


bye blackdrag

--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

[Jochen Theodorou]

Am 13.07.2015 23:00, schrieb Justin Mclean:

Hi,


We don't bundle the source from any of those libraries true, but we do generate 
sources as part of our build using ANTLR and we do bundle the class files from 
the ANLTR and ASM projects in some of our jars and we do bundle the jars from 
some of those projects in some of our binary zips. So, only use of source files 
is important for NOTICE/LICENSE or would we need slightly different versions of 
those files in different places?


Yes only refer to what is bundled [1] and yes the NOTICE/LICENSE files would 
need to be different [2].

Thanks,
Justin

1. http://www.apache.org/dev/licensing-howto.html#guiding-principle
2. http://www.apache.org/dev/licensing-howto.html#binary



then source and binary distribution have to have different 
NOTICE/LICENSE files?


bye blackdrag

--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

[Jochen Theodorou]

Am 14.07.2015 07:26, schrieb Alex Harui:



On 7/13/15, 10:05 PM, Jochen Theodorou blackd...@gmx.org wrote:


then source and binary distribution have to have different
NOTICE/LICENSE files?


Yep, I think of it as the list of allergens in the package.  If you use
peanut oil to cook the raw ingredients, you’d better tell the consumer.


ok, but there is no harm in listing allergens that are not actually in 
there. So why can't we have a single NOTICE/LICENSE file that covers 
both cases? Is it not possible to say something that the binary 
distribution will additionally include this and that? Having to have two 
distinct files looks unnecessarily complex to me


bye blackdrag

--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

[Jochen Theodorou]

Am 13.07.2015 16:25, schrieb Paul King:
[...]

For binary releases:
- All are missing DISCLAIMER, LICENSE and NOTICE


These are all in the meta-inf directory within all the produced jars but
agreed should be in the root of the zips (already true for src zip) as
well.


I thought having hose in META-INF for jar files is common practice. At 
least the few apache jars I checked here either have none of those or 
they have them in that directory. What sense does it make to have those 
files in a ja root directory?


by blackdrag

--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: I still don't see your priorities

[Jochen Theodorou]

Hi again,

sorry, I was not clear enough when I mentioned time. I guess it did let 
you think in the wrong direction. 3 years is time, yes, but what counts 
is the work done and the diversity. What about contributors/committer? 
You should come with a couple of people (4+) that can work actively on 
the project. Also, just because you are an apache project does not mean 
you will automatically get more people. The name can help, but it is 
still your project, that has to do the actual work. And with work I mean 
not only development, but also community build. Collaboration comes with 
a healthy community.


And if you understand all that perfectly fine, then what keeps you from 
gathering a few people and make a proposal?



Am 04.07.2015 21:32, schrieb Stefan Reich:

Basic work for TinyBrain has been done. It's been at least 3 years.
Am 04.07.2015 19:26 schrieb Jochen Theodorou blackd...@gmx.org:


Am 04.07.2015 18:53, schrieb Stefan Reich:


You wait for something to exist, and THEN you support it?

How about taking something good that WANTS TO EXIST, and supporting that?



Stefan, you sill don't understand that the ASF is basically a bunch of
people supporting open source in their free time. All the infrastructure is
almost completely done by volunteers. If someone gets money for working on
an apache project, it is usually not the ASF doing the payments.
And given that time is of the essence I find it perfectly fine to expect
some basic work has been done already. 9 of 10 new opensource projects fail
in the earlest stages.

bye blackdrag

--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org







--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: I still don't see your priorities

[Jochen Theodorou]

Am 04.07.2015 18:53, schrieb Stefan Reich:

You wait for something to exist, and THEN you support it?

How about taking something good that WANTS TO EXIST, and supporting that?


Stefan, you sill don't understand that the ASF is basically a bunch of 
people supporting open source in their free time. All the infrastructure 
is almost completely done by volunteers. If someone gets money for 
working on an apache project, it is usually not the ASF doing the payments.
And given that time is of the essence I find it perfectly fine to expect 
some basic work has been done already. 9 of 10 new opensource projects 
fail in the earlest stages.


bye blackdrag

--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts

[Jochen Theodorou]

Am 26.06.2015 11:39, schrieb Jochen Theodorou:

Am 26.06.2015 09:19, schrieb Branko Čibej:

On 25.06.2015 09:17, Jochen Theodorou wrote:

[...]

nightly source tarballs? Is that really a thing?


Yes, it is, why wouldn't it be? Httpd isn't even written in Java, and
yet it can actually run on computers! :)


I was asking because whoever is able to setup an environment to build
httpd is surely also able to use the repository directly to get exactly
the version they want... in the Java world it can be more easy thanks to
Ivy, gradle and maven and you can go with almost no setup


I want to add, that it looks like httpd is a bad example for nightly 
builds, since (unless I am wrong) it seems there has been no activity in 
repository that I could call by anything daily recently. So if they 
should have nightly builds, I doubt their use.


bye blackdrag

--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts

[Jochen Theodorou]

Am 26.06.2015 09:19, schrieb Branko Čibej:

On 25.06.2015 09:17, Jochen Theodorou wrote:

[...]

nightly source tarballs? Is that really a thing?


Yes, it is, why wouldn't it be? Httpd isn't even written in Java, and
yet it can actually run on computers! :)


I was asking because whoever is able to setup an environment to build 
httpd is surely also able to use the repository directly to get exactly 
the version they want... in the Java world it can be more easy thanks to 
Ivy, gradle and maven and you can go with almost no setup


bye blackdrag

--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts

[Jochen Theodorou]

Am 24.06.2015 23:32, schrieb Ross Gardler (MS OPEN TECH):

For HTTPd I was referring to the assertion from Justin earlier in this thread  
FWIW, httpd always had nightly tarballs available for consumption and testing. 
(though reading that now I wonder if he meant source tarballs - which is an easy way of 
resolving this whole issue)


nightly source tarballs? Is that really a thing?

bye blackdrag

--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts

[Jochen Theodorou]

Am 24.06.2015 22:32, schrieb Emmanuel Lécharny:

Le 24/06/15 22:28, David Nalley a écrit :

[...]

More generally to the underlying issue that prompted this discussion:
With the concrete example of Geode's DockerHub presence, I don't think
it's acceptable:
https://registry.hub.docker.com/u/apachegeode/geode/

Specifically, it's promoting folks consume a nightly build.
There's no warning that this hasn't met the ASF standards for
software, or that this project hasn't even pushed out a release yet.
Then there's the fact that the dockerfile isn't even coming from the
ASF it's coming from: https://github.com/markito/geode-docker


That is a clear breach of The ASF release policy, I agree.


Just to clarify this... as far as I can see, both pages are not under 
the control of apache. The github page is not a mirror page from the 
apache organization as well. Why does the apache policy extend to 
non-apache pages?


bye blackdrag

--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts

[Jochen Theodorou]

Am 25.06.2015 15:13, schrieb Sean Busbey:
[...]

If the Docker Hub page wasn't under the control of the Geode PMC, then I'd
say it was a marks violation and they'd have to seek out control of it or
removal.


can you explain me how that is a marks violation?

bye blackdrag

--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts

[Jochen Theodorou]

Am 24.06.2015 14:04, schrieb Marvin Humphrey:
[...]

What differentiates the general public from developers is whether they are
aware of the conditions placed on the artifacts and thus exercising informed
consent.


What I don't understand is, why I am exercising informed consent if I 
read the something on a dev list, if I got there through google, a blog 
post, nabble or whatever. I mean I may not have searched for a snaphost 
for example, and only found a page explaining that may issue is solved 
if I do this and that. That could be on a blog for example.


The dev list restriction is for me just serving as fig leaf to have 
something defining this exercised consent.


Plus there are a ton of pages that link to nightly builds and snapshot 
on the official apache websites. There are only normally not on the top 
page, but in some developer or how to build section. From what I did 
read, I would have thought that this is not allowed.


bye blackdrag

--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Communicating intent around non-release, downstream integration binary artifacts

[Jochen Theodorou]

Am 23.06.2015 07:16, schrieb Marvin Humphrey:
[...]

How am I supposed to invite all the downstream developers of the
world to start integrating with my awesome feature FOO before it
gets formally released when our policy makes statement like:
If the general public is being instructed to download a package,
then that package has been released.


Rather than invite them in before you make a release, why not release
first and then invite them in?



Are we really suggesting that I can not present at conference, tweet
and otherwise promote the awesomeness of my project based on
'what's coming'?


Why not release before presenting, tweeting, or promoting?


I am not Roman, but my interpretation in combination with the above 
would be, that if releases require 72h+ and you cannot just upload it 
somewhere and say it is no release, that it takes ages. Something like 
continuous delivery for example looks for me impossible with apache.



IOW, I would like to focus on answering the question of how can we
empower our communities to effectively communicate *their* intent
of how *they* expect an artifact to be consumed.


They can communicate their intent by voting on a release.


if every provided download is effectively a release, then you need the 
voting and all before you can release... that takes ages. Imagine you do 
around 13 releases per year. You will be easily busy with voting for 
over two months in total.


bye blackdrag

--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Groovy release and LEGAL-171

[Jochen Theodorou]

Am 08.06.2015 09:07, schrieb Sergio Fernández:

Hi,

my two cents without knowing in detail the issue:

Could I make a clean build from a source release without that file?

Without looking to the source code, I'm pretty sure it could be replaced by
the right flags of the maven-javadoc-plugin...


can it be used outside maven? Becuase we are talking about a gradle build.

bye blackdrag

--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: You know what... Apache is just too complicated.

[Jochen Theodorou]

Am 18.05.2015 20:35, schrieb Stefan Reich:

Lots of rules, Americans in the background... I don't see that it works.

Why don't we spend our time just PRODUCING SOMETHING?

All you'd have to do is connect programmers to projects. Simple. Why all
the rules?


I can give you my take:
Contributors will more or less give their free time for no money, so 
they want recognition in exchange. That and legal stuff is what most of 
those rules are about.


Since I am too involved with Groovy I am too biased to comment about 
JavaX, or if it fits for Apache. But I can tell you, that as soon as you 
have to deal with more than a handful of people you know privately 
and/or if people start actually looking at what your stuff does, things 
easily start to get socially complicated.


bye Jochen

--
Jochen blackdrag Theodorou
blog: http://blackdragsview.blogspot.com/


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [GROOVY] mailing lists are ready, see you there!

[Jochen Theodorou]

Am 26.03.2015 18:16, schrieb Bertrand Delacretaz:

Hi,

See https://issues.apache.org/jira/browse/INFRA-9339 - to subscribe
use listname-subscribe@groovy.a.o, and let's continue the groovy
podling discussions on that dev list.


not listname-subscribe@groovy.incubator.a.o ?


bye blackdrag


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Ignite (Incubating) 1.0-RC3

[Jochen Theodorou]

Am 22.03.2015 00:09, schrieb Marvin Humphrey:
[...]

Because release candidate and RC are specialized terms with
precise meaning at Apache and because we make a strong legal
distinction between released and unreleased code, this is
extremely confusing.  Having something named RC which is also an
official Apache release is... gah, it makes my brain hurt.

Please consider adopting different terminology in the future --
alpha, beta, golden master candidate / GM candidate, etc.


Being new at Apache...how is RC and release candidate related to 
released and unreleased code?


Normally a release candidate is code ready for release, that if nothing 
has been found, will result in a full blown release with unchanged code 
base. The terms alpha and beta don't catch that at all. They are for 
earlier versions. I did never hear of golden master candidate / GM 
candidate. So what is a generally understandable wording for RC if RC 
is not supposed to be used here.


bye Jochen

--
Jochen blackdrag Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Ignite (Incubating) 1.0-RC3

[Jochen Theodorou]

Am 21.03.2015 10:47, schrieb Branko Čibej:
[...]

Do you happen to know exactly which versions of those files were
imported? I looked at the ConcurrentHashMap implementation and compared
the current version on that site:

 
http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr166e/ConcurrentHashMapV8.java?revision=1.123


with the one in the Ignite release package, and the differences are far
larger than just license header changes:

 https://paste.apache.org/p/3SAz


I suggest comparing with the history of the OpenJDK8 file: 
http://hg.openjdk.java.net/jdk8/jdk8/jdk/log/687fd7c7986d/src/share/classes/java/util/concurrent/ConcurrentHashMap.java


There have been quite a few changes in jdk8 for this map afaik

bye Jochen

--
Jochen blackdrag Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Groovy Incubation proposal

[Jochen Theodorou]

Am 16.03.2015 09:25, schrieb Upayavira:

When Stephen Connolly says ”We @ Maven will have a full dump of the
Codehaus JIRA and we have a VM set
up to test migration…” isn’t he implying that the Groovy issues are
*included* in that? I.e. there’s not so much for you to worry about
here?


Even if Stephen gets a full dump, this does not mean we will get the 
Groovy part out of it. Ben was so far telling us he cannot give it out 
like that, because of private and internal data in there. Instead he 
suggested a json export (which most likely will not contain everything)


So unless Stephy has this clear with his employee I stand on the part, 
that we don't have that.


bye Jochen

--
Jochen blackdrag Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Groovy Incubation proposal

[Jochen Theodorou]

Am 13.03.2015 17:49, schrieb Stian Soiland-Reyes:
[...]

Is the wider Groovy community aware that transitioning to Apache is not
done overnight? There is no guarantee this will be complete by mid-April,
which to me sounds optimistic.


well, once we are accepted we will communicate that. There is no need to 
come with such news if you are not going to accept anyway



Have anything be done to ask Codehaus for an extension of support during
the migration process?


Codehaus is out of money for quite a while already.

bye Jochen

--
Jochen blackdrag Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Groovy Incubation proposal

[Jochen Theodorou]

Am 13.03.2015 22:38, schrieb Stephen Connolly:

(Disclosure Ben works for my employers, so I have slightly more ability to
bend his ear. As a result I got him to agree to do two full exports from
JIRA, one to let us test the process and a second when we are ready to
migrate)


ah ok, that explains it. It does not look like we get the privilege so far

bye Jochen

--
Jochen blackdrag Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Groovy Incubation proposal

[Jochen Theodorou]

Am 13.03.2015 22:37, schrieb Stephen Connolly:

We @ Maven will have a full dump of the Codehaus JIRA and we have a VM set
up to test migration...


you mean more than a JSON export lacking comments and attachements?

bye Jochen

--
Jochen blackdrag Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Groovy Incubation proposal

[Jochen Theodorou]

Am 13.03.2015 13:28, schrieb Benson Margulies:
[...]

This has nothing to do with the start of incubation in my view.


+1

I really think this point has been made clear by every one. Is really 
the only discussion point about something that is supposed to happen 
once we are incubation? Shouldn't we focus more on the things that get 
prevent the project from entering incubation? Because my current 
impression is that there is no such point.


bye Jochen

--
Jochen blackdrag Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Groovy Incubation proposal

[Jochen Theodorou]

Am 12.03.2015 10:57, schrieb Bertrand Delacretaz:

Hi,

On Wed, Mar 11, 2015 at 8:08 PM, jan i j...@apache.org wrote:

...The proposal talks several places about a vibrant community and the initial
commiters are only 5...


As others have said this was discussed while preparing the proposal. I
also agree that it's fine to include only the core Groovy committers
to enter incubation, as usual it will be their task to grow that
community before graduating.


community equals committers?

Anyway... how many committers would you guys find appropriate to exit 
incubation - whenever that will be? 5 seems not to be enough. Not asking 
for an exact number here of course.


bye Jochen

--
Jochen blackdrag Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Groovy Incubation proposal

[Jochen Theodorou]

Am 12.03.2015 17:21, schrieb Ted Dunning:

On Thu, Mar 12, 2015 at 4:04 AM, Jochen Wiedmann jochen.wiedm...@gmail.com
wrote:


   * several writers of documentation (without committer privileges)
   * one or two creators of graphics (icons, or whatever, without
committer privileges)
   * one or more organizations providing hosting services, and the like


This is a good list.  But I take strong issue with the without committer
privileges part.

If somebody is contributing, make them committers.  Expect them to be
responsible about what they commit and follow whatever process there is.


If talk about say 10 commits within 3 months, sure. Just does not happen 
for 90% of the contributors. Many work on a project at their workplace 
and once the problem the have faced is solved they walk away again.


bye Jochen


--
Jochen blackdrag Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Groovy Incubation proposal

[Jochen Theodorou]

Am 12.03.2015 18:15, schrieb Roman Shaposhnik:
[…]

In short:
* blocking proposal on the # of initial committers -- no, or at
least I don't think so.
* killing ourselves over reaching every single contributor on GH -- no.
* doing a reasonable due diligence *while incubating* on reaching out
  to past contributors and having a conversations with them (IF they
  are interested!) -- ABSOLUTELY!


good, that means you don't see a problem for the acceptance of the proposal

bye Jochen

--
Jochen blackdrag Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Groovy Incubation proposal

[Jochen Theodorou]

Am 12.03.2015 12:04, schrieb Jochen Wiedmann:

Hello, Jochen,

On Thu, Mar 12, 2015 at 11:14 AM, Jochen Theodorou


community equals committers?


No. The community is more than the team of committers. I'm sure you
understand. OTOH, the set of committers can be considered a
representation of the community.

I am quite certain, most Incubator members would accept a project to
have a vibrant community, if the project could show, for example,

   * several writers of documentation (without committer privileges)
   * one or two creators of graphics (icons, or whatever, without
committer privileges)
   * one or more organizations providing hosting services, and the like

assuming them to be independent of each other. However, that would be
most unusual for an Apache project: In most cases, the committers are
the active project contributors.


for example: 
https://github.com/groovy/groovy-website/graphs/contributors 
groovy-website is currently the stuff shown at groovy-lang.org That 
shows 23 contributors without commit rights in something that does not 
even exist for a year.


bye Jochen

--
Jochen blackdrag Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Groovy Incubation proposal

[Jochen Theodorou]

Am 11.03.2015 20:08, schrieb jan i:

The proposal talks several places about a vibrant community and the
initial commiters are only 5.

I am not raising it as a problem, just would like a little explanation.


It is only 5 because we did work mostly with github pull requests. Many 
people just spend a little time to get their things fixed or their 
feature implemented and then become inactive (in terms of code 
contribution) again.


bye Jochen

--
Jochen blackdrag Theodorou - Groovy Project Tech Lead
blog: http://blackdragsview.blogspot.com/
german groovy discussion newsgroup: de.comp.lang.misc
For Groovy programming sources visit http://groovy-lang.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org