Re: About Registration

[Stian Soiland-Reyes]

On Fri, 30 Mar 2018, 09:19 Buddhika Lakshan,
 wrote:
> How to be a apache member?

Formal membership of the Apache Software Foundation is by invitation
only, following a formal vote. Membership recognize long-term
commitment to the goals and practices of the ASF.


However, anyone can contribute to any of our projects, no need to
"register" - they are all open source!

https://community.apache.org/newcomers/


Contact the ASF project of interest for further help. For instance
here is how you can typically contribute to a fictional Apache project
"Foo"

Sign up to the d...@foo.apache.org mailing list http://lists.apache.org/
   Basically there is were all decisions and communication should
happen in a project, although some of the emails might be coming
through from Jira and GitHub pull requests.
   Just lurking around and read how communication is done can teach you a lot.

Download their source code from git/svn, make sure it builds on your machine.

Feel free to ask questions on the dev@ list if you can't get your
build environment set up or weird errors pop up  - it could be the
project needs to update the build instructions?

Find a bug or idea you want to work on - most projects use
https://issues.apache.org/jira/ or GitHub issues, so you can just
search around there for something easy.

Fork on GitHub, check out to your own branch

Once you have some kind of (small) fix, raise a Pull Request. Rather
multiple PRs than a single big one!

Respond to questions to the Pull request, e.g. for suggested code improvements!

If no-one responds to your PR for a few days, perhaps they were on
their Easter break? Just ping on the dev@ list - but don't be
inpatient as most Apache contributors do this in their spare time.



Here's a bit more about the formal processes and how the Foundation
works, written by Foundation member (and now on Board of directors)
Shane Curcuru
https://communityovercode.com/2015/03/how-apache-really-works/


Basically the organizational ASF "career" path is:

* Anonymous (you just download and use our code, that's fine!)
* User questions (asking questions on mailing list on how to use the code)
* (unofficial) project contributor (anyone joining mailing list
discussion, submitting pull requests, website updates)
* (official) Project Committer (formal write access, recognizes contributors)
* Project Management Committee (voting rights on releasesand new
project members; recognizes project-wide commitment)
* Foundation Member (voting rights on board of directors and new
members, policy discussions; recognize ASF-wide commitment)
* Board of Director (day to day running of the foundation; recognize
ASF-wide leadership)

ASF is a "meritocracy" - the more you do, the more you will be
recognized! But there is no requirement to climb this ladder; most
Apache contributors are at the top lines of this list, so the easiest
is just to start contributing! And it is important to note that it
does not have to be code; documentation, design, discussion, mentoring
- all of them count! Have fun!

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

Re: Does GSoC help develop communities?

[Stian Soiland-Reyes]

On 5 December 2016 at 17:07, Jacob Champion <champio...@gmail.com> wrote:
> Perhaps a bit off-topic for this thread in particular, but in all
> seriousness, I like this idea a lot. As you've noted, older projects and
> established developers don't always know which parts of their projects need
> "newbie improvement" -- after all, they've already figured it out for
> themselves.


Yeah, let's start that in another thread.


Here is a starting point:

https://svn.apache.org/repos/asf/comdev/tmp/random_projects.py

stain@biggiebuntu:~/src/comdev/tmp$ ./random_projects.py 3
karaf
activemq
oozie


(would this belong under comdev/tools? It seems to be meetup-centric)

-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: Does GSoC help develop communities?

[Stian Soiland-Reyes]

Perhaps something for ComDev is to work on engagement with software
developers who don't currently consider themselves part of any ASF
community, but use our software without contributing (much) back.

These are generally more experienced than GSOC students, and while they
won't have as much continual time available, they could contribute in other
ways.

You may them moaning on StackOverflow or at big software conferences.
ApacheCon is nice, but is often preaching to the converted (and their
colleagues they managed to lure along :-).

I would think that many times ASF comitters could be at a more specific
conference or venue for their field, and could easily give an ASF/open
source pep talk to people they meet or present to. Golden opportunity!
Perhaps some Comdev PDFs of a generic flyer with "How does ASF work? Join
us!" could be handy to print out, so they don't have to make up everything
on the spot or beg here for trademark guidance to compose their own ASF
promo material.


Knowing myself and my organisation, we used ASF software for at least 10
years, developing our own open source software. It didn't occur to us to
during that time that perhaps we could (should!) also help out on ASF
software we relied on, like httpd, tomcat, commons, derby, Jena, etc.
No-one told us so, no READMEs or announcements, no people or stands at big
conferences.



Now there is GitHub pull requests, which do significantly lower the
barrier, but many ASF projects still don't say much (or at all) on their
pages and READMEs that this is a welcome contribution path.


Many ASF projects don't explain well enough for outsiders how development
happens. Perhaps it looks as if we are all experts and you need to be
specially invited. Perhaps people sign up to dev@ lists, but get scared by
the open development discussions, thinking "Uh, I don't know enough about
this, it's clearly not for me. And what is this VOTE thing?". We can't
know, because those people are not around.


The information is there, but it is often buried, not linked to from
project home pages and email threads - "everybody knows". For instance I
try to include statements like this in VOTE emails:


> Anyone can participate in testing and voting, not just

committers, please feel free to try out the release candidate
and provide your votes.

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



ComDev could help with building a generic pages like "what is a release
candidate and what do I do", "How are decisions made?". This then fits into
the ComDev or ASF blog and could be used as a default link or template for
projects to refer to when voting - it should be more observational than
policy.

Could it make sense for ComDev to (sensitively) contribute patches pr
recommendations to ASF projects in this regard? It should not look like
medling or patronising, just like a pull request with friendly suggestions.

Often I find it is that incubator projects get it right (eventually), while
older projects are comfortably established and are effectively outdated in
respect to the the ComDev maturity model and ASF best practice. (E.g. link
to older mbox mailing list archive, no link to Code of Conduct).

Perhaps ComDev can act like a prpject visitor. (Not auditor or inspector!)
We can make a wiki page with a randomised list of all ASF projects, a quick
checklist (smaller than maturity model) and just go through them one by one
and raise issues/pull requests for any small community encouragement issues
we find. Is that too intrusive?

On 5 Dec 2016 3:26 pm, "Daniel Gruno"  wrote:

> On 12/05/2016 03:46 PM, Shane Curcuru wrote:
> > Ulrich Stärk wrote on 12/5/16 9:27 AM:
> >> On 05.12.16 14:30, Daniel Gruno wrote:
> >>> On 12/05/2016 01:41 PM, Ulrich Stärk wrote:
> > ...snip...
> >>> But this goes beyond GSoC in my mind. We should be looking at ALL
> ComDev
> >>> projects and evaluate what we want to keep, what isn't working, and
> what
> >>> needs a do-over. The task of ComDev is to *develop communities*, it
> >>> shouldn't just be a dumping ground for all things cross-project,
> whether
> >>> they work or not. That is at least my opinion.
> >>>
> >>> We try strategies, give them life, see if they work, and if not, we put
> >>> them to sleep or fix them.
> >>
> >> Geez, we are not maximizing for efficiency here (and that coming from a
> management consultant, how
> >> ironic).
> >>
> >> Let me take GSoC as an example again. As long as we have volunteer
> mentors from our communities that
> >> want to mentor students working on their projects than we IMO don't
> need any additional metric or a
> >> certain level of usefulness to justify running the program. Our
> communities think it is important -
> >> otherwise they wouldn't invest the time -, so should we.
> > ...snip...
> >
> > You both have excellent points.
> >
> > I believe GSoC is a very valuable program for the ASF and the projects
> > that participate, and I really hope the 

Re: Does GSoC help develop communities?

[Stian Soiland-Reyes]

I think GSOC is very valuable, both for the students and the ASF projects
that participate.

Even if a student does not hang around after GSOC (were they made
committer?) it is still good for communities to get fresh drive and ideas,
and ask questions which established committers might not have thought that
newbies didn't know. GSOC projects are good ways to kick-start new
prototypes and challenge the existing architecture.

In a way GSOC also teaches/reminds projects how to make its code,
documentation and community welcoming for newcomers, so that is why I think
it is particularly good to encourage fresh incubator podlings to
participate.

This can't be easily measured in numbers.

GSOC mentoring can draw significant project bandwidth, yes, but then
projects and potential mentors can choose to participate or not per year.

On 5 Dec 2016 2:46 pm, "Shane Curcuru"  wrote:

> Ulrich Stärk wrote on 12/5/16 9:27 AM:
> > On 05.12.16 14:30, Daniel Gruno wrote:
> >> On 12/05/2016 01:41 PM, Ulrich Stärk wrote:
> ...snip...
> >> But this goes beyond GSoC in my mind. We should be looking at ALL ComDev
> >> projects and evaluate what we want to keep, what isn't working, and what
> >> needs a do-over. The task of ComDev is to *develop communities*, it
> >> shouldn't just be a dumping ground for all things cross-project, whether
> >> they work or not. That is at least my opinion.
> >>
> >> We try strategies, give them life, see if they work, and if not, we put
> >> them to sleep or fix them.
> >
> > Geez, we are not maximizing for efficiency here (and that coming from a
> management consultant, how
> > ironic).
> >
> > Let me take GSoC as an example again. As long as we have volunteer
> mentors from our communities that
> > want to mentor students working on their projects than we IMO don't need
> any additional metric or a
> > certain level of usefulness to justify running the program. Our
> communities think it is important -
> > otherwise they wouldn't invest the time -, so should we.
> ...snip...
>
> You both have excellent points.
>
> I believe GSoC is a very valuable program for the ASF and the projects
> that participate, and I really hope the volunteers stepping up to
> organize keep doing it.  I'll try to remember to thank you more often!
>
> Separately, it's great when we can also improve things, or at least show
> some sort of progress towards helping our project's communities grow.
> Given the rest of the organization that GSoC brings, and the fact that
> our LDAP and other records are getting pretty easy to script against, it
> would be great if some volunteer wanted to track people who became
> committers from GSoC to see their contributions in the future.
>
> But just because no-one has stepped up to do the metrics doesn't mean we
> should stop GSoC.  If people want to volunteer to do something that's
> generally positive, great.  Suggestions for improvements are good;
> getting in the way to slow progress because some additional goal hasn't
> yet attracted a volunteer to do it is not as good.
>
> - Shane
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: Does GSoC help develop communities?

[Stian Soiland-Reyes]

Yes, that was the very case for us in Taverna, where two students got
engaged because of GSOC advertising, even if they didn't participate in the
GSOC programme (we lacked mentor capacity), so they co-mentored each other
instead.  Both are now committers.

Related SSI blog post, "Downloading developers":

https://www.software.ac.uk/blog/2016-10-12-downloading-developers-google-summer-code

On 18 Nov 2016 4:58 pm, "Buddhika Jayawardhana" 
wrote:

> Also there may be students who have who actually did not take in part in
> GSOC for Apache, but got involved with Apache because of GSOC ,and still
> stick around.
>
> On 16 November 2016 at 15:48, Nick Burch  wrote:
>
> > On Wed, 16 Nov 2016, Rich Bowen wrote:
> >
> >> It would be great to have some kind of statistics on how GSoC helps
> >> projects longer term. Do students stick around? Does the code written
> >> actually get incorporated into releases? Does it in fact contribute to
> the
> >> mission of Community Development, or is it just a nice summer job for
> these
> >> students?
> >>
> >
> > Do we have a list (maybe somewhere in the comdev private svn?) of
> everyone
> > who has taken part in GSoC?
> >
> > If so, it'd be fairly easy to annotate that with apache IDs, then see
> > who's now on PMCs or who's now a member. Producing sharable statistics
> from
> > that automatically is then easy. (I say this as someone who helped update
> > the similar Travel Assistance Committee / TAC ones on Monday!)
> >
> > Not sure if it's easy to find out the "last commit date" for people, to
> > check for the "still around" part (eg for people who got committership
> > during GSoc, maybe on a branch), but I know where infra are to ask...
> >
> > Nick
> >
> > PS FWIW, within Tika we've certainly had a few GSoC people stick around!
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> > For additional commands, e-mail: dev-h...@community.apache.org
> >
> >
>
>
> --
> Best Regards
>
> *Buddhika Jayawardhana*
> Undergraduate | Department of Computer Science & Engineering
> University of Moratuwa
> *buddhika...@cse.mrt.ac.lk * | LinkedIn
> 
>

Re: resolver sources ?

[Stian Soiland-Reyes]

Hi,

I am not sure what you mean by xml-commons / resolver sources 2.9.1.
Do you have the URL to which artifact you mean?



http://archive.apache.org/dist/xml/commons/xml-commons-resolver-1.2.zip
 is the latest version I can find, but I just had a quick look.

There are newer versions in
http://archive.apache.org/dist/xerces/xml-commons/



Perhaps you are thinking of XercesJ 2.9.1?

http://xerces.apache.org/mirrors.cgi
has 2.11.0

2.9.1 should be archived in
http://archive.apache.org/dist/xerces/j/



You may want to subscribe to and contact j-...@xerces.apache.org to ask
with a detailed URL to which artifact you are looking for the source for.

See
https://lists.apache.org/list.html?j-...@xerces.apache.org

On 1 November 2016 at 21:08, Christophe Marchand <cmarch...@oxiane.com> wrote:
> Hello,
>
> I'm looking for xml-commons / resolver sources. A 2.9.1 release is available
> on maven, but I can't find the sources.
> Can someone give a link to an up-to-date repository ?
>
> Thanks in advance,
> Christophe
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: ASF for Google Code-In

[Stian Soiland-Reyes]

+1 to have a go, we discussed it in Taverna as well, we could give them
something to do in the Android app.

It would be a bit similar to HelpWanted.apache.org I guess, but with
mentoring..? It would have to be quite bite-sized for high school students,
but you would probably also be surprised as to what some of them can do!

On 30 Oct 2016 11:22 pm, "Roman Shaposhnik"  wrote:

> Hi!
>
> a project I mentor got interested in:
>  https://developers.google.com/open-source/gci/
>
> Has there been any attempts to have ASF
> as a mentoring organization there?
>
> The current list of orgs is pretty eclectic:
>https://codein.withgoogle.com/archive/2015/organization/
> but given that folks like Ubuntu are on the list
> I don't see why ASF shouldn't be.
>
> Thanks,
> Roman.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: Addition to the project maturity model

[Stian Soiland-Reyes]

"release artifacts"? Or does that hint to much of Maven?

We can do it as two different requirements..

RE50 - independendly generate a source archive (RE10).

RE60 - independently generate any convenience binaries (RE40)


I'm not sure what is the deal with the BASIC line numbering idea of
RE* - perhaps these additions could also be RE11 and RE41 to better
align.


On 29 September 2016 at 14:25, William A Rowe Jr <wr...@rowe-clan.net> wrote:
> On Wed, Sep 28, 2016 at 3:33 AM, Mark Thomas <ma...@apache.org> wrote:
>
>> All,
>>
>> After a discussion on the general@incubator.a.o mailing list [1], I'd
>> like to propose the following addition to the project maturity model.
>>
>> RE50
>> The release process is documented and repeatable to the extent that
>> someone new to the project is able to independently generate a release
>> build.
>>
>
> Release 'build'? That sounds very .jar'ish to me :)
>
> In non-JVM environments, we may have radically different ways of building,
> even on linux a project may have autoconf vs cmake as parallel options.
> No single release manager is expected to try all alternatives across some
> broad array of target platforms.
>
> The project must also demonstrate that they have documented how-to
> for users/consumers to generate a binary build from the release package.
> In terms of maturity, that might start out as windows-only or unix-only
> or java-only, but as the project evolves more supported build platforms,
> they will have the template for adding more build how-to documentation.
>
> Since binaries are not releases, is it enough to say 'release package'
> to capture the essence of tarball, .zip, or whatever the sources include?
> If a project wants to include the .jar file as a side effect of creating the
> release sources, I think 'release package' covers that to.
>
> Otherwise, strongly +1 to this suggestion.



-- 
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718

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

Re: Addition to the project maturity model

[Stian Soiland-Reyes]

On 28 September 2016 at 19:26, Joan Touzet  wrote:
> Big +1 here. Projects that can't be repeatably built risk decay
> faster than those that can.

+1 - as long as it is documented it doesn't matter if it says "copy
the file three times while jumping high in the air".

Obviously automated build/release simplifies things - documentation
would also highlight any special build infrastructure.


Not sure how a project can prove the "someone new to the project" bit
- perhaps this can be motivation to encourage new committers to (try
to) do a release?

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

Re: Distributing ASF Material

[Stian Soiland-Reyes]

Great you are connecting with Women in Big Data!

I think as long as they are not claiming association or endorsement it
should be fine to redistribute ASF marketing material (which license
do we have on those?), even if an ASF committer is not always there.

Separation is the key, e.g. keep the ASF posters/flyers separate from
WiBD and Hortonworks posters/flyers.


Apache(tm) and the Apache feather logo are still protected trademark,
so they can't be used as part of the stand's banners without
permission.

On 15 August 2016 at 09:58, Sharan Foga <sharan.f...@gmail.com> wrote:
> Hi Rich
>
> I've just found out that the booth at Grace Hopper will actually be a 
> Hortonworks one. They are a sponsor of Women in Big Data. I know the ASF 
> prefer not to be aligned with any one company so am checking if this changes 
> the situation.
>
> One idea they have suggested, is that they know that at least one ASF 
> Committer will be present at the conference (possibly two)  so they could 
> make sure that the ASF material is only offered when a Committer is also 
> present at their booth.  Could this be an acceptable solution?
>
> Thanks
> Sharan
>
> On 2016-07-29 18:59 (+0200), Rich Bowen <rbo...@rcbowen.com> wrote:
>> It is preferable to have someone able to answer questions, but I don't
>> think we'd refuse.
>>
>> On Jul 26, 2016 9:00 AM, "Sharan Foga" <sharan.f...@gmail.com> wrote:
>>
>> > Hi All
>> >
>> > I was chatting yesterday to a contact from the Women in Big Data group
>> > (WiBD)
>> >
>> > https://www.womeninbigdata.org/
>> >
>> > and they mentioned that they would be represented at the Grace Hopper
>> > Celebration of Women in Computing event in Houston later this year. I hear
>> > that conference tickets are pretty much sold out.
>> >
>> > They have a stand are willing to distribute ASF marketing material on our
>> > behalf. I didn't know if that was OK or not so am asking here. As the ASF
>> > may not be officially represented at that conference  – would another
>> > organisation distributing ASF material be an issue?
>> >
>> > Thanks
>> > Sharan
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>> > For additional commands, e-mail: dev-h...@community.apache.org
>> >
>> >
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/-0001-9842-9718

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

Re: License Version 2.0

[Stian Soiland-Reyes]

On 27 June 2016 at 14:47, Android Developer
<rodrigocastrillo...@gmail.com> wrote:
> Good day
> I 'm android developer and work for a direct sales company, I can use the
> library for encryption SharedPreferences to store user data for free?
>
> Thank you very much.

Hi,

I'm afraid you will need to provide more details about which library
you mean.

Apache Software Foundation have many projects:
https://www.apache.org/index.html#projects-list

in addition to the Apache Incubator projects:
http://incubator.apache.org/


Also android.content.SharedPreferences is a class provided by the
Android SDK, which is not developed by Apache Software Foundation:
https://developer.android.com/


If some software is licensed as Apache license, version 2.0 aka
https://www.apache.org/licenses/LICENSE-2.0.html - then you can use it
for free and redistribute, provided you follow the Redistribution and
attribution requirements:

https://www.apache.org/licenses/LICENSE-2.0.html#redistribution


-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/-0001-9842-9718

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

Re: Hipchat Room for Apache Women?

[Stian Soiland-Reyes]

How about divers...@apache.org? I hope I would still be welcome! :)
On 14 Jun 2016 11:20 p.m., "Jacques Le Roux" 
wrote:

> We do, at least I do, and I'm certainly not alone :)
>
> Jacques
>
> Le 14/06/2016 à 15:21, Patricia Shanahan a écrit :
>
>> It could be a meeting place for those interested in ASF women's issues,
>> without excluding men who share that interest.
>>
>> On 6/14/2016 5:39 AM, Sharan Foga wrote:
>>
>>> Hi Patricia
>>>
>>> Personally I think that the mailing list is a better forum for detailed
>>> discussions. It has the threaded structure and it's easier to follow
>>> discussion points and respond to particular things that people have said.
>>> (We could use this list for those type of discussions as it's relevant to
>>> developing the ASF community.)
>>>
>>> My understanding is that the chat room doesn't really give us that and
>>> that it's more about short fast dialogues, so I'm not sure how well it
>>> would work. (The main idea behind my original suggestion was to use it more
>>> like a meeting place, and not so much a discussion one.)
>>>
>>> Thanks
>>> Sharan
>>>
>>> On 2016-06-14 13:26 (+0200), Patricia Shanahan  wrote:
>>>
 How do you feel about a room for discussing ASF women's issues?

 On 6/14/2016 1:25 AM, Sharan Foga wrote:

> Hi
>
> Thank you both for your feedback on this and it's showing that it's
> not the way people want to go.
>
> Thanks
> Sharan
> On 2016-06-13 17:50 (+0200), Kay Schenk  wrote:
>
>>
>>
>> On 06/13/2016 06:17 AM, Patricia Shanahan wrote:
>>
>>> On 6/13/2016 4:45 AM, Sharan Foga wrote:
>>>
 Hi Everyone

 I discovered Hipchat last week (well I knew Infra were using it!)
 but
 found it to be quite a nice informal online environment.

 I was wondering whether this could be a good way to bring together
 our existing community of women so that they can get to know each
 other and generally just hangout. The rooms can be public or
 private,
 plus there is one to one chat.

 What do people think?

>>>
>>> I object to a chat room for Apache women just as strongly as I would
>>> object to one for Apache men, and will not join it. I would be happy
>>> to
>>> join a chat room for discussing Apache women's issues, provided both
>>> men
>>> and women who are interested in the subject are made welcome.
>>>
>>> My particular brand of feminism supports treating men and women
>>> equally,
>>> and minimizing facilities and clubs that are only for men or only for
>>> women.
>>>
>>> Patricia
>>>
>>
>> I'm share Patricia's views on this. I don't think a separate chat room
>> solely for woman is in keeping with the "Apache Way".
>>
>>
>> --
>> 
>> MzK
>>
>> "Time spent with cats is never wasted."
>> -- Sigmund Freud
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>> For additional commands, e-mail: dev-h...@community.apache.org
>>
>>
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>
 -
 To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
 For additional commands, e-mail: dev-h...@community.apache.org



>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>>> For additional commands, e-mail: dev-h...@community.apache.org
>>>
>>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
>> For additional commands, e-mail: dev-h...@community.apache.org
>>
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
> For additional commands, e-mail: dev-h...@community.apache.org
>
>

Re: Encouraging More Women to Participate on Apache Projects?

[Stian Soiland-Reyes]

Hi, Sharan! Great initiative, diversity is a very important topic for
ASF and software development in general!


Here's another great community:

http://www.womeninhpc.org/

They bring together many highly skilled HPC devops and researchers who
I am sure could bring valuable contributions to many HPC- and
cloud-related Apache projects.


Example of text from their training events, which I think could be a
good slot to sneak in some "Contribute to Open source (perhaps ASF?)"
slides:

> This event is open to everyone interested in using HPC, but all our training 
> staff will be women and we hope that this provides an opportunity for women 
> to network and build collaborations as well as learning new skills for a 
> challenging and rewarding career in HPC.




On 23 May 2016 at 11:45, Sharan Foga <sharan.f...@gmail.com> wrote:
> Hi All
>
> Just a quick update. I've sent out an email to the following groups so far:
>
> - Pyladies
> - Phpladies
> - Women Who Code
> - Girls Who Code
> - Black Girls Code
>
> I'll post any feedback I get. Also if anyone thinks of any other groups
> they'd like me to contact then please let me know.
>
> Thanks
> Sharan
>
>
> On 20/05/16 14:26, Sharan Foga wrote:
>>
>> Thanks very much to everyone for their feedback and support.
>>
>> Rich - I will contact these groups to see what feedback and advice they
>> can give.
>>
>> Thanks
>> Sharan
>>
>> On 20/05/16 14:05, Rich Bowen wrote:
>>>
>>> I would suggest that the most constructive thing we could do would be to
>>> reach out to pyladies and phpwomen and other similar organizations and
>>> ask
>>> for recommendations and assistance in setting up a similar entity here.
>>> On May 19, 2016 11:18, "Sharan Foga" <sharan.f...@gmail.com> wrote:
>>>
>>>> Hi All
>>>>
>>>> I'm interested in finding out how we could encourage more women to
>>>> participate on Apache projects. It's a discussion topic that came up
>>>> last
>>>> week while I was at Apachecon. My understanding is that we don't have
>>>> any
>>>> current strategies in place so I think it could be good to look at
>>>> gathering some ideas about how to tackle the problem and also hear about
>>>> any lessons learned from any previous or similar strategies.
>>>>
>>>> What do people think?
>>>>
>>>> Thanks
>>>> Sharan
>>>>
>>>>
>>>>
>>
>



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons
http://orcid.org/-0001-9842-9718

Re: SHA512 by default for GPG sigs

[Stian Soiland-Reyes]

In principle +1, a PGP signature based on sha1 is not cryptographically
strong.

Obviously blindly checking a PGP signature, even after importing the KEYS
from https://www.apache.org/dist, that is also not any proof you got the
intended release, just an artifact by someone who previously signed some
ASF release. (If you are paranoid and/or work my for a three-letter
government institution, then you probably want more proof of exactly which
version you are downloading)

I think the convenience of the old standard .sha1 and .md5 files is that
they can also be included in this VOTE emails, forming a distributed
evidence in list archives of which release was approved. (although I see
many projects now being made more lax about this and just refer to a
transient Maven step repo). In addition to being easy to check, they are
also easy to inline say in a Dockerfile, so I would not get rid of those
even if the .asc is improved.

Are there any compatibility issues for downstream users with your proposed
default change? What about for Maven deployment? I assume a newer gpg is
needed; what would be the new version requirement, and how does this match
what is available in typical distros and OS installs?
On 18 May 2016 7:55 p.m., "Christopher"  wrote:

> Hi all,
>
> I'm not sure a better list to get feedback on, but I wanted to bring
> attention to the proposal here:
> https://issues.apache.org/jira/browse/MPOM-118
>
> Essentially this is a suggestion to configure the maven-gpg-plugin to sign
> using SHA512 as its digest algorithm in the ASF Parent POM, used by many
> Maven/Java-based projects within ASF. This configuration takes affect
> during software releases when this plugin is activated (typically prior to
> a release candidate vote, and staging a release in Nexus for distribution
> to Maven Central).
>
> This would only affect the hash algorithm used to generate GPG signatures
> for releases, and not any separate SHA/MD hashes published separately by
> any project, which can be weaker (SHA1, MD5) for convenience, and don't
> convey the strong authenticity statement that digital signatures provide.
>
> For background, gpg uses SHA1 by default, unless the signing key or gpg
> configuration has a preference to use another algorithm (as described on
> https://www.apache.org/dev/openpgp).
>
> This proposed configuration change wouldn't force the use of SHA512 (it
> could still be overridden by a project), but it would make it the default,
> which helps improve the security of releases in the case where release
> managers have failed to keep their configuration up-to-date with the best
> recommendations for using gpg.
>
> Thoughts? +1s? Discuss here or on the JIRA please.
>
> Thank you.
>

Re: Adding asfext:registered to projects.a.o?

[Stian Soiland-Reyes]

How about something very modern - moving to JSON-LD schema.org annotations
in the root index of the project homepage and just fetching all of those..?

Seriously; keeping them under a single comdev control sounds most sensible
as I doubt the distributed DOAP files are well maintained.  Projects can
raise pull requests to update and then see their changes live on the new
projects.apache.org pages
On 11 Feb 2016 17:35, "sebb"  wrote:

> On 11 February 2016 at 12:03, Shane Curcuru  wrote:
> > I need to annotate our structured data set of Apache projects to track
> > which project names are registered trademarks.  This is needed to be
> > able to properly generate a.o/foundation/marks/list (which is currently
> > sadly outdated since it's manually built now).  This is a serious need
> > for Brand Management, since we regularly have third parties say "but you
> > didn't SAY it was your trademark, so I can do it anyway..."
> >
> > My thought is to annotate the PMC DOAP files with a registered marker,
> > then use the existing projects.a.o building of the organized data.  Then
> > use either JS or some cron static generation to display the actual
> > marks/list page.
>
> There are two kinds of RDF files:
> - the PMC RDF files [1] which are mainly stored in the comdev area
> [2], though they can also be stored elsewhere.
> The locations of the files are held in committees.xml [3]
> [These are not actually DOAP files, though the format looks similar.]
>
> - the project DOAP files which are stored by individual projects; they
> are listed in projects.xml [4]
>
> A single PMC RDF file can be associated with multiple DOAP files, e.g.
> Commons, Creadur, Tomcat all have multiple independent project
> releases.
>
> > Is annotating the project data sources the best idea, or should I simply
> > create a new stable URL data source that's just a list of registered
> > names, and join the tables?
>
> I doubt if either of the above file types are suitable.
> The location of the index XML files [3], [4] has already been changed
> once (when projects-new was established).
>
> DOAP files are located all over the place and are often moved within
> the SCM without updating the index file.
> If they are located in the source tree there are often multiple copies
> in different branches.
>
> PMC RDF files may not be updateable except by the project (if located
> in their SCM), and again may move without warning if they are not in
> [2].
>
> It would potentially be possible to recover the PMC RDF files from
> their external locations and insist that they only be stored in the
> comdev area.
> But a single PMC may have multiple marks. Potentially also a project
> may move from a PMC to become its own PMC.
>
> Therefore I think a separate file is needed.
> That would also allow write access to be limited if necessary.
>
> > The end result needs to be webcontent listing projects like:
> >
> > The ASF claims these trademarks
> > ...list all active TLPs
> > Apache {$projectname}
> > {$if registered then "" else ""}
> >
> > 
> >   {$shortdesc}
> > ...
> > The following projects are retired
> > ...list all Attic projects
> >
> > The following projects are in incubation; all trademarks here may be
> > property of respective owners
> > ...list all Incubation projects
> >
> > Separately, we should list the name of each software *product* here,
> > since if we offer something with a clear name as an independently
> > downloadable software product, it can be our trademark.  So I'd like to
> > list "Apache Directory Studio", since that's a notable name and a major
> > product.  But I don't want to list "Apache Commons Foo Bar Baz and
> > Kitchensink", since those are effectively just minor components that
> > aren't really worth claiming.
> >
> > Comments/suggestions please?  I'm including the Whimsical project since
> > they are also major consumers of this data.
> >
> > - Shane
>
> [1] https://projects.apache.org/pmc_rdf.html
>
> [2]
> https://svn.apache.org/repos/asf/comdev/projects.apache.org/data/committees/
> [3]
> https://svn.apache.org/repos/asf/comdev/projects.apache.org/data/committees.xml
> [4]
> https://svn.apache.org/repos/asf/comdev/projects.apache.org/data/projects.xml
>

No announce@ archive for August?

[Stian Soiland-Reyes]

Why is there no annou...@apache.org archive for August?

http://mail-archives.apache.org/mod_mbox/www-announce/


The list seems still to be working in external archives:
http://apache-announce.markmail.org/

-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

Re: GitHub Pages

[Stian Soiland-Reyes]

This looks good.

So do I understand any of the commiters editing the site would still
need to run Jekyll manually and push (how?), or is there a GitHub like
autobuild?

Is Jekyll still requiring various Ruby libraries to be installed in a
carefully selected version (with fun time on Windows for native
dependencies), or is docker images like jekyll/jekyll making things
easier?




On 3 August 2015 at 15:58, Owen O'Malley omal...@apache.org wrote:
 On Wed, Mar 4, 2015 at 11:56 PM, Ted Dunning ted.dunn...@gmail.com wrote:

 Several projects are using Jekyll to emulate the github style site
 processing.  As an example: http://drill.apache.org/

 THis is still a bit inconvenient in that the gh-pages branch has to be
 built using jekyll and then checked into SVN, but it does work pretty
 easily.  The process pretty much has to be manual because of the access
 required to check things into SVN, but there is nothing else that requires
 manual intervention.


 Actually, now infra has set it up so that you can have both in the same
 repository using the asf-site branch in git. Here is the generated html
 for ORC: https://github.com/apache/orc/tree/asf-site

 I really like the Jekyll engine for generating the HTML. ORC's jekyll
 source is at https://github.com/apache/orc/tree/master/site

 .. Owen



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

Re: GSoc 2015 Application misplaced

[Stian Soiland-Reyes]

We are very sorry. We asked our contact at Google, which unfortunately
replied that it is too late:

 No, I'm sorry, there's nothing we can do about it now. The student should
 have contacted us about this before the applications closed this year.


Just a thought:

Is there any chance your proposal could be appropriate for
Apache Spamassasin? Your application does not seem rspamd-specific.

I know Spamassasin always have had Bayesian filtering, but the other
machine learning methods you mention sounds interesting.

Spamassasin mailing list:
http://mail-archives.apache.org/mod_mbox/spamassassin-dev/

On 29 March 2015 at 20:17, Sarang Shrivastava sarang...@gmail.com wrote:
 Hello all,
 I accidentally made a blunder while submitting my Gsoc 2k15 proposal. The
 proposal was meant for rspamd but accidentally got posted with Apache
 Software Foundation.

 The link to my proposal is 
 https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015/xlr_24/5629499534213120?verified=True
 

 Please help me out. It would be very appreciating if you being an open
 source organization would help out an open source enthusiast.


 --
 *Sarang Shrivastava*
 *Computer Science  Engineering*
 *MNNIT Allahabad*



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

Re: work with you

[Stian Soiland-Reyes]

On 18 March 2015 at 09:10, ϻǿɧᾷᵯᵯᶐȡ ʂĥ mohmma.d.1...@hotmail.com wrote:
 Hi guys ,I'm mohammad and I'm from Palestine , i'm Registered in google 
 summer of codeand I am a Java programmerand i want working with you but i'm 
 bad in English , Can I work with you ?


I suggest one of:

1) Language support. I think you speak Arabic, which has 420 million
speakers. Projects like Apache OpenOffice do a lot of translation and
documentation in different languages (localization)

2) Code. You are probably good enough in English to understand
variables and class names. As Thiago says, try to stay at bug-fix
level - explaining new modules needs more English.

3) Graphics and layout - find a project with a GUI or website that can
be made prettier. You probably don't need to look for long! :)

4) Find a mentor that you think speaks Arabic - ask kindly if (s)he
would help you.

5) Almost cheating: https://translate.google.com/  -- but try to write
simple, so it does not get too confusing. Include the English AND the
Arabic in the emails.


The harder thing for you would be to write the proposal, and to follow
the mailing lists. Just be honest about your language skills.

Apache communities have people of all kinds and languages, but English
is the language used on the mailing lists, code and documentation.


For the proposal - keep it short - use many links, code examples or diagrams.

See project ideas at http://s.apache.org/gsoc2015ideas or make your own.

Look for Arabic-looking names in Reporter field:

https://issues.apache.org/jira/issues/?filter=12330297jql=labels%20%3D%20gsoc2015%20ORDER%20BY%20reporter%20ASC



See an example proposal  at
http://community.staging.apache.org/gsoc#application-template  -- you
can skip some sections.



Google Translate from English to Arabic

أقترح أحد:

1) دعم اللغة. أعتقد أنك تتحدث العربية، التي لديها 420 مليون المتكلمين.
مشاريع مثل أباتشي أوبن أوفيس تفعل الكثير من الترجمة والتوثيق في لغات
مختلفة (توطين)

2) كود. وربما كنت جيدة بما فيه الكفاية في اللغة الإنجليزية لفهم
المتغيرات وأسماء فئة. كما يقول تياجو، في محاولة للبقاء في مستوى علة
الإصلاح - شرح وحدات جديدة يحتاج الى مزيد من الإنجليزية.

3) الرسومات وتخطيط - يجد مشروع مع واجهة المستخدم الرسومية أو الموقع
التي يمكن تقديمها أجمل. وربما كنت لا تحتاج إلى نظرة لفترة طويلة! :)

4) البحث عن معلمه الذي تعتقد يتحدث العربية - نسأل تتكرم إذا (ق) وقال
انه مساعدتك.

5) الغش تقريبا: https://translate.google.com/ - ولكن في محاولة لكتابة
بسيطة، لذلك لا يحصل مربكة جدا. تشمل اللغة الإنجليزية واللغة العربية في
رسائل البريد الإلكتروني.


أن الشيء الأصعب بالنسبة لك أن يكون لكتابة هذا الاقتراح، ومتابعة
القوائم البريدية. فقط نكون صادقين حول مهاراتك اللغوية.

المجتمعات أباتشي لها الناس من جميع أنواع واللغات، ولكن اللغة
الإنجليزية هي اللغة المستخدمة في القوائم البريدية، ورمز والوثائق.


للاقتراح - يبقيه قصيرة - استخدام العديد من وصلات، وأمثلة التعليمات
البرمجية أو الرسوم البيانية.

نرى أفكار المشاريع في http://s.apache.org/gsoc2015ideas أو على مسؤوليتك الخاصة.

ابحث عن العربية المظهر الأسماء في الميدان المراسل:

https://issues.apache.org/jira/issues/?filter=12330297jql=labels%20%3D%20gsoc2015%20ORDER%20BY%20reporter%20ASC



رؤية اقتراح سبيل المثال في
http://community.staging.apache.org/gsoc#application-template - يمكنك
تخطي بعض المقاطع.






-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

Re: Google Code shutting down Jan 2016

[Stian Soiland-Reyes]

+1 for GitHub  - as Apache Extras are easily mini-communities of one
or two people and not as clear way in to contribute.


GitHub should seriously be considered. Making an apache-extras
organization there should be straight forward.

As for binaries - I found it very useful to use BinTray for Beanshell
- as I could do both Maven and regular downloads:

https://code.google.com/a/apache-extras.org/p/beanshell/wiki/Download

On 12 March 2015 at 21:49, Christopher ctubb...@apache.org wrote:
 I don't know the reasons for choosing SF, but I'd highly recommend
 putting serious consideration into GitHub. It's quite pleasant to work
 with, and although I'm not a part of the apache-extras, I think those
 who are would be quite satisfied with it (that's just my personal
 opinion, of course).

 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii


 On Thu, Mar 12, 2015 at 5:37 PM, David Nalley da...@gnsa.us wrote:
 It is my understanding that moving to SF from Google Code is a ComDev
 decision. I have interacted with SF and then brought the PoCs they've
 done here, but AFAIK, no decision has been made.

 --David

 On Thu, Mar 12, 2015 at 4:55 PM, Ross Gardler (MS OPEN TECH)
 ross.gard...@microsoft.com wrote:
 Ahhh... I see no that's just code for I don't have time, but these folks 
 have shown interest ;-)

 I'm happy to help make sure we hit this deadline, but I'm not driving it.

 Ross

 -Original Message-
 From: Ulrich Stärk [mailto:u...@spielviel.de]
 Sent: Thursday, March 12, 2015 1:50 PM
 To: dev@community.apache.org
 Subject: Re: Google Code shutting down Jan 2016

 *Really* moving board@ to BCC ;)

 You said you put people in contact with each other so I was under the 
 impression you were actively part of a group driving this.

 Jim, do you have any updates on the current status?

 Cheers,

 Uli

 On 2015-03-12 21:40, Ross Gardler (MS OPEN TECH) wrote:
 Moving board@ to BCC

 I am *not* working on it. I have no idea who said I was (I do hope it
 wasn't me!)

 All I know is that Jim, David and Roberto are working on it, I don't
 know how actively but it is now a priority.

 I believe Jim is involved wearing his ComDev hat so (with his
 agreement) you can look to him for those updates. David is wearing his 
 infra hat and Roberto wears his SF hat.

 Ross

 Microsoft Open Technologies, Inc. A subsidiary of Microsoft
 Corporation

 -Original Message- From: Ulrich Stärk
 [mailto:u...@spielviel.de] Sent: Thursday, March 12,
 2015 1:36 PM To: dev@community.apache.org Cc: bo...@apache.org
 Subject: Re: Google Code shutting down Jan 2016

 We reported about apache extras in September and November and both
 times we were told that Jim, Ross, David and Roberto were working on
 it. Some time in October David asked for feedback on a proof of concept, 
 no news since then.

 Can you shed some light on who is driving this atm?

 Cheers,

 Uli

 On 2015-03-12 21:22, Ross Gardler (MS OPEN TECH) wrote:
 Today Google announced that Google Code will be shutting down Jan 25, 
 2016.

 We need to create a replacement for Apache-extras. Can we please make
 sure that progress on this is reported in the ComDev board report each 
 quarter.

 I suggest the starting point should be to expand discussions with
 SourceForge, they have offered neighborhoods in the past. David, with
 his infra hat, has been exploring options for download provision already 
 (I'm not sure of the current status).

 (and as a reminder, this is why we don't like to use services
 provided by external companies)

 Ross

 Microsoft Open Technologies, Inc. A subsidiary of Microsoft
 Corporation





-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

Disk space requirement for building on Windows (was: Re: [jira] [Commented] (JENA-897) jena-jdbc-tdb tests use %TEMP% instead of target/)

[Stian Soiland-Reyes]

 Thanks, Rob!

I tried looking yesterday at ways to reduce the disk space
requirements when building on Windows - including truncating the files
after closing. This seems to require deep changes into TDBs
ChannelManager which keeps the corresponding FileChannels - perhaps a
new method for that purpose?

https://github.com/apache/jena/blob/master/jena-tdb/src/main/java/com/hp/hpl/jena/tdb/base/file/ChannelManager.java


It seems on Windows with Oracle/OpenJDK you can call System.gc() to
(hopefully) release the ByteBuffers that lock the memory regions (and
then making the files deletable) - but this adds a significant
overhead. The dispose methods on ByteBufferImpls are not easily
accessible - you would need some introspection hackery to get hold of
that cleaner() and that would of course only work on Oracle/OpenJDK.
as fc.map() still does the same thing.

Close your eyes -  GPL3!
https://github.com/stain/jdk8u/blob/master/src/share/classes/java/nio/Direct-X-Buffer.java.template#L72
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b132/java/nio/DirectByteBuffer.java/#72


I tried using the FileChannels from JDK7 NIO2 (e.g.
FileChannel.open(Path)) instead of through RandomAccessFile - but it
did not make any difference


Perhaps System.gc() is not worth it in general (* on Windows) when
closing a dataset - I tried to modify the ChannelManager to always do
this on release, it meant each test in jena-jdbc-tdb took 1.5s instead
of 0.2s, but it did allow me to delete the used folders from target/
while the JVM/test was running.

For the tests we could do something like for every 10 tests do
System.gc() and wipe the old data.

Perhaps Fuseki 2 could do System.gc() on [Remove]  SystemTDB.isWindows.



On 10 March 2015 at 10:00, ASF GitHub Bot (JIRA) j...@apache.org wrote:

 [ 
 https://issues.apache.org/jira/browse/JENA-897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14354617#comment-14354617
  ]

 ASF GitHub Bot commented on JENA-897:
 -

 Github user asfgit closed the pull request at:

 https://github.com/apache/jena/pull/41


 jena-jdbc-tdb tests use %TEMP% instead of target/
 -

 Key: JENA-897
 URL: https://issues.apache.org/jira/browse/JENA-897
 Project: Apache Jena
  Issue Type: Bug
  Components: JDBC
Affects Versions: Jena 2.12.1, Jena 2.13.0
 Environment: Windowx 8.0 x64, C: with 34 GB free
Reporter: Stian Soiland-Reyes
Priority: Critical
 Fix For: Jena 2.13.1


 .. and thus mvn clean install on Windows will easily consume 37 GB on C: and 
 run out of disk space - even if Jena is built on a larger partition.



 --
 This message was sent by Atlassian JIRA
 (v6.3.4#6332)



-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

Re: Disk space requirement for building on Windows

[Stian Soiland-Reyes]

The System.gc() is not guaranteed to work - but it did work for me.
That is what I meant by a 'best effort' within the test. The test does
not require all those old test folders to hang around.

Could we do a workaround for the test to set say a tinier block-size
instead of 8 MB?


As I have been unable to build all of Jena on Windows - what is the
actual disk space requirement? It should at least be documented in the
README.

On 10 March 2015 at 11:07, Rob Vesse rve...@dotnetrdf.org wrote:
 Using an alternative approach would not make any difference

 It is a fundamental bug in Windows memory mapped files that means that a
 JVM can never guarantee to completely release memory mapped files while
 the JVM is alive.

 Andy has posted this many times on threads about TDB on Windows in the
 past.  No workaround we could attempt could ever solve the issue on
 Windows so there is really no point in expending effort changing something
 low level that otherwise works fine across multiple platforms.

 Rob

 On 10/03/2015 10:25, Stian Soiland-Reyes st...@apache.org wrote:

 Thanks, Rob!

I tried looking yesterday at ways to reduce the disk space
requirements when building on Windows - including truncating the files
after closing. This seems to require deep changes into TDBs
ChannelManager which keeps the corresponding FileChannels - perhaps a
new method for that purpose?

https://github.com/apache/jena/blob/master/jena-tdb/src/main/java/com/hp/h
pl/jena/tdb/base/file/ChannelManager.java


It seems on Windows with Oracle/OpenJDK you can call System.gc() to
(hopefully) release the ByteBuffers that lock the memory regions (and
then making the files deletable) - but this adds a significant
overhead. The dispose methods on ByteBufferImpls are not easily
accessible - you would need some introspection hackery to get hold of
that cleaner() and that would of course only work on Oracle/OpenJDK.
as fc.map() still does the same thing.

Close your eyes -  GPL3!
https://github.com/stain/jdk8u/blob/master/src/share/classes/java/nio/Dire
ct-X-Buffer.java.template#L72
http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8-b
132/java/nio/DirectByteBuffer.java/#72


I tried using the FileChannels from JDK7 NIO2 (e.g.
FileChannel.open(Path)) instead of through RandomAccessFile - but it
did not make any difference


Perhaps System.gc() is not worth it in general (* on Windows) when
closing a dataset - I tried to modify the ChannelManager to always do
this on release, it meant each test in jena-jdbc-tdb took 1.5s instead
of 0.2s, but it did allow me to delete the used folders from target/
while the JVM/test was running.

For the tests we could do something like for every 10 tests do
System.gc() and wipe the old data.

Perhaps Fuseki 2 could do System.gc() on [Remove]  SystemTDB.isWindows.



On 10 March 2015 at 10:00, ASF GitHub Bot (JIRA) j...@apache.org wrote:

 [
https://issues.apache.org/jira/browse/JENA-897?page=com.atlassian.jira.pl
ugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14354617#com
ment-14354617 ]

 ASF GitHub Bot commented on JENA-897:
 -

 Github user asfgit closed the pull request at:

 https://github.com/apache/jena/pull/41


 jena-jdbc-tdb tests use %TEMP% instead of target/
 -

 Key: JENA-897
 URL: https://issues.apache.org/jira/browse/JENA-897
 Project: Apache Jena
  Issue Type: Bug
  Components: JDBC
Affects Versions: Jena 2.12.1, Jena 2.13.0
 Environment: Windowx 8.0 x64, C: with 34 GB free
Reporter: Stian Soiland-Reyes
Priority: Critical
 Fix For: Jena 2.13.1


 .. and thus mvn clean install on Windows will easily consume 37 GB on
C: and run out of disk space - even if Jena is built on a larger
partition.



 --
 This message was sent by Atlassian JIRA
 (v6.3.4#6332)



--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718







-- 
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/-0001-9842-9718

Re: [VOTE] Replace projects.apache.org with projects-new.apache.org

[Stian Soiland-Reyes]

+1 - looks great!


..Apologies if this was explained before I joined this list - How does
this work for podlings? For the old site I was able to make a DOAP
file, but on the Apache Taverna entry on projects-new I am unable to
edit it as I am not in the Incubator PMC.

Can we still maintain the old doap file? Those instructions are on
http://projects.apache.org/doap.html and perhaps would need to be
moved over in some form.


On 6 March 2015 at 16:57, Daniel Gruno humbed...@apache.org wrote:
 +1 but clearly biased ;-)


 On 2015-03-06 17:54, Ross Gardler (MS OPEN TECH) wrote:

 +1

 Microsoft Open Technologies, Inc.
 A subsidiary of Microsoft Corporation

 -Original Message-
 From: Rich Bowen [mailto:rbo...@redhat.com]
 Sent: Friday, March 6, 2015 8:53 AM
 To: dev
 Subject: [VOTE] Replace projects.apache.org with projects-new.apache.org

 I'd like for us to go ahead and replace projects.apache.org with
 projects-new.apache.org. It now has all the functionality that projects.a.o
 has, and much more, and there's no reason to have two sites up. If you
 object to moving forward with this, please say so.

 [ ] +1, do it
 [ ] +0, whatevs
 [ ] -1, No (and say why, so we can address the problem)

 --Rich

 --
 Rich Bowen - rbo...@redhat.com
 OpenStack Community Liaison
 http://rdoproject.org/





-- 
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/-0001-9842-9718

Re: GitLab?

[Stian Soiland-Reyes]

 for Java



-- 
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/-0001-9842-9718

www.apache-extras.org wrong redirect (was: GPL Code in GitHub)

[Stian Soiland-Reyes]

That must be a configuration error for http://www.apache-extras.org/

http://apache-extras.org/ redirect correctly to
https://code.google.com/a/apache-extras.org/hosting/

I've raised it as https://issues.apache.org/jira/browse/INFRA-9229


On 4 March 2015 at 15:26, John D. Ament johndam...@apache.org wrote:
 I notice that apache-extras is now forwarding to Any23.  Is that on purpose?

 On Wed, Mar 4, 2015 at 10:15 AM Benson Margulies bimargul...@gmail.com
 wrote:

 An Apache project may not manage a codebase outside of Apache. Some people
 who happen to be members of an Apache community can maintain code outside
 of Apache, if they are very clear in distinguishing; it must not be a
 product of the project. See 'Apache Extras'.

 On Wed, Mar 4, 2015 at 8:46 AM, Jean-Baptiste Onofré j...@nanthrax.net
 wrote:

  Hi Julian,
 
  the code is not included in the project (just a reference) ?
 
  Regards
  JB
 
 
  On 03/04/2015 02:44 PM, Julian Tenney wrote:
 
  Question: I know I've seen this discussed here before, and in any case,
  you guys are the best source for an answer:
 
  Can we have GPL code in a repository as long as that is not distributed
  with the product in a 'official' release?
 
  Thanks a lot,
 
  Julian
 
 
 
 
  This message and any attachment are intended solely for the addressee
  and may contain confidential information. If you have received this
  message in error, please send it back to me, and immediately delete it.
 
  Please do not use, copy or disclose the information contained in this
  message or in any attachment.  Any views or opinions expressed by the
  author of this email do not necessarily reflect the views of the
  University of Nottingham.
 
  This message has been checked for viruses but the contents of an
  attachment may still contain software viruses which could damage your
  computer system, you are advised to perform your own checks. Email
  communications with the University of Nottingham may be monitored as
  permitted by UK legislation.
 
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 
 
  --
  Jean-Baptiste Onofré
  jbono...@apache.org
  http://blog.nanthrax.net
  Talend - http://www.talend.com
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 
 




-- 
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/-0001-9842-9718

Re: GitHub Pages

[Stian Soiland-Reyes]

I would love to see a GitLab trial at Apache infrastructure - I feel
uncomfortable at directing other developers to look at
http://git-wip-us.apache.org/ - the rendering of a repository does not
even tell you where to clone from!

GitLab Installation is fairly easy, there's also a GitLab docker image
that is pretty easy to test:

https://registry.hub.docker.com/u/genezys/gitlab/

On 5 March 2015 at 00:14, Niclas Hedhman nic...@hedhman.org wrote:
 On this note;  Git without Github is like sex without a partner, sufficient
 but not very satisfactory. Github option has been explored in the past, and
 due to various reasons, it was not possible to achieve.
 But, during my last 2-3 year absence, has the GitLab[1] option been
 discussed and/or tried? GitLab is open sourced, can run on our infra and
 has many of the essential features of Github.
 But perhaps people are satisfied enough with the Github mirroring that is
 already in place, but with GitLab in house, we could (in theory) add
 features around licensing (like ICLA style assurance, similar to Jira), and
 non-committers could(!) be allowed a direct route to the horse's mouth...

 Although the Enterprise system cost money, my guess is that GitLab would be
 happy to waive fees and give us access to EE.


 Just a thought.

 [1] https://about.gitlab.com/features/

 // Niclas



 On Thu, Mar 5, 2015 at 5:06 AM, Christopher ctubb...@apache.org wrote:

 All,

 Has any thought been put into leveraging GitHub pages for project
 documentation, static site hosting? A lot of www.apache.org is simple
 static content, as are project pages. Since a lot of projects are now using
 git, and we mirror projects in GitHub, perhaps we can help the individual
 projects maintain their site's static content by simply committing to a
 gh-pages branch for their project?

 Since it's just static content which is still hosted and controlled by ASF,
 but simply placed in a way that GitHub can render it from the mirrors, I
 don't think there's too many issues of concern, but wasn't sure if
 anybody's put any thought into it. I know it would certainly be easier for
 some projects than using the existing CMS system with SVN (especially those
 otherwise developing exclusively with Git).

 It might just work today, but I haven't tried it. I'd be willing to work
 with INFRA to help experiment with it, though (especially if we wanted to
 try out the CNAME feature).

 More info: https://pages.github.com/

 --
 Christopher L Tubbs II
 http://gravatar.com/ctubbsii




 --
 Niclas Hedhman, Software Developer
 http://www.qi4j.org - New Energy for Java



-- 
Stian Soiland-Reyes
Apache Taverna (incubating)
http://orcid.org/-0001-9842-9718