Re: Font size on incubator site too small?

[Andy Seaborne]

Or default to the user's choice of font family in the browser.

On 28/11/2019 06:01, Dave Fisher wrote:

Reading glasses will enlarge things for many of us.

I’m certainly in favor a larger font, but please keep it serifed.

Sent from my iPhone


On Nov 27, 2019, at 11:48 PM, Ted Dunning  wrote:

The problem might just be that pixels are getting smaller.




On Thu, Nov 28, 2019 at 12:15 AM Justin Mclean 
wrote:

Hi,

Is it just my old eyes or do other people also find the font size too
small on the incubator site? While it does scale well and easy for a user
to increase the size, have we set the default too small? This may of course
depend on platform and browser use and I’ve not done any exhaustive
checking, as the measurement is in px that may be the issue. The body text
seem to be set to 14px, (which is 10.5pt and that should be in pt or ems
not px) and 12pt (16px) is generally recommended as a minimum size.

Thanks,
Justin
-
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: [VOTE] Shut down unused/inactive incubator lists

[Andy Seaborne]

+1



On 21/01/2019 00:11, sebb wrote:

The following lists are all but inactive:

announce@ Last post Jan 2008
android-interest@ Last post Mar 2011
dev@ - only general circulars
jaxws-tck@ (private) Last post 2012
projects@ Last post Jul 2011
user@ - only general circulars

I think they should be shut down.

Please vote so an Infra Jira can be raised to shut them down.
They can have a bounce message added to direct posters to
general@/private@ as appropriate

[  ] +1
[  ] -1 - give a reason please

Please vote by end January 2019

Sebb.

-
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: Poddlings length of time in the incubator

[Andy Seaborne]

On 26/08/18 00:43, Justin Mclean wrote:

Hi,

Below is a list of podlings that have been in the incubator for more than 2 
years. What can be done to encourage these projects along? Do they have missing 
mentors or need some other assistance?

While not all podlings graduate in 2 years and may move towards graduation at 
different rates, I’m not sure that the being in the incubator for longer than 2 
years achieves much.

Looking like they are soon to graduate:
Airflow
Singa
Unomi

Reasonably active:
Gearpump
S2Graph
Tamaya
Taverna
Tephra
Toree

Little or low activity:
BatchEE
Edgent
Joshua
Milagro
Myriad
ODF Toolkit
Pony Mail
Quickstep
Rya
Samoa
SensSoft

Possibly retirement?
ODF toolkit (7 years in the incubator!)

Retiring:
Gossip

There was some talk of BatchEE graduation ion their list but seems little 
activity. Could the mentors of that project follow up on that?

Edgent has had little activity since IBM staff have left and I'm not sure what 
can be done there.

Is there any reason that S2Graph, Taverna and Tephra are not closer to 
graduation?


Taverna has had a decent uptick on the technical side driven by a 
successful GSoC.  Energy from the PPMC is needed to make sure all code 
has been released, or at least passed licensing, (including moving other 
stuff out for now), then graduate.


Andy




Thanks,
Justin



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

Re: [VOTE] Release Apache Taverna Language 0.16.0-incubating RC1

[Andy Seaborne]

bcc: dev@taverna

+1 (binding)

Source downloaded,built (java8 - fails on java10; the podling is aware 
of this) and tests pass.


Checksum and sigs verified

DISCLIAMER, LICENSE and NOTICE present.

---

The POM parent (separate release) includes other maven repos
  https://dl.bintray.com/
  https://repo.spring.io/
  https://jcenter.bintray.com/

but I'm told everything is in maven central. Raised TAVERNA-1051.

Andy

On 21/05/18 10:57, Stian Soiland-Reyes wrote:

The Taverna PPMC has voted to release:

   Apache Taverna Language 0.16.0-incubating

with +4 PPMC-binding votes. This email is the IPMC vote.

   
Vote thread:

https://lists.apache.org/thread.html/29405e13efcd3282e978982c2c4c02b1d1bf683460ce618c7248617a@%3Cdev.taverna.apache.org%3E

Result:
https://lists.apache.org/thread.html/6c30d76520c2e933c4b93db7dc87cef42f2d34871f0b6f334020d451@%3Cdev.taverna.apache.org%3E


This carries forward one +1 IPMC binding vote from myself.


Apache Taverna Language is a set of APIs for workflow definitions (SCUFL2),
Research Object Bundles and workflow inputs/outputs/run (DataBundle), as
consumed and produced by the Apache Taverna workflow system.

The API includes support for the legacy formats from Taverna 2 and Taverna 1,
and can be also used independently of Apache Taverna 3.  The command line tool
tavlang can be used for conversion and inspection of research objects and
workflow bundles.




The release candidate to be voted over is available at:

https://dist.apache.org/repos/dist/dev/incubator/taverna/source/taverna-language-0.16.0-incubating-RC1/


Checksums:

$ sha1sum *zip
1f6050994b4bd2661f343119cdcb18b83dc362cf  
apache-taverna-language-0.16.0-incubating-source-release.zip

$ sha256sum *zip
bcdba80fbea54b1532cb81b6846e5711f1efe98ad289ecd4a2c6dd2833767115  
apache-taverna-language-0.16.0-incubating-source-release.zip

$ sha512sum *zip
008672c7f7cb1e6e461a2d5113aa111208970cfe9e0b3507fb3a34bc95957db094f0d8e8829beca9496cfa6a6d023943409335839bacd0bdedc82db87d14b9aa
  apache-taverna-language-0.16.0-incubating-source-release.zip
s




Build the release candidate using:

 mvn clean install




The release candidates correspond to the following git commit:

https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-language.git;a=commit;h=c48ef9d339d7d68791691617ef2ddc56d195131e


The release candidate is signed with an (updated) GPG key:
https://www.apache.org/dist/incubator/taverna/KEYS


A staged Maven repository is available for review at:
https://repository.apache.org/content/repositories/orgapachetaverna-1019


The changelog for this release is available from JIRA:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12334881=12318322



Please vote on releasing these packages as:

   Apache Taverna Language 0.16.0-incubating


The vote is open for at least 72 hours and passes if a majority of at least
three +1 Apache Incubator PMC votes are cast.

[ ] +1 Release this package
[ ]  0 I don't feel strongly about it, but don't object
[ ] -1 Do not release this package because...


Anyone can participate in testing and voting, not just IPMC members,
please feel free to try out the release candidate and provide your
votes!

How to review a release? https://s.apache.org/review-release




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

Re: Urgent: Regarding Java package name change to org.apache.*

[Andy Seaborne]

On 04/08/17 13:09, Shane Curcuru wrote:

John D. Ament wrote on 8/4/17 7:59 AM:

On Fri, Aug 4, 2017 at 7:17 AM Shane Curcuru  wrote:

...snip...

- Other reverse domain names *really* should change to org.apache;
otherwise it's just confusing.



Agreed.  The one caveat to all this is the implementation of javax.
namespace which is typically required and managed by the Geronimo TLP
(typically).

...snip...

Good point - any package names where there's a well-known technical
standard that specifies package names takes precedence for naming.
That's what a normal user would expect, and they also (typically)
understand there's a difference between the standard API names and the
actual implementation of the API they've downloaded.



We seem to have lost the community impact.  Projects with a existing 
pre-ASF history can have a halo of support in tutorials, books, etc (not 
from the donating corp) that all contribute to the success of a project.


The principle that the project outputs come from Apache can be achieved 
in various ways.  State the principle not the mechanism.


Andy

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

Re: Urgent: Regarding Java package name change to org.apache.*

[Andy Seaborne]

On 03/08/17 23:20, John D. Ament wrote:

Which must's do you see greg?

On Aug 3, 2017 1:09 PM, "Greg Trasuk" <tras...@stratuscom.com> wrote:


Does this actually need to be policy?  What’s the harm to the foundation
if a project continues to use a non-Apache package name, assuming that the
code was donated appropriately?



>>> 1) package names with reverse domains MUST be renamed
>>> before graduation or have an IPMC approved plan for renaming

SHOULD
(i.e. it needs a justification but isn't absolutely prohibited)

>>> 2) Projects who expect that their future users outnumber
>>> current users are highly encouraged to rename packages

+1

>>> 3) Other projects are not required to rename packages and
>>> backward compatibility is sufficient reason to not rename packages.

So there seem to be several cases:

Donated names should be fine.  (What about Maven coordinates here?)

.com really ought to migrate at the first convenient moment.
Non-donated, non-".com", less pressure but ought to migrate.
(Maven coordinates MUST change on entering the incubator.)

Andy


Certainly, it should be a goal for all projects to use o.a.* package
names, but if you look around the Foundation’s projects, you’re probably
going to find lots of non-o.a.* packages.  So it seems like this is another
case of “Incubator has one (sort-of) policy, while the rest of the
Foundation does its own thing” cases.  And that being the case, it seems
like an unreasonable imposition on podlings.

I’d suggest taking out the MUSTs wherever possible, and having mentors
make “should”, or maybe even “oughta” recommendations.  Apache is already
seen as unfriendly enough to podlings.

Cheers,

Greg.

On Aug 3, 2017, at 12:34 PM, John D. Ament <johndam...@apache.org>

wrote:


One caveat - if your packages are "com.theoldcompany.someproject" they
should be renamed to "org.apache.someproject" before graduation.  If you
have "org.someproject" already or just "someproject" as your package

names,

that's not a naming issue so I don't see that ever blocking graduation.

John

On Thu, Aug 3, 2017 at 12:25 PM Alex Harui <aha...@adobe.com.invalid>

wrote:



OK, so to summarize a more refined recommendation:

1) package names with reverse domains MUST be renamed before graduation

or

have an IPMC approved plan for renaming
2) Projects who expect that their future users outnumber current users

are

highly encouraged to rename packages
3) Other projects are not required to rename packages and backward
compatibility is sufficient reason to not rename packages.

Or should #2 also be a MUST?

-Alex

On 8/3/17, 8:34 AM, "Andy Seaborne" <a...@apache.org> wrote:




On 03/08/17 15:51, Julian Hyde wrote:

It rarely comes down to the IPMC or the Board dictating how a project
names its java classes (does anyone recall an instance?), so it’s

mainly

the project’s discretion. In my opinion, where the project is on its
adoption curve is an important consideration.


+1


Most projects that enter the incubator are early on the adoption

curve.

Their future users outnumber their current users. The earlier these
projects make the change to org.apache, the fewer people they will
ultimately impact. It seems that gobblin is in this category.

A few projects, such as Flex, are already near the top of their
adoption curve. The cost/benefit of renaming is not as compelling.


Jena was not early on the adoption curve. Long term compatibility has
been, and is, a major element of the project culture.  Importantly,
there are active users who answer questions (here, elsewhere), external
web tutorials, books etc referring to the pre-ASF API.  We have a
responsibility to them as well.

"add an API" is more stuff that a small set of volunteer contributors
(Jena has had no paid contributors working on) could not have coped
with.  If a project has the capacity, sure. Not all project will.

Set the expectations too high and it is implicitly a filter for a
certain kind of project in size and structure.

Andy




Julian



On Aug 3, 2017, at 7:37 AM, Alex Harui <aha...@adobe.com.INVALID>
wrote:

 From the peanut gallery:

Does the PPMC get to decide what constitutes a "very good reason" or
does
the IPMC and after graduation, the board?

Flex has not changed its packages in the 5 years at Apache.  We felt
backward compatibility was and is a "very good reason".  It was way
more
important to not require folks to alter their code in order to move

to

the
Apache versions of Flex.  Also, we are not using Java/Maven so there
isn't
really a shading option.

On the other hand, it seems like it could be confusing for Apache
projects
to have packages starting with "com.".  Flex's packages start with
"mx" or
"spark" (the component set names).

Seems like a more refined guidance would

Re: Urgent: Regarding Java package name change to org.apache.*

[Andy Seaborne]

On 03/08/17 15:51, Julian Hyde wrote:

It rarely comes down to the IPMC or the Board dictating how a project names its 
java classes (does anyone recall an instance?), so it’s mainly the project’s 
discretion. In my opinion, where the project is on its adoption curve is an 
important consideration.


+1


Most projects that enter the incubator are early on the adoption curve. Their 
future users outnumber their current users. The earlier these projects make the 
change to org.apache, the fewer people they will ultimately impact. It seems 
that gobblin is in this category.

A few projects, such as Flex, are already near the top of their adoption curve. 
The cost/benefit of renaming is not as compelling.


Jena was not early on the adoption curve. Long term compatibility has 
been, and is, a major element of the project culture.  Importantly, 
there are active users who answer questions (here, elsewhere), external 
web tutorials, books etc referring to the pre-ASF API.  We have a 
responsibility to them as well.


"add an API" is more stuff that a small set of volunteer contributors 
(Jena has had no paid contributors working on) could not have coped 
with.  If a project has the capacity, sure. Not all project will.


Set the expectations too high and it is implicitly a filter for a 
certain kind of project in size and structure.


Andy




Julian



On Aug 3, 2017, at 7:37 AM, Alex Harui  wrote:

 From the peanut gallery:

Does the PPMC get to decide what constitutes a "very good reason" or does
the IPMC and after graduation, the board?

Flex has not changed its packages in the 5 years at Apache.  We felt
backward compatibility was and is a "very good reason".  It was way more
important to not require folks to alter their code in order to move to the
Apache versions of Flex.  Also, we are not using Java/Maven so there isn't
really a shading option.

On the other hand, it seems like it could be confusing for Apache projects
to have packages starting with "com.".  Flex's packages start with "mx" or
"spark" (the component set names).

Seems like a more refined guidance would be that:
1) packages starting with "com" (and maybe org.somethingOtherThanApache)
should be changed as soon as possible/practical
2) there is no recommendation for other package prefixes

My 2 cents,
-Alex

On 8/3/17, 5:42 AM, "Shane Curcuru" > wrote:


John D. Ament wrote on 8/2/17 9:13 PM:

On Wed, Aug 2, 2017 at 8:54 PM Roman Shaposhnik 
wrote:


On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari 
wrote:

Hi all,

In regards to the recently incubated project - Gobblin, we were
wondering
about the policy around renaming Java package names to org.apache.* Is

it a

mandatory requirement or good to have?

The reason to ask this is that while we see many projects have
migrated

to

use org.apache.* package name for their Java source files, the Kafka
project uses kafka.* for Scala sources and org.apache.kafka.* for Java
sources.

Please let us know as soon as possible, because we are in process of
renaming the  packages but if not mandatory we would want to keep

gobblin.*

package name and avoid the cost of downstream migrations and backwards
incompatibility.


You don't have to do it right away, but it is a requirement unless you
have a really,
really, really good reason of why you can't do that.



I'm not aware of any requirement around Java package naming.  IN fact,
last
time it came up it was clear that its a best practice only, and doesn't
have any actual naming requirements.


John: Do you have a link to that discussion?  I'm of the mind that it's
an expected best practice, unless you have a really, really good reason
otherwise.

Abhishek: Can you describe in more detail what these packages do in the
context of your software product?

In general, yes, I'd echo Roman's point strongly for the primary
external API that most users would call:


Or to put it a different way: during your eventual graduation this
question will be
asked and you better have a really, really good explanation if you're
still using
something other than o.a.


That is, supporting packages, or things that are standards, or things
that are specific plugins that integrate with external code - those I
could understand staying with a non-a.o package name for compatibility
or other reasons.

But the main program that users run in the JVM, or the primary Gobblin
classes that users integrating the code into their application?  That
should be in an org.apache.gobblin.* package.

Simple "backwards compatibility for users" as an argument is only
suitable if you're deprecating and have a plan to switch in the
reasonably-near future after graduation.  Not for the long term.

Thanks for raising the question early!



Thanks,
Roman.


--

- Shane

https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.apach 

Re: Urgent: Regarding Java package name change to org.apache.*

[Andy Seaborne]

On 03/08/17 05:13, Roman Shaposhnik wrote:

On Wed, Aug 2, 2017 at 6:13 PM, John D. Ament  wrote:

On Wed, Aug 2, 2017 at 8:54 PM Roman Shaposhnik 
wrote:


On Wed, Aug 2, 2017 at 5:40 PM, Abhishek Tiwari  wrote:

Hi all,

In regards to the recently incubated project - Gobblin, we were wondering
about the policy around renaming Java package names to org.apache.* Is

it a

mandatory requirement or good to have?

The reason to ask this is that while we see many projects have migrated

to

use org.apache.* package name for their Java source files, the Kafka
project uses kafka.* for Scala sources and org.apache.kafka.* for Java
sources.

Please let us know as soon as possible, because we are in process of
renaming the  packages but if not mandatory we would want to keep

gobblin.*

package name and avoid the cost of downstream migrations and backwards
incompatibility.


You don't have to do it right away, but it is a requirement unless you
have a really,
really, really good reason of why you can't do that.



I'm not aware of any requirement around Java package naming.  IN fact, last
time it came up it was clear that its a best practice only, and doesn't
have any actual naming requirements.


I'm not a policy wonk, but for every single podling I've witnessed this
has been a very strong bias to be in o.a namespace.

Speaking as an IPMC member I would like to see new projects migrate
into o.a namespace unless there's a really good reason not to.

Or to put it another way, if you want to avoid threads like this one:
http://markmail.org/message/2bsrtgckuuihhnv4
during your graduation VOTE -- it is better to think about rename now.


Jena was in a similar position with the main APIs under non o.a package 
spaces.


We waited until a major version came along and that was several years 
after graduation.  While it had always been the intent to change, we 
could see that there was going to be major version hop due to othe 
factors and we didn't want to do it twice. We did move non-API code 
under o.a much earlier on an piecemeal basis.


Jena users also have data with URI naming based on host names from our 
origins in HP. We have not moved those to a.o names but encourage 
migration though outputting some warnings when it is encountered and can 
easily changed.


I think it sends a positive signal to new contributors to make the 
package change but it isn't always practical to do so by graduation. 
The user community is already impacted by moving the mailing lists and 
web sites etc.


For JVM-related projects, the maven coordinates change on entering 
incubation. That is a strong enough signal.


Andy


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

Re: Granting access to Jenkins

[Andy Seaborne]

Done

On 28/06/17 10:26, Henri Yandell wrote:

Could a PMC Chair type person grant access to Jenkins for Ly please (login
lxn2)?


https://cwiki.apache.org/confluence/display/INFRA/Jenkins#Jenkins-HowdoIgetanaccount

I gave it a shot, but I don't believe I have the correct permissions.

Thank you,

Hen



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

Re: Is the incubator full?

[Andy Seaborne]

On 25/08/16 07:34, Sergio Fernández wrote:

> I think you may be seeing signs of self-throttling. Basically if the
> new proposal
> comes in and there's nobody interested in mentoring it -- well the project
> won't
> go in.


Well, that just 1% of the work. Every body could easily volunteer for
mentoring; most os the work at that phase is done by the champion. But what
really requires time is actually mentoring the podling. My feeling is (I
have no figures) that is most of our current podling we have just 1-2
active mentors. That would be another way to look to that detail.


That agrees with my experience.

A commitment to mentoring for 2 or more years is substantial. My 
experience has been that mentors fade away for all the obvious reasons 
of volunteers+(lack of)time.  Signing up to mentor is the easy part and 
everyone is well-intentioned.


So is the incubator full?  No, but it needs to be careful about the 
nature of the set of mentors.


Andy

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

Re: [VOTE] $podling.apache.org is the same as $podling.incubator.apache.org

[Andy Seaborne]

+1 (binding)

Andy

On 28/06/16 15:28, John D. Ament wrote:

All,

Its been discussed a few times, and I'd like to provide clear feedback to
the infra team on how to implement going forward.

Typically, the addresses $podling.apache.org and $
podling.incubator.apache.org work, and have worked for a while.

This is a call to vote on whether the IPMC agrees to this or not.  If they
do, I will ask infra to further clean this up, as DNS seems to be an issue
at times for podlings.  The benefit is that for SEO, the website URL does
not change.

I'm going to leave this open for 72 hours, at least and hope for some
binding votes on this subject.

[+1] I want the two URLs to both work the same.
[+/- 0] Don't care
[-1] I want the $podling.incubator.apache.org URL to be the one that works,
including emails.

John




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

Re: New mentors for Taverna?

[Andy Seaborne]

Hi all,

I'm one of the "semi-active mentors" of Taverna. In my case, I have a 
new $job, which is related to some Apache communities but not Taverna. 
A new job is a busy time so I'm really not able to properly support the 
podling at the moment.  I wish I could but I also have to be realistic.


Taverna is (I believe) in good shape. Having done an incubator release 
of part of the codebase, they understand and take the IP issues 
seriously.  They have added a person to the PPMC.  All-in-all, good 
progress towards graduation and getting more of the codebase out is the 
next step.


So - please could Taverna have some additional mentors?

Andy

On 01/02/16 14:36, Stian Soiland-Reyes wrote:

The majority of the mentors of the Taverna podling have raised
concerns that they no longer have sufficient time available to help
Taverna in the incubator.

In effect we will then have 2 semi-active mentors remaining for continuity.

This has become a concern because Taverna is picking up speed and
moving towards releases of the main code base (our first release was
for a more self-contained library), and this means some effort is
needed to review and guide us through those releases.

We in the Taverna PPMC have already learnt a lot about the Apache Way,
we have done our first release, we had 3 very successful GSOC
students, and we have voted in our first new PPMC member.

However knowing the effort needed to review a "new" code base for a
release, we think it would not be fair on the remaining 2 mentors to
take the full burden of responsibility.


Therefore we would like to ask the Incubator PMC if anyone would be
interested in becoming an active mentor of Taverna as we enter this
exciting phase?



About Taverna:

http://taverna.incubator.apache.org/

Taverna is a domain-independent suite of tools used to design and
execute data-driven workflows, which invoke a mixture of local and
remote (REST, WSDL) services. Taverna is used by scientists and
researchers in domains like bioinformatics, chemistry, musicology,
biodiversity and virtual physiology to combine and process data from
multiple sources using a wide variety of analytical tools.

Taverna workflows can be designed in a graphical workbench,
programmatically through the Taverna Language API, or using an
RDF/JSON-based workflow format. They can be executed locally (command
line, within workbench or through OSGi-based APIs), or on a Taverna
server (REST/WSDL), which has been integrated by portals and
frontends, including an Android mobile app. Taverna results include
full provenance trace of the execution as we strive to support
reproducible computational research.

This is an exciting time for us, as we are not just releasing version
3 of Taverna, but also working on a Common Workflow Language
integration (YaML), including support for coordinating Docker-based
command line tools.

We rely on a large selection of Apache tools, like Woden, Felix, Jena,
Derby, Tika, Velocity, Commons, HTTP Client and Maven.





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

Re: Mentor disengagement - a suggestion

[Andy Seaborne]

On 14/10/15 16:21, Ross Gardler wrote:

Further to Sam's suggestion and observations below see

Suggestion 0.1.8 at 
http://wiki.apache.org/incubator/IncubatorIssues2013#Suggestions


(Summary: Champion => PPMC chair)

I agree with the comments that champion-as-chair is a negative to the 
community self-goverance.


Some kind of phased transition seems better, running down the process 
commitments of mentors as the community ramps up.


"Champion" => "lead mentor" and the incoming community nominates one of 
their own as "community point of contact" or "community lead".


"Community lead" picks up responsibilities like reporting (usually in 
the 3 months phase??) and is there to make sure sufficient mentors are 
active enough.


Andy



-Original Message-
From: sa3r...@gmail.com [mailto:sa3r...@gmail.com] On Behalf Of Sam Ruby
Sent: Wednesday, October 14, 2015 7:26 AM
To: general@incubator.apache.org
Subject: Re: Mentor disengagement - a suggestion

On Wed, Oct 14, 2015 at 10:07 AM, Ted Dunning  wrote:

On Wed, Oct 14, 2015 at 6:46 AM, Jim Jagielski  wrote:


My point is that with 1 mentor, everyone knows where the buck stops.
With >1 nobody knows. A flat hierarchy for mentors does not seem
workable or, at least, optimal.



That's a fine point.

But it is counter to my experience.

For instance, on Kylin, I was extremely active early on. Lately,
Julian Hyde has taken much more of the questions.  It has worked very
well.  We have a third mentor (whose name I won't mention) who has
been nearly completely missing, but that hasn't been a problem since
everybody knows that they are totally MiA.



If we wish to address this, and not "force" mentors to leave, we
could simply add the idea of "lead mentor" and have the PPMC vote on
which mentor they want to be the lead mentor (pseudo PPMC chair); the
remaining mentors would remain as co-mentors but the intent is that
the lead mentor would be the primary person responsible.



I think that this is largely process without clear need. But others
may have different experience.


The following is from the definition of "champion" on the incubator roles and 
responsibility page[1]:

---
During incubation, the Champion:

  * Coordinates the creation and timely delivery of the podling's board reports.
  * Keeps an eye on the mentors' activity and takes action (ask for new 
mentors, talk to the Incubator PMC) if they don't seem to provide enough 
oversight or mentorship to the podling,
---

First question: does this description match current practice.  Second
question: is there something in that description that needs to get done, but 
isn't getting done?

There also is a separate thread about the number of podlings that the Incubator 
can handle.  That number would tend to increase if some of the work were 
decentralized more.

My take is that (at least for this month) Marvin is effectively doing the first 
bullet for all podlings.  Now I don't see any signs of burnout in Marvin, so 
that's not the immediate concern, but scalability and sustainability would 
benefit from decentralizing this more.

As to the second bullet, it isn't clear to me that that is being done.
Even if it were only a one time thing, reverifying (or in many cases,
naming) the champion for every podling, and then asking each to reverify the 
active status for every mentor for podlings that they champion might go a long 
way toward easing some of the concerns that people have raised.

Ultimately the definition of champion, as posted, should match reality.

- Sam Ruby

[1] 
https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fincubator.apache.org%2fincubation%2fRoles_and_Responsibilities.html%23Champion=01%7c01%7cRoss.Gardler%40microsoft.com%7c02e20d0e08f54f9c81f408d2d4a356cc%7c72f988bf86f141af91ab2d7cd011db47%7c1=q10OQ8l3N4%2bAPk%2bXJYxZVF1mEREPIOYNpQcD9Frr0rI%3d

-
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: [VOTE] Accept Rya into the Apache Incubator

[Andy Seaborne]

+1 (binding)

On 14/09/15 16:17, Adam Fuchs wrote:

Thanks again for the healthy discussion on Rya. With that, I would like to
call a VOTE for accepting Rya as a new incubator project.

The proposal text is included below, and is posted on the wiki here:
https://wiki.apache.org/incubator/RyaProposal

The discussion thread on Rya starts here:
http://mail-archives.apache.org/mod_mbox/incubator-general/201509.mbox/%3CCALt5_xJKtRcUr3WGjfrY77DYWF0-8DWi%3DzyS7hrMFTg%2BYAORjQ%40mail.gmail.com%3E

The vote will be open until Thu Sep 17 15:15:00 UTC 2015.

[ ] +1 accept Rya in the Incubator
[ ] ±0
[ ] -1 because...

Thanks,
Adam


= Rya Proposal =
== Abstract ==
Rya (pronounced "ree-uh" /rēə/) is a cloud-based RDF triple store that
supports SPARQL queries.

== Proposal ==
Rya is a scalable RDF data management system built on top of Accumulo. Rya
uses novel storage methods, indexing schemes, and query processing
techniques that scale to billions of triples across multiple nodes. Rya
provides fast and easy access to the data through SPARQL, a conventional
query mechanism for RDF data.

== Background ==
RDF is a World Wide Web Consortium (W3C) standard used in describing
resources on the Web. The smallest data unit is a triple consisting of
subject, predicate, and object. Using this framework, it is very easy to
describe any resource, not just Web related. For example, if you want to
say that Alice is a professor, you can represent this as an RDF triple like
(Alice, rdf:type, Professor). In general, RDF is an open world framework
that allows anyone to make any statement about any resource, which makes it
  a popular choice for expressing a large variety of data.

RDF is used in conjunction with the Web Ontology Language (OWL). OWL is a
framework for describing models or ontologies for RDF. It defines concepts,
relationships, and/or structure of RDF documents. These models can be used
to 'reason/infer' information about entities within a given domain. For
example, you can express that a Professor is a sub class of Faculty,
(Professor, rdfs:subClassOf, Faculty) and knowing that (Alice, rdf:type,
Professor), it can be inferred that (Alice, rdf:type, Faculty).

SPARQL is an RDF query language. Similar with SQL, SPARQL has SELECT and
WHERE clauses; however, it is based on querying and retrieving RDF triples.

Work on Rya, a large scale distributed system for  storing and querying RDF
data, started in 2010.

== Rationale ==
With the increase in data size, there is a need for scalable systems for
storing and retrieving RDF data in a cluster of nodes. We believe that Rya
can fulfill that role. We expect that communities within government, health
care, finance, and others who generate large amounts of RDF data will be
most interested in this project.

 From its inception, the project operated with an Apache-style license, but
it was open to mostly US government-related projects only. We believe that
having the project and the development open for all will benefit both the
project and the interested communities.

== Current Status ==
The project source code and documentation are currently hosted in a private
repository on Github. New users are added to the repository upon request.

=== Meritocracy ===
Meritocracy is the model that we currently follow, and we want to build a
larger and more diverse developer community by becoming an Apache project.

=== Community ===
Rya has being building a community of users and developers for the past 3
years. There is currently an active workgroup with monthly meetings and the
number of participants in the meeting is increasing.

=== Core Developers ===
The core developers are a diverse group of people who are either government
employees or former / current government contractors from different
companies.

=== Alignment ===
Rya is built on top of Accumulo, an Apache project.

== Known Risks ==
=== Orphaned Products ===
There is a very small risk of becoming orphaned. The current contributors
are strongly committed to the project, there is a large enough number of
developers interested in contributing to the project, and we believe that
the support for the project will continue to grow from the interested
communities.

=== Inexperience with Open Source ===
The initial committers have various degrees of experience with open source
projects - from very new to experienced. This project was open source
within government from the beginning. We are aware that it will be
different and more difficult functioning in a real open source environment.
We are enthusiastic and committed to learning the Apache way and being
successful in operating under Apache's development process.

=== Homogenous Developers ===
The current list of developers form a heterogeneous group, with people for
academia, government, and industry, collaborating from distributed
geographic locations. We aim to expand the list of contributors with the
help of the Apache incubation process.

=== Reliance on Salaried Developers ===

Re: Should Apache VOTEs be in a first-come, first-serve queue?

[Andy Seaborne]

On 14/09/15 17:26, Marko Rodriguez wrote:

Hello,

It appears that VOTEing in general@ is inefficient and biased. An Apache member will see a VOTE on 
the list and can choose whether to participate in that VOTE or not. I believe there are problems 
with this algorithm. The first has to do with efficiency. For instance, Groovy received (out of my 
foggy memory) some 20+ VOTEs when only 3 were were needed and other project VOTEs were sitting 
around hoping for an Apache member to spend time on their project. Second, if no Apache member 
really cares about the project's VOTE, then the project committee is left "hoping" that 
someone will care --- pinging around to their mentors (no reply), to the list ("please")… 
like beggars in the street.

Should general@ have a VOTE queue where if an Apache member has time to VOTE 
they can only VOTE on a project at the top of the queue. They can not pick 
which projects to VOTE on. This solves the two aforementioned problems:

1. Apache member attention is not wasted on low-entropy states (why are 
20 +1 VOTEs needed -- no new information is contributed).
- increased efficiency
2. Apache member attention is not biased by human whim (why are VOTE 
requests left idle while later VOTE requests are satiated).
- remove human bias

With a VOTE queue, each project's VOTE requirements are met in the order in which the 
VOTE was added to the queue and no project is left pinging mentors and the list saying -- 
"can someone please VOTE on our artifacts?"

Thoughts?,
Marko.

http://markorodriguez.com




There is an implicit assumption of uniformity of voters in that description.

For me, I vote when I know something about what I'm voting on.  So if I 
came along with some spare time [*], and the queue head was for 
something I don't feel I had the background to be useful, I wouldn't 
vote, and that time will go elsewhere.


The effects you describe exist to some extent but I think they reflect 
underlying matters, and are not problems per se.


Andy

[*] This is hypothetical.


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

Re: [VOTE] Release Apache Taverna Parent 1-incubating-RC4 Apache Taverna Language 0.15.0-incubating RC4

[Andy Seaborne]

There are 2 mentors votes for this release.

Could we get a third please, or the assistence to produce a better release?

Andy

On 05/08/15 12:11, Ian Dunlop wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hello,

The Apache Taverna Incubator PPMC has voted +5 to release

Apache Taverna Parent 1-incubating (RC4)
Apache Taverna Language 0.15.0-incubating (RC4)

Incubator PMC members please review and vote on this incubator release.

Apache Taverna Language is a set of APIs for workflow definitions
(SCUFL2) and workflow inputs/outputs/run (DataBundle), as consumed and
produced by the Apache Taverna workflow system. The API includes
support for working with Research Object Bundles, and loading/saving
Taverna workflows in different formats.

Please see original [VOTE] thread
http://mail-archives.apache.org/mod_mbox/incubator-taverna-dev/201507.mb
ox/%3C55B8DBC7.2040806%40manchester.ac.uk%3E

and [DISCUSS] thread
http://mail-archives.apache.org/mod_mbox/incubator-taverna-dev/201507.mb
ox/%3C55B8DC3F.2070602%40manchester.ac.uk%3E

Please note that the git commit ids were incorrect in the original
[VOTE] email but were corrected during the vote process.
Also, during the release checks some NOTICE files were found to
contain information that was already in the top level LICENSE and a
bug was raised against it, see
https://issues.apache.org/jira/browse/TAVERNA-864

The release candidates to be voted over are available at:

https://dist.apache.org/repos/dist/dev/incubator/taverna/source/taverna-
parent-1-incubating-RC4/
https://dist.apache.org/repos/dist/dev/incubator/taverna/source/taverna-
language-0.15.0-incubating-RC4/

SHA-1 checksums:
3eb09278b914b96fb5c6059523b1bb3e69a09334
taverna-parent-1-incubating-source-release.zip
4eeb37d141fea284cc8de17635d97a47b279ea91
taverna-language-0.15.0-incubating-source-release.zip

MD5 checksums:
bccfe1116189f5ccc640fcbed4a4f96f
taverna-parent-1-incubating-source-release.zip
685b3aed3833a0b921d129995944dfc3
taverna-language-0.15.0-incubating-source-release.zip

Build the release candidates in the above order, using:

Java 7: mvn clean install -Dmaven.javadoc.skip=true  (see
https://issues.apache.org/jira/browse/TAVERNA-867 for the reasons the
maven command line params are required)
Java 8: mvn clean install

The release candidates correspond to the following git commits:

https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-maven-parent
.git;a=commit;h=b12a1cc0ed2540507ab43107124e8ee911da4ddf

https://git-wip-us.apache.org/repos/asf?p=incubator-taverna-language.git
;a=commit;h=e2a9954e796d886d137eed3091b21637e9c8d1fd

Release candidates are signed with a GPG key available at:

https://dist.apache.org/repos/dist/release/incubator/taverna/KEYS

A staged Maven repository is available for review at:

https://repository.apache.org/content/repositories/orgapachetaverna-1006
/

The changelog for this release is available from JIRA:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=1231832
2version=12332247
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=1231832
2version=12332246

Please vote on releasing these packages as:

Apache Taverna Maven Parent 1-incubating
Apache Taverna Language 0.15.0-incubating

The vote will be open for a minimum of 72 hours.

[ ] +1 Release this package
[ ] 0 I don't feel strongly about it, but
don't object
[ ] -1 Do not release this package because...

Cheers,

Ian
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJVwe91AAoJEPK45GBX+Cy5lMsH/jiDvvduoZ43y9SVMQcbIvdn
GZDXOviSco5NAWnekqVzR5juXXHGVCZD56NFDfDkzlS1EinQP11HWEZjx1Tgz5TL
0ghvwRtymc5s6Vu2SMlWeiZszja/lD2430zc28jwtBhesd3xckUIa2VHg9viDiaT
w5iCQQB95TiCnShJaUDbFg0TiLB2BH/xZrb07967MsyH1YeSOI72aOhVkxbFthlE
ELJhRmKBtmfl/RJoPydzrs4IOvvml57hcJQT6DjONGEuaIzSvOJVcV8l+oZgmM1a
QqK6bjS0I+rmcK6udAFrgZmtNKsI/n+qufnaTxg1j1ghZRhDWo/ZAawpzGBo/+I=
=K8dX
-END PGP SIGNATURE-

-
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: apache package naming convention

[Andy Seaborne]

Hi,

Jena graduated 2012 with old namespaces under com.hp.hpl.jena, and some 
under org.openjena, with an intention to change at the first major 
release update.  As new packages came along, they went into 
org.apache.jena but the user facing packages remained where they were.


We released Jena 3.0.0 last month, so 3 years. That major release was 
coupled to another incompatible change (RDF 1.1 semantics) so 3.x
wasn't just to do the packages, package renaming waited until a 
convenient point.


Our users have data with (RDF) namespaces under old names - we are not 
planning on changing that at all.  (A general issue for all linked data.)


I don't see it as an issue for graduation if the project has considered 
the matter.


Andy

On 07/08/15 23:16, Matthew Hayes wrote:

Hi all,

Roman Shaposhnik suggested I open a discussion on the following topic:

For Apache DataFu, all of the Java classes are declared in a datafu.*
namespace.  This has been the naming convention since the DataFu project
started in 2010.  Since DataFu became part of the Apache incubation
process, the topic has come up of moving all of the classes into a
org.apache.datafu.* namespace.  This was first discussed in January 2014
(see DATAFU-7) and most recently again in the past couple weeks.  The
consensus at the time last year was that it would be a huge pain for users
and not worth the cost.  It would break any script out there currently
using DataFu.  Also Jakob Homan and Russell Journey pointed out that this
is just a convention and not all Apache projects follow it.  Since we would
like DataFu to graduate sometime soon it would be good to clarify what the
requirements are on package naming conventions before we do a release.

Thoughts?

Thanks,
Matt




-
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!

[Andy Seaborne]

Great - it's good that was the understanding on the lists anyway and 
notification of the action is a good idea as Bertrand notes; it's also 
highlighting the move (can't assume all the user list subscribers have 
groked that!). A read-only-ish list like commits is not an issue.


Andy

(This it's on the web so I can use it

On 27/03/15 06:25, Paul King wrote:


Only users from the previous list will be added and there was an
assumption that all code/patches sent to that list would be Apache
licensed by default. So, not quite the same thing but as long as we warn
people and tell them how to unsubscribe, I think auto subscribing them
would be OK?

Cheers, Paul.

On 27/03/2015 8:21 AM, Andy Seaborne wrote:

Signing up to Apache list means the user is making an explicit act of
joining a place where code (or pointers to code) sent is granted to
Apache.

Implicit subscription muddies the waters for contributions.

 Andy




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

Re: ICLA/CCLA/SGA guidelines for GitHub or multi-entity projects was: [Groovy] Next steps...

[Andy Seaborne]

Podling commons-rdf fits that description. It started at GitHub in the 
knowledge that ASF was a possible route; ALv2 from the start.  (We 
started at GH because there are people who would join discussions more 
freely on GH.)


It so happens, the contributors are all ASF committers.  With advice 
from our champion, we settled on one SG, naming the contributors and 
signed by the original creator of the project (Sergio, who created the 
project) on behalf of the Commons RDF Community.


We've just done that and ingested the code (today!) - if there is a 
better way, now is the time to say so because we can adjust easily.


Andy

(The SG leaves open things like an updated AL, not that is likely.)

On 26/03/15 16:42, P. Taylor Goetz wrote:

This seems like an appropriate thread to raise a question that’s been
in the back of my head for a while…

If a new project is created on github (or elsewhere — i.e. outside of
the ASF), but with the intention that it would be contributed to an
existing ASF project (ALv2 license from day 1), would a Software
Grant and/or IP clearance be required?

Put another way, what are the best practices to follow when creating
a new project, outside the ASF, with the goal of eventually
contributing that work to an existing ASF project?

The documentation for the IP clearance template [1] states:

Any code that was developed outside of the ASF SVN repository must
be processed like this, even if the external developer is an ASF
committer.”

To me that sounds like any new module, or even a sufficiently large
pull request, requires IP clearance. If that’s the case, I would
expect the clearance document list [2] to be much longer than it is,
and have more ASF projects represented there, especially some of the
faster growing ones.



-Taylor

[1] http://incubator.apache.org/ip-clearance/ip-clearance-template.html
[2] http://incubator.apache.org/ip-clearance/index.html



-
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!

[Andy Seaborne]

Signing up to Apache list means the user is making an explicit act of 
joining a place where code (or pointers to code) sent is granted to Apache.


Implicit subscription muddies the waters for contributions.

Andy

On 26/03/15 21:55, Ted Dunning wrote:

your loop is a fine solution.  Just test it carefully ahead of time.



On Thu, Mar 26, 2015 at 2:44 PM, Konstantin Boudnik c...@apache.org wrote:


I think you can write a script to do a call to
 echo subscribe | mailx -s subscribe dev-subscribe-john=
host.dom...@groovy.incubator.apache.org
via the list of current list subscribers.

Or perhaps open a INFRA ticket and provide them with the list of emails
addresses to be subscribed.

There might be another way that I am unaware about though. Anyone?

Cos

On Thu, Mar 26, 2015 at 09:54PM, Guillaume Laforge wrote:

And how to add in batch the current subscribers of the old list.

2015-03-26 21:29 GMT+01:00 Cédric Champeau cedric.champ...@gmail.com:


BTW should we already update the links [1] on the website? How should

we

proceed to migrate/deprecate the Codehaus lists?

[1] http://groovy-lang.org/mailing-lists.html

2015-03-26 20:34 GMT+01:00 Cédric Champeau cedric.champ...@gmail.com

:



I got them too.
Le 26 mars 2015 19:10, Guillaume Laforge glafo...@gmail.com a

écrit

:


I also got moderation messages


2015-03-26 18:51 GMT+01:00 Roman Shaposhnik ro...@shaposhnik.org:


I don't.

On Thu, Mar 26, 2015 at 10:47 AM, Andrew Bayer 

andrew.ba...@gmail.com

wrote:

Just making sure - others besides me are getting the subscribe

moderation

emails?

A.

On Thu, Mar 26, 2015 at 10:22 AM, Bertrand Delacretaz 
bdelacre...@apache.org wrote:


On Thu, Mar 26, 2015 at 6:21 PM, Jochen Theodorou 

blackd...@gmx.org



wrote:

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


of course yes, sorry - the names on INFRA-9339 are correct.

-Bertrand



-

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






--
Guillaume Laforge
Groovy Project Manager

Blog: http://glaforge.appspot.com/
Social: @glaforge http://twitter.com/glaforge / Google+
https://plus.google.com/u/0/114130972232398734985/posts









--
Guillaume Laforge
Groovy Project Manager

Blog: http://glaforge.appspot.com/
Social: @glaforge http://twitter.com/glaforge / Google+
https://plus.google.com/u/0/114130972232398734985/posts


-
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] Accept CommonsRDF into the Apache Incubator

[Andy Seaborne]

On 27/02/15 19:19, Lewis John Mcgibbney wrote:

Hi general@,

Over the last while a number of individuals have been putting together a
proposal and gathering interest in proposing Commons RDF for acceptance
into the Apache Incubator. Having worked our way through the Incubator
documentation checklists -
http://incubator.apache.org/guides/proposal.html#formulating, we are now
brining this proposal back to the general@ list.

Commons RDF is a set of interfaces for the RDF 1.1 concepts that can be
used to expose common RDF-1.1 concepts using common Java interfaces. The
current CommondRDFProposal document can be found at -
https://wiki.apache.org/incubator/CommonsRDFProposal

This thread is therefore aimed at obtaining general consensus from the
incubator community on whether the proposal document is suitable and
whether the project as described should begin an incubation period at
Apache.

The VOTE is therefore as follows

[ ] +1 I am happy with Commons RDF entering incubation
[ ] +0/-0 I am neither yay or nay
[ ] -1 I am not happy with this proposal because

The VOTE will be open for at least 72 hours.

p.s. Here is my +1 PPMC binding



I'm not sure what the protocol is here, or even if there is one!

But here's my

+1 (binding)

if it counts.

Andy


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

Re: [STATUS] WAS [DISCUSS] Commons RDF to join the Apache Incubator

[Andy Seaborne]

John,

Thank you very much for the offer of mentoring - I've added you to the list.

And I've renamed the proposal as CommonRDFProposal as that seems to be 
naming style on the wiki.


Andy

On 22/02/15 20:56, John D. Ament wrote:

Lewis,

It looks like there were a few things called out.

- Identify a champion (looks like you did already)
- Solicit support from mentors.

It looks like those are the only two open issues.  Benedikt cannot be
listed as a mentor, as mentioned previously (unless I'm missing an email),
but feel free to include him as a PPMC member/commons representative (would
be more accurate than listing under mentor from my POV.. unless he's
interested in helping out the incubator and shows off his skills quick
enough [PS - looking for shepherds for next month's report]).

If you need a hand, I'd be happy to throw my hat in with you and Rob (I'm
jumping at Marvin's note about low maintenance).

John

On Sun Feb 22 2015 at 2:53:26 PM Lewis John Mcgibbney 
lewis.mcgibb...@gmail.com wrote:


Hi Folks,
I've read through the commentary on the recent [DISCUSS] thread for Commons
RDF [0].
It is not clear to me what the outcome was really... can anyone else
provide a fresh insight as to where this proposal is going and what is
required to progress it from status draft to status proposal?
Thanks in advance
Lewis

[0] *http://s.apache.org/Vtk http://s.apache.org/Vtk*
--
*Lewis*






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

Re: [STATUS] WAS [DISCUSS] Commons RDF to join the Apache Incubator

[Andy Seaborne]

On 23/02/15 10:32, Benedikt Ritter wrote:

Hello,

2015-02-22 21:56 GMT+01:00 John D. Ament johndam...@apache.org:


Lewis,

It looks like there were a few things called out.

- Identify a champion (looks like you did already)
- Solicit support from mentors.

It looks like those are the only two open issues.  Benedikt cannot be
listed as a mentor, as mentioned previously (unless I'm missing an email),
but feel free to include him as a PPMC member/commons representative (would
be more accurate than listing under mentor from my POV.. unless he's
interested in helping out the incubator and shows off his skills quick
enough [PS - looking for shepherds for next month's report]).



I think at the moment commons representative would be the best to
describe my role. I'm interested in helping out here at the incubator, but
I'll need time to learn how this project works.


Benedikt - I've updated the proposal with a Apache Commons 
Representative section.


Andy



Regards,
Benedikt




If you need a hand, I'd be happy to throw my hat in with you and Rob (I'm
jumping at Marvin's note about low maintenance).

John

On Sun Feb 22 2015 at 2:53:26 PM Lewis John Mcgibbney 
lewis.mcgibb...@gmail.com wrote:


Hi Folks,
I've read through the commentary on the recent [DISCUSS] thread for

Commons

RDF [0].
It is not clear to me what the outcome was really... can anyone else
provide a fresh insight as to where this proposal is going and what is
required to progress it from status draft to status proposal?
Thanks in advance
Lewis

[0] *http://s.apache.org/Vtk http://s.apache.org/Vtk*
--
*Lewis*










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

Re: [STATUS] WAS [DISCUSS] Commons RDF to join the Apache Incubator

[Andy Seaborne]

On 22/02/15 19:52, Lewis John Mcgibbney wrote:

Hi Folks,
I've read through the commentary on the recent [DISCUSS] thread for Commons
RDF [0].
It is not clear to me what the outcome was really... can anyone else
provide a fresh insight as to where this proposal is going and what is
required to progress it from status draft to status proposal?
Thanks in advance
Lewis

[0] *http://s.apache.org/Vtk http://s.apache.org/Vtk*



Sergio is out for a bit, back soon.  Since there is no rush (?), no one 
has rushed ...


Andy

On 12/02/15 14:12, Sergio Fernández wrote:
 I'll be out for a couple of weeks. But my colleagues in the proposal
 will keep involved in the discussion. Then let's hope in that time
 someone will have jumped in and we can move forward with the formal
 process.


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

Re: [DISCUSS] Commons RDF to join the Apache Incubator

[Andy Seaborne]

On 11/02/15 10:02, Rob Vesse wrote:

Marvin

Yes I would be willing to be a mentor for this podling if there isn't
sufficient volunteers and they would be willing to have me


Thank you - added! (before you change your mind :-))


I agree that there is a tendency then to make the podling Jena heavy but I
have had zero involvement in the Commons RDF effort to date and the API
they are talking about currently is at a level of a stack that I have
historically contributed nothing to nor do I particularly use so hopefully
I would be seen as relatively neutral.  To be honest I wouldn't have the
bandwidth to get actively involved in the code  design) efforts (nor do I
particularly want to) and thus would only want to be a mentor.


Understood.


As you said this would probably be a relatively easy mentoring gig with
most of the effort being around just keeping an eye on the community to
sign off and comment on reports and to review release as and when they
come around.


I hope you'll bring in your experience from other projects, inside and 
outside Apache.


 On 10/02/2015 20:31, Marvin Humphrey mar...@rectangular.com wrote:
(sorry to chop but it's a long way down)
 The Champion's main work is to help formulate the proposal.  That
 work is essentially done -- so it doesn't matter too much who takes
 that role, now.

Ack.

 Are Andy and Reto opting out out as a gesture of openness to Sesame?

Sergio has done a great job of pulling the proposal together.

I have a one-podling-at-a-time policy and Taverna is already filling the 
slot.


In my experience, champion also gets involved in the initial bootstrap 
tasks, and in this case I would hope we can easily share those tasks around.


Andy



Rob

On 10/02/2015 20:31, Marvin Humphrey mar...@rectangular.com wrote:


On Tue, Feb 10, 2015 at 7:21 AM, Stian Soiland-Reyes st...@apache.org
wrote:


The natural path to Apache Commons Sandbox has been studied, but we
think that in this phase of the project, which focuses on the API
design and actively involves the developers of existing toolkits, it
is better to have a more focused community and infrastructure. Rather
than a new Top-Level Project, the goal is still to graduate as part of
Apache Commons, that is when API has achieve the required maturity and
the project goes into maintenance mode.


If Commons is OK with this, I imagine this is a fine plan -- good enough
for
entering incubation.

I also think it would be OK for the project to decide it wants to become a
TLP.  Whether the project joins Commons or becomes its own TLP won't
impact
the number of people qualified to work on it.  Some Apache TLPs are
effectively in maintenance mode and have very low activity, but still
have PMC
members willing to answer user questions, make security releases and file
still here quarterly reports.  That seems like a legitimate aspiration
for
this project.

A potential Jena destination also seems as though it would have certain
advantages, though my naive speculation is that it might be sub-optimal in
terms of providing neutral territory for negotiating a common API for
Jena and
Sesame.

In any case it seems likely that if the project achieves its design goal,
there will be people willing to work on it as long as both Jena and Sesame
remain viable.  That makes it different from other potential maintenance
mode TLPs which are in danger of stagnation because they cannot renew
their
communities.

Is that take roughly accurate, Sergio et al?


=== Mailing lists ===

  * commons-rdf-dev
  * commons-rdf-commits


Those sound like final mailing lists rather than Incubator ones.  I might
have
expected these instead:

d...@commons-rdf.incubator.apache.org
comm...@commons-rdf.incubator.apache.org

Do you expect to keep separate mailing lists after graduation, or will
traffic
be shunted onto existing Commons mailing list like d...@commons.apache.org
and
comm...@commons.apache.org?


  * Sergio Fernández (wikier dot apache dot org)
  * Andy Seaborne (andy dot apache dot org)
  * Peter Ansell (ansell dot apache dot org)
  * Stian Soiland-Reyes (stain at apache dot org)
  * Reto Gmür (reto at apache dot org)


Lots of Apache experience in this group.  Four are PMC members of at
least one
Apache project.  Andy and Reto are ASF Members.  Andy and Sergio are both
IPMC
members.  Stian is a core contributor of the Taverna podling.

You probably haven't been getting much feedback because there's a lot
going on
in the Incubator right now and everybody figures that with a group like
that
you're in good shape. :)

=== Champion ===

* TBD

The Champion's main work is to help formulate the proposal.  That work is
essentially done -- so it doesn't matter too much who takes that role,
now.
Are Andy and Reto opting out out as a gesture of openness to Sesame?


=== Nominated Mentors ===

  * Benedikt Ritter (britter at apache dot org)
  * TBD


Benedikt is a member of the Commons PMC, but he's not a member of the
IPMC nor
an Apache Member

Re: [DISCUSS] Commons RDF to join the Apache Incubator

[Andy Seaborne]

On 11/02/15 08:14, Sergio Fernández wrote:

On 10/02/15 21:31, Marvin Humphrey wrote:

If Commons is OK with this, I imagine this is a fine plan -- good
enough for
entering incubation.

I also think it would be OK for the project to decide it wants to
become a
TLP.  Whether the project joins Commons or becomes its own TLP won't
impact
the number of people qualified to work on it.  Some Apache TLPs are
effectively in maintenance mode and have very low activity, but still
have PMC
members willing to answer user questions, make security releases and file
still here quarterly reports.  That seems like a legitimate
aspiration for
this project.

A potential Jena destination also seems as though it would have certain
advantages, though my naive speculation is that it might be
sub-optimal in
terms of providing neutral territory for negotiating a common API for
Jena and
Sesame.

In any case it seems likely that if the project achieves its design goal,
there will be people willing to work on it as long as both Jena and
Sesame
remain viable.  That makes it different from other potential maintenance
mode TLPs which are in danger of stagnation because they cannot renew
their
communities.

Is that take roughly accurate, Sergio et al?


Completely :-)


Yes.

Personally, I'd keep the destination open for both TLP and Apache 
Commons, then see where we are at graduation time. A lot of (good) 
things can happen during incubation.


Andy







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

Re: [Proposal] TinkerPop: A Graph Computing Framework [RE-SUBMISSION]

[Andy Seaborne]

Looks good but there is one part that wasn't clear to me.

In this proposal, the TinkerPop2 repos appear in the initial source 
listing as well, but are not in the submission plan.


Is TinkerPop2 also part of the proposal? Is there is risk in it being a 
burden on the project? Conversly, if it is difficult to disentangle 
TinkerPop2 and TinkerPop3 (copyright, IP), then non-granting of it might 
lead to hard issues later.


Andy



R. Initial Source

TinkerPop https://wiki.apache.org/incubator/TinkerPop is currently 
hosted on GitHub https://wiki.apache.org/incubator/GitHub: 
https://github.com/tinkerpop/.


The following repositories would like to be migrated to ASF.

TinkerPop3 https://wiki.apache.org/incubator/TinkerPop3

https://github.com/tinkerpop/tinkerpop3
Blueprints (TinkerPop2 https://wiki.apache.org/incubator/TinkerPop2)

https://github.com/tinkerpop/blueprints
Pipes (TinkerPop2 https://wiki.apache.org/incubator/TinkerPop2)

https://github.com/tinkerpop/pipes
Frames (TinkerPop2 https://wiki.apache.org/incubator/TinkerPop2

https://github.com/tinkerpop/frames
Gremlin (TinkerPop2 https://wiki.apache.org/incubator/TinkerPop2)

https://github.com/tinkerpop/gremlin
Rexster (TinkerPop2 https://wiki.apache.org/incubator/TinkerPop2)

https://github.com/tinkerpop/rexster


S. Source  Intellectual Property Submission Plan

TinkerPop https://wiki.apache.org/incubator/TinkerPop has required 
CLAs from contributors in the past to ensure solid IP provenance. 
TinkerPop https://wiki.apache.org/incubator/TinkerPop plans to 
submit a Software Grant for the content in the following repositories: 
https://github.com/tinkerpop/tinkerpop3


We plan to transfer to the ASF the TinkerPop 
https://wiki.apache.org/incubator/TinkerPop trademark as well as the 
commissioned artwork for TinkerPop 
https://wiki.apache.org/incubator/TinkerPop logos and the 
http://tinkerpop.com http://tinkerpop.com/ and http://tinkerpop.org 
http://tinkerpop.org/ domains.

Re: proposal: mentor re-boot

[Andy Seaborne]

On 08/01/15 16:48, Chip Childers wrote:

On Wed, Jan 07, 2015 at 08:18:59PM -0800, Marvin Humphrey wrote:

Retiring the role of Champion sounds like an idea whose time has come.  We
gave the Champion additional oversight responsibilities a while back -- but
how many times since then has having that additional layer made a difference?


My 2 cents:

In my experience, the Champion is a useful concept for the purpose of
having discussions with the incoming project's community *before* they
become a podling. I've acted as a champion for one podling so far, as
well as acted in this role for one community that ended up *not* wanting
to incubate.

I see this as a valuable activity (I don't care what it's called),
because it's important that incoming projects understand what they are
signing up for. As much as it's an investment for the ASF to accept
podlings, it's an investment for the inbound communities to make the
proposal.

For the project that I acted as a Champion for, I considered that part
of the work to be done when they became a podling. I also asked to be a
mentor, and am doing so now... and being a mentor is a bit different
from that initial introduction.

In the end though, regardless of what we name things, podlings should
have support from people here in the incubator from the time they start
considering the move to the time they become a TLP.


+1

The other minor aspect of champion can making sure getting bootstrap 
happens quickly. Other mentors may not immediately be active, or as well 
known to the podling.  It is admin smoothing over the transition, not 
vital, but helpful.


Andy


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

Re: Git write access for podlings

[Andy Seaborne]

On 02/01/15 16:40, David Nalley wrote:

On Fri, Jan 2, 2015 at 5:36 AM, Stian Soiland-Reyes st...@apache.org wrote:

Git allows you to commit as whoever you want - e.g. like in SMTP
email, the headers are decided by the sender. SVN on the other hand
will show the authenticated user in the commit log. So - speaking as a
former sysadmin - it sounds a bit daring to let anyone new to Apache
from a fresh Incubator proposal to also get instant write access to
all Incubator projects, including those that are just about to
graduate.



 From a git commit log perspective, this is true, but we also retain
push records that show us the user authenticated as, as well as the IP
Address they are pushing commits from. In example:
https://git-wip-us.apache.org/logs/asf/incubator-nifi.git


I looked at Jena's log and until Dec 2 this year, the IP address was always

@http.192.168.0.58

and since 2014-12-03 there are likely looking true IP addresses but of 
the NAT gateway used.


Andy








That said - assuming there has not been any reported abuse of this
global write access - then it is a very good sign of all the new
committers being responsible people - or perhaps they just didn't know
they had that write access to begin with :). It's a trust-thing - I
remember when I started my first proper sysadmin job, and on day one
received the root passwords for systems running web and email for
30.000 students. Don't mess it up was implicit.

Apache Commons has already given write access to *all* ASF committers
[1] - which would presumably include any incubator committers.  If
it's good enough for for Commons, it should be good enough for
Incubator. Part of moving to Apache is also to trust all your
committers.

[1] 
https://mail-archives.apache.org/mod_mbox/commons-dev/201412.mbox/%3ccab917rjy57z-4pnwthvr9tuq7y3td8usg8jcmhvdthalwho...@mail.gmail.com%3E


Even with the danger of introducing a bigger temptation by explicitly
documenting the incubator-wide write policy - I would still +1 to
document this so you are aware and don't accidentally push back (as
git workflow is to commit locally and it is a bit easy to accidentally
do git push) - with a clause that this does not mean you have
formally become a committer on the other incubator projects.


I would propose to also improve documentation at

http://wiki.apache.org/general/GitAtApache
http://www.apache.org/dev/git.html
http://www.apache.org/dev/writable-git

so it does not give impression you have to use SVN-with-git-mriroring
or that writeable GIT is experimental. I don't know enough about the
particular setup at git.apache.org yet to do it myself.



sigh I thought we had removed all of the experimental labels.
Thanks for finding these.

--David

-
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: Incubator PMC/Board report for Nov 2014 ([ppmc])

[Andy Seaborne]

On 27/10/14 14:15, Marvin wrote:

Dear podling,

This email was sent by an automated system on behalf of the Apache Incubator 
PMC.
It is an initial reminder to give you plenty of time to prepare your quarterly
board report.

The board meeting is scheduled for Wed, 19 November 2014, 10:30 am PST. The 
report
for your podling will form a part of the Incubator PMC report. The Incubator PMC
requires your report to be submitted 2 weeks before the board meeting, to allow
sufficient time for review and submission (Wed, Nov 5th).

Please submit your report with sufficient time to allow the incubator PMC, and
subsequently board members to review and digest. Again, the very latest you
should submit your report is 2 weeks prior to the board meeting.

Thanks,

The Apache Incubator PMC


Taverna wasn't in the incubator template so I added a section for it to 
make sure it didn't get lost.  No shepherd assignment.


Have I failed to find some place that needs updating so the template 
includes Taverna?  Or was it just timing, because we only started late 
in October?


Andy


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

[RESULT] [VOTE] Accept Taverna into the Apache Incubator

[Andy Seaborne]

To: general@incubator.apache.org

This VOTE passes with 13 +1 binding votes

Suresh Marru
Alan D. Cabrera
jan I
Ralph Goers
Bertrand Delacretaz
Andy Seaborne
Suresh Srinivas
Chris Mattmann
Jean-Baptiste Onofré
Jake Farrel
Leif Hedstrom
Jean-Louis Monteiro
Roman Shaposhnik

and no 0's or -1's

I'll start the podling setup process.

Thank you everyone.

Andy

On 16/10/14 16:54, Andy Seaborne wrote:

Following the discussion earlier in the thread:

https://www.mail-archive.com/general@incubator.apache.org/msg45241.html

I would like to call a Vote for accepting Taverna as a new incubator
project.

The proposal is available at:

https://wiki.apache.org/incubator/TavernaProposal

Vote is open until at least Sunday, 19th October 2014, 23:59:00 UTC

  [ ] +1 accept Taverna in the Incubator
  [ ] ±0
  [ ] -1 because...

Only Votes from Incubator PMC members are binding, but everyone is
welcome to contribute to the process.



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

[VOTE] Accept Taverna into the Apache Incubator

[Andy Seaborne]

Following the discussion earlier in the thread:

https://www.mail-archive.com/general@incubator.apache.org/msg45241.html

I would like to call a Vote for accepting Taverna as a new incubator 
project.


The proposal is available at:

https://wiki.apache.org/incubator/TavernaProposal

Vote is open until at least Sunday, 19th October 2014, 23:59:00 UTC

 [ ] +1 accept Lens in the Incubator
 [ ] ±0
 [ ] -1 because...

Only Votes from Incubator PMC members are binding, but everyone is 
welcome to contribute to the process.


Andy

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

Re: [VOTE] Accept Taverna into the Apache Incubator

[Andy Seaborne]

Dmitriy Repchevsky
dmitry.repchev...@bsc.es

Donal K. Fellows
donal.k.fell...@manchester.ac.uk


Finn Bacall
finn.bac...@manchester.ac.uk


Hajo Nils Krabbenhöft
h...@krabbenhoeft.de


Ian Dunlop
ian.dun...@manchester.ac.uk

Ingo Wassink
i.h.c.wass...@ewi.utwente.nl


Julián Garrido
jgarr...@iaa.es


Mark Wilkinson
ma...@illuminae.com


Luke McCarthy
elmccar...@gmail.com


Robert Haines
rhai...@manchester.ac.uk


Shoaib Sufi
shoaib.s...@manchester.ac.uk


Steffen Möller
moel...@inb.uni-luebeck.de


Stian Soiland-Reyes
st...@soiland-reyes.com
(ICLA on file.)

Stuart Owen
so...@cs.manchester.ac.uk


In addition to the Core Team (mentioned earlier), this list also reflects
Taverna's existing meritocracy as it includes plugin developers whose
contributions have been merged into the main code base. We acknowledge that
not all of these are likely to continue as Core developers, but would
like to encourage that during the Incubating process.

Affiliations

The majority of the initial committers are employed by University of
Manchester as part of the myGrid team, including responsibilities for
contributing to and supporting
Taverna. http://www.mygrid.org.uk/about-us/people/core-mygrid-team/.

Dmitriy Repchevsky is employed by the Barcelona Supercomputing Center,
including responsibilities for contributing to Taverna. Steffen Möller is
employed by University of Lübeck. Julián Garrido is employed by Instituto
de Astrofísica de Andalucía.

Sponsor Champion

Andy Seaborne

Nominated Mentors

Andy Seaborne
Chris Mattmann
Suresh Srinivas
Suresh Marru
Marlon Pierce

Offers of participation, not formally a mentor:

Michael Joyce

Sponsoring Entity

The Incubator.

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

Re: [VOTE] Accept Taverna into the Apache Incubator

[Andy Seaborne]

  [ ] +1 accept Taverna in the Incubator
  [ ] ±0
  [ ] -1 because...


+1 (binding)

Andy


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

Re: [] Accept Taverna into the Apache Incubator

[Andy Seaborne]

yes - s/Lens/Taverna/

(sigh)

On 16/10/14 18:27, jan i wrote:

+1 binding (assuming its Taverna, and there has been a simple copy/paste
error).

have fun.
jan I.

On 16 October 2014 18:48, Alan D. Cabrera l...@toolazydogs.com wrote:


+1 - binding

I assume that you mean Taverna instead of Lens.


Regards,
Alan




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

Re: [Proposal] Taverna workflow

[Andy Seaborne]

On 14/10/14 16:51, Marlon Pierce wrote:

Hi all--

I'm a bit late on this but I would also like to serve as a mentor. I'm a
PMC member of Apache Airavata and Apache Rave, and I've also served as a
mentor for Apache Stratos.

Marlon


Marlon,

Thank you for the offer - I've added you to the the mentor list on the 
proposal.


Andy



On 9/26/14, 10:18 AM, Andy Seaborne wrote:

On 25/09/14 19:19, Suresh Marru wrote:


If you need a mentor, count me in.
I actively contribute to Apache Airavata, and will be happy to bring
our experiences from a similar journey. Infact Ross queried on
airavata lists few years ago about potential taverna move to
airavata/apache(Ross mentioned it further in this thread), good to
see finally its happening. Integrating plugin community into the
apache project (once its voted in) seems to be a low hanging fruit to
diversify.


On 25/09/14 17:36, Suresh Srinivas wrote:
   If you you need a volunteer, I am available.

Hi there,

It being Friday, and Stian is about to be away, I've added you both to
the mentors list.  Taverna has a long history so getting as much
experience from mentors will be very valuable.

Thanks
Andy

PS I put Michael in as Not formally a mentor



-
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: [Proposal] Taverna workflow

[Andy Seaborne]

On 25/09/14 19:19, Suresh Marru wrote:


If you need a mentor, count me in.
I actively contribute to Apache Airavata, and will be happy to bring our 
experiences from a similar journey. Infact Ross queried on airavata lists few 
years ago about potential taverna move to airavata/apache(Ross mentioned it 
further in this thread), good to see finally its happening. Integrating plugin 
community into the apache project (once its voted in) seems to be a low hanging 
fruit to diversify.


On 25/09/14 17:36, Suresh Srinivas wrote:
   If you you need a volunteer, I am available.

Hi there,

It being Friday, and Stian is about to be away, I've added you both to 
the mentors list.  Taverna has a long history so getting as much 
experience from mentors will be very valuable.


Thanks
Andy

PS I put Michael in as Not formally a mentor



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

Re: Is a Software Grant Agreement always needed for IP Clearance?

[Andy Seaborne]

On 05/04/14 16:19, Craig L Russell wrote:

Hi Rob,

If you developed the code during the time the ICLA and CCLA were in effect 
(from February 2012) I don't see a need to file additional paperwork.

Craig


As a matter of good practice, when is it best to use the IP Clearance 
process?


In this case, we have a significant area of new functionality, written 
by Rob, who has appropriate xCLAs on file.  It is within the projects 
charter.


The code was written solely by Rob and developed outside the project's 
code repository.


The IP Clearance Template (point 3) says an SG and CCLA must be in place 
and it is sent to the secretary.  It does not seem necessary as the 
existing CCLA is on file.


As a significant new piece of code, it does seem worth recording the 
acceptance by the project.


What's the best practice?

Andy



On Apr 5, 2014, at 8:08 AM, Rob Vesse wrote:


Hi All

I’m in the process of carrying out IP Clearance for some code developed outside 
of the ASF that my employer (Cray) has now agreed to contribute to the Apache 
Jena project where I am a committer and PMC member.

In this case the software was developed entirely by myself though obviously 
Cray holds the copyright.  I have an ICLA on file for myself and Cray filed a 
CCLA for me when I originally joined the Apache Jena project as a committer and 
PMC member.  In this scenario is a SGA actually needed to carry out IP 
Clearance of the contributed code or are the existing ICLA and CCLA sufficient?

Thanks,

Rob Vesse


Craig L Russell
Architect, Oracle
http://db.apache.org/jdo
408 276-5638 mailto:craig.russ...@oracle.com
P.S. A good JDO? O, Gasp!





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

Re: Hoya Proposal

[Andy Seaborne]

As a project name Jena has been in use for the project for about 13 
years now.  1.0 was 9 Jan 2001.   A mere 983K (zipped).


The discussion is about Hyena for Hoya.

Andy

On 13/01/14 23:38, sebb wrote:

Jenny ?

On 13 January 2014 22:21, Ted Dunning ted.dunn...@gmail.com wrote:

Too many people will read that as Jena, the city in Thuringia.

https://en.wikipedia.org/wiki/Jena

-1




On Mon, Jan 13, 2014 at 1:57 PM, Andy Seaborne a...@apache.org wrote:


On 13/01/14 20:25, Bertrand Delacretaz wrote:


On Mon, Jan 13, 2014 at 5:36 PM, Bertrand Delacretaz
bdelacre...@apache.org wrote:


On Mon, Jan 13, 2014 at 3:33 PM, Steve Loughran ste...@hortonworks.com
wrote:


...What do people think about a project name Hyena? It's close
enough, lives
in the savannah...



I think it's too close to http://jena.apache.org/



to be clear, this is a strong -1 from me, having confusing project
names inside Apache is not ok. Hyena and Jena sound exactly the same
in several languages, unfortunately.



The j-e-n in Jena is like Jen-kins or Gen-er-al.

It is derived from Jennifer

http://en.wikipedia.org/wiki/Jennifer_%28given_name%29

which is often, but not here, with nn:

http://en.wikipedia.org/wiki/Jenna

 Andy



-Bertrand




-
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: Hoya Proposal

[Andy Seaborne]

On 13/01/14 20:25, Bertrand Delacretaz wrote:

On Mon, Jan 13, 2014 at 5:36 PM, Bertrand Delacretaz
bdelacre...@apache.org wrote:

On Mon, Jan 13, 2014 at 3:33 PM, Steve Loughran ste...@hortonworks.com wrote:

...What do people think about a project name Hyena? It's close enough, lives
in the savannah...


I think it's too close to http://jena.apache.org/


to be clear, this is a strong -1 from me, having confusing project
names inside Apache is not ok. Hyena and Jena sound exactly the same
in several languages, unfortunately.


The j-e-n in Jena is like Jen-kins or Gen-er-al.

It is derived from Jennifer

http://en.wikipedia.org/wiki/Jennifer_%28given_name%29

which is often, but not here, with nn:

http://en.wikipedia.org/wiki/Jenna

Andy



-Bertrand



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

Re: [VOTE] Enable Release Checklist Experiment

[Andy Seaborne]

+1

On 14/12/13 14:42, Dave wrote:

+1


On Sat, Dec 14, 2013 at 9:11 AM, Joseph Schaefer joe_schae...@yahoo.comwrote:


+1

On Dec 13, 2013, at 11:31 PM, Henry Saputra henry.sapu...@gmail.com
wrote:


So it begins =)

+1

Thanks for leading the effort, Marvin

- Henry


On Fri, Dec 13, 2013 at 12:59 PM, Marvin Humphrey
mar...@rectangular.com wrote:

Greetings,

As the next step in our ongoing efforts to reform the release voting

process,

I propose that we run an experiment allowing the PPMC members of select
podlings to earn binding votes under limited circumstances by

completing a

release checklist.

For participating podlings, the Incubator's release management guide...

http://incubator.apache.org/guides/releasemanagement.html

... would be supplanted by the following documents:

http://incubator.apache.org/guides/release_manifest.txt
http://incubator.apache.org/guides/release.html

The scope of this VOTE is limited to approving the following patch to

our

policy page:

https://paste.apache.org/k4vJ

Here is the patch content minus markup:

2013 Alternate Release Voting Process

Select podlings pre-cleared by a majority vote of the IPMC MAY
participate in
an alternate release voting process:

Should a Podling decide it wishes to perform a release, the Podling

SHALL

hold a vote on the Podling's dev list and create a permanently

archived

Release Manifest as described in the Experimental Release Guide.  At

least

three +1 votes from PPMC members are required (see the Apache Voting
Process page).  If the majority of PPMC votes is positive, then the

Podling

SHALL send a summary of that vote to the Incubator's general list and
formally request the Incubator PMC approve such a release.

Formal approval requires three binding +1 votes and more positive

than

negative votes.  Votes cast by members of the Incubator PMC are

always

binding.  For all releases after the first, votes cast by members
of the PPMC
are binding if a Mentor approves the Release Manifest.

Please note that the proposed change is both incremental and reversible:

*   It is incremental because podlings must be opted in by vote of the

IPMC to

participate.
*   It is reversible because once the experiment has run its course the
policy change can be reverted with zero impact through lazy

consensus.


Those who may have questions about the legitimacy of allowing binding

votes

from non-IPMC members should see this post from Roy Fielding:

http://s.apache.org/v7

Please vote:

[ ] +1 Yes, apply the patch enabling the experiment.
[ ] -1 No, do not apply the patch enabling the experiment.

This majority VOTE will run for 7 days and will close at 13:00 PST on

Friday,

December 20, 2013.  Votes cast by members of the Incubator PMC are

binding.


Here is my own +1.

Marvin Humphrey

-
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







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

Re: Cultivating Outstanding IP Stewards

[Andy Seaborne]

On 17/11/13 11:17, Upayavira wrote:



On Sun, Nov 17, 2013, at 04:59 AM, Alex Harui wrote:



On 11/16/13 8:47 AM, Upayavira u...@odoko.co.uk wrote:





Alex,

I'm not sure I see the difference between a release auditor and an IPMC
member. If someone is sufficiently clued up to audit a release, then
they're surely ready to join the Incubator PMC. Am I missing something?

To me, there is more responsibility in being on the IPMC, like reviewing
proposals for new podlings and voting on their graduation and becoming a
mentor.  Personally, that's why I don't want to be on the IPMC, but I
might be willing to help IP audit a podling's release.  Just like some
projects don't have all committers on the PMC, a Release Auditor is just
someone who can do that specific task, and there is no need to vote them
in if they are already on some other TLP PMC because any member of a TLP
PMC supposedly knows how to do release auditing.



My interest is in a lesser level of involvement, where someone has shown
merit within their own PPMC and can get a binding vote there, but
no-where else. That feels to me like a very useful intermediate step to
have.

I agree, except for the no-where else part.  If you know how to check a
RAT report and have an idea of what should be in the NOTICE files, you
should be able to help out any other podling by reviewing their release
and casting a binding vote so they can learn how to do that.  I'd say
that
3 IPMC members must vote to give a person Release Auditor status if they
are not already on a TLP PMC.  Consider this:  I am an the Flex PMC but
not the IPMC, but if I join the PPMC of some new podling, why shouldn't I
be able to cast a binding vote for that podling's releases?


With a two tier model - with PPMC membership granting voting rights on
podling releases, then a podling would start with just mentors on its
PPMC. If you clearly knew what you were doing, you'd get voted onto the
PPMC pretty quickly, and thus you'd be able to vote on your releases.


I am concerned that it would be dis-empowering to the incoming community 
if at least the active and major developers of the podling were not on 
the PPMC at the start.


Andy



Upayavira

-
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: Cultivating Outstanding IP Stewards

[Andy Seaborne]

On 10/11/13 09:04, ant elder wrote:

How about simply changing the rules for Incubator releases so that
they don't require at least three binding votes, but instead make it
at least three votes only one of which must be binding. That would
mean there would still be the element of oversight that a mentor vote
gives but avoids all the problems with not having three mentors. I'm
sure the board would grant the Incubator authority to implement that
change.

...ant


Having some mechanism to give real, effective value to the PPMC votes 
seems like an excellent idea.  Whether it is this exact proposal or 
something else, I don't know.  At the moment, the PPMC votes are not 
essential which I find a bit odd.


Maybe make some/all the mentor votes being votes on the process of the 
release (IP checking included), not the content.  (Or maybe different 
mentor vote classes is just complexity.)


Doing IP the first time seems to come a surprise for podlings (in my 
very limited experience).  But once one or two people on the PPMC get 
it, it's time to handover that responsibility to the PPMC.


Andy



On Sun, Nov 10, 2013 at 8:00 AM, Alex Harui aha...@adobe.com wrote:

IMO, there are two problems:

1) We're trying to train folks to manage IP for their community but they
have to seek approval from folks are aren't as vested in their community.
My analogy is telling a new city council member: Welcome to the city
council.  For the next year all of your decisions will require
ratification by 3 state senators.

2) Release voting takes a long time.  It would seem like tools should be
able to reduce the time on several of the steps, except for this one from
[1] compile it as provided, and test the resulting executable on their
own platform.

Sometimes I think about trying to get on the IPMC and helping some podling
get a release out but:
A) Really, I just want to help check the legal aspects of a podling's
release and don't have bandwidth to want to take on the other roles
implied by being on the IPMC.
B) I don't want to take the time to figure out how to build and test a
release that I have no vested interest in.

Now, incubating releases are not official releases, right? So why have
such time- consuming requirements to get approval from the IPMC?  Let's
assume that the podling folks tested the building and operation of the
source package.  Could we build an ant script that any IPMC member or any
PMC member from any TLP (to expand the pool of potential helpers to folks
who supposedly know how) can run just to check:

1) source package has the name incubating
2) source package is signed
3) unzip source package
4) grab a tag from SVN/Git
5) Diff
6) Run Rat (without any fileset exclusions)

Then some podling writes to general@ and says: can we get legal approval
to release? Please run the release checker ant script with the following
inputs url to package url to SVN/Git tag

Then it could run while I read through all of the other ASF emails and
eventually I get a report that contains mainly a list of non-Apache files
in the RAT report that I review and comment on if needed.  To me, if
you're reviewing a RAT report, you are a building inspector who has looked
around inside.

Can we make it that simple?

For sure, if any podling member is qualified for IPMC before graduation
they should be nominated and added, and I suppose we could also approve
them to cast binding votes as a release checker which may be a lower bar
and maybe less of a time commitment, but I think if it is possible to have
a larger group of folks approve incubating releases mainly be reviewing
RAT reports that might make it easier for a podling to get a release out
the door and still assist in the training of the podling's future PMC
members.


[1] http://www.apache.org/dev/release.html#approving-a-release

My two cents (probably more),
-Alex

On 11/9/13 9:38 PM, Marvin Humphrey mar...@rectangular.com wrote:


On Sat, Nov 9, 2013 at 4:11 AM, Dave Brondsema d...@brondsema.net wrote:

On 11/09/2013 02:23 AM, Jake Farrell wrote:



If mentors are not performing their duties to vote on a given releases
for
a podling, then it is up to the IPMC as a whole to help that podling by
doing the do diligence and casting a vote. We all asked to be apart of
the
IPMC or where honored by a nomination and accepted the role. It is up
to us
to show these podlings what the Apache was really means. These projects
have all come to the ASF and we (the IPMC) have openly voted them into
incubation, its up to us to help them succeed.


While this is true in theory it's hard in practice to wrangle those
votes together.


That's not the only problem.  While IPMC volunteers who perform
freelance
release reviews keep the Incubator from grinding to a halt, our reliance
on
them undermines the Incubator's effectiveness as an IP clearinghouse.  I
wish
that we would redirect those volunteer energies elsewhere.

IPMC members who vote +1 on an initial incubating release are 

Re: [VOTE] Graduate Apache Marmotta as TLP

[Andy Seaborne]

+1

On 04/11/13 08:59, Jakob Frank wrote:

Hi all,

the Marmotta podling, whose goal is to provide an Open Platform for
Linked Data, entered incubation in December 2012. Since then, the
codebase has stabilized and two releases were published following ASF
policies and guidelines.
The community has grown, two new committers have joined the development
team and more people joined the mailing lists.

The last incubator report lists Marmotta as Ready to graduate [1], the
Marmotta community has decided to take this step [2] and agreed on a
Graduation Resolution Draft [3] which is also attached below.

The resolution draft was posted to general@incubator.a.o for discussion
[4] and raised no concerns, now please cast your votes:

[ ]  +1 Graduate the Marmotta podling from Incubator
[ ]  +0 Indifferent to graduation status of the Marmotta podling
[ ]  -1 Reject graduation of the Marmotta podling from Incubator because...

The vote will be open for at least 72 hours starting now.


Best,
Jakob
on behalf of the Marmotta community

[1] http://s.apache.org/marmotta-graduation-vote
[2] http://s.apache.org/marmotta-graduation-result
[3] http://s.apache.org/marmotta-graduation-resolution
[4] http://s.apache.org/dYt



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

Re: Shepherd assignments July 2013

[Andy Seaborne]

On 17/07/13 06:49, Ross Gardler wrote:

Ross Gardler   Marmotta

Looks good. Releases made, Committers brought in. Mentors appear to be
watching. Recommend mentors consider graduation sooner rather than later.


The mentors have. The podling is reluctant to leave the nest :-)

(This mentor is now in standby mode)

Andy


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

Re: Vote on personal matters: majority vote vs consensus

[Andy Seaborne]

On 25/03/13 08:41, ant elder wrote:

On Mon, Mar 25, 2013 at 8:36 AM, Upayavira u...@odoko.co.uk wrote:



Now, you might argue that mentoring is a lot more than voting, but we
could create another bottleneck in getting release votes through,
requiring votes from incubator PMC members who are not particularly
focused on the podling.



Thats exactly what i would argue, mentoring is a lot more than voting
on releases. Many (most?) poddlings don't get three mentor votes on
releases anyway and have to come to general@ so changing to have
non-PMC mentors isn't going to make that worse than it already is.

...ant


I agree mentoring is a lot more than voting.

One point though (not suggesting new process) - there is some value in 
coming to general@ at least once in the podlings incubation. It brings 
in a wider perspective and understanding because small-N mentors on a 
podling may not themselves have a complete awareness of everything.


Andy


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

Re: [DISCUSS] Expressing priorities about release reviews

[Andy Seaborne]

On 13/01/13 12:45, Benson Margulies wrote:
...

3. Most of the reviewing in this area is done by sebb. We're lucky to
have him paying attention to this at all, because it sure seems
sometimes as if no one else does.

Adding all of this up, I've got a very modest proposal. Let's create a
checklist, put it prominently at the top of the relevant doc, and then
see if we can't improve the visibility of this. Sebb, could I ask you
to dump your checklist into this email thread?


+1

We need to clone sebb's reviewing process as good practice and it would 
pull together the knowledge about NL.


Andy


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

Re: How to use an apache webpage

[Andy Seaborne]

On 20/12/12 05:33, Joe Schaefer wrote:

All webpages we host are works in progress subject to change when
better consensus emerges.  Please do not affix any labels to the
pages describing them as drafts as that only serves to discourage
others from working on them.  Normative policy documents are few and
far between and you will recognize them by their self-descriptions as
such.

Every interested party is welcome to collaborate with us to produce
more informative and accurate webpages through the CMS.  Please help
out where you can.  Our documentation becomes increasingly
authoritative as more and more people refer to it in positive ways;
ie the best documents wear well over time.

HTH Sent from my iPhone


I've always found the draft label confusing and as a newbie, suggesting 
that content is not yet active but will become so at some time.  But it 
seems from this thread it means descriptive or advice or 
non-normative in W3C-standards-speak.  To me, any non-draft documents 
is documenting current state and subject to change.


Andy


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

Re: [VOTE] Accept Marmotta into the incubator

[Andy Seaborne]

On 29/11/12 20:51, Peter Ansell wrote:

On 29 November 2012 21:28, Andy Seaborne a...@apache.org wrote:


== Relationships with Other Apache Projects

Although current RDF/SPARQL support in LMF is build on top of OpenRDF Sesame
API, Marmotta is closely related to many Apache projects, such as Stanbol,
Jena and Any23. See “Alignment” above.


Hi Andy,

Any23 is also based on the OpenRDF Sesame API, so it doesn't seem to
fit in a list after Although. It may be easier to fit it in the list
before saying Although. In addition, Stanbol can theoretically work
with OpenRDF Sesame API through Clerezza, or through OWLAPI with my
extensions that have not yet been accepted into the OWLAPI trunk. May
be easier to avoid saying Although altogether.

Good luck Marmotta team!



Peter,

The dev mailing list is up and running so do come and join the discussions.

New style naming:
  dev AT
  marmotta.incubator.a.o

Andy

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

[RESULT][VOTE] Accept Marmotta into the incubator

[Andy Seaborne]

Thank you to everyone who has taken part in the reviewing the proposal.

The voting thread is from:
http://s.apache.org/yj

The vote results:

There were 13 +1 votes, of which 10 were binding.   No 0 or -1 votes.

The vote passes.

Andy

Votes:
 (* = binding)

Ross Gardler *
Fabian Christ
Andy Seaborne *
Alan Cabera *
Bertrand Delacretaz *
Nandana Mihindukulasooriya *
Dave Fisher *
Alexei Fedotov
Ted Dunning *
Chris Mattman *
Ralph Goers *
Jakob Homan *
Andreas Kuckartz

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

[VOTE] Accept Marmotta into the incubator

[Andy Seaborne]

 that the future 
development will occur on both salaried and volunteer time, particularly 
by participants from the Linked Data community.


== Relationships with Other Apache Projects

Although current RDF/SPARQL support in LMF is build on top of OpenRDF 
Sesame API, Marmotta is closely related to many Apache projects, such as 
Stanbol, Jena and Any23. See “Alignment” above.


== An Excessive Fascination with the Apache Brand

While we expect the Apache brand may help attract more contributors, our 
interests in starting this project is based on the factors mentioned in 
the Rationale section.


== Documentation

Documentation for the current project can be found at:

http://lmf.googlecode.com

http://doc.lmf.googlecode.com/hg/api/index.html

http://doc.lmf.googlecode.com/hg/rest/index.html

http://doc.lmf.googlecode.com/hg/client/index.html

== Initial Source

LMF (formerly KiWi) has been developed since 2008. It is important to 
say that the whole LMF will not be contributed to Marmotta, actually 
only those parts that make up the Linked Data Platform functionality 
(Linked Data Server, RDF Store, SPARQL, LDCache, Versioning, Reasoner 
and LDPath) . The idea is to focus Marmotta much more in the core needs, 
keeping all surrounding functionalities (Media-related modules and 
Semantic Search, basically) out of the initial scope. Although the 
community will be who ultimately decides what are the relevant modules. 
Since LMF is a very modular software artifact it will be pretty easy to 
make such partitioning to kick-off Marmotta.


The current source code can be found at Google Code: 
http://lmf.googlecode.com


== Source and Intellectual Property Submission Plan

Salzburg Research Forschungsgesellschaft mbH is the sole copyright owner 
of the initial code to be contributed, so should not be any problem with 
the standard IP clearance process. Current licence is already Apache 
Software License 2.0.


== External Dependencies

Most of current dependencies should have Apache compatible licenses, 
including BSD, CDDL, CPL, MPL and MIT licensed dependencies. We are 
aware of some incompatible licenses right now, but we will work to solve 
this issue. See Appendix A for a detailed list of dependencies.


== Cryptography

Does Not Apply.

== Required Resources

Mailing lists

marmotta-dev
marmotta-commits
marmotta-users

Repository

git://git.apache.org/marmotta.git

Issue Tracking

Jira: MARMOTTA (Kanban board enabled at GreenHopper)

Other Resources

Jenkins/Hudson for builds and test running.
Wiki for internal documentation purposes
Blog to improve the project dissemination

== Initial Committers

Sebastian Schaffert
   (sebastian dot schafftert at salzburgresearch dot at)
Thomas Kurz
   (thomas dot kurz at salzburgresearch dot at)
Jakob Frank
   (jakob dot frank at salzburgresearch dot at)
Dietmar Glachs
   (dietmar dot glachs at salzburgresearch dot at)
Sergio Fernández
   (sergio dot fernandez at salzburgresearch dot at)
Rupert Westenthaler
   (rwesten at apache dot org)

== Affiliations

All initial committers are currently affiliated to Salzburg Research 
Forschungsgesellschaft mbH.


== Sponsors

= Champion

Andy Seaborne (andy at apache dot org)

= Nominated Mentors

Fabian Christ (fchrist at apache dot org)
Nandana Mihindukulasooriya (nandana at apache dot org)
Andy Seaborne (andy at apache dot org)

= Sponsoring Entity

Apache Incubator PMC

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

Re: Retirement decision making

[Andy Seaborne]

On 29/11/12 14:53, Bertrand Delacretaz wrote:

On Thu, Nov 29, 2012 at 3:18 PM, Alan Cabrera l...@toolazydogs.com wrote:

... Would you also add the three or more active PMC members requirement?  What 
constitutes active?...


IMO the bare minimum is being able to find three PMC members to vote
on things when needed.

Once a project gets below this limit it's in trouble and usually
headed for the attic, but that's not the only possibility - see
Resolution to reboot the Apache Xalan PMC at
http://www.apache.org/foundation/records/minutes/2011/board_minutes_2011_07_20.txt
for example.


I think we need to be a bit careful about graduating a podling that is a 
minimum viable project.  That's not say it shouldn't be done but if it's 
minimal, and looks ropey, then we're aren't doing us or them any favours 
if the project looks likely to get into problems quite soon.  After all, 
graduation itself requires project resource.


Andy



-Bertrand

-
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: [PROPOSAL] Apache Marmotta

[Andy Seaborne]

A quick update on the Marmotta proposal.

Thanks everyone for the comments.  The proposal should reflect the 
discussions.


One of the mentors is not yet formally a member of IPMC so we're waiting 
until we have three formal mentors before calling the proposal vote.


(and still, ideally, looking for an experienced mentor - I'm looking 
like the old timer on the projects mentor list!)


Andy


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

Re: [PROPOSAL] Apache Marmotta

[Andy Seaborne]

On 20/11/12 10:05, Sergio Fernández wrote:

Hi,

we were internally discussing that the project would benefit a lot from
having a mentor outside of the core Semantic Web community. Then he/she
could help us to address those issues of which are not fully aware when
you work so close in a topic. For instance, someone from the REST
community would be great! Any volunteer(s)?

Cheers,



Two of the three mentors are new to mentoring and fairly new to Apache, 
each having done once round the incubator loop in a recent projects 
(Jena, Stanbol) as project members.  We're feeling a bit light on Apache 
history and breadth.


The project would benefit from a mentor with a longer Apache history - 
someone who can give a wider perspective about culture and community - 
who ensures we establish the wider ideals of the foundation into the 
Marmotta community.


Volunteer?

(Or a mentor-mentor?)

Andy


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

Re: [PROPOSAL] Apache Marmotta

[Andy Seaborne]

On 19/11/12 11:20, Sebastian Schaffert wrote:

Hi all,

we have had a brainstorming round and came up with the suggestion Apache 
Marmotta as a new name. We looked a bit and the name seems not to be taken yet, so 
there would probably no legal issues with the name.

Why Marmotta? It is Italian for marmot, one of the predominant animals in the 
mountains around us. It also is very social (i.e. links) and digs deep tunnels (looks for data). 
It is more or less easy to pronounce (only contains a and o as vowels and no unpronouncible combinations). 
The animal itself has typically a very positive association (cute) and would also provide easy branding with 
images and logos.

What do you think?


The helpful documentation is at:

http://incubator.apache.org/guides/names.html



Greetings,

Sebastian


For Marmot (English spelling, added by Google as I am in the UK) found:

http://www.lrz.de/services/software/parallel/marmot/

http://burlymarmot.com/ - a software company.

which is a different spelling so helps differentiate.

Andy





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

Re: [PROPOSAL] Apache Linda

[Andy Seaborne]

On 17/11/12 09:01, Sergio Fernández wrote:

Hi Roy,

we were aware of the possible conflict/confusion with the name; but
since the Linda model is quite old, not really spread nowadays and
completely far away of the Linked Data topic, personally I can't see a
really big issue here. But of course the Incubator PMC has a deeper
knowledge of such a kind of decisions and its implications, so we'll do
out best to address it during this discussion.

Anyway, we'd prefer to focus the discussion on the proposal itself.
After all, the name is something we can change. But the project is
something important to discuss.

BTW, regarding that, in other to provide some more background about the
proposal, I'd also like to point you the slides we presented one week
ago at ApacheCon Europe: http://slidesha.re/VUQ7ia

Thanks for all your feedback.

Best,


On 16.11.2012 19:30, Roy T. Fielding wrote:

I suggest choosing a different name.

   http://en.wikipedia.org/wiki/Linda_%28coordination_language%29

We generally don't use names that have been (and continue to be)
used extensively by other software projects.

Roy


You're right changing the name can be done later but the name tends to 
get embedded both in the system (e.g. URLs, JIRA project) and more 
importantly in people knowing about the community.


Renaming for the community is hard and risky - I would say it is easier 
to sort it out as part of project initialization if you believe the name 
change is likely.


I did a quick search and found 2 lindas: Linda Spaces (the blackboard 
system that, I guess, is triggering the comments here) and TCP Linda, a 
parallel execution environment (which may well be related to the 
blackboard linda).


TCP Linda ==
http://www.gaussian.com/g_prod/linda.htm

Linda spaces leads to JavaSpaces so is a known name in the Java world at 
least.  There is a SourceForge project linda (but looks dormant)


Andy


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

Re: [DISCUSS] [VOTE] Graduate Apache Any23 from the Apache Incubator

[Andy Seaborne]

 WHEREAS, the Board of Directors deems it to be in the best
 interests of the Foundation and consistent with the Foundation's
 purpose to establish a Project Management Committee charged with
 the creation and maintenance of open-source software, for
 distribution at no charge to the public, related to the automatic crawling,
 parsing and analyzing of data to produce RDF.


Chris wrote:

How about:

related to automatic crawling, parsing, analyzing, producing, and converting RDF
data?


Minor:

[[
related to automatic crawling, parsing, analyzing, producing, and 
converting *of* RDF data

]]






Sound better?

sebb wrote:


At first glance, with the previous version in mind, it seems better.
But when re-read in isolation the phrase implies to me that only RDF
data is involved.

==

Not sure how well known RDF is as a TLA.
For avoidance of doubt, perhaps put:

RDF (Resource Description Framework) data

where necessary.


+1 to RDF (Resource Description Framework)

Andy


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

Re: [VOTE] Graduate Apache Any23 from the Apache Incubator

[Andy Seaborne]

On 16/08/12 14:41, Mattmann, Chris A (388J) wrote:

Hi Folks,

We have already called and completed a community VOTE with the Any23
community and the Tika PMC and they have positively recommended Any23's
graduation from the Incubator.

VOTE: http://s.apache.org/fU
RESULT: http://s.apache.org/VAl

I am now calling for a VOTE with the Incubator PMC to graduate Any23 from
the Incubator. I'll leave the VOTE open for at least the next 72 hours.

[ ] +1 Graduate Any23 from the Apache Incubator.
[ ] +0 Don't care.
[ ] -1  Don't graduate Any23 from the Apache Incubator because...

The Any23 draft board resolution is pasted for your consideration below.

Thank you!

Cheers,
Chris Mattmann
Any23 Champion

P.S. Here's my +1!


+1 (binding)

The community and project are in good shape.

Andy


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

Re: Clerezza status (Was: [Incubator Wiki] Update of August2012 by BertrandDelacretaz)

[Andy Seaborne]

On 11/08/12 12:33, Reto Bachmann-Gmür wrote:

On Thu, Aug 9, 2012 at 9:56 PM, Andy Seaborne a...@apache.org wrote:


On 08/08/12 23:16, Jukka Zitting wrote:


If the efforts to grow or reactivate the community fail, would it be a
good idea to seek to join forces with some related projects like
Stanbol, Any23 or UIMA? Or do you feel that there are still enough
active people to allow the project to function as a standalone TLP
(able to reach 3 PMC votes for releases, etc.)?



Or Jena.



I think from the scope of the application (platform for semantic web
applications) clerezza is the closest to jena. However from the software
architecture clerezza is signifantly closer to Stanbol. Main elements of
clerezza are a very spec close layered RDF API and a platform based on
OSGi, not sure how much the Jena community is interested in these.


Ask them :-)

If it helps, Jena can add OSGi-packaged components.

I see various rdf.jena in the Stanbol parent.  Maybe we should 
take this to (stanbol|clerezza)-dev for detailed discussion.


Andy



Reto




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

Re: Graduation tasks : (was INFRA-4767)

[Andy Seaborne]

sebb - thanks for the pointers.

Andy

On 09/05/12 01:33, sebb wrote:

On 8 May 2012 23:22, Andy Seabornea...@apache.org  wrote:

Seeing INFRA-4767 ...


Need to update the website

1) List of VPs
Also, if a VP position changes, please update the web-site file at:

http://www.apache.org/foundation/index.html

using the CMS application, or update:


https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/foundation/index.mdtext

2) Index of TLPs


https://svn.apache.org/repos/asf/infrastructure/site/trunk/templates/blocks/projects.mdtext



Is projects.mdtext something a graduating project needs to update?


Yes, once the TLP.apache.org website is available.


I'm happy to do it for Jena -
it's not in
  http://i.a.o/guides/graduation.html#notes-on-hand-over
so it hasn't been done so far.

Anywhere else need doing?


DOAP file needs creating and adding to the list [1]
If you already have one it will need updating, and files.xml updated
with the new location.

The PMC chair should have sufficient karma to update that.

[1] 
https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/files.xml


Andy



-
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

Graduation tasks : (was INFRA-4767)

[Andy Seaborne]

Seeing INFRA-4767 ...


Need to update the website

1) List of VPs
Also, if a VP position changes, please update the web-site file at:

http://www.apache.org/foundation/index.html

using the CMS application, or update:

https://svn.apache.org/repos/asf/infrastructure/site/trunk/content/foundation/index.mdtext

2) Index of TLPs

https://svn.apache.org/repos/asf/infrastructure/site/trunk/templates/blocks/projects.mdtext


Is projects.mdtext something a graduating project needs to update?

I'm happy to do it for Jena -
it's not in
  http://i.a.o/guides/graduation.html#notes-on-hand-over
so it hasn't been done so far.

Anywhere else need doing?

Andy


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

Re: May reports due in ten days

[Andy Seaborne]

On 22/04/12 12:55, Jukka Zitting wrote:


   Ready to graduate: Jena, Lucene.NET, NPanday, OpenNLP


Jena graduation has been approved by the board.

We need to do the graduation process now ...

Andy

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

Re: Adding branding items to graduation requirements

[Andy Seaborne]

P.S. Jena looks fairly good, although missing (TM) after the first use
of name, and needs to tweak homepage text a little. I like their logo!


Thanks for that - what are those tweaks (either email or JIRA) and we'll 
get them fixed.


Andy

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

[RESULT] [VOTE] Graduate Apache Jena as a Top Level Project

[Andy Seaborne]

Result for the graduation vote for Apache Jena on general@i.a.o:

+1:
Bertrand Delacretaz
Benson Margulies
Chris Mattmann
Alan Cabrera
Andreas Kuckartz (non-binding)
Leo Simons
Jukka Zitting
Matthew Franklin

0:
None

-1:
None

so we're delighted to announce that the vote has succeeded.

Thanks everyone!

Andy
on behalf of the Jena project



[ ] +1 Recommend to the ASF Board that Apache Jena Proposal
   is ready to graduate to being a top level project.
[ ] 0
[ ] -1 Do not graduate Apache Jena because ...

The vote will be tallied no earlier than:

Thursday April 5th, at 23:59 UTC.


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

[IMPC] [VOTE] Graduate Apache Jena as a Top Level Project

[Andy Seaborne]

This is a call for vote to graduate the Apache Jena podling from Apache 
Incubator to be a top level project.


Jena entered incubation in November 2010.  The project has added two new 
committers and PPMC members, made several releases and has a diverse 
committer base.  The user and development communities are active.  The 
PPMC has indicated [1,2,3] that it believes the project is ready to 
graduate as a top-level project with the resolution draft below.


We ask that the IPMC approve this graduation request though this VOTE.

[1] Vote:   http://s.apache.org/jena-graduation-vote
[2] Result: http://s.apache.org/jena-graduation
[3] Request for comments:
http://mail-archives.apache.org/mod_mbox/incubator-general/201203.mbox/%3C5C4A33CB-B122-43A8-B082-CBD63B526DE7%40cray.com%3E

On behalf of the Apache Jena PPMC,

Andy

-

[ ] +1 Recommend to the ASF Board that Apache Jena Proposal
   is ready to graduate to being a top level project.
[ ] 0
[ ] -1 Do not graduate Apache Jena because ...

The vote will be tallied no earlier than:

   Thursday April 5th, at 23:59 UTC.

-

X. Establish the Apache Jena Project

   WHEREAS, the Board of Directors deems it to be in the best
   interests of the Foundation and consistent with the
   Foundation's purpose to establish a Project Management
   Committee charged with the creation and maintenance of
   open-source software related to accessing, storing, querying,
   publishing and reasoning with semantic web data while
   adhering to relevant W3C and community standards.

   NOW, THEREFORE, BE IT RESOLVED, that a Project Management
   Committee (PMC), to be known as the Apache Jena Project,
   be and hereby is established pursuant to Bylaws of the
   Foundation; and be it further

   RESOLVED, that the Apache Jena Project be and hereby is
   responsible for the creation and maintenance of software
   related to accessing, storing, querying,
   publishing and reasoning with semantic web data while
   adhering to relevant W3C and community standards;
   and be it further

   RESOLVED, that the office of Vice President, Apache Jena be
   and hereby is created, the person holding such office to
   serve at the direction of the Board of Directors as the chair
   of the Apache Jena Project, and to have primary responsibility
   for management of the projects within the scope of
   responsibility of the Apache Jena Project; and be it further

   RESOLVED, that the persons listed immediately below be and
   hereby are appointed to serve as the initial members of the
   Apache Jena Project:

 * Andy Seaborne  (andy)
 * Benson Marguilies  (bimargulies)
 * Chris Dollin   (chrisdollin)
 * Damian Steer   (damian)
 * Dave Reynolds  (der)
 * Ian Dickinson  (ijd)
 * Paolo Castagna (castagna)
 * Rob Vesse  (rvesse)
 * Stephen Allen  (sallen)

   NOW, THEREFORE, BE IT FURTHER RESOLVED, that Andy Seaborne
   be appointed to the office of Vice President, Apache Jena, to
   serve in accordance with and subject to the direction of the
   Board of Directors and the Bylaws of the Foundation until
   death, resignation, retirement, removal or disqualification,
   or until a successor is appointed; and be it further

   RESOLVED, that the initial Apache Jena PMC be and hereby is
   tasked with the creation of a set of bylaws intended to
   encourage open development and increased participation in the
   Apache Jena Project; and be it further

   RESOLVED, that the Apache Jena Project be and hereby
   is tasked with the migration and rationalization of the Apache
   Incubator Jena podling; and be it further

   RESOLVED, that all responsibilities pertaining to the Apache
   Incubator Jena podling encumbered upon the Apache Incubator
   Project are hereafter discharged.

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

[VOTE] Release Jena Fuseki 0.2.1-incubating

[Andy Seaborne]

Hi,

Here is a vote on a release for Jena Fuseki module, 0.2.1-incubating. 
This RC-2 of this release.


Please vote to approve this release:

   [ ] +1 Approve the release
   [ ]  0 Don't care
   [ ] -1 Don't release, because ...

This vote will be open until:

   Wednesday 21/March 23:59 UTC
   (3 whole days: 72 hours from the same hour tonight).

jena-dev thread:
http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201203.mbox/%3C4F63A159.7010506%40apache.org%3E

Staging repository:
https://repository.apache.org/content/repositories/orgapachejena-081/

Proposed files and structure to merge with existing Jena dist/ area:
http://people.apache.org/~andy/merge-jena-fuseki-0.2.1-RC-2/

Keys:
http://www.apache.org/dist/incubator/jena/KEYS

SVN tag:
https://svn.apache.org/repos/asf/incubator/jena/Jena2/Fuseki/tags/jena-fuseki-0.2.1-incubating/


 Andy

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

[VOTE] [Result] Release jena-tdb-0.9.0-incubating (RC-5)

[Andy Seaborne]

On 04/03/12 22:19, Andy Seaborne wrote:

The Jena PPMC has voted to release

Apache Jena TDB 0.9.0-incubating

and we would now be grateful if members of IPMC would review and vote
for this release.

--


...



Please vote to approve this release:

[ ] +1 Approve the release
[ ] -1 Don't release, because ...

This vote will be open until:

Wednesday 7/March 23:59 UTC
(3 whole days: 72 hours from the same hour tonight).


Result of the vote for release of Jena TDB 0.9.0 (RC-5) on jena-dev:

The vote passes.

+1 votes: 3

IPMC votes:

Benson Margulies
ant elder
Leo Simons

0 votes: none

-1 votes: none

Call for the VOTE email and thread:
Vote started 2012-03-04:

http://mail-archives.apache.org/mod_mbox/incubator-general/201203.mbox/%3C4F53EA65.4030604%40apache.org%3E

Thanks everyone,
Andy

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

Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-5)

[Andy Seaborne]

On 08/03/12 09:14, Paolo Castagna wrote:

Thank you ant.

We still need 2 more votes, right?


We need one more IPMC vote.

We have Benson on the project vote thread on jena-dev@i and ant from 
general@i.


Please - one more IPMC +1!

Andy



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

[VOTE] Release jena-tdb-0.9.0-incubating (RC-5)

[Andy Seaborne]

The Jena PPMC has voted to release

  Apache Jena TDB 0.9.0-incubating

and we would now be grateful if members of IPMC would review and vote 
for this release.


--

Main changes from RC-4:

+ Added license to scripts, and XML files.
  small test files don't have a license; test manifests do.
+ New layout of dist/

http://markmail.org/message/oh5stsl2ikbslobs

--

PPMC vote:
http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201202.mbox/%3C4F4E9B97.7060901%40apache.org%3E

We have one IPMC +1 from this thread.

Staging repository:
https://repository.apache.org/content/repositories/orgapachejena-001/

Proposed dist/ area:
http://people.apache.org/~andy/dist-jena-tdb-0.9.0-incubating-RC-5/

This will be added to the existing released modules.

Keys:
http://www.apache.org/dist/incubator/jena/KEYS

SVN tag:
https://svn.apache.org/repos/asf/incubator/jena/Jena2/TDB/tags/jena-tdb-0.9.0-incubating-RC-5/

The module is tagged with the version and RC-5 to indicate the release 
candidate in this release cycle.  If voted on successfully, the tag will 
be changed (svn mv) to the same name but minus the RC designation.


Please vote to approve this release:

  [ ] +1 Approve the release
  [ ] -1 Don't release, because ...

This vote will be open until:

  Wednesday 7/March 23:59 UTC
  (3 whole days: 72 hours from the same hour tonight).

Andy

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

Re: [VOTE] [ended] Release jena-tdb-0.9.0-incubating (RC-4)

[Andy Seaborne]

Currently, this vote has 2 +1 and some comments.  This release vote 
isn't going to get the necessary 3 +1's so is being closed.  We'll be 
back with another RC.


Andy

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

Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-4)

[Andy Seaborne]

sebb,

What I'm trying to get to at the moment is something that enables a 
release of TDB and we can apply to next module.


jena is a number of modules, we have released 3 (5 actually - 2 are the 
parent POM and the distribution maker for the core) already; TDB is the 
sixth, and there are 3 more in the pipeline.


People have been asking for more packaging forms - WAR file for the 
server functionality, OSGi for Jena as a whole, which seems to be a 
non-trivial exercise.


One of the ones to come is not a simple jar build - it's a server that 
can used as a jar, as a combined dependencies jar or run from the 
command line.  I'm trying to understand the constraints required so that 
will be smooth(er).


We are discussing rebuilding our build strategy but doing so, and to get 
it working reliably and stably will take time.  We chose to release with 
what we have, and not let reworking the build system become critical 
path for graduation.


 The apache-jena-tdb... is then merely being a renamed file for browsing
 apache-jena-tdb-0.9.0-incubating-distribution.zip

 (c.f. Ant which has renamed items in it dist/ant)

I referred to Ant specifically because the incubator documentation for 
podling releases picks ant and httpd out as examples to look at.


ant has top level items for easy discovery which are renamed duplicates 
of things in binaries/


 `-- source-release
 `-- jena-tdb-0.9.0-incubating

 What's the point of the subdirectory?

because there are other modules with their own source-release artifact. 
 The TDB release items will be merged into the existing directory.


We had been following a layout like CXF where source-release and 
binaries are in the same directory.  Given that is where a the 
maven-driven process puts them, someone taking the source releease 
doing mvn package is going to look in target/ and expect created items 
to be there.


That was the RC-2 proposal for dist for TDB.  If, as seems necessary, we 
have to adopt a different layout, we'll reorganise the existing release 
items into the same structure.



Would a structure:

dist
|-- binaries
|   `-- jena-tdb-0.9.0-incubating
|   |-- jena-tdb-0.9.0-incubating-distribution.tar.gz
|   |-- jena-tdb-0.9.0-incubating-distribution.zip
|   |-- jena-tdb-0.9.0-incubating-javadoc.jar
|   |-- jena-tdb-0.9.0-incubating-sources.jar
|   |-- jena-tdb-0.9.0-incubating.jar


The jars are not generally needed for dist/


|-- download
|   |-- apache-jena-tdb-0.9.0-incubating-distribution.tar.gz
|   |-- apache-jena-tdb-0.9.0-incubating-distribution.zip


Are these the same as the distribution archives above?


`-- source-release
`-- jena-tdb-0.9.0-incubating


What's the point of the subdirectory?


|-- jena-tdb-0.9.0-incubating-source-release.zip


Name does not agree with binary archives


+ the .asc, .md5 .sha1 files

be acceptable?

Or with download/ removed its files at the top level?


I still find it very confusing.
e.g. where is the source file for jena-tdb-0.9.0-incubating-distribution.tar.gz?


jena-tdb-0.9.0-incubating-source-release.zip

Given the way maven classifiers work, it is a reasonable expectation of 
the user to find the various classifier artifacts in target/ after

mvn package


Why is there a download directory and a binaries directory?


Like ant, I pulled out the items which are download-unpack-go.  The 
dist areas serves several audiences - for (new) users, not necessarily 
experienced maven users, we have the Jena website (we use Apache CMS to 
produce the website, not maven by the way) simply point to download/ 
(mirrored).  Ditto URLs handled out on the web as being the place to go 
to download Jena.


I don't mind if it's download/ or (like ant) at the top level.

Andy


Mocked up at:

http://people.apache.org/~andy/dist-tdb-proto/



See my mockups at:

http://people.apache.org/~sebb/dist-tdb-proto/

one - parallel binaries/ and source/
two - single directory named after the release.

The latter is likely to be easier to manage when moving to svnpubsub.

$ ls -1R

./one:
KEYS
binaries
source

./one/binaries:
apache-jena-tdb-0.9.0-incubating-distribution.tar.gz
apache-jena-tdb-0.9.0-incubating-distribution.zip

./one/source:
apache-jena-tdb-0.9.0-incubating-source-release.zip

./two:
KEYS
apache-jena-tdb-0.9.0-incubating

./two/apache-jena-tdb-0.9.0-incubating:
apache-jena-tdb-0.9.0-incubating-distribution.tar.gz
apache-jena-tdb-0.9.0-incubating-distribution.zip
apache-jena-tdb-0.9.0-incubating-source-release.zip

-
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 jena-tdb-0.9.0-incubating (RC-4)

[Andy Seaborne]

`-- source-release
 `-- jena-tdb-0.9.0-incubating


What's the point of the subdirectory?


because there are other modules with their own source-release artifact.  The
TDB release items will be merged into the existing directory.


So why don't you do the same for the download directory?


The download/ directory would be for all modules.

But as I said, top level work for me as well.  One place where you can 
get all the jena-related unpack-and-go files.


Is that not possible?


We had been following a layout like CXF where source-release and binaries
are in the same directory.





I still find it very confusing.
e.g. where is the source file for
jena-tdb-0.9.0-incubating-distribution.tar.gz?


Sorry, that was a mistake - I meant where is the source for the dowload file

apache-jena-tdb-0.9.0-incubating-distribution.tar.gz


As per ant example - there is a correctly named and positioned file 
and also a copy (and rename) elsewhere.


The specific rename is because, long term, post rework the build, we 
think apache-jena-... will be the packaged up forms and jena-... the 
core jars but that isn't really the issue here.  A systematically named 
file is available.



What I care about is that it is:
- more difficult to find the source than some of the binaries, because
of the extra directory level.


Maybe I don't understand how should we manage multiple modules with 
currently have independent version numbers.


The proposal is have:

/sources/jena-arq-2.9.0-incubating/
/sources/jena-core-2.7.0-incubating/
/sources/jena-iri-0.9.0-incubating/
/sources/jena-tdb-0.9.0-incubating/
/binaries/jena-arq-2.9.0-incubating/
/binaries/jena-core-2.7.0-incubating/
/binaries/jena-iri-0.9.0-incubating/
/binaries/jena-tdb-0.9.0-incubating/

Is this better?

/jena-arq-2.9.0-incubating/sources/
/jena-arq-2.9.0-incubating/binaries/
/jena-core-2.7.0-incubating/sources/
/jena-core-2.7.0-incubating/binaries/
/jena-iri-0.9.0-incubating/sources/
/jena-iri-0.9.0-incubating/binaries/
/jena-tdb-0.9.0-incubating/sources/
/jena-tdb-0.9.0-incubating/binaries/

Can we put easy to find files in /?


- not at all clear how to find the source for some of the binaries, as
it is at a different level and with a different name.


/sources/jena-tdb-0.9.0-incubating/jena-tdb-VER(-classifier)?
/binaries/jena-tdb-0.9.0-incubating/jena-tdb-VER-source-release

are at the same level.

We did have a form like sling uses, split per module.


- binaries are available as tar.gz and zip, but source only as zip


Sorry - I thought I'd answered this earlier.  We use org.apache:apache 
which comes down to this (in assemblies/source-release.xml) which just 
makes a zip.


assembly
  idsource-release/id
  formats
formatzip/format
  /formats
  componentDescriptors
componentDescriptorassemblies/source-shared.xml/componentDescriptor
  /componentDescriptors
/assembly

so we just followed that.  It's a tradeoff - reuse unchnaged vs forking it.

For the .jar.gz: we used to ship a zip, which any Java systems must have 
access to as jar files are zip archives.  Adding .tar.gz was courtesy 
for people wanting files in those forms because it very little work to 
help them.


Andy

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

Re: [ATTN] Incubator releases distribution area reminder!

[Andy Seaborne]

On 24/02/12 16:56, Daniel Shahaf wrote:

Mark Struberg wrote on Fri, Feb 24, 2012 at 09:17:57 +:

PS: txs to Daniel Shahaf for pointing me at the current docs



I didn't :)

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



As I'm discovering, the incubator guides aren't completely clear :-)

1/

Incubator guide:
[[
Distribution policy with regard to releases is simple:

The Incubator insists that artifacts for {podling} are contained 
within www.apache.org/dist/incubator/{podling}.


]]

which does not mention the maven repository at all, and says that 
artifacts go in the dist/incubator/ area.


Two meanings of artifact - maven artifact and Apache product.

2/

If the intention is to strongly suggest specific layouts then the text:

[[
Best Practice
  Layout

A podling is free to choose a suitable layout for its released artifacts 
within the podling distribution directory.


It is recommended that standard layouts (commonly used by other 
projects) be studied

]]

could be revised to include the constraints

3/

[[
Often symbolic links are created from the root of the project 
distribution directory to the latest version of each release. This 
allows scripts or users to easily locate the latest release.

]]

is at odds with

http://www.apache.org/dev/mirror-step-by-step.html
[[
9. Do not use symbolic links in mirrored directories!
]]
although that does say Note: This file contains out-of-date information.

Sorry - I do read the documentation sometimes ;-)

Andy


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

Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-4)

[Andy Seaborne]

We distribute through maven but also many of our users are not experienced
developers but students, including ones new to java.

To make it as easy as possible for this category of user, we ship a
distribution which is the collection of jars needed for use without a
maven/ivy infrastructure.


That's fine, so long as the NL files agree with the contents.


They should do.


This is created in the maven target/ area - and it is then renamed into the
dist/ area as apache-jena* by the distribution build script.  Maven forces
the name to be jena-tdb- on staging whatever assembly root name is
given.


Again that's OK, but the layout of the dist area - and the naming
convention - is very confusing.

There is no direct correspondance between the binary and source archives.
It should be immediately obvious how to find the source and
corresponding binary, but that's not the case at present.


The directory structures align:

/download/jena-tdb-0.9.0-incubating
/source-release/jena-tdb-0.9.0-incubating

but since this isn't /binaries and /sources we'll build about RC - 
we'll be back in a week to 10 day I hope.



The scripts can all have AL headers; there are some XML files as well
that could have them.


I will put either short or full AL headers on the scripts.

find . -name \*xml | xargs grep -L Licensed to the Apache Software 
Foundation | xargs wc -l


  39 ./testing/Deployment/pom.xml
   8 ./src/main/java/com/hp/hpl/jena/tdb/tdb-properties.xml
   8 ./src/main/resources/org/apache/jena/tdb/tdb-properties.xml
  55 total

and tdb-properies.xml has 2 Java properties.

Andy


There is one Java file that has no AL header.


  12 are NOTICE/LICENSE/DEPENDENCIES etc.


These are OK


and then there setting and eclipse files that you have commented on before.

(aside: we tried autogenerating Eclipse files following previous comments
but encountered problems with eclipse:eclipse which we are investigating)


No need to autogenerate; just don't store them with the default names or paths.

Perhaps store them under a resources/eclipse directory.



Andy


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

[VOTE] Release jena-tdb-0.9.0-incubating (RC-4)

[Andy Seaborne]

The Jena PPMC has voted to release

  Apache Jena TDB 0.9.0-incubating

and we would now be grateful if members of IPMC would review and vote 
for this release.


== Major changes since RC-2

+ Distribution has it's own content for NOTICE/LICENSE files which
  rolls up information for the redistributed binaries.
+ jar file META-INF/NOTICE says Apache Jena - module TDB at the top.
+ source-release.zip does not contain a trunk/ copy.
+ New dist/ layout

The existing released files will need to moved to this layout.
The KEYS file is copied into the proposed dist/ area for clarity.

== Project vote

Result:
http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201202.mbox/%3C4F4614CB.9010802%40apache.org%3E

including 1 IPMC vote (Benson Margulies)

Call for VOTE:
http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201202.mbox/%3C4F40CE69.2080402%40apache.org%3E

The following was noted in the jena-dev RC-4 vote:

* The license information for Plugged-In software is in the distribution 
LICENSE file twice.


== Staging repository

https://repository.apache.org/content/repositories/orgapachejena-001/

Direct link to TDB area in staging:
http://s.apache.org/vcp

== Proposed dist/ area:

The following will be added to the existing distribution area:

http://people.apache.org/~andy/dist-jena-tdb-0.9.0-incubating-RC-4/

will be added to:
http://www.apache.org/dist/incubator/jena/

Note: we will reorganise the current dist/ area to fit into this style 
of layout.


== Keys

https://svn.apache.org/repos/asf/incubator/jena/dist/KEYS

== SVN tag

The module is currently tagged with the version and -RC-4.  If voted 
on successfully, the tag will be changed (svn mv) to the same but 
minus the RC labelling.


https://svn.apache.org/repos/asf/incubator/jena/Jena2/TDB/tags/jena-tdb-0.9.0-incubating-RC-4/


Please vote on this release:

  [ ] +1 Approve the release of Apache Jena, module TDB 0.9.0-incubating
  [ ] -1 Don't release, because ...

This vote will be open until:
  Sunday 26/February 23:59 UTC
(72 hours from the same hour tonight).

Andy

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

Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC2)

[Andy Seaborne]

On 12/02/12 12:22, sebb wrote:
... lots of useful comments ...


Hi sebb,

We have just posted a vote on an RC-4 - this reply is to some of the 
specific points you raised:


 Please vote on this release:

   [ ] +1 Approve the release of Apache Jena, module TDB 0.9.0-incubating
   [ ] -1 Don't release, because ...

 The binary NL files need to be sorted out before release.
 The tag and the packaging also need to be sorted out before release.

We believe these have been addressed.

The dist area has been changed to
[DIR] download/
[DIR] source-release/

The SVN tag has been redone without a recursive trunk.

The distribution has it's own LICENSE and NOTICE files that roll up the 
binaries incorporate in the distribution.



The jars need to contain valid NOTICE files; however the files start as follows:





TDB
Copyright 2012 The Apache Software Foundation


Changed to
Apache Jena - Module TDB



The top-level dir contains binary zip and tar archives, but no source archive.
The subdir jena-tdb-0.9.0-incubating/ contains what appears to the the
source archive, but only as a zip.


This is produced by mvn -Papache-release (unmodified) which produces 
just source-release.zip


Andy

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

Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC-4)

[Andy Seaborne]

On 23/02/12 18:32, sebb wrote:

Hi sebb,

Thanks for the review,


== Staging repository

https://repository.apache.org/content/repositories/orgapachejena-001/

This contains zip and tar.gz binary and source archives, which should
be deleted as they are not useful to Maven.


There are two addition classifiers used: source-release and distribution.

To take the file jena-tdb-0.9.0-incubating-source-release.zip 
specifically, this gets there because


   mvn release:perform -Papache-release

puts it there.  This seems to be the practice elsewhere as well:

e.g.
https://repository.apache.org/content/repositories/releases/org/apache/sling/org.apache.sling.engine/2.2.4/


For distribution:

We distribute through maven but also many of our users are not 
experienced developers but students, including ones new to java.


To make it as easy as possible for this category of user, we ship a 
distribution which is the collection of jars needed for use without a 
maven/ivy infrastructure.


This is created in the maven target/ area - and it is then renamed into 
the dist/ area as apache-jena* by the distribution build script.  Maven 
forces the name to be jena-tdb- on staging whatever assembly root 
name is given.


I seem to have missed some document somewhere - what is the correct way 
to handle this?  Pointer?



== SVN tag

  The module is currently tagged with the version and -RC-4.  If voted on
  successfully, the tag will be changed (svn mv) to the same but minus the
  RC labelling.

  
https://svn.apache.org/repos/asf/incubator/jena/Jena2/TDB/tags/jena-tdb-0.9.0-incubating-RC-4/

There are a lot of source files without AL headers.
These need to be fixed.



Could you say which ones you mean?

Following the recent discussion on this (LEGAL-124), I thought the 
conclusion was it wasn't necessary on short files with little or no 
creativity or value.


The files in testing/ are short test files - we do put the ASF header on 
the manifests.


e.g:
https://svn.apache.org/repos/asf/incubator/jena/Jena2/TDB/tags/jena-tdb-0.9.0-incubating-RC-4/testing/Pattern/pattern-1.rq


PREFIX :  http://example/OTHER

SELECT *
{
:NoSuchNode ?p ?z .
?x ?p ?z
}

I found
  A total of 118 files that do not contain th line
Licensed to the Apache Software Foundation (ASF) under

  67 under testing/
  25 are scripts
  12 are NOTICE/LICENSE/DEPENDENCIES etc.
and then there setting and eclipse files that you have commented on before.

(aside: we tried autogenerating Eclipse files following previous 
comments but encountered problems with eclipse:eclipse which we are 
investigating)


Andy

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

Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC2)

[Andy Seaborne]

Hi there,

We're short for votes for this release.  Is there anything the podling 
can do, such as co-ordinate different checking undertaken, to help IPMC 
to vote on this release?


Andy


On 08/02/12 13:03, Andy Seaborne wrote:

The Jena PPMC has voted to release

Apache Jena TDB 0.9.0-incubating

and we would now be grateful if members of IPMC would review and vote
for this release.

== Overview

This will be the second incubator release for by Jena; it's the first
Apache release for the TDB module.

Jena is composed of a number of modules. Historically, they have been
released semi-independently, sort of flying in formation. We intend to
switch to a more integrated build process and we want to create the time
to do that by making this first Apache release of TDB now.

Jena TDB is currently delivered as maven artifacts for the jar and also
a single distribution file as a zip or tar.gz containing all the jars
and their dependencies so users have a download and unpack option.

== Project vote

Result:
http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201202.mbox/%3C4F324DFA.2050800%40apache.org%3E


Call for VOTE:
http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201202.mbox/%3C4F2DA188.6080105%40apache.org%3E


== Staging repository

https://repository.apache.org/content/repositories/orgapachejena-192/

Direct link to TDB area in staging:
http://s.apache.org/apache-jena-tdb-0.9.0-incubating-RC-2/

== Proposed dist/ area:

The following will be added to the existing distribution area:

http://people.apache.org/~andy/dist-tdb-0.9.0-RC2/

will be added to:
http://www.apache.org/dist/incubator/jena/

== Keys

https://svn.apache.org/repos/asf/incubator/jena/dist/KEYS

== SVN tag

The module is currently tagged with the version and -RC-2. If voted on
successfully, the tag will be changed (svn mv) to the same but minus
the RC labelling.

https://svn.apache.org/repos/asf/incubator/jena/Jena2/TDB/tags/jena-tdb-0.9.0-incubating-RC-2/



Please vote on this release:

[ ] +1 Approve the release of Apache Jena, module TDB 0.9.0-incubating
[ ] -1 Don't release, because ...

This vote will be open until:
Saturday 11/February 23:59 UTC
(72 hours from the same hour tonight).


As well as the vote, we'd also appreciate any feedback for improving our
release process and project generally.

Andy



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

Re: [VOTE] Release jena-tdb-0.9.0-incubating (RC2)

[Andy Seaborne]

Hi sebb,

Thanks very much for the time and feedback - we'll be back when we've 
fixed these problems.


Andy

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

[VOTE] Release jena-tdb-0.9.0-incubating (RC2)

[Andy Seaborne]

The Jena PPMC has voted to release

  Apache Jena TDB 0.9.0-incubating

and we would now be grateful if members of IPMC would review and vote 
for this release.


== Overview

This will be the second incubator release for by Jena; it's the first 
Apache release for the TDB module.


Jena is composed of a number of modules.  Historically, they have been 
released semi-independently, sort of flying in formation.  We intend 
to switch to a more integrated build process and we want to create the 
time to do that by making this first Apache release of TDB now.


Jena TDB is currently delivered as maven artifacts for the jar and also 
a single distribution file as a zip or tar.gz containing all the jars 
and their dependencies so users have a download and unpack option.


== Project vote

Result:
http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201202.mbox/%3C4F324DFA.2050800%40apache.org%3E

Call for VOTE:
http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201202.mbox/%3C4F2DA188.6080105%40apache.org%3E

== Staging repository

https://repository.apache.org/content/repositories/orgapachejena-192/

Direct link to TDB area in staging:
http://s.apache.org/apache-jena-tdb-0.9.0-incubating-RC-2/

== Proposed dist/ area:

The following will be added to the existing distribution area:

http://people.apache.org/~andy/dist-tdb-0.9.0-RC2/

will be added to:
http://www.apache.org/dist/incubator/jena/

== Keys

https://svn.apache.org/repos/asf/incubator/jena/dist/KEYS

== SVN tag

The module is currently tagged with the version and -RC-2.  If voted 
on successfully, the tag will be changed (svn mv) to the same but 
minus the RC labelling.


https://svn.apache.org/repos/asf/incubator/jena/Jena2/TDB/tags/jena-tdb-0.9.0-incubating-RC-2/


Please vote on this release:

  [ ] +1 Approve the release of Apache Jena, module TDB 0.9.0-incubating
  [ ] -1 Don't release, because ...

This vote will be open until:
  Saturday 11/February 23:59 UTC
(72 hours from the same hour tonight).


As well as the vote, we'd also appreciate any feedback for improving our 
release process and project generally.


Andy

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

Re: Questions for projects

[Andy Seaborne]

On 30/01/12 17:32, Jukka Zitting wrote:

Jena

When can I vote on your graduation?



Jena's report is already signed off on the wiki: [*]

http://wiki.apache.org/incubator/February2012

The project is discussing graduation.



Plan:
* Graduation preparation
  (checking, drafting the scope/charter, resolution, chair, more checking)
* There are no technical or infrastructure items blocking graduation.



Andy

[*] hey - we're early for once - long may it last!

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

[VOTE] Release jena-2.7.0-incubating (RC1)

[Andy Seaborne]

Please vote on releasing the following as
  Apache Jena version 2.7.0-incubating

This will be the first incubator release for Jena at Apache.

== Overview

Jena is a Java framework for building Semantic Web applications. Jena 
provides a collection of tools and Java libraries to help to develop 
semantic web and linked-data apps, tools and servers.


Jena is composed of a number of modules.  Historically, they have been 
released semi-independently, sort of flying in formation, not as a 
single unit.  We intend to switch to a more integrated build process and 
we want to create the time to do that by making this first Apache 
release with a hybrid of the way we used to do it and a more integrated 
build.


For this first release, we need to release several modules at once as 
none have been released at Apache before.  Our apologies for the extra 
checking work this results in.  It also makes building everything from 
scratch involve more steps than an integrated build would do.


Jena is delivered as maven artifacts for the jar for each module.  It is 
also delivered as zip file containing all the jars and their 
dependencies so users have a download and unpack option.


The version number of the release aligns with the main artifact and the 
packaged download.  Different modules have different version numbers.


Detailed version numbers:

jena-top  0-incubatingParent POM
jena-iri  0.9.0-incubatingIRI parsing library
jena-core 2.7.0-incubatingMain Jena APIs for RDF and OWL.
jena-arq  2.9.0-incubatingSPARQL query engine.
apache-jena   2.7.0-incubatingDownload, with all dependencies.

== Project vote

Apache archives:
http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201112.mbox/%3C4EEDE5F6.1070409%40apache.org%3E

Markmail:
http://markmail.org/message/dob5hsk46ldqkqt4

== Maven staging repository
https://repository.apache.org/content/repositories/orgapachejena-334/

== Proposed dist/ area:
http://people.apache.org/~andy/dist-apache-jena-2.7.0-incubating-RC-1/

== Keys
https://svn.apache.org/repos/asf/incubator/jena/dist/KEYS

== SVN tags

Each module is currently tagged with the version and -RC-1 to denote 
the first release candidate for this release cycle.  If voted on 
successfully, the tag will be changed (svn mv) to the same but minus 
the -RC-1.


https://svn.apache.org/repos/asf/incubator/jena/Jena2/JenaTop/tags/jena-top-0-incubating-RC-1/

https://svn.apache.org/repos/asf/incubator/jena/Jena2/IRI/tags/jena-iri-0.9.0-incubating-RC-1/

https://svn.apache.org/repos/asf/incubator/jena/Jena2/jena/tags/jena-core-2.7.0-incubating-RC-1/

https://svn.apache.org/repos/asf/incubator/jena/Jena2/ARQ/tags/jena-arq-2.9.0-incubating-RC-1/

https://svn.apache.org/repos/asf/incubator/jena/Jena2/JenaZip/tags/apache-jena-2.7.0-incubating-RC-1/

== Website

Including details of this proposed release:
  http://jena.staging.apache.org/jena/


Please vote on this release:

  [ ] +1 Approve the release of Apache Jena 2.7.0-incubating
  [ ] -1 Don't release, because ...

This vote will be open until:
  Wednesday 21/December 23:59 UTC
(72 hours from the same hour tonight).


As well as the vote, we'd also appreciate any feedback for improving our 
release process and project generally.


Andy

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

[VOTE] Release jena-2.7.0-incubating (RC1)

[Andy Seaborne]

Please vote on releasing the following as
  Apache Jena version 2.7.0-incubating

This will be the first incubator release for Jena at Apache.

== Overview

Jena is a Java framework for building Semantic Web applications. Jena 
provides a collection of tools and Java libraries to help to develop 
semantic web and linked-data apps, tools and servers.


Jena is composed of a number of modules.  Historically, they have been 
released semi-independently, sort of flying in formation. We intend to 
switch to a more integrated build process and we want to create the time 
to do that by making this first Apache release now.


For this first release, we need to release several modules at once as 
none have been released at Apache before.  Our apologies for the extra 
checking work this results in.  It also makes building everything from 
scratch involve more steps than an integrated build would do.


Jena is delivered as maven artifacts for the jar for each module.  It is 
also delivered as zip file containing all the jars and their 
dependencies so users have a download and unpack option.


The version number of the release aligns with the main artifact and the 
packaged download.  Different modules have different version numbers.


Detailed version numbers:

jena-top  0-incubatingParent POM
jena-iri  0.9.0-incubatingIRI parsing library
jena-core 2.7.0-incubatingMain Jena APIs for RDF and OWL.
jena-arq  2.9.0-incubatingSPARQL query engine.
apache-jena   2.7.0-incubatingDownload, with all dependencies.

== Project vote

Apache archives:
http://mail-archives.apache.org/mod_mbox/incubator-jena-dev/201112.mbox/%3C4EEDE5F6.1070409%40apache.org%3E

Markmail:
http://markmail.org/message/dob5hsk46ldqkqt4

== Maven staging repository
https://repository.apache.org/content/repositories/orgapachejena-334/

== Proposed dist/ area:
http://people.apache.org/~andy/dist-apache-jena-2.7.0-incubating-RC-1/

== Keys
https://svn.apache.org/repos/asf/incubator/jena/dist/KEYS

== SVN tags

Each module is currently tagged with the version and -RC-1 to denote 
the first release candidate for this release cycle.  If voted on 
successfully, the tag will be changed (svn mv) to the same but minus 
the -RC-1.


https://svn.apache.org/repos/asf/incubator/jena/Jena2/JenaTop/tags/jena-top-0-incubating-RC-1/

https://svn.apache.org/repos/asf/incubator/jena/Jena2/IRI/tags/jena-iri-0.9.0-incubating-RC-1/

https://svn.apache.org/repos/asf/incubator/jena/Jena2/jena/tags/jena-core-2.7.0-incubating-RC-1/

https://svn.apache.org/repos/asf/incubator/jena/Jena2/ARQ/tags/jena-arq-2.9.0-incubating-RC-1/

https://svn.apache.org/repos/asf/incubator/jena/Jena2/JenaZip/tags/apache-jena-2.7.0-incubating-RC-1/

== Website

Including details of this proposed release:
  http://jena.staging.apache.org/jena/


Please vote on this release:

  [ ] +1 Approve the release of Apache Jena 2.7.0-incubating
  [ ] -1 Don't release, because ...

This vote will be open until:
  Thursday 22/December 23:59 UTC
(72 hours from the same hour tonight).


As well as the vote, we'd also appreciate any feedback for improving our 
release process and project generally.


Andy

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

Re: [VOTE] Add Any23 to the Apache Incubator

[Andy Seaborne]

Accept Any23 into the Apache Incubator
  +1 (non-binding)

Andy

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

Re: [PROPOSAL] Any23 to join the incubator

[Andy Seaborne]

On 04/09/11 11:02, Michele Mostarda wrote:

Hi Nick,

On 4 September 2011 10:32, Nick Kewn...@apache.org  wrote:



On 3 Sep 2011, at 16:01, Davide Palmisano wrote:


http://wiki.apache.org/incubator/Any23Proposal


Hmmm.  Could've done with something like that a decade or so ago.
It's been a while since I worked with the semweb, but I might take
an interest.



We hope so!



How would Any23 relate to well-known semweb libraries such as
Redland  family?



Currently we use Sesame [1], which is an RDF library really similar to Jena.


which is:
http://incubator.apache.org/jena/

There's a nice collection of semantic web related projects now in incubator.

Andy

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

Re: [PROPOSAL] 3 month deadline on CLA item

[Andy Seaborne]

On 02/08/11 11:24, Stefan Bodewig wrote:

On 2011-08-02, Henri Yandell wrote:


As can be seen elsewhere, I'm on a self-given mission to clean up the
history of podlings by getting them to sign off on the following
checklist item:



Check and make sure that the papers that transfer rights to the ASF
been received. It is only necessary to transfer rights for the
package, the core code, and any new code produced by the project. 



I view this as the first item that a podling should be dealing with,
along with setting up the committers and getting that first codebase
in. By comparison, a website is a nice to have and community is just
icing.


Dealing with, completing is a different issue.


Proposal time.



In parallel to cleaning up history, I'd like to stop the rot going
forward. I'd like to propose that each new podling has 3 months (or
another calendar length if that feels too short/too long) to get the
checklist item signed off. I'm partial to 3 months as we would make
them report monthly until they have the item signed off, perhaps with
6 months as a 'do we retire the podling?' checkpoint.


+1 in general but three month may be too short, I'm leaning to the
report monthly until done with a checkpoint - and six month feels good
to me.

Currently I'm mentor of a podling where one of the original contributors
who enthusiastically supported the move to the ASF has gone MIA for
several month now without any sort of CLA or grant in sight.  In such a
situation you hope your reminder mails have been lost, there is some
sort of vacation and things will work out.  You wait until you realize
it is time to act because nothing is going to happen.  In such a case
three month get eaten up quickly.

Stefan


My experience with the Jena podling is that getting a Software Grant can 
take a seemingly long time.  It's not a priority item for anyone in the 
the granting organisation so everything just goes slow.  It took us 
about 8 months to do the process and that was a starting point of 
already had discussions that, in principle, the organisation would make 
the grant.


Keeping it at the top of the podling todo list is good - our mentors 
were good at doing that.


Andy

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

Re: [DISCUSS] real-time communications

[Andy Seaborne]

On Thu, Nov 25, 2010 at 10:48 AM, Bertrand Delacretaz
bdelacre...@apache.org  wrote:

On Thu, Nov 25, 2010 at 1:14 AM, Jeremy Carrolljer...@topquadrant.com  wrote:

On 11/24/2010 3:58 PM, Emmanuel Lecharny wrote:


But this is like if you are working in an office in front of a collegue :
most of the time, you don't chit-chat, you work. And when it comes to make a
decision impacting the whole project, then the discussion is moved to the
ML.



In the Jena team, several committers work in one office, I am one of the
ones who doesn't - moreover, I am an 8hr time shift away. The real-time
comms of the office chit-chat is simply a fact of life. I guess clarity
about what the risks are and how we should address them would be useful...


I think it just comes down to everything must happen on the dev list
and make sure your project is open new people and outsiders.

As long as anything that has a significant impact on the project is
discussed/decided on the dev list, and people who cannot attend the
out-of-list discussions do not feel left out, I think you'll be fine.

-Bertrand


All project decisions I can recall for Jena have been whole-group.

The Jena committers are heavy email users and while 
once-upon-a-long-time ago we did sometimes have F2F meetings (when we 
were all in the same timezone, indeed same UK building) email was and is 
the major means of communication.  As we are now a distributed team, 
email has been the means of communication.  The one phone meeting we've 
had was arranged (by email) precisely to include everyone possible 
especially Jeremy.


In the past, I can remember stepping away from my desk for a few minutes 
for coffee to come back to 10's of messages (bounced of a US server of 
course) of Jena discussions between people a few feet apart.


Andy

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

Re: [Proposal] Accept Jena into the Incubator

[Andy Seaborne]

On 13/11/10 02:23, Jeremy Carroll wrote:

On 11/12/2010 6:05 PM, Benson Margulies wrote:

CyberNeko and TagSoup both have acceptable licenses. Some people
prefer TagSoup because it does not require Xerces.

Have you read http://www.apache.org/legal/resolved.html?


No I hadn't. That is very useful.

A first reaction, concerning the GRDDL dependencies, is:
1) BrowserLauncher needs to go - I will make the code changes
2) Saxon dependency is a B
3) Cyberneko is fine - Jena already has dependencies on Xerces


Cyberneko 1.9 is Apache License v2 (from the project page on SF).

GRDDL depends on an older v0.9 which has it's own license, if I 
understand correctly.


Jeremy - you understand the issues and code here.  Is the text added to 
the proposal OK and can we assume you will either resolve the legal 
issue or modify the codebase of the GRDDL reader to amke it a non-issue.


Andy

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

Re: [Proposal] Accept Jena into the Incubator

[Andy Seaborne]

On 13/11/10 13:32, Ross Gardler wrote:

All,

Resolving IP issues are a part of the incubation process not the acceptance 
process

It is not necessary to delay entry into the incubator because some o these 
issues need to be satisfactorily resolved. The Jena developers are aware of 
this and have undertaken to do what is required in meetings with myself as 
Champion.  Can one of the Jena team please add a note to this effect in the 
proposal in order to remove any doubt about this.


Done.  The text added says:

[[
The initial committers overtake to resolve all IP and copyright issues 
that concern the dependencies of the initial source and of any 
contributions in accordance with Apache requirements for graduating from 
incubator status.


All contributions to the Jena codebase are under BSD-style license.  The 
majority of copyright is held by HP. Some copyright is held by others, 
as noted in the codebase. This includes contributions from the initial 
committers below and any other contributions.

]]

At this point, any of the Jena initial committers can revise that text 
otherwise lazy consensus applies.



I'd like to call a vote on Jenas entry but am unable to do so until this 
discussion is resolved. I am going to assume the addition of a commitment to 
resolve these issues are sufficient to move forwards (lazy consensus).

Ross


Andy

PS We recently removed a dependency on json.org code.  I know Apache 
allows it but some organisations found that license difficult to work with.


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

Re: [Proposal] Accept Jena into the Incubator

[Andy Seaborne]

On 12/11/10 08:40, Nick Kew wrote:


On 8 Nov 2010, at 23:36, Ross Gardler wrote:


I am pleased to offer, for your consideration, the following proposal to accept 
Jena, a semantic web framework into the incubator. The text of the proposal is 
copied here for your convenience and can be found at 
http://wiki.apache.org/incubator/JenaProposal


Strong +1 in principle.  I'd offer to mentor, but I see you now have plenty.

One niggle: have you clarified somewhere that all the dependencies
licenses are Apache-compatible?  The openjena.org page referenced
relies on references that are broken links!


Grr ... rotting links ...

Where?  I'll fix them ASAP.  Checking:

http://openjena.org/Licenses/index.html

I found the links for JUnit and WoodSToX have rotted.  Anything else 
gone bad?


Andy

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

Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?

[Andy Seaborne]

On 10/11/10 23:28, Jeremy Carroll wrote:

- The core API for (mutable) graphs in:
http://incubator.apache.org/clerezza/mvn-site/org.apache.clerezza.rdf.core/apidocs/index.html


http://incubator.apache.org/clerezza/mvn-site/org.apache.clerezza.rdf.core/apidocs/org/apache/clerezza/rdf/core/TripleCollection.html#filter(org.apache.clerezza.rdf.core.NonLiteral,%20org.apache.clerezza.rdf.core.UriRef,%20org.apache.clerezza.rdf.core.Resource)


IteratorTriple filter(NonLiteral subject, UriRef predicate, Resource
object)

vs

http://jena.sourceforge.net/javadoc/com/hp/hpl/jena/graph/Graph.html#find(com.hp.hpl.jena.graph.Node,%20com.hp.hpl.jena.graph.Node,%20com.hp.hpl.jena.graph.Node)


ExtendedIteratorTriple find(Node s, Node p, Node o)

seems to be the fundamental choice.

The latter was the choice Chris Dollin and I made in 2002/2003 and I
still find it preferable, for program uniformity, to the closer to the
spec choice in Clerezza.
We were writing the spec at the same time, and I always saw it as a
description of a Web exchange format, and not of a programming interface
(for instance implementing RDF Semantics Rec is hard with the Clerezza
interface).


Isn't the model interface operation a more appropriate comparision 
because that is what the application sees?


StmtIterator listStatements(Resource s, Property p, RDFNode o)

Graph.find is the SPI interface to storage. The Graph level has named 
variables, not just RDF terms.  SPARQL uses this, heavily.


In SPARQL, literals can occur in any position during query processing. 
Patterns involving literals as subjects, or as predicates, just simply 
don't match the data (section 12.3.1).


Once upon a time, when we were going Jena1-Jena2, the idea was that the 
application API was just one presentation.  There could be other RDF 
APIs over the SPI.  There's not been a second RDF presentation API but 
the design concept was there and still is.  All the interfaces in the 
API are mainly implemented only once, and I'm not aware of any users 
which use the extensibility within the Resource API anymore 
(Parliament/BBN used to - I think they now use an associated 
datastructure to map to internal information for any API 
resources/literals from their storage).  The Resource-level API 
implementation could be simplified if theer is only one implementation 
of that presentation.  There is generality in Jena that we thought was a 
good idea at the time but looking at way the world has gone since, not 
all of it is used or useful nowadays.  Better use of factory/interface 
at the SPI would be more helpful. The experimental Jena3 core also has 
extension nodes and graph nodes with an eye to future possible needs 
from the standards world.



I am not quite sure what that means in terms of this discussion which is
more procedural than technical.


Same here.

Advice on an appropriate discussion forum welcome - while we're in a 
state of exploring the relationships of projects, I'm guessing that here 
is the only common place there is.


Andy

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

Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?

[Andy Seaborne]

I haven't understood yet the relationship of Stanbol and Clerezza to be 
able to say anything about how a commons area between those two systems 
might work.  In terms of direct dependencies, does Stanbol just directly 
depend on Clerezza and only indirectly on Sesame, Jena rdf2go and the 
OWLAPI that the proposal lists?


Jena has two levels of API, the Model/Statement/Resource that 
applications usually use, and the SPI Graph/Triple/Node thathe the 
storage and inference layers plug into.  Roughly, speaking, the API 
faces upwards to applications and the SPI downwards to components. 
There is also the same design for the support for RDF datasets for 
SPARQL.  SPARQL, especially SPARQL Update, works on quads for named graphs.


There are significant investments by users in uses of both API and SPI 
and the cost of change for users isn't trivial.  Worse, the SPI is used 
by systems that are distributed on making any change over messy. There 
needs to be a real advantage to change.


Speaking personally, I'm not strongly motivated by a common API; I don't 
think it helps the semantic web enough compared with other things I 
could work on.  If others are working on one, I'll do what I can to make 
my contributions work as smoothly as possible with that through 
discussing what hooks and flexibility I can contribute to Jena to make 
it work smoothly with other systems.



I'm not particularly worried about there being several APIs since that's 
the state we're in and I don't see it changing particularly quickly 
because there are large investments in deployed systems that exists.  As 
some of these systems themselves are distributed onwards, chnage woudl 
be slow.


Most of my contribution is storage and query which works at the lower 
level anyway, so it has less effect on me but the SPARQL related parts 
of the public APIs are mostly my fault. I am currently working on a 
SPARQL 1.1 compliant server - the on-the-wire standardization is more 
important.  Working on storage and query does result in a slight 
obsession with efficiency - storage and query need to be tightly coupled 
for performance.


Jeremy identified the IRI library as a potential contribution to a 
commons area.  It is free-standing, and does not use or call any Jena 
RDF code - it depends only on ICU4J (and JUnit + Jflex in the build).


The client-side content negotiation code in Jena could do with an 
upgrade so if there is system-independent code that can be reused for 
the systems here and more widely, that would be great.  I would use it 
as I need to provide code-level access to for client SPARQL 1.1 access.


If nothing else, shared knowledge and expertise would move things along 
faster, and even if functionality needs tying to specific systems, 
having all the projects in Apache greatly helps community.


Andy

PS Reto - GVS [*] isn't on the list of thing to contribute to Apache as 
we're focusing on the core system that is used and we support.  But that 
does not preclude including GVS either now or later.  It is covered by 
our agreement-in-principle with HP.  Do you want to do that?


[*] Reto wrote a graph versioning system for Jena several years ago.

On 08/11/10 21:39, Reto Bachmann-Gmuer wrote:

Hi Jeremy

One of Clerezza aims was to use an RDF api that is maximally close to RDF
abstract syntax and semantics, on this RDF core api we have different
façades and utilities as well as a frontend adapter implementing the jena
API. Related standards like SPARQL and the various serialization formats are
supported as well, respective engines can be added at runtime (when running
in a OSGI container). We decided to design our own API as we found the
various API available (jena, openrdf, rdf2go) would neither be as modular
nor as close to the spec as we wanted them to be. The API comes with the
typical utilities like a command line tool and a maven plugin for the
transformation of vocabularies into classes

Apart from core part tightly coupled to RDF and related specs Clerezza also
provides a framework for implementing rest applications (JAX-RS). The
encourages design pattern is that requests are answered in terms of RDF
(i.e. a graph and typically a selected resource within this graph), clerezza
takes care about content-negotiation and for RDF formats the serializer
registered for that media type is used. For non RDF formats a template
(typically a Scala Server Pages) is selected and takes care of the
rendering.

I described this parts of Clerezza because they seem to be quite close to
what you suggest for commons. As it is hard to share utilities without
having shared APIs for the core stuff our code deals with I think some
efforts in this area could have the greatest benefit.

If you have some time, I would like to encourage feedback on the respective
APIs as currently used in Clerezza

- The core API for (mutable) graphs in:
http://incubator.apache.org/clerezza/mvn-site/org.apache.clerezza.rdf.core/apidocs/index.html
- 

Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?

[Andy Seaborne]

On 09/11/10 16:22, Florent Guillaume wrote:

On Tue, Nov 9, 2010 at 1:19 PM, Andy Seaborne
andy.seabo...@epimorphics.com  wrote:

Jeremy identified the IRI library as a potential contribution to a commons
area.  It is free-standing, and does not use or call any Jena RDF code - it
depends only on ICU4J (and JUnit + Jflex in the build).


Please note that Abdera already has an IRI library.
http://svn.apache.org/repos/asf/abdera/java/trunk/dependencies/i18n/src/main/java/org/apache/abdera/i18n/iri/


Florent,

Thanks for pointing that out.  I see it has a test suite as well and it 
would be good to make sure we've got things right.


Illegal IRIs in data have been a bit of a plague in RDF data and the IRI 
library (written by Jeremy) is a response to that.  It checks both rules 
for specific IRI schemes and also recommended forms as IRIs are often 
com pared for equality.  The library is quite picky.  It includes 
profiles for RDF URI references, IRI and the compromise we use in Jena 
as a balance of legacy and spec exactness.


There is an online test service for RDF data in non-RDF/XML formats at:

http://sparql.org/data-validator.html

The IRIs are checked with the IRI library.

Andy

A few examples:

http://example/a b

Code: 17/WHITESPACE in PATH: A single whitespace character. These match 
no grammar rules of URIs/IRIs. These characters are permitted in RDF URI 
References, XML system identifiers, and XML Schema anyURIs.


http://example/a[]b

Code: 0/ILLEGAL_CHARACTER in PATH: The character violates the grammar 
rules for URIs/IRIs.


http://example:80/

Code: 13/DEFAULT_PORT_SHOULD_BE_OMITTED in PORT: If the port is the 
default one for the scheme it should be omitted.
http://example:80/ Code: 14/PORT_SHOULD_NOT_BE_WELL_KNOWN in PORT: 
Ports under 1024 should be accessed using the appropriate scheme name


urn:xyz

Code: 61/SCHEME_PATTERN_MATCH_FAILED in PATH: The scheme specific syntax 
rules are violated.


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

Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?

[Andy Seaborne]

On 09/11/10 16:59, Jeremy Carroll wrote:

I could be accused of having gone overboard ...


yes ... :-)


Having changed job and looking at this from a different perspective I am
less convinced by the pickiness.


At least leave the picky mode there, please.  It's been very helpful in 
working with data generated by one organisation and used by another. 
Script generated IRIs have been


Once dubious data gets into a database, it's troublesome to get it out. 
Having the data storage only cover the required spec common ground is 
better.


TDB uses the IRI profile (not RDF URI references) as strict as possible 
except that these two warnings are switched off:


ViolationCodes.UNWISE_CHARACTER
  that is {, }, |, \, ^, `
  It's the | that I found used in generated IRIs.

Whitespace is handled separately.
  are syntax errors.

ViolationCodes.UNREGISTERED_IANA_SCHEME
  because people invent schemes for data.

I did find the most strict mode a bit too strict :-)

Andy

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

Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?

[Andy Seaborne]

On 08/11/10 18:32, Jeremy Carroll wrote:

To make the commons discussion more concrete I would suggest the
following items for the commons:

- an IRI library
- some code to do with vocabularies.
- connecting to a URL and doing semweb aware content negotiation (this
is typically done badly)

(Actually the IRI code should probably be wider, Jena initially used the
xerces URI code but then the needs exceeded what they supported)

Jeremy


Good idea.  The IRI code is independent of the rest of Jena and is 
valuable in it's own right.


ARP (Jena RDF/XML parser) is also independent of the Jena code structure 
and once was (is it still possible to get just ARP?).  It's just the 
final step of generation that turns the output of parsing into 
Jena-specific objects.  Might be worth splitting out if it would be useful.


The lowest level of RIOT parsing, which defines the tokens for creating 
any of the Turtle family of langauges, is not Jena dependent.  The 
actual RIOT parsers themselves are as they directly generate 
Jena-specific objects to avoid the copy overhead.  It's a performance 
trade-off.


[RIOT is a set of faster parsers for non-XML serializations of RDF, 
currently part of ARQ, but should migrate to Jena core when fully 
stable. - original need was parsers for formats capable of delivering to 
the TDB database at full loading speed without heavy CPU load.]


But the command line tools based on RIOT which parse or validate one 
format are reusable - they use Jena internally, but the input and output 
are completely standard.


The RDF validator Eyeball is also a useful tool in its own right.

Andy


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

Re: Clerezza, Stanbol, Jena, Semantic Commons, WDYT?

[Andy Seaborne]

On 08/11/10 17:30, Ian Dickinson wrote:

Hi Donald,

On 08/11/10 17:01, Donald Whytock wrote:

Perhaps db.apache.org would be a better example?  Should there be a
semantic.apache.org?

I looked around in db.apache.org and I couldn't see anything that said
what the goals of that project are, separate from the goals of the
individual sub-projects. Where should I be looking?

As others have noted, the three semantic web-related projects currently
being proposed have rather different objectives and provide different
capabilities. I personally don't object in principle to factoring out
common code or needs where that's useful, but +1 to Olivier: let's wait
until a clear requirement is identified.


I agree.  I don't think that a semantic XYZ is useful if that makes 
semantic some sort of different software.  Semantic web technology is 
getting used more widely and a semantic commons or formal grouping of 
projects risks creating the idea that it's all or nothing, which isn't 
the case, hopefully.


Andy

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