Re: [DISCUSS] China Contribution.

[Emmanuel Lécharny]

Le 13/11/16 à 22:57, Reynold Xin a écrit :
> "a better global way to A) communicate across a medium that everyone uses
> daily B) archive to search and come back to"
>
> How would we even validate or decide that? For discussions like this it is
> very easy to fall into confirmation bias.
>
> I use mailing lists all the time since it is the Apache Way, but I also
> admit there are potentially better ways for other projects. People that are
> used to mailing lists might think mailing lists are the best thing in the
> world, but the reality is that majority of the developers in this world,
> outside a few core open source projects, have never used mailing lists. 
Many projects never used unit tests, Version control system, Bug tracker
systems, etc...

That probably explain why many projects are plain failures too.

> If
> we talk to the QQ/Wechat/web-based-forum generation in China and force them
> to use mailing lists, they might comply because it is the Apache Way, but
> they will also develop the sentiment that the ASF refuses to change and
> adapt newer technologies.

Are you suggesting they should ignore the time zones ? Because, all in
all, it's all about TZ and asynchronous interactions.

Yes, sure, it's way more convenient to be able to have everyone on a
project being connected at the very same time and chatting live.

Start with a project gathering people from Australia, South Korea,
California, Florida, England, Turkey, France, Italy, Germany,
Switzerland, Slovakia, China, Netherland, Poland,  try to get all those
people collaborating... The Directory project tried to organized weekly
calls, we never were able to do it more than three weeks in a raw : some
had to wake up at 7am, others at midnight, whild some were having lunch.
Simply not flying.

And please, come on with english being a problem : it's way better than
having all of those different people speaking in their own language and
using google translate (just give it a try with Koran, turkish or
german. Good luck with that !!!).



>
> And to be honest, while I think mailing lists are great for simple voting
> and information dissemination, there are obvious downsides of mailing lists
> too. That's why a lot of projects also augment mailing lists via video
> discussions, google docs for commenting, wiki, etc.
At the end of the day, the only reliable source, that anyone can read
from almost everywhere on the planet, asynchronously, is and will always
be the mailing list.

OTOH, get me a pointer to video archives that I can search, get me
traces of 10 years old google docs visible by *everyone* even those who
haven't been invited to access them, get me 2010 IRC logs that I can
read in 2016...

>
> In reality, there are also legal reasons why we use mailing lists, and
> those are not as well known. We should document those and make them more
> visible too.

Please stop thinking that we have a legal reason for everything we are
doing. This is not a state, we don't have a Law for every single aspect
of what we do.

Time to read "the ASF WAY Book" ;-)

-- 
Emmanuel Lecharny

Symas.com
directory.apache.org


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

Re: [DISCUSS] China Contribution.

[Emmanuel Lécharny]

En pratique, la question de la langue à utiliser sur une liste de
diffusion est spécieuse. L'anglais est la Lingua Franca du 21ème siècle.


And if you haven't understood what I wrote in my native language, which
is understood by around 500 million people around the globe, I guess you
get my implicit point ;-)


More seriously, it's not about how good are developpers in english :
many of the Apache developpers are not english native speakers, and we
do many mistakes. That does not matter too much : nobody will blame
anyone for that. At some point, code is not in english, but in C, Java,
Scala, etc... If you work as an IT person, you already have to face
english in almost all the technical documents found on internet. Take
the RFCs for instance : have thay all been translated to chinese ?


But the most important thing : we are all about community. It's pretty
hard to build it if you split it in 2, or more, because there is a
language issue. It's going to be hard to communicate between a split
community, way harder than using a very basic english...



Le 11/11/16 à 07:45, Reynold Xin a écrit :
> Adding members@
>
> On Thu, Nov 10, 2016 at 10:40 PM, Reynold Xin  wrote:
>
>> To play devil's advocate: is it OK for Apache projects that consist
>> primarily of Chinese developers to communicate in Chinese? Or put it
>> differently -- is it a requirement that all communications must be in
>> English?
>>
>> I can see an inclusiveness argument for having to use English, as English
>> is one of the most common languages. However, many talented software
>> developers in China don't have the sufficient level of proficiency when it
>> comes to English, as the penetration rate of English in China is much lower
>> than other countries. It is as hard for Chinese speakers to learn English
>> as for English speakers to learn Chinese.
>>
>> One can certainly argue forcing everybody to use English will also exclude
>> those Chinese developers, and from the perspective of the number of native
>> speakers, Mandarin (a Chinese dialect) outnumbers English 3 to 1 according
>> to Wikipedia.
>>
>> Similar argument also applies to Japanese, and many other countries,
>> except the number of Chinese speakers is much larger.
>>
>>
>>
>>
>> On Thu, Nov 10, 2016 at 10:18 PM, Luke Han  wrote:
>>
>>> Hi Gunnar,
>>>
>>> I don't think your point is right, one community's problem (maybe not
>>> real,
>>> but just
>>> refer to what you mentioned) could NOT represent all contributions from
>>> China,
>>> or any other territories from all of the world.
>>>
>>> This will misleading people to ignore contributions from Chinese and LABEL
>>> for such
>>> contributors and committers..as your pattern, there are tons of "issue" to
>>> describe like
>>> Russian Contribution, German Contributions, Canada contribution or
>>> others...
>>> that's not right way.
>>>
>>> Yes, Chinese people are not native English speakers, but they are
>>> contributing to
>>> most of the ASF projects and others foundation projects very much,
>>> involved
>>> in many
>>> discussion, development, decision and others deeply.
>>>
>>> Let's try to talk with some data, here's summary about last 31 days
>>> mailing
>>> list activity from lists.apache.org [1]:
>>>
>>> Project |  Emails|   Topics|   Participants
>>> HBase |   610  |406  |   100
>>> Spark   |   412  |88   |   124
>>> Kylin |   294  |144  |   61
>>> CarbonData |   852  |250  |   116
>>> HAWQ  |   284  |109  |   57
>>> Trafodion  |   87   |20   |   25
>>>
>>> There are many Chinese people are participating in these projects, you
>>> could check
>>> each one and see how Chinese people are discussing within mailing list.
>>>
>>> It's really not easy for Chinese people, they have to find out a way to
>>> access
>>> gmail or others since there's GFW, they are not native English speakers,
>>> they have limited experiences for open source especially the Apache Way.
>>> But they are willing to contribute, willing to participate global
>>> community, and try
>>> their best to learn and follow The Apache Way. We should have the patience
>>> for
>>> those new comers.
>>>
>>> As one thing I'm doing now is try to let more people to know our journey,
>>> our experience
>>>  about how to follow the Apache Way, how we overcome such
>>> challenges...through
>>> conference, events, meetup, blog, book and so on...and also helping many
>>> potential projects
>>> who are interesting to join Apache family.
>>>
>>> I would like suggest to change this topic to something like "Help
>>> Trafodion
>>> community"
>>> which will help to focus on real issue and your concern (Does Trafodion
>>> PMC
>>> know
>>> this concern?)  I'm very happy to help...share with you many articles,
>>> session recordings and
>>> others about open source, even could try to do some face to face
>>> 

Re: [VOTE] Accept NetBeans into the Apache Incubator

[Emmanuel Lécharny]

An obvious
> [X +1 Accept NetBeans into the Apache Incubator 


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

Re: Radical proposal: no initial list of committers

[Emmanuel Lécharny]

Le 27/09/16 à 13:25, Greg Stein a écrit :
> The NetBeans proposal (among many others in the past) has demonstrated a
> significant "problem" with trying to establish an appropriate list of
> initial committers. There are many people that want to be on, for various
> reasons. Because they are committers, recent or historic. Or they want the
> "prestige" to be there. Some people believe they "deserve" to be on the
> list. etc etc
>
> Establishing the list is particularly difficult for large and old
> communities.
>
> But. What if we just said "no such list" ?
>
> This will shift the initial voting of committers upon the Champion/Mentors
> who will construct the entirety of the PPMC. But hey: aren't they supposed
> to be involved? Aren't they supposed to demonstrate how to earn merit, and
> the committership that results?
>
> This would also solve the problem of initial committers that have not
> established any merit whatsoever. We've had many situations where people
> simply add themselves to the list. Why? Cuz they chose to do so. It is sort
> of silently allowed for IPMC members to add themselves. "I wanna join!"
> BAM. It happens.
>
> So yeah. Radical thought: NO initial list. The PPMC is just the Champion +
> Mentors. They will build the committers and PPMC according to merit. (note:
> this could be *very* fast for a particular few highly-engaged with bringing
> the project to the ASF)
>
> ???
>
> Cheers,
> -g
>
Well, that's tempting...


OTOH there is no problem with having an initial list, even with people
who want to see their name on the web site for teh sake of their own ego
: it's easy to demote committer in the long run (moving them to an
emeritus status).


We have so many dormant committers in so many projects anyway !


My take is the initial list is just a curtesy made to the involved
people, and a few more. Nothing less, nothing more. The PPMC list, OTOH,
is critical.


My 2 cts.


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

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Emmanuel Lécharny]

Le 26/09/16 à 22:49, Geertjan Wielenga a écrit :
> Thankl of the below has been done.
>
> Some more are being added. However at this point the more we add the more
> insulting to those we omit. We've done our best. The list is strong. None
> will commit nothing, all have a history of years being active in one way or
> another in the NetBeans community.

And that is just fine !


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

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Emmanuel Lécharny]

Le 26/09/16 à 07:32, Geertjan Wielenga a écrit :
> On Mon, Sep 26, 2016 at 6:52 AM, Alex Harui wrote:
>
>
>> But if you are thinking 100 people, I'd try to get it down to 40-ish.
>
> Seems like a very random number. In the case of NetBeans, that would mean
> we'd have few others on the list than those from Oracle, which is not what
> we want -- instead, we want to reflect the various communities (Oracle,
> NetBeans Platform companies, NetBeans plugin developers, NetBeans Dream
> Team members, etc) in our list and yes that's going to result in a number
> larger than 40.

The number doesn't matter.

Just ask the existing committers if they want to keep going under an
Apache flag. Some will say yes, add them to the list. Some will say no,
don't put them on the list. Some will simply not reply, ask tehm once
more just in case they forgot to answer (vacations, etc), and act
accordingly to their answer - or non answer . At the end of the day, you
have your list.


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

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Emmanuel Lécharny]

Le 25/09/16 à 05:22, Geertjan Wielenga a écrit :
> It really is impossible for us to follow all the (in many cases
> contradictory) advice we have been given re the initial contributors list.

And this is the reason you have mentors and a champion. Follow their
advices, you'll be fine (because if someone say that mentors are wrong,
and if mentors are wrong, then mentors will correct their message to you).


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

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Emmanuel Lécharny]

Le 24/09/16 à 01:25, Roman Shaposhnik a écrit :
> On Thu, Sep 22, 2016 at 1:48 AM, Bertrand Delacretaz
>  wrote:
>> Hi Wade,
>>
>> On Wed, Sep 21, 2016 at 11:38 PM, Wade Chandler
>>  wrote:
>>> ..I can say as a long time contributor who is not on the initial list, I
>>> understand, think it is fine, and agree that being added once we get into
>>> the actual incubation phase makes sense...
>> Thanks!
>>
>> As someone who has mentored several projects here in the last ten
>> years or so I think although people sometimes see a lot of value in
>> being on the initial committers list they should not, IMO.
>>
>> What very often happens during incubation is some people who were on
>> this list almost never contribute to the project, and other expected
>> or unexpected people show up, do great things and get elected as a
>> result.
>>
>> Also, as mentor I will recommend reviewing the list of committers and
>> PMC members shortly before graduation, to give the opportunity to
>> people who didn't actually become active to gracefully retire - if the
>> project governance works it's easy to come back later by becoming
>> active, and the project benefits from having a roster that reflects
>> the reality of active contributors.
>>
>> So in summary people shouldn't put too much value on the initial list
>> of committers, it's just that - an initial list, a kind of draft that
>> will evolve during incubation, and probably evolve a lot for a large
>> project such as NetBeans.
> Well, but they do. In fact, when I was a VP of Incubator a few years
> ago I had to deal with a formal escalation brought to the ASF level
> by somebody who felt unduly left out of that initial list of committers.

Shit happens. But because it happens does not mean we should appy very
bureaucratic rules for all the other projects.

It's enough to *warn* the new podling that they have to be careful. Up
to them to decide which level of check they want to apply.

> If the code one wrote is going into ASF -- and especially if it is a
> non-trivial amount of code, one can certainly expect some considerations.
>
> This is the same principle as ASF postulates when we say that we
> don't fork the communities. We truly don't. That's why for a project
> as large as NetBeans I think it is important for us to inquire what
> kind of due diligence was done to get the list of initial committers
> just right. Otherwise it is going to be OpenOffice vs. LibreOffice
> type of situation all over again (not that commiters was the key
> issue there -- but you catch my drift).
>
>>> ...I am able to contribute as much as I can at this stage anyways...
>> Indeed, and that stays true once incubation starts. Even though an
>> Apache PMC ultimately makes all the project decisions, they are
>> expected to listen to their community. The "community" section at
>> https://community.apache.org/apache-way/apache-project-maturity-model.html
>> expresses that.
> Right. And all I want to get out folks on this thread at this point is two
> things:
>  #1 admission that past contributions will be valued a LOT when it
>   comes to somebody requesting to be added as a committer to the
>   project during incubation
>
>  #2 a bit of explanation of what was the process to arrive at initial list of
>   committers
>
>>> ...getting into building a thorough list before hand will
>>> certainly take time away from higher priority items at this stage...
>> Yes, that's why the NetBeans mentors pushed to avoid adding people to
>> the list of initial committers before the incubation vote starts, as
>> for a popular project that's a lot of work with no real value as
>> mentioned above.
> I disagree. Like I said -- being a VP of incubator having to deal with
> that type of escalation was not a fun place to be in.

Yes, but again, just because it happened once is not a valid reason to
burry each project under tons of checks, rules and paperwork.


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

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Emmanuel Lécharny]

Le 24/09/16 à 15:18, Geertjan Wielenga a écrit :
> On Sat, Sep 24, 2016 at 2:32 PM, Shane Curcuru wrote:
>
>
>> Correct.  The whole point of Incubation at Apache is to show that the
>> community can learn to self-govern by following Apache processes - and a
>> key point of self-governance is responsibly adding new committers.
>>
>> In my experience, it's far better to just start incubation at this point
>> rather than worrying about getting the *initial* list perfect.
>
> The perspective on this point are clearly extremely divided when I read
> through this thread. 
Welcome to The ASF ;-)

> Some from Apache consider the initial committers list
> extremely important and that that list should be extremely complete. (And
> there's even a suggestion that people might fork NetBeans if they're not on
> the initial committers list which, to me, sounds really odd.) 

I would suggest you listen to mentors and your champion at this point ;-)

Regardless, here is what is important :

" There are no ASF wide rules on how to decide when to make someone a
committer, podlings need to agree an approach that works for them. Some
ASF projects have a high bar requiring significant contributions before
someone is considered, other projects grant it more freely to anyone who
shows interest in contributing. Some projects use formal [DISCUSS] and
[VOTE] threads on the private mailing list, others use a more lazy
consensus approach.'

(http://incubator.apache.org/guides/ppmc.html, adding new committers).

I suggest you read this page.

> Others
> consider the initial committers list to be an indicator of the diversity of
> the individual contributors who will be involved in the project -- and
> that's the approach we've been following so far since the mentors for
> Apache NetBeans have told us that this is the approach to take.

And I do think this is the right approach. But sme may have a slightly
or totally different vision. We are diverse ;-)
>
> However, I will work more on the initial contributors list, regardless of
> the confusion about it. I do think it will be good to have (1) as complete
> a list as possible and (2) clear motivation about why people are on that
> list, i.e., what they have done to get on that list in the first place.

Truedat.

>
> My aim is, in order to bring this part of the discussion to an end, to take
> the strictest approach from all the different approaches apparent in this
> discussion and make the list as complete and comprehensive as possible and
> provide motivation for each person in the list. 
I really do think that providing motiviation for each of the comitter is
a bit over the top. The IPMC role is not to validate this list, it's
really to check that the project is moving forward in the right
direction. When Netbeans will be a TLP, the project's PMC will be
responsible for selecting whoever they want to become committer, nobody
else than the PMC will be selecting them. The PPMC being a PMC in the
making, it's responsible to vote in new committers - and make them added
by an IPMC member -. It's then up to the PPMC to define the rules they
want to befollowed.

In other words, do what you think is the best for the future TLP that
nebeans will become :-)


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

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Emmanuel Lécharny]

Le 23/09/16 à 15:30, Geertjan Wielenga a écrit :
> OK. Before the vote, will work on making the initial contributors list as
> complete as possible.
>
> What is the process for doing that? Do I simply make changes directly in
> the proposal? Do I make the changes public here before adding them to the
> proposal? Do I work directly with the mentors via e-mails to discuss and
> then after than make the changes?

IMHO, whatever works. The IPMC is not qualified to vote who shoud be a
committer, and who shouldn't. So if your initial list is not perfect,
well, not a big deal. You can fix it later on, voting in committers once
accepted in the incubator.

It's easy to vote in committers, so don't try to add everyone in the
initial list just because you want to cover all the angles. IMO, the
existing list should already be considered as good enough !

You should rather focus on who should be part of the PPMC, becuase it's
very likely to become the PMC once promoted. That's teh critical part !

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

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Emmanuel Lécharny]

Le 21/09/16 à 07:37, Geertjan Wielenga a écrit :
> On Wed, Sep 21, 2016 at 6:49 AM, Roman Shaposhnik wrote:
>
>> I've recently had an inquiry from a former Sun employee who
>> used to hack on NetBeans way back when: how was the list
>> of initial committers determined? Or more importantly, if he
>> wants to be added to that list up-front would that be OK?
>
> Very many more will be added once we enter incubation.
>
> I put the initial list of committers together. The initial list reflect an
> initial list of committers coming from Oracle [though several more will be
> added later] as well as an initial list of committers from companies
> committed to NetBeans primarily because their software, e.g., at Airbus and
> European Space Agency, depends on it.
>
> A growing list of developers have indicated they'd like to be added too.
> We'll start doing that as indicated in the propopsal -- as soon as the
> proposal has been voted on, accepted, and entered into incubation.

That's pretty much what is expected : this is one of the incubation exit
criterium anyway !


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

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Emmanuel Lécharny]

Le 19/09/16 à 20:50, cowwoc a écrit :
> Mark Struberg-2 wrote
>> Linux never was on hg, so the comparison doesn't fit.
>>
>> To be more clear: I'm not concerned that GIT cannot handle the NetBeans
>> repo size. 
> I actually concerned by this. A client I work for has a large Git repo. I
> doubt its size is anywhere close to the Linux repo, but its performance is
> abysmal. Navigating the git log or invoking "git checkout" takes minutes. It
> is almost completely unusable.
>
> I'm sure you've read this by now, but HG seems a better fit for these larger
> projects:
> https://www.reddit.com/r/programming/comments/1unehr/scaling_mercurial_at_facebook/
>
> All this to say: I would tread carefully. Out of curiosity, is there a
> reason that Apache projects can't use Mercurial?

Can we avoid hacking this discussion ? Create a new thread on a more
suited mailing list if you want to discuss the pros and cons of using
your favorite SCM.

Thanks !


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

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Emmanuel Lécharny]

Le 19/09/16 à 16:33, Mark Struberg a écrit :
> Linux never was on hg, so the comparison doesn't fit.
>
> To be more clear: I'm not concerned that GIT cannot handle the NetBeans repo 
> size. 
> But we cannot guarantee yet that the import from hg to GIT doesn't loose 
> important information or works at all.

Ok, makes sense then.

It could not harm anyway. It's just that I don't think it's really
critical at this point.

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

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Emmanuel Lécharny]

Le 19/09/16 à 13:10, Raphael Bircher a écrit :
> Hi Geertjan
>
> I'm registred at NetBeams now, to get a closer look at the project. I
> was a bit shocked about the similarities with the formar
> OpenOffice.org project. The structure of the Project, the workflow
> etc. are so close to the OpenOffice.org project, much closer as I
> expected. My biggest fear for the incubation is not the technical
> aspect. For infrastructure we will find solutions, and for many
> problems exist already blueprints from the OpenOffice Project. My
> biggest fear ist the community. As I saw on the NetBeans ML, the
> decision to join the ASF was made by Oracle. Well a load of the
> community members welcome this step, but there are also fears. This
> fears has to be addressed, this is very very important.
Can you list the feares you want to be addressed ?

>
> One Mail also complained about the Initial Committer list. Are all
> active committers who did commit in the last 6 month (or so) on the
> initial committer list. forgotten people can create bad blood and
> disappointment. The committers are the most value part of a project.
>
> This are at the moment my biggest concerns.

It's up to the current committers to ask to be included in this list.
This happens for every single project with more than a few committers
that is being incubating.

The rational being that committers who haven't been active for a certain
period of time are likely to be not anymore interested in the project.
That's fine, nobody should be included if they don't care anymore, but
we should include anyone who has participated in the past and want to be
part of the incubating project. It's realy a no brainer.

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

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Emmanuel Lécharny]

Le 19/09/16 à 15:16, Mark Struberg a écrit :
> To be honest: I was a bit worried when the github import blew up. That was 
> actually the main reason why I started a local import.
Beside playing with the import tools for your own interest, I seriously
doubt that importing the netbeans code base on our infrastructure could
be an issue. Linux which is very likely to be a way bigger code base is
already on git...


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

Resulr, was: [VOTE] OpenAZ retirement

[Emmanuel Lécharny]

Ok, I think it's time to close this vote. Wev' got 7 +1 for the retirement :

Bertrand,
Colm,
John,
Mark,
Roman,
Ted,
and me.

I'll move forward from this point.

Thanks !


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

[VOTE] OpenAZ retirement

[Emmanuel Lécharny]

Hi !


Despite an effort to reboot the project in april, we weren't successful
in keeping the existing committers active. At this point, a decision to
retire the podling was taken, and a vote was don eon the PPMC :
https://lists.apache.org/thread.html/e87c384315966c81c523fad94326d8c72e312b3025d2e7b86b50e377@%3Cdev.openaz.apache.org%3E


Per http://incubator.apache.org/guides/retirement.html, I'm starting a
vote on the incubator mailing list.


[ ] +1   : retire OpenAZ

[ ] +/-0 : No opinion

[ ] -1   : Don't retire OpenAZ.


Thanks !


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

Re: RTC vs CTR (was: Concerning Sentry...)

[Emmanuel Lécharny]

Le 18/11/15 17:54, Ross Gardler a écrit :
> Summarizing:
>
> In a healthy project I believe that the only significant things that change 
> between CTR and RTC are:
>
> 1) speed of commit (CTR is faster)
> 2) quality of master, not releases (RTC catches most issues before commit, 
> CTR shortly after commit)
>
> I agree with others, nothing in the Apache Way says RTC is bad. Personally I 
> believe CTR builds communities faster, but there are successful RTC projects. 
> What really matters is  managing the trade off above.
>
> Justification (mostly a repeat of what has been said already):
>
> I don't care what the website says. If I have a personal interest in a 
> project succeeding then I will do everything in my power to ensure it 
> succeeds. I assume the same is true for everyone else. This means that 
> "mandatory" reviews are not required because they just get done by the people 
> who care about project success.
>
> RTC does not guarantee reviews any more than CTR does, despite what a web 
> page says. It merely guarantees a way period in which someone will give a 
> patch a cursory glance. I'm not saying this is the normal RTC behavior, I'm 
> merely saying this is all that is guaranteed. Fortunately the process doesn't 
> change the way most people behave in a project, we can still trust them to do 
> their reviews.
>
> Furthermore, there seems to be an assumption that CTR means complex or 
> controversial code will be committed. In my experience this is not true. 
> People don't like to waste time writing code that may be rejected. What I see 
> is people discussing such changes, and providing psuedo code and then real 
> code for review before committing to master. It saves time to get early 
> review.

+1.

Thi is well summarized. We don't care what the project picks (CTR or
RTC), because at the end of the day, nobody can ensure the 'review' is
done. The only difference between teh two modes is that you expect the
+1 to be gathered before the commit in RTC, which is likely to be
bypassed at some poing by those who don't have time to review
thouroughly the commits.

And those who think that with RTC, it will never happen, then they
should be aware that it's already a battle to get PMC members to
actually *review* a release befoe casting a vote :/

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

Re: RTC vs CTR (was: Concerning Sentry...)

[Emmanuel Lécharny]

Le 18/11/15 11:31, Stephen Connolly a écrit :
> I believe the issue here is that with CTR it is very easy to miss the 72h
> lazy consensus voting (with an assumed +1 absence any votes cast) that most
> CTR projects operate under... and thus it can also be very easy to miss the
> fact that there are reviews going on (and I am being generous here, I
> suspect that a lot of CTR commits are only reviewed within the 72h by a
> blind man on a galloping horse)

I'm not sure why you are correlating commit reviews and a 72h vote...
They are two really different things.

>
> If the PMC is doing its duty, then when release time comes around, if they
> have not been tracking the commits, then they should not be providing a
> binding +1 for the release until they have reviewed the commit delta from
> the last release *at least from the point of view of ASL compliance*.
No. There is nothing that says such a thing. It would be very good if
every PMC member casting a vote were reviewing all the commits since the
last release, but this is unlikely to happen, and it's not even
required. And unless you point us to the so called ASL compliance, I
think this is your own interpretation of the PMC member that you are
pulling here.
>
> So if we look at a well established CTR project such as Maven, you do not
> see many comments on individual commits... from this you might be forgiven
> if you concluded that there is no review going on... and thus infer that
> CTR is really C. I cannot speak for the entire Maven PMC but I can assure
> you that I reviewed each and every commit in the delta between the 3.3.3
> release and the 3.3.9 release from both a technical perspective and the
> legal umbrella perspective (does that mean I spotted every bug, nope... no
> code review can catch every bug... and it took us 6 goes to get the release
> out... but there was review)
That's good for Maven. But that does not mean any other project should
do so.

Look, this is where we *trust* other committers - and this is the reason
we voted them in, btw - : they *know* they should not break the ASF
rules (IP, etc) plus they *know* they should not break the trust the
community has put in them.

In 10 years, I have very rarely seen such things happening - and most of
the time it was a mistake -. I saw someone pushing some revamped Sun
code (and signaled so to the project), vote -1 on one commit (not sure I
should be proud of that veto, btw) and asked for some better code to be
pushed a few times, but more as a discussion than as a formal request.
Otherwise, did I saw some commits that needed some fixe because they
were breaking the build ? You bet ! (and I plaid guilty as charged too).
Bottom line, trusting my co-workers was easy : they are all my pairs,
and I don't feel like I'm any superior in any way, so I was expecting
their code to be at least as good as mine. Who would I be if I was to
check their daily commits and not asking them to review mine otherwise ?

And the best of it : it simply works. With flying colors. We have a
bunch of tests that avoid many errors to be introduced into the code,
and we can release fast enough so that our users can actually be real
users, and provide us with feedbacks. There is nothing better than users
feedbacks : not only they see what's wrong in our products, but they
also use it ways we haven't thought about, discovering new problems we
totally missed. That's the key : release often means get quick feedbacks.

But there is more : asking people who are volunteers to review what
others are pushing would introduce a latency that would certainly kill
the project.

Now I can see how people being paid by a company might *want* such
reviews to be done (regardless of the mode, CTR or RTC), and I feel that
as a bias toward a control by a few companies, excluding de facto those
who don't have time to work on the project but what they squeeze out of
a day job, familly, and sleep... And I saw that frequently in *many*
projects ! Sounds like a hidden agenda, isn't it ?  That would may be
pushing the thing a bit too far, but I suspect that in some case, yes,
that was exactly that. This is *NOT* The Apache Way...



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

Re: RTC vs CTR (was: Concerning Sentry...)

[Emmanuel Lécharny]

Le 18/11/15 14:34, Stephen Connolly a écrit :
> On Wednesday 18 November 2015, Emmanuel Lécharny <elecha...@gmail.com>
> wrote:
>
>> Le 18/11/15 11:31, Stephen Connolly a écrit :
>>> I believe the issue here is that with CTR it is very easy to miss the 72h
>>> lazy consensus voting (with an assumed +1 absence any votes cast) that
>> most
>>> CTR projects operate under... and thus it can also be very easy to miss
>> the
>>> fact that there are reviews going on (and I am being generous here, I
>>> suspect that a lot of CTR commits are only reviewed within the 72h by a
>>> blind man on a galloping horse)
>> I'm not sure why you are correlating commit reviews and a 72h vote...
>> They are two really different things.
>
> When I last read up my understanding is that CTR operates as if there is a
> vote for each commit.

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

*Commit-Then-Review*<http://www.apache.org/foundation/glossary.html#CommitThenReview>
(Often abbreviated 'CTR' or 'C-T-R'.) A policy governing code
changes which permits developers to make changes at will, with the
possibility of being retroactively vetoed
<http://www.apache.org/foundation/glossary.html#Veto>. C-T-R is an
application of decision making through lazy consensus
<http://www.apache.org/foundation/glossary.html#LazyConsensus>. The
C-T-R model is useful in rapid-prototyping environments, but because
of the lack of mandatory review it may permit more bugs through in
daily practice than the R-T-C
<http://www.apache.org/foundation/glossary.html#ReviewThenCommit>
alternative.

The important piece here is '...the lack of mandatory review...'



>  It's a really lazy vote though as the vote passes if
> nobody comments on the commit after 72h... And personally I do not see much
> value in post-hoc votes... What are we going to do, rewrite history? But as
> I understand the "vote" is so that the code in source control can be
> covered by the legal umbrella despite it being outside of a formal source
> release.

AFAIU, it means it's very much a C[-T-R] and not a C-T-R...


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

Re: RTC vs CTR (was: Concerning Sentry...)

[Emmanuel Lécharny]

Le 18/11/15 08:12, Todd Lipcon a écrit :
> On Tue, Nov 17, 2015 at 10:48 PM, Emmanuel Lécharny <elecha...@gmail.com>
> wrote:
>>> Except that there seems to be great disagreement among the Members as to
>>> whether RTC is somehow anti-Apache-Way.
>>>
>>> If you want to try to create an ASF-wide resolution that RTC doesn't
>> follow
>>> the Apache Way, and get the board/membership to vote on it, go ahead, but
>>> it confuses podlings who are new to the ASF when people espouse personal
>>> opinions as if they are ASF rules.
>> That is not the point.
>>
>>
>> The question is not to decide if C-T-R is The Apache Way over R-T-C. The
>> question is wether a project entering incubation with a selected R-T-C
>> mode is likely to exit incubation for the simple reason it will be very
>> hard for this project to grow its community due to this choice. It's
>> like starting a 100m race with a 20kb backpack on your shoulder...
>>
> If you have any statistics that show this to be the case, I'd be very
> interested. RTC is the norm in basically every Apache project I've been a
> part of, many of which have thriving communities and are generally regarded
> as successful software projects.

I don't have stats. I don't know a lot of Apache Projects using R-T-C,
and the 5 incubating projects I have mentored haven't even mentionned
the matter at all : it was C-T-R from day zero for them.

I would be *very* surprised if more than a few Apache projects were to
use R-T-C mode...

And again, it's not really important here. The key is to know if you
want the project to be out of incubator quickly. From the community
building POV, I just think that using R-T-C will make the path way
longer... If you think it's not a problem, then fine.

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

Re: RTC vs CTR (was: Concerning Sentry...)

[Emmanuel Lécharny]

Le 18/11/15 03:06, Todd Lipcon a écrit :
> On Tue, Nov 17, 2015 at 5:57 PM, Konstantin Boudnik  wrote:
>
>> On the contrary... The business of the Incubator and IPMC is to help
>> podlings
>> and their communities to grok and follow the Apache Way. Trust is a
>> foundation
>> principal of a healthy community. Hence, this whole discussion has quite a
>> lot
>> of business in the incubator.
>>
> Except that there seems to be great disagreement among the Members as to
> whether RTC is somehow anti-Apache-Way.
>
> If you want to try to create an ASF-wide resolution that RTC doesn't follow
> the Apache Way, and get the board/membership to vote on it, go ahead, but
> it confuses podlings who are new to the ASF when people espouse personal
> opinions as if they are ASF rules.

That is not the point.


The question is not to decide if C-T-R is The Apache Way over R-T-C. The
question is wether a project entering incubation with a selected R-T-C
mode is likely to exit incubation for the simple reason it will be very
hard for this project to grow its community due to this choice. It's
like starting a 100m race with a 20kb backpack on your shoulder...



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

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Emmanuel Lécharny]

Le 05/11/15 13:48, Joe Brockmeier a écrit :
> On 11/05/2015 03:13 AM, Martijn Dashorst wrote:
>>> PMC membership has nothing to do with technical mastery of the codebase,
>>> which is why I cringe every time I see people talking about what "the bar"
>>> should be. It's about trust.  If you trust someone to work the gears on a 
>>> release,
>>> that has  considerable impact on the well-being of a project, and personally
>>> meets my definition of "belongs on the PMC".
>> We have a new PMC member who hasn't done much (if any) work on the actual
>> code base of Wicket, but runs an awesome twitter account [1] posting
>> new projects
>> and applications using our framework, posting job listings etc. We wanted 
>> him to
>> continue to do so and acknowledged that he found sites and jobs we were not
>> doing, so it was only logical to ask him to become a PMC member and our true
>> social manager!
>>
>> We *trust* him to do good with the twitter account and wanted to give him the
>> official seal of trust by inviting him to the PMC. If and when he finds time 
>> to
>> contribute in other ways, we will be welcoming.
> You have no idea how glad I am to hear that this sort of thing is
> happening. Having a deep technical understanding of the code base should
> *not* be a blocker for people to be recognized for their contributions
> to projects. 
It never was. On Directory or MINA, we voted in people who focused on
documentation or other non-coding things. Three of them have been added
to the PMC. Use your jugement, you will quickly see when someone is
beneficial to your community !


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

Re: [VOTE] Graduate Groovy from the Incubator

[Emmanuel Lécharny]

Le 01/11/15 20:30, Rich Bowen a écrit :
> On Oct 28, 2015 4:26 PM, "Konstantin Boudnik" <c...@apache.org> wrote:
>> Following discussions [1] about its current status, the Groovy community
>> has voted [2] to graduate from the Incubator. The vote passed [3] with 12
> +1s
>> total, 5 are binding:
>>
>> Guillaume Laforge
>> Cédric Champeau
>> Paul King
>> Jochen Theodorou
>> Pascal Schumacher
>> Emmanuel Lécharny (binding)
>> Bertrand Delacretaz (binding)
>> Andrew Bayer (binding)
>> Jim Jagielski (binding)
>> Konstantin Boudnik (binding)
>> Russel Winder
>> Guillaume Alleon
>>
>> The Groovy community has:
>> * completed all required paperwork:
>> https://incubator.apache.org/projects/groovy.html
>> * completed multiple releases (2.4.4, 2.4.5, 2.4.6 is in the works)
>> * completed the name check procedure:
>> https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-88
>> * addressed 50+ JIRAs:
>> http://is.gd/1tACON
>> * voted in multiple new committers/PPMC members
>>
>> Therefore, I'm calling a VOTE to graduate Groovy with the following Board
>> resolution. The VOTE will run for at least 72 hours, ending
>> Saturday, October 31st 8 PM PST.
> I recognize that I have missed the vote and thus my response is moot. I
> have been traveling, but i don't expect preferential treatment.
>
> However, as useful as these other measures are, as a member, and as a
> director who will need to vote on this resolution, I'd like to know if you,
> as a mentor, feel that this project had attainded maturity as described in
> the maturity metric document, and will operate according to the Apache way?
Yes, and Bertrand has conducted the check we now run on poddling we
think are ready to become TLP.

As a mentor who have followed a few podlings in the past, I must say
that Groovy was one of the easiest ! OTOH, the project was already
mature before being accepted in incubator. Keep in mind that this move
was dictated by the decision from Pivotal to stop paying the main
developpers, combined with the shutdown of the Codehaus hosting
facility. The Groovy fellows decided that The ASF was the best place to
host the project, and they did a long due diligence to check that the
ASF requirements were easy to follow for them. In many ways, it was all
about finding the right place for the project, and The ASF was a perfect
fit.

Every single requirements (IP clearance, voting releases, accepting new
committers, discussion on the ML, etc) where easily met, and the groovy
community was really open minded and ready for any required change in
their way of doing things. Mature ? You bet !

My 2cts



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

Re: [VOTE] Graduate Groovy from the Incubator

[Emmanuel Lécharny]

Le 29/10/15 02:43, Marvin Humphrey a écrit :
> On Wed, Oct 28, 2015 at 4:13 PM, Emmanuel Lécharny <elecha...@gmail.com> 
> wrote:
>
>>>> The incubation checklist looks good.  The language of the graduation
>>>> resolution looks good, but one thing:
>>>>
>>>> Cédric Champeau <cedric.champ...@gmail.com>
>>>> Paul King <pa...@asert.com.au>
>>>> Guillaume Laforge <glafo...@gmail.com>
>>>> Pascal Schumacher <pascalschumac...@gmx.net>
>>>> Jochen Theodorou <blackd...@gmx.org>
>>>> Andrew Bayer <andrew.ba...@gmail.com>
>>>> Konstantin Boudnik <c...@apache.org>
>>> If past resolutions are guide, those should all be Apache email addresses.
>> Should, not must, AFAIK
> I wrote to board@apache and got some clarification: there's an "informal
> policy" or "at least a strong convention" to use only apache.org email
> addresses, and they would like the Groovy resolution to be updated to use
> them.
>
> The primary reason is that the apache.org email addresses definitively
> identify a given contributor.  (The Board also uses tooling to look up the
> extracted id in LDAP and double-check spelling of names, see how many ASF
> Members are on the proposed PMC, etc.)
>
> So using apache.org addresses is technically a "should" in that this glitch
> doesn't derail the vote and that a flawed resolution could have been sent to
> Board and it would get likely bounced back, then fixed.  But given that a
> flawed resolution needlessly caused a month's delay in establishing a TLP last
> month, I think we ought to up our game and work harder to get these
> resolutions right.

Agreed. Anyway, you *must* use your apache address for many services on
The ASF, so better use it roght away.

>
> Here's an updated list:
>
> Cédric Champeau <cchamp...@apache.org>
> Paul King <pa...@apache.org>
> Guillaume Laforge <glafo...@apache.org>
> Pascal Schumacher <pascalschumac...@apache.org>
> Jochen Theodorou <blackd...@apache.org>
> Andrew Bayer <aba...@apache.org>
> Konstantin Boudnik <c...@apache.org>
>
> Marvin Humphrey

Thanks Marvin !
>
> -
> 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] Graduate Groovy from the Incubator

[Emmanuel Lécharny]

[X] +1 Graduate Apache Groovy from the Incubator.

Obviously !



Le 28/10/15 22:14, Marvin Humphrey a écrit :
>>
>> I lurked on the Groovy dev list for a while and they did great.  The
>> community handled some pretty challenging licensing stuff well (stars
>> to Paul King for doing some heavy lifting).
>>
>> The incubation checklist looks good.  The language of the graduation
>> resolution looks good, but one thing:
>>
>> Cédric Champeau 
>> Paul King 
>> Guillaume Laforge 
>> Pascal Schumacher 
>> Jochen Theodorou 
>> Andrew Bayer 
>> Konstantin Boudnik 
> If past resolutions are guide, those should all be Apache email addresses.

Should, not must, AFAIK


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

Re: [graduation] Maturity model-based assessment of Groovy for its graduation

[Emmanuel Lécharny]

Le 18/10/15 10:48, Martijn Dashorst a écrit :
> -1 on requiring all projects to do this exercise. It is not policy,
> and frankly as a volunteer organization we can let the communities
> themselves determine whether this is something they want to spend
> their time on.

Well, I unerstand your concerns, but it seems odd that we engage podling
to go through such a process that we haven't asked the TLP to do in the
past, and not check that the TLPs at large are compliant with such a
check list.
>
> I thought we were a community for/over code, not a bureaucracy for/over code.

As a community focused foundation, I'd rather see such an exercise as a
reinsurance for the larger community that are our users that we do
fulfill The ASF expectations in various areas. Calling that bureaucratcy
is a bit like saying the checklist every pilot is doing before take off
a spurious and annoying task...
>
> If/when a community finds itself in a hard spot, perhaps *then* it is
> valuable to assess the maturity model, to see how/what can be improved
> upon. But requiring this of all projects? With a deadline too?

Would'nt it be too late ? Wouldn't it be a better idea to check
peridodically that no hard spot is appearing ? Fixing a community is way
more difficult than anticipating potential pitfalls that can derail the
process later on...

But that might just be me...


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

Re: [graduation] Maturity model-based assessment of Groovy for its graduation

[Emmanuel Lécharny]

Le 15/10/15 11:46, Bertrand Delacretaz a écrit :
> Hi Incubator PMC,
>
> FYI I have started an experiment at
> https://github.com/apache/incubator-groovy/blob/master/MATURITY.adoc ,
> using our maturity model to evaluate Groovy before its mentors suggest
> its graduation (which should happen very soon).
>
> So far this has helped uncover a few issues that we (at least I)
> hadn't noticed otherwise. Nothing major, but interesting, and I think
> it can be useful for the IPMC and Board once they have to decide to
> graduate the podling.

That's an interesting exercise !

Having read the document Betrand has completed for Groovy, I do think
that an audit of all the existing TLP should be done in the next month
to check if all the iterms are correctly fullfiled. I suspect we would
be surprised...


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

Re: [graduation] Maturity model-based assessment of Groovy for its graduation

[Emmanuel Lécharny]

Le 15/10/15 13:49, Bertrand Delacretaz a écrit :
> On Thu, Oct 15, 2015 at 12:14 PM, Emmanuel Lécharny <elecha...@gmail.com> 
> wrote:
>> ...I do think
>> that an audit of all the existing TLP should be done in the next month
>> to check if all the iterms are correctly fullfiled
> That would be interesting but that's 167 TLPs if my memory is
> correct...that's a a lot of work for next month ;-)

I was not specifically thinking about such a short term target ;-) In my
mind, this is something that could take a full year...

And, no, that is not an incubator concern, I'm just bouncing the ball
one step farther...

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

Re: [graduation] Maturity model-based assessment of Groovy for its graduation

[Emmanuel Lécharny]

Le 15/10/15 16:28, Filip Hanik a écrit :
> On Thursday, October 15, 2015, Emmanuel Lécharny <elecha...@gmail.com>
> wrote:
>
>> Le 15/10/15 13:17, Rich Bowen a écrit :
>>> A huge +1, but I wonder about a few things. Who does the work?
>> I guess that each PMC should be responsible for this work, with a dead
>> line soft enough that it allows each check to be done with no stress,
>> and under the supervision of some members in charge of helping them.
>>
>>> Who
>>> evaluates the results?
>> Either the board, or a group gathered for that purpose.
>
> the board? doesn't that become a bottleneck.

Indeed. The board can delegate ;-)


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

Re: Mentor disengagement - a suggestion

[Emmanuel Lécharny]

Le 12/10/15 13:18, Rich Bowen a écrit :
> Fellow mentors,
>
> There was a conversation at ApacheCon about the Incubator. I'll leave
> it to the other participants to champion the particular parts that
> they are passionate about, but I was particularly concerned with
> mentor disengagement, and suggestions for improving it.
>
> A mentor's role is to help a project learn the ropes at the ASF, and
> that mentor might not necessarily be deeply versed in the particular
> technology that the podling works with. As such, it can frequently be
> the case that the mentor becomes disengaged from the daily
> conversation of the lists, and eventually with the entire process.
>
> As a means of refocusing the mentors' efforts, and keeping them
> engaged, I'd like to encourage each mentor (or group of mentors) to
> consider writing a running report (ie, evolving, updated every
> quarter) based on
> https://community.apache.org/apache-way/apache-project-maturity-model.html
> where they evaluate each point on the maturity model, as a path
> towards graduation. This gives a concrete target, and a lens through
> which to view the podling's progress towards that target.
>
> This could be kept in the incubator wiki, and linked from the official
> project report, or it could be maintained just for your own benefit. I
> think it would be particularly useful to attach to a graduation
> recommendation, as a sign that the recommendation is more than just
> checking the various boxes, but is a glowing endorsement of the
> project's readiness to be TLP.
>
> As a side-note, I'd also encourage mentors who are mentors in name
> only, and not reality, to consider cleaning up the paperwork by
> removing themselves from the roster. It doesn't look great when a
> podling can't get mentor signoff on their reports.
>
Sounds liek a good idea. I would also encourage mentors to actually add
a comment in each report they are signing.

Actually, when discussing a podling potential exit from incubation, a
[DISUSSION] thread is started on the podling mailing list, and the
mentors can express their opinion, which can be aggregated in a report
when the podling is proposed for exit, or on the opposite, when the
podling is seen as not ready, and send this report to the board (within
all the other podling reports).

Regarding inactive mentors, this is quite simple : we have a monthly
report that has to be signed off by mentors, if one mentor does not sign
it three time in a raw, shouldn't we consider that this mentor has
already stepped down ?

My 2cts...


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

Re: Require projects to have solid API docs

[Emmanuel Lécharny]

Le 11/10/15 17:59, Andrew Pennebaker a écrit :
> In the future, could Apache Incubator require projects to maintain better
> API documentation before graduation? In particular, Kafka has rather sparse
> documentation in v0.8. The Javadocs appear to be randomly hosted on this or
> that professor webpage, and no Kafka javadoc has documentation for
> *both* Consumers
> and Producers.

I'm ok with this proposal, when we have checked that every TLP has a
decent API documentation...

Good luck with that ;-)

/me guilty as charged...


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

Re: Evaluation the interest of EasyMock at Apache

[Emmanuel Lécharny]

Le 23/09/15 08:45, Bertrand Delacretaz a écrit :
> Hi,
>
> On Wed, Sep 23, 2015 at 1:18 AM, Henry Saputra  
> wrote:
>> ...you should not worry too much about having the project to be in
>> incubator forever...
> That's assuming the community grows.
>
> https://github.com/easymock/easymock/graphs/contributors shows a huge
> majority of commits by Henri with just a few "drive-by" contributions
> here and there.
>
> Turning that into a more diverse Apache-style community would be
> great, but for that you need people to show up and get involved. From
> this angle I think it makes absolute sense for Henri to gauge interest
> here first.

That is one big problem for established code bases that aren't moving
too much, but are heavily used by many, many developpers.

Not all the projects deserve to go through incubation, and not all the
projects (especially small ones) deserve to be TLP.

We had some discussion lately about moving such projects to a place at
The ASF where they could gather more then 1 or 2 PMC member to vote a
new release, but still be visible. Apache commons could be such a place,
but it's really a group of java libraries. We might need a new TLP for
tools, whatever the languages they are written in (Java, C, Python, etc).

But this might not be the best place to discuss that, maybe we can have
a get together meeting in Budapest

Anyway, +1 for accepting EasyMock at The ASF !


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

Re: Question related to IP Clearance and software grant

[Emmanuel Lécharny]

Le 01/09/15 18:15, Andrea Pescetti a écrit :
> jan i wrote:
>> Your concern is valid for all countries in EU. except if a country has a
>> exception. the default in the IT industry is that the employer
>> need to allow you to do similar work off hours ...
>> in any case copyright belong to the company.
>
> Wow, this is really interesting! I know this is not legal-discuss, but
> if you have any pointers I would really like to read them.
>
> I don't know of any similar regulations for Italy (I work for an
> Italian company), but this is due to pure ignorance. All my Apache
> work, and a significant part of the open-source work of my colleagues,
> is done outside working hours, so your note is very interesting for me.
>
> If you have any more information I'm looking forward to reading it.
> Otherwise, thanks a lot for an eye-opening remark because so far I had
> assumed that by default a contract would not interfere with off-hours
> activities. To be clear: my past and future contributions to Apache
> are not endangered in any way, but still I had never thought this
> could apply by default in the EU. And I'll get it checked in any case.
In France, this can be part of your contract when you are an employee.
Although it has some limitation, and for a benevolent participation,
like working on an Apache Project, during your own time, it seems that
you are safe (at least, it has been ruled by the court 10 years ago. My
information was a bit dated...). Now, what you woerk on during your own
hours should not harm your employer, of course !



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

Re: Question related to IP Clearance and software grant

[Emmanuel Lécharny]

Le 01/09/15 16:36, Bertrand Delacretaz a écrit :
> Hi,
>
> On Tue, Sep 1, 2015 at 4:16 PM, Emmanuel Lécharny <elecha...@gmail.com> wrote:
>> ...is a code donation require a software grant signed from the employer of
>> the people who wrote the code ? In other words, do we require that the
>> employer explicitely allow the employees to work on some code ?...
> My understanding is that whoever signs the grant must be authorized to
> donate the code, that's it.
>
> Depending on people's contracts it can be either themselves or their
> employer - we cannot judge that from our side.
>
> I don't think we ever require a cCLA, that's something that's only
> relevant between people and their employers.

To be clear, in France, when you are an employee, most of the time you
*have* to ask an explicit persmission from your employer to work on some
other project, even out of your working hours (for the simple reason
that if you work out of hours, then you might be totally worn out during
your day job, which would be detrimental to the employer). That may have
some legal implications : typically, the copyright might be claimed by
the employer, as if the code was written during day job, which then may
be a legal problem for The ASF and the users...

I'm not sure that is a problem for other countries (and FTR, my question
was bnot about french employees or a french company)

thougts ?

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

Question related to IP Clearance and software grant

[Emmanuel Lécharny]

Hi guys,

is a code donation require a software grant signed from the employer of
the people who wrote the code ? In other words, do we require that the
employer explicitely allow the employees to work on some code ?

M understanding is that it's required, and the employer must sign the
grant and a CCLA (or add the employee names to an existing CCLA,
extending it). Is that correct ?

What if the employees can't get such a document from their management ?

Thanks !


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

Re: Question related to IP Clearance and software grant

[Emmanuel Lécharny]

Le 01/09/15 16:55, Bertrand Delacretaz a écrit :
> Hi,
>
> On Tue, Sep 1, 2015 at 4:44 PM, Emmanuel Lécharny <elecha...@gmail.com> wrote:
>> ...typically, the copyright might be claimed by
>> the employer, as if the code was written during day job, which then may
>> be a legal problem for The ASF and the users...
> This becomes more a legal-discuss topic...however that's covered by
> our committers iCLA, section 4, "You represent that you are legally
> entitled to grant the above license. If your employer(s) has
> rights...".
>
> So if someone commits code without their employer's permission it's
> clearly their responsibility.
>
> The same applies to software grants IMO, on our side we accept them if
> we can reasonably assume that whoever signed them is authorized to do
> so, and if someone wasn't it's also clearly their responsibility.

Ok, many thanks for your input. I think it clarifies the situation.



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

Re: Question related to IP Clearance and software grant

[Emmanuel Lécharny]

Le 01/09/15 16:55, jan i a écrit :
> On 1 September 2015 at 16:44, Emmanuel Lécharny <elecha...@gmail.com> wrote:
>
>> Le 01/09/15 16:36, Bertrand Delacretaz a écrit :
>>> Hi,
>>>
>>> On Tue, Sep 1, 2015 at 4:16 PM, Emmanuel Lécharny <elecha...@gmail.com>
>> wrote:
>>>> ...is a code donation require a software grant signed from the employer
>> of
>>>> the people who wrote the code ? In other words, do we require that the
>>>> employer explicitely allow the employees to work on some code ?...
>>> My understanding is that whoever signs the grant must be authorized to
>>> donate the code, that's it.
>>>
>>> Depending on people's contracts it can be either themselves or their
>>> employer - we cannot judge that from our side.
>>>
>>> I don't think we ever require a cCLA, that's something that's only
>>> relevant between people and their employers.
>> To be clear, in France, when you are an employee, most of the time you
>> *have* to ask an explicit persmission from your employer to work on some
>> other project, even out of your working hours (for the simple reason
>> that if you work out of hours, then you might be totally worn out during
>> your day job, which would be detrimental to the employer). That may have
>> some legal implications : typically, the copyright might be claimed by
>> the employer, as if the code was written during day job, which then may
>> be a legal problem for The ASF and the users...
>>
>> I'm not sure that is a problem for other countries (and FTR, my question
>> was bnot about french employees or a french company)
>>
> Your concern is valid for all countries in EU. except if a country has a
> exception.
>
> the default in the IT industry is that the employer need to allow you to do
> similar work
> off hours, if not granted it is considered a contract breach and in any
> case copyright belong
> to the company.
>
> I had many problems with exact this part in my companies. We ended up by
> writing a generic
> disclaimer to all, that what they did off hours, belonged to them, but the
> company wanted to know
> about it.
>
> Be aware that in many places the binding is upto 6 month after a emloyer
> leaves the company.

Thanks for your input. I'll make it clear to the people who submitted
some code, in order for them to be aware of such legal problem.



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

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

[Emmanuel Lécharny]

Le 17/07/15 01:02, Justin Mclean a écrit :
 Hi,

 +1 ! And adding such a tool into rat or whatever would be extremely
 helpful, too...
 The “tools” I use generally make a bit of noise and require some 
 interpretation / filtering so I’m not sure they could be automated cleanly. 
 One thing rat might be able to do that I don’t think it currently does is 
 detect files containing more than one license header.

 Best advice I can give is follow this guide [1] and use it when reviewing 
 releases.

Thank Justin !


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

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

[Emmanuel Lécharny]

Le 17/07/15 09:21, Cédric Champeau a écrit :
 Lets be clear, what I was referring to is this: the identified LN issue
 is a non-code change that has no implication to the stability of your
 release whatsoever. Hence manually fixing it, re-spinning the RC and
 calling a shortened (12-24h) vote doesn't seem to present a problem
 First of all, the fact of rolling back a release already takes time.
 There's much more involved than a couple of artifacts uploaded on
 dist.apache.org. We are very picky at quality, and a release is issued
 from a CI server, which automates all tasks that are subject to human
 errors. It involves creating a release branch, tagging, uploading
 Maven artifacts to Artifactory, uploading the distribution to Bintray,
 synchronizing to Maven Central, etc... What we did for the new Apache
 release process is cut this into small steps that introduce potential
 human errors. And basically, we have staging areas for the
 source/distribution artifacts (what you vote on), and staging area for
 the complete set of artifacts (Groovy produces more than 270 jar
 artifacts). Rolling back, as I said, implies several steps, including
 closing those staging repos, removing the tags, branches, ... And due
 to some restrictions of the Apache infrastructure, we have a complex
 setup (we need to push the tags on personal branches from GitHub, then
 push them to Apache Git, as explained in our release document [1]).

 So, rolling back a release is not cheap. And then, you have to release
 again. And releasing, for the same reasons, is far from being cheap. I
 am the first one really annoyed by this as the release manager,
 because as I explained when joining Apache, I spent numerous hours
 polishing the Groovy release process, and releasing was a single click
 button. I could release 2 branches of Groovy in a couple of hours.
 *That* was cheap. For this release, it took me several hours and a lot
 of manual steps are involved. I know most of you are used to release
 from your own computers. That simplifies things a little, but that's
 not a guarantee of quality, in the sense that human errors are
 possible: you could release from a local source tree which is not
 exactly what the source reference is (so produce a correct source zip
 but that would differ from what the real source is), you could have
 dependencies in your local Maven repo which wouldn't be found
 otherwise (caching problem), you could build on a non-approved JDK
 (our CI builds do it from JDKs which were approved to be bug-free by
 the team, in particular with invokedynamic...), ... We don't want to
 do that.

 In addition, fixing this LN issue is not cheap either. First of all,
 we were not aware that the source and binary versions had to be
 different (and it seems that our mentors missed it for the first RC we
 tried). Second, we are still working on the issue, because we want to
 avoid being downvoted again, so it implies a lot of new sanity checks.
 Paul is doing that, but that's all on personal time of a distributed
 team, so no, we wouldn't have released in time. And there were already
 changes to the codebase after the rc was issued (development doesn't
 stop during voting), so either we would have to fork the RC branch,
 release from it and add new burden to our release process, or we would
 have to revote for everything including sources.

 Last but not least, I would also say that none of us was aware that a
 shortened vote period was possible. And since at Apache, everybody
 seem to have an opinion on everything, we would have taken the risk of
 being downvoted for not giving enough time to vote. That said, given
 that our vote on dev@ passed because we gave enough time to our
 voters. With 24h voting period we wwouldn't have had enough votes.
 Also, if we reissue a rc for the IPMC, I don't see why only the IPMC
 should vote. Otherwise it means that the artifacts that were voted on
 dev@ are different from those voted on general@. And that's a bad
 thing IMHO.

 To my mind, incubating is about learning how this works, and I think
 we're doing a reasonable job in that area. If you put the entry level
 too high, then you just discourage people to contribute.

ALl of this makes perfect sense to me.

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

I suggest we discuss this matter instead of arguing about why this
release was not perfect (we all agreed on that already) The critical
point is that it should not take hours to cut a release nor to rollback
it. That would be a constructive discussion.

I'd like to remember everyone that each project is quite able to define
the way they do things, as soon as they fits in the Apache process,
which is not that rigid. At this point, we may dedicate some time with
mentors, someone from infra and obviously the 

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

[Emmanuel Lécharny]

Le 17/07/15 09:28, Cédric Champeau a écrit :
 Thanks Justin. We had read that document, but even reading the binary
 section, it wasn't clear that source and binary LN had to be
 different. 

Guiding Principle :

The |LICENSE| and |NOTICE| files must *exactly* represent the contents
of the distribution they reside in.



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

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

[Emmanuel Lécharny]

Le 17/07/15 12:02, Jochen Theodorou a écrit :
 Am 17.07.2015 09:31, schrieb Emmanuel Lécharny:
 [...]
 Now, I'm a bit scared : why the hell can't we make it easier to cut a
 release at Apache for this project ? I mean, the infrastructure should
 not be a limitation here : we do have a CI, we most certainly can tune
 it to fit Groovy.

 that would not change anything. What makes things complicated is
 points of human interaction in the middle of the release process. That
 won't be different with a better tuned CI
I'm puzzled. Cédric said in a previous mail that before being an Apache
podling, releasing was just a matter of a couple of hours and very few
human interaction. What makes it so more complex in an Apache environement ?



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

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

Let me be clear : I'm cutting releases for years on Apache projects. The
process is quite simple :
- I use Maven *locally*. When the release is completed, I just have to
close the staging repository on Nexus, and push the packages on dist.
Nothing that can't be done automatically, except closing the repository
- last, not least, I stage the release on nexus.

Tell me what's different for Groovy, that requires much more manual
processing ?



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

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

[Emmanuel Lécharny]

Le 16/07/15 18:49, Roman Shaposhnik a écrit :
 On Thu, Jul 16, 2015 at 1:47 AM, Emmanuel Lécharny elecha...@gmail.com 
 wrote:
 Le 16/07/15 10:41, Justin Mclean a écrit :
 Hi,

 This vote passes with 4 binding +1 votes, no 0 notes, and 2 -1
 binding votes.
 If you read carefully I think you find there were 3 -1 votes on the binary 
 releases.
 True. I -1 the binary release. Interesting case : should we release if
 we have as many -1 than +1 ?
 Personally, I'm disappointed in the podling for not taking
 care of feedback that seems really easy to take care of.

I'm not.

They are dealing with a zero-day exploit, and it was clearly explained
on the private mailing list.

That some missing  and incorrect NL were detected after the release has
been cut is unfortunate (or fortunate, considering taht it has been
detected), but this is know known and will be addressed. IMO,
considering that a new release will occur soon, for which patches will
be applied to fix those incorrect NL is good enough to vote this release.

I seriously *wish* that all the other Apache projects are as respectful
to the requirements regarding NL, and I must say that, having been
through Seb scrutinity (thanks, Seb, btw), my own projects were not
perfect despite many releases that have been cut in the past.

I find it a but tough to say you are disapointed, because they *have*
considered the pros and cons of releasing now vs postponing to get the
NL fixed.


 I'll change my vote to -0 to avoid sucha  dead lock :-)

 I expect the groovy podling to cut a release asap that fixes the NL issues.
 That's my strong expectation as well. If we're doing this whole
 mentoring thing -- lets do it right.

I think they are doing it right, so far. My  remark was more for the
record than anything else.






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

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

[Emmanuel Lécharny]

Le 16/07/15 19:48, Daniel Gruno a écrit :
 Can someone show me where in the bylaws this dreaded and apparently
 mandatory 72+ hour window is?
 When last I looked, it was the preferred thing to do in most
 circumstances, it was not _MANDATED BY LAW_.

Nobody said that. However, I like it when a pdoling absorbed the
information that a vote must be hold for 72 h : that means they
understand how it works.

That being said, you are right : those 72 h can be bypassed when required.


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

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

[Emmanuel Lécharny]

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

 This vote passes with 4 binding +1 votes, no 0 notes, and 2 -1
 binding votes.
 If you read carefully I think you find there were 3 -1 votes on the binary 
 releases.

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

I'll change my vote to -0 to avoid sucha  dead lock :-)

I expect the groovy podling to cut a release asap that fixes the NL issues.


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

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

[Emmanuel Lécharny]

Le 16/07/15 20:43, Alex Harui a écrit :
 IMO, what would really help would be a step-by-step guide to examining a
 release for L  N issues.  Justin explained part of his technique in this
 thread already.  The person creating the release artifacts should have a
 decent chance at finding these issues before opening any vote thread.

+1 ! And adding such a tool into rat or whatever would be extremely
helpful, too...


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

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

[Emmanuel Lécharny]

Le 13/07/15 16:09, Cédric Champeau a écrit :
 2015-07-13 16:03 GMT+02:00 Emmanuel Lécharny elecha...@gmail.com:

 Le 13/07/15 13:48, Daniel Gruno a écrit :
 Where is this documentation? If it is stated anywhere that
 people.apache.org is an acceptable place for RCs, it is clearly wrong
 and needs fixing.
 It's not written, it's a common usage for almost all of the projects,
 AFAICT. It's good to know that it's not the right place for such packages.

 It *was* written a couple of hours ago:
 Projects typically use http://people.apache.org/~${RM}/** or the newer /dev
 tree of the dist repository https://dist.apache.org/repos/dist/dev or the
 staging features of repository.apache.org to host release candidates posted
 for developer testing/voting (prior to being, potentially, formally blessed
 as a GA release).

 Now this has just been changed :)

Jurst FTR, dist.a.o exists for 3 years now (AFAIR) and for those of us
who cut releases for a decade (I can't believe I have spent 10 years on
an apache project...), people.a.o was the place to store such packages.
At this point, I think there were some missing communication (which
could be both side : either the message was not transmitted, or not read ;-)

I strongly suggest that every PMC should be reminded !

Thanks Daniel.


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

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

[Emmanuel Lécharny]

Le 13/07/15 13:48, Daniel Gruno a écrit :
 Where is this documentation? If it is stated anywhere that
 people.apache.org is an acceptable place for RCs, it is clearly wrong
 and needs fixing.

It's not written, it's a common usage for almost all of the projects,
AFAICT. It's good to know that it's not the right place for such packages.

What's the alternative ?


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

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

[Emmanuel Lécharny]

Hi,

my +1 (Binding), for the source package.

Addressing Justin's issues :

There *are* issues, but considering the security issue fixed in this
release, I'd rather have this version out.

- The build scripts are failing because there are Windows file (^M at
the end of ech line). Removing them let you build the project. This has
to be fixed, though.
- NOTICE : not critical, IMO, but need to be fixed.
- LICENSE : I can't find the normalize.css file. The MIT  BSD license
should be added into LICENSE. The not bundled licenses should be removed.

All in all, there are issues, that need to be addressed, and I expect
them to be fixed in the next release.

Regarding the binary package, it has to contain the NL files. I have
not checked it, because they are by-product, but that was a mistake
(obviously, people will use them instead of using the sources). I would
-1 the binary package as of today.

Thanks !

Le 13/07/15 14:12, Justin Mclean a écrit :
 Hi,

 -1 (binding) as LICENSE and NOTICE have issues, included files which have 
 Apache header when they are licensed under other terms, and binary connivence 
 files are missing required files (i.e. DISCLAIMER, LICENSE and NOTICE) Note 
 that the binary LICENSE and NOTICE file are very likely different to the the 
 source LICENSE and NOTICE files.

 For the source release I checked:
 - signatures ok but should be signed by apache.org address
 - hashes good
 - DISCLAIMER exists
 - LICENSE and NOTICE have issues (see below)
 - No unexpected binaries in source release
 - All source files have Apache header
 - Probably my setup/config but unable to compile from source and get this 
 error:

 FAILURE: Build failed with an exception.
 * Where:
 Script 
 '/Users/justinmclean/Downloads/ApacheGroovy/groovy-2.4.4/gradle/asciidoctor.gradle'
  line: 19
 * What went wrong:
 A problem occurred evaluating script.
 Could not create task of type 'AsciidoctorTask'.
  LICENSE and NOTICE issues:
 - NOTICE contains items that are not required (as they are not bundled) and 
 it’s not in usual format
 - LICENSE is missing:
   - MIT licensed asciidoctor.org see /src/spec/assets/css/style.css
   - MIT licensed normalize.css (in two places)
   - BSD licensed FileNameCompleter.groovy which also has an Apache header
 - LICENSE also contains several licenses/items that are not bundled and so 
 shouldn’t be included e.g. ANTLR 2, ASM 4, Hamcrest, JLine, JSR223, JUnit, 
 Multiverse 

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

 Other issues:
 - release candidate not in correct place
 - not signed by apache.org address
 - Short form of bundled licenses are preferred to long version
 - all zips unzip to same directory

 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

Re: [VOTE] Release Apache Groovy 2.4.4-incubating

[Emmanuel Lécharny]

Le 13/07/15 23:21, Justin Mclean a écrit :
 Hi,

 - LICENSE : I can't find the normalize.css file.
 See:
 ./subprojects/groovy-docgenerator/src/main/resources/org/codehaus/groovy/tools/stylesheet.css
 ./subprojects/groovy-groovydoc/src/main/resources/org/codehaus/groovy/tools/groovydoc/gstringTemplates/topLevel/stylesheet.css

 It contains this:
 normalize.css v2.1.0 | MIT License | git.io/normalize

Ah, thanks , I was looking for the file normalize.css...

What tool are you using to find the licenses that are not listed ?



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

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

[Emmanuel Lécharny]

Le 25/06/15 09:21, Jochen Theodorou a écrit :
 Am 24.06.2015 22:32, schrieb Emmanuel Lécharny:
 Le 24/06/15 22:28, David Nalley a écrit :
 [...]
 More generally to the underlying issue that prompted this discussion:
 With the concrete example of Geode's DockerHub presence, I don't think
 it's acceptable:
 https://registry.hub.docker.com/u/apachegeode/geode/

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

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

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

Good question ! My perception is that it is an ASF policy breach,
assuming the team providing such a package is a member of the Apache
community.

If it's not the case, then, there is no problem, or nothing we can do.

However, when you look at the link [1], the page says :  If you have
any problems with or questions about this image, please contact us using
d...@geode.incubator.org mailto:d...@geode.incubator.org or join our
HipChat http://s.apache.org/geodechat channel.. Although the mail is
wrong (it should be d...@geode.incubator.apache.org), the hipchat channel
link referes to http://s.apache.org/geodechat, clearly an Apache resource.


[1] https://registry.hub.docker.com/u/apachegeode/geode/



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

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

[Emmanuel Lécharny]

Le 24/06/15 22:28, David Nalley a écrit :
 On Wed, Jun 24, 2015 at 12:01 PM, Ross Gardler (MS OPEN TECH)
 ross.gard...@microsoft.com wrote:
 +1 (to this and Jochen's response)

 Roman was explicit in his question about clearly identifiable non-release 
 artifacts available to the general public. We can debate words on a page 
 forever, or we can work with the intent and get on with producing software.

 There is plenty of precedent here (including the oldest project in the 
 foundation).
 Link please? because I can't find it, and a couple of folks from the
 httpd PMC tell me this isn't the case.

 I don't think there's a problem with snapshots or nightly builds being
 available. I do think there is a problem with promoting nightly
 builds, or even promoting them from the website.
 I do think that the Release Policy is binding on projects, and more so
 on podlings that haven't kicked out a release yet.



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

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

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


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

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

[Emmanuel Lécharny]

Le 24/06/15 14:04, Marvin Humphrey a écrit :
 On Tue, Jun 23, 2015 at 3:20 PM, Ross Gardler (MS OPEN TECH)
 ross.gard...@microsoft.com wrote:
 There is nothing preventing clearly identifiable non-release artifacts
 available to the general public.
 The Releases Policy page forbids it explicitly:

 During the process of developing software and preparing a release, various
 packages are made available to the developer community for testing
 purposes. **Do not include any links on the project website that might
 encourage non-developers to download and use nightly builds, snapshots,
 release candidates, or any other similar package.** The only people who 
 are
 supposed to know about such packages are the people following the dev list
 (or searching its archives) and thus aware of the conditions placed on the
 package. If you find that the general public are downloading such test
 packages, then remove them.

 Under no circumstances are unapproved builds a substitute for releases. If
 this policy seems inconvenient, then release more often. Proper release
 management is a key aspect of Apache software development.

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

 Those conditions are are not limited to instability of the codebase, but also
 whether the artifacts meet Apache's licensing and legal requirements for
 releases.

IMO, 'public' here means : 'exposed on the project's web site'.

Whatever is built, and pushed on temporary spaces that are not
mentionned on the project's web site does not enter in this category.

The release policy does not state this is forbidden to produce those
non-release builds, nor to push it somewhere reachable to anyone, but
forbid advertizing about it (announce@a.o, or a news on the project's
web site).

What is important here is the spirit, not the letter : we want to be
sure that those who download those non-release packages *know* what they
are doing and what they are exposing themselves to.


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

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

[Emmanuel Lécharny]

Le 24/06/15 19:21, Marvin Humphrey a écrit :
 On Wed, Jun 24, 2015 at 9:01 AM, Ross Gardler (MS OPEN TECH)
 ross.gard...@microsoft.com wrote:

 We can debate words on a page forever, or we can work with the intent and
 get on with producing software.
 Amen.  So when's that Geode release coming?

Ask the Geode fellosws ;-)


 My summary of the intent: Don't advertise automated non-release artifacts
 in such a way that people may accidentally stumble across them and believe
 them to be production releases. That's it.
 Apache projects have to *release*.  Snapshots are not a substitute.
Are we discussing such a fact ? Not that I know.



 This goes double for any podling which has not yet demonstrated that its
 codebase is clean enough and its community mature enough to withstand the
 release process.

That is crystal clear. And this is part of the incubator exit criteria.


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

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

[Emmanuel Lécharny]

Le 24/06/15 09:19, Rob Vesse a écrit :
 Personally I think the policy should be clarified such that nightly
 builds MUST only live on ASF infrastructure 

Non sense. Nightly built can stay wherever is suitable. It's not The ASF
business anyway, The ASF does not endorse nighly build or non-release
packages.

 (whether that be the Nexus SNAPSHOTs repo, committer web space etc).
 As soon as you start putting them on external services like DockerHub
 then they are potentially widely visible to the general public.
Not a problem, as soon as you don't advertize them. People are grown up
adults that know what to do with such builds, would they found them
somwhere which is not advertized as an Apache official release.


 Going back to the example of libraries published as Maven artifacts
 for those projects already publishing SNAPSHOTs these only get
 published to the Apache Nexus server (repository.apache.org) and are
 not synced to Maven central.
So ? SNAPSHOTs are visible, anyone can download them, and they are not
endorsed by apache. They are just stored there because it's convenient,
not because it's official or whatever makes an ASF release.

Pushing your reasoning to its limit would force any Apache project to
push non-release packages to a protected area, for committers only. Not
even close to what's going to happen, any time soon, I hope.

 People who want to consume those artifacts have to explicitly
 configure their Maven setup to enable Apache SNAPSHOTs. For me this is
 a sufficient barrier to distinguish between developers and users.

Users download official releases from the Apache web site, and The ASF
is only responsible for what is inside those released packages. It's
enough to avoid pretending that a non-release package or a SNAPSHOT is
*not* a release to protect The ASF *and* its users, which is the only
important thing so far.

 FWIW if someone has made the effort to join the mailing list and
 report a bug which we then want to ask them to test a fix for then
 they are clearly in the developer category (or more accurately they
 are a contributor) and I would have no problem to pointing them to the
 nightly builds so they could do this. However putting stuff out there
 on an external hosting service that is widely accessible seems to go
 against the spirit (and likely the letter) of the policy Rob 

This is just against *your* perception of what is the spirit. Pushing
some SNAPSHOT or non-release package somwhere convenient for people to
check that it's correct is just part of the dev process, as far as we
don't claim it's a release and we don't push people to use it as
official releases. Adding another layer by asking those packages to be
pushed on a ASF infrastructure is just making things harder for the
developpers. We don't need that, The ASF does not require that.



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

Re: wiki access needed for openAz incubator

[Emmanuel Lécharny]

Le 07/04/15 17:14, DRAGOSH, PAMELA L (PAM) a écrit :
 Hi,

 I just created the user account DragoshPamela, I need to be able to update 
 the April 2015 wiki for the OpenAz podling.

 Thanks,

 Pam

Hi Pam,

if you can't update the wiki (you just have to log in the wiki with the
user you created), send me the text, I can update the wiki.

Thanks !

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

[Emmanuel Lécharny]

I think we are going a bit too far here.

Groovy has been under the AL 2.0 license since it moves from BSD (back
in 2003). AL 2.0 says :

 Subject to the terms and conditions of this License, each Contributor
hereby grants to You a perpetual, worldwide, non-exclusive, no-charge,
royalty-free, irrevocable copyright license to reproduce, prepare
Derivative Works of, publicly display, publicly perform, sublicense, and
distribute the Work and such Derivative Works in Source or Object form.

My understanding is that any groovy contributor, including the 5 initial
commiters, can grant the existing code base to The ASF, per the AL 2.0
license.

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

[Emmanuel Lécharny]

Le 26/03/15 14:43, Guillaume Laforge a écrit :
 So, in summary, can we all agree that I (Groovy projet lead /
 representative) can fill in the form, and say on behalf of the Groovy
 community, I grant the rights to the ASF?

Jim said Just do it !...

Let's discuss about the legal aspect there, but I'd like such a
discussion to be disconnected from the Groovy incubation.

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

[Emmanuel Lécharny]

Le 26/03/15 15:11, Upayavira a écrit :

 On Thu, Mar 26, 2015, at 01:31 PM, Emmanuel Lécharny wrote:
 I think we are going a bit too far here.

 Groovy has been under the AL 2.0 license since it moves from BSD (back
 in 2003). AL 2.0 says :

  Subject to the terms and conditions of this License, each Contributor
 hereby grants to You a perpetual, worldwide, non-exclusive, no-charge,
 royalty-free, irrevocable copyright license to reproduce, prepare
 Derivative Works of, publicly display, publicly perform, sublicense, and
 distribute the Work and such Derivative Works in Source or Object form.

 My understanding is that any groovy contributor, including the 5 initial
 commiters, can grant the existing code base to The ASF, per the AL 2.0
 license.
 My IANAL take:

 Almost, but not quite :-) No granting is required. The AL2.0 is a
 license that allows the ASF to do with it what it wants to do.

 Only the owner of the code can “grant” additional privileges. As we’ve
 noted, that’s an unclear thing. No-one has the right to speak on behalf
 of the many contributors to the original codebase without asking their
 permission first. Fortunately, we don’t need to do that :-) We can just
 import the code.

That's my understanding too. But a grant is required for incubation...


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

[Groovy] Next steps...

[Emmanuel Lécharny]

Hi guys,

ok, the vote result is out, groovy has been accepted. I suppose the next steps
are :
- vote the 5 proposed persons as committers, once they have submitted
their ICLA (it's already done for a few of them)
- create groovy ML (dev, commits, users, private, ...)
- create the git repo
- push the code base in the git repo
- create the JIRAs for the project
- migrate the existing JIRAs
- create tehe web site (or migrate the existing one)

I most certainly am missing some steps... Feel free to add items.

Another question : who is in charge of all those tasks ?

Thanks !


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

Re: [Groovy] Next steps...

[Emmanuel Lécharny]

Technically, I just added two moderators. We can add some more, I guess.

One more thing : in order to add initial committers, the pdofling must
be listed in https://id.apache.org/acreq/members/?. How do we add it ?


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

Re: [Groovy] Next steps...

[Emmanuel Lécharny]

Le 25/03/15 19:42, Jake Farrell a écrit :
 podlings do not appear in the acreq script until they have been added to
 podlings.xml, even if they file their ICLA with initial committer as part
 of groovy.

It has been added in podlings.xml.

I'm currently fighting to get the groovy page to appears in the
incubator web site, I'm not lucky atm...

I could use some help here.

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

Re: [Groovy] Next steps...

[Emmanuel Lécharny]

Le 25/03/15 20:00, Roman Shaposhnik a écrit :
 On Wed, Mar 25, 2015 at 9:24 AM, Bertrand Delacretaz
 bdelacre...@apache.org wrote:
 ...Another question : who is in charge of all those tasks ?..
 If you could create tickets like the
 https://issues.apache.org/jira/browse/INFRA-8968 example that would
 enable our infra team to get started.
 Great example. Do we have  the ubmrela JIRA for Groovy yet?

yes : https://issues.apache.org/jira/browse/INFRA-9338


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

Re: [Groovy] Next steps...

[Emmanuel Lécharny]

Le 26/03/15 01:01, Konstantin Boudnik a écrit :
 I have just helped bootstrapping two podlings in the last a couple of months,
 so I will add JIRAs to do the what needs to be done from the INFRA side of the
 things. 

Here is the Infra JIRA :
https://issues.apache.org/jira/browse/INFRA-9338

As you can see, there is just one sub-task for mailing list requests
(which has been done).

I have also asked for the creation of Guillaume Laforge and Cédric
Champeau ASF accounts.



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

Re: [Groovy] Next steps...

[Emmanuel Lécharny]

Le 25/03/15 22:23, Bertrand Delacretaz a écrit :
 On Wed, Mar 25, 2015 at 7:54 PM, Emmanuel Lécharny elecha...@gmail.com 
 wrote:
 ...I'm currently fighting to get the groovy page to appears in the
 incubator web site, I'm not lucky atm.
 I just published

 http://incubator.apache.org/projects/groovy.html

Thanks. I figured out what was the pb : I had a missing /td in the
groovy.xml file, so teh generation of the groovy.html file was impossible.

Seriously, a xml based site is, well, unmanageable. What if incubator
were to use the ASF CMS instead ? Ah, wait... (sarcasm included...)


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

Re: [RESULT] [VOTE] Accept Groovy into the Apache Incubator

[Emmanuel Lécharny]

Le 23/03/15 20:38, Guillaume Laforge a écrit :
 We're already worrying about it enough, don't frighten us ;-)))

Mentors, get the whip out, they are ready ;-)

Congrats guys, this is the very first step, not the most interesting one !



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

Re: [VOTE] Accept Groovy into the Apache Incubator

[Emmanuel Lécharny]

Le 19/03/15 07:55, Roman Shaposhnik a écrit :
 Following the discussion earlier in the thread:
http://s.apache.org/KWE

 I would like to call a VOTE for accepting Groovy
 as a new incubator project.

 The proposal is available at:
 https://wiki.apache.org/incubator/GroovyProposal
 and is also included at the bottom of this email.

 Vote is open until at least Saturday, 21st March 2015, 23:59:00 PST

Are we done ?

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

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

[Emmanuel Lécharny]

Le 22/03/15 11:04, Jochen Theodorou a écrit :
 Am 22.03.2015 00:09, schrieb Marvin Humphrey:
 [...]
 Because release candidate and RC are specialized terms with
 precise meaning at Apache and because we make a strong legal
 distinction between released and unreleased code, this is
 extremely confusing.  Having something named RC which is also an
 official Apache release is... gah, it makes my brain hurt.

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

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

It's unrelated. Release is a process, more specifically the result of a
process, RC is just a name. Unreleased code is just what is on the
repository, not yet packaged as a tar ball that has been voted and
endorsed as  a release by the project PMC.

 Normally a release candidate is code ready for release, that if
 nothing has been found, will result in a full blown release with
 unchanged code base. 
+1
 The terms alpha and beta don't catch that at all. 
+1
 They are for earlier versions. I did never hear of golden master
 candidate / GM candidate. 
Because there is nothing like a rule at The ASF that tells you you must
deliver golden master whatever.

The ASF is quite directive about what is a release, it's totally silent
on which name you should use for a release. You can even use a code
name, like Ubuntu does...

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

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

[Emmanuel Lécharny]

Le 22/03/15 00:09, Marvin Humphrey a écrit :
 On Sat, Mar 21, 2015 at 2:16 AM, Dmitriy Setrakyan
 dsetrak...@apache.org wrote:

 We wanted to have community to play with the RC3 release for a bit until we
 release the final 1.0 release in a week or two.
 Because release candidate and RC are specialized terms with
 precise meaning at Apache and because we make a strong legal
 distinction between released and unreleased code, this is
 extremely confusing.  Having something named RC which is also an
 official Apache release is... gah, it makes my brain hurt.

Marvin,

there is no such thing as a 'precise meaning' for any release at The
ASF. The project might decide to call it whatever they want (RC, GA,
Candidate, Milestone, or even Blueberry) if they want to.

This is totally unrelated to any legal aspect. Release is one thing, ie,
the very *process* of releasing some code, the name which is used to
expose the package being release is another thing.

It *might* be confusing though, I agree. What we currently do in many
project is to move along a thread of releases, like :

1.0-M1 - 1.0-M2 -... 1.0-Mx - 1.0-RC1 - 1.0-RC2 -... 1.0-RCy - 1.0

Mx are milestones
RCy are release candidate
1.0 is the stable version (often it's just RCy renamed)

I have also seen 1.0-GA in place of 1.0



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

That's up to the project to decide what they want to adopt. This is a
good suggestion, but not commonly adopted.

One more thing : your build tool is most of the time a driver when it
comes to pick a scheme. You often want to be sure that a given revision
is seen as following all the others. Typically, if you are going to work
in a OSGi environment, the naming scheme you use for release is
extremelly important.



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

Re: [VOTE] Accept Groovy into the Apache Incubator

[Emmanuel Lécharny]

[X] +1 accept Groovy in the Incubator

(Binding)

Emmanuel Lécharny


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

Vote ? was [DISCUSS] Groovy Incubation proposal

[Emmanuel Lécharny]

Hi guys,


we can discuss for 3 more months, but at some point, isn't it time to
start a vote ?

We already have demonstrated our ability to raises various points on
various subjects, time to demonstrate The ASF in action !


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

Re: [DISCUSS] Groovy Incubation proposal

[Emmanuel Lécharny]

Le 13/03/15 12:13, Jim Jagielski a écrit :
 community. Forgive me presuming to say this but this seems a
 contradiction with The Apache Way as written about. Also it is very
 CVCS/Subversion focussed.

 In a DVCS world, committers are just the gatekeepers of the central
 mainline, the judges/jury as to what meets the quality criteria. They
 are not the totality of the people who contribute, and they do not
 define the community.
 IMO, there is a mindset difference which is key, between the CVCS and
 DVCS world, and it all comes down to community over code.

Sorry, I don't think so :

If you can't push change in the git repo, you are just in one corner of
the internet, signaling the world you have modified something through a
PR, which might - or might not - be picked.

Those who pick those PRs and push them into the master are the
equivalent of The ASF committers.

I don't see how different is it from a CVCS world, where you checkout
trunk, change something, cut a diff and push it into a JIRA or whatever,
for the committers to process them...

Because, at the end of the day, when you clone a Git repo, this very
repo is stored and managed in a *central* place...


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

Re: [DISCUSS] Groovy Incubation proposal

[Emmanuel Lécharny]

Le 12/03/15 18:59, Marvin Humphrey a écrit :
 On Wed, Mar 11, 2015 at 11:58 AM, Roman Shaposhnik r...@apache.org wrote:

 It is my pleasure and privilege to open up the following
 proposal:
 https://wiki.apache.org/incubator/GroovyProposal
 I've read through the proposal (rev 17).  It looks good to me.

 FWIW I winced a bit on Apache Pig's behalf when I read that Groovy, if
 accepted by Incubator, will be a first major programming language developed
 under the umbrella of Apache Software Foundation.

I don't know about Pig, but Harmony was the first major programming
language developped under the umbrella of the ASF, AFAIK. Even if it was
shut down...

Just saying ;-)

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

Re: [DISCUSS] Groovy Incubation proposal

[Emmanuel Lécharny]

Le 11/03/15 21:20, Martijn Dashorst a écrit :
 Great initiative!

 Just one question: I don't see anything related to the groovy name and
 possible trademark in the proposal. Does Pivotal have any claims to
 the name groovy, and if so are those claims transferred to the ASF?

I think we have raised the issue during the preliminary discussions. I
don't think Pivotal has any rights on the Groovy name.

I'm afraid that Marvin Gaye might has some, though ;-)


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

Re: [VOTE] [PROPOSAL] Accept OpenAz (Access Control Tools) into the Apache Incubator

[Emmanuel Lécharny]

+1

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

Re: Need an additional Mentor for the OpenAz Project

[Emmanuel Lécharny]

Le 15/12/14 19:22, Hal Lockhart a écrit :
 The OpenAz Project currently has two mentors, but we need at least one more. 
 Is there anyone who would be willing to join us?

If we can be more than just 3 mentors, that would be extremelly cool !


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

[IP CLEARANCE] Apache Fortress, a a standards based and Open Source Identity Access Management Java SDK for LDAP v3 compliant systems

[Emmanuel Lécharny]

Please check this IP-Clearance form

http://incubator.staging.apache.org/ip-clearance/fortress.html

It is for a software grant for Apache Fortress from Joshua Tree Software.

Joshua Tree Software were the original sponsors of the Fortress project and
have donated the code to ASF.

Thanks,
Emmanuel Lécharny


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

Re: Finding a Champion

[Emmanuel Lécharny]

Le 3/20/14 6:42 PM, Hal Lockhart a écrit :
 Thanks to everyone for the encouraging comments. I will report back to OpenAz 
 and begin drafting a proposal.

 I suspect we will want Paul to act as our Champion, since WSO2 is already 
 active in the project. I think the group will be glad to have Emmanuel and 
 Colm help us as Mentors.
I'll be pleased to be a mentor, and having Paul as a Champion seems the
perfect fit !

Waiting for the proposal now :-)

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com 


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

Re: Finding a Champion

[Emmanuel Lécharny]

Le 3/18/14 7:47 PM, Rich Bowen a écrit :

 On 03/18/2014 02:40 PM, Hal Lockhart wrote:
 I am a newbie here. I am involved in an open source project called
 OpenAz. It is focus is to provide tools and components for developing
 authorization and access control systems. Our web page (and wiki) is
 here:

 http://www.openliberty.org/wiki/index.php/OpenAz_Main_Page

 We are using SourceForge for the code. We use the Apache license
 throughout. The project was started in 2009 and was very small
 initially. More recently we have been gaining more momentum and
 participants. We intend to propose to become an Incubator project.

 I have looked at the documents and lists and I believe I understand
 how to write the first draft of a Proposal. However, how does one go
 about recruiting a Champion. Does it make sense to draft a proposal
 and then try to attract a Champion to it or is there a better way to
 proceed?


 This email was a good start.

 Also, finding an existing Apache member who's either active in your
 community, or is a user of your stuff, would be a good thing to
 investigate. I see from your website that WSO2 is somehow involved.
 There's several ASF members there.

 Failing that, tell us why your project is awesome and why we'd want to
 be involved.

If you don't find a more suitable champion, I'd be please to offer my
support.

There is defintively a need for some XACML related project at the ASF.

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com 


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

Re: Change of Chair

[Emmanuel Lécharny]

Le 6/13/13 11:03 PM, Benson Margulies a écrit :
 Incubator community,

 I have tendered my resignation as VP, Incubator. The PMC has recommend
 Marvin Humphrey as my successor in a motion submitted to the
 Foundation board for consideration at the meeting next week.
We have had 3 very good chairman those last years (Noel, Jukka and you),
and I'm pretty sure the new chairman will be as good as they were !

Congrats to all of you, guys !


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com 


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

Re: [VOTE] Accept Apache Open Climate Workbench into the Incubator

[Emmanuel Lécharny]

, we will follow a similar approach by Mattmann in
 [[http://lucene.apache.org/nutch/|Apache Nutch]] and by Jukka Zitting lead
 this effort in Apache Tika. Mattmann is familiar with this process.

 == Required Resources ==
 Mailing lists

  * d...@climate.incubator.apache.org
  * comm...@climate.incubator.apache.org
  * priv...@climate.incubator.apache.org

 Subversion Directory

  * https://svn.apache.org/repos/asf/incubator/climate

 Issue Tracking

  * JIRA CLIMATE (CLIMATE)

 Other Resources

  * CLIMATE Wiki http://cwiki.apache.org/CLIMATE
  * Review Board instance - CLIMATE
  * Jenkins instance - CLIMATE

 == Initial Committers ==
 ||'''Name''' ||'''Email''' ||'''Affiliation''' ||'''CLA''' ||
 ||Chris A. Mattmann ||mattmann at apache dot org
 ||[[http://www.jpl.nasa.gov/|NASA Jet Propulsion Laboratory]] ||yes ||
 ||Cameron E. Goodale ||goodale at apache dot org
 ||[[http://www.jpl.nasa.gov/|NASA Jet Propulsion Laboratory]] ||yes ||
 ||Paul Ramirez ||pramirez at apache dog org
 ||[[http://www.jpl.nasa.gov/|NASA Jet Propulsion Laboratory]] ||yes ||
 ||Andrew F. Hart ||ahart at apache dot org
 ||[[http://www.jpl.nasa.gov/|NASA Jet Propulsion Laboratory]] ||yes ||
 ||Jinwon Kim||jkim at atmos dot ucla dot edu
 ||[[http://jifresse.ucla.edu|UCLA Joint Institute for Regional Earth
 System Science and Engineering]] || no||
 ||Duane Waliser||duane dot waliser at jpl dot nasa dot gov
 ||[[http://www.jpl.nasa.gov/|NASA Jet Propulsion Laboratory]] || no ||
 ||Huikyo Lee||Huikyo dot Lee at jpl dot nasa dot
 gov||[[http://www.jpl.nasa.gov/|NASA Jet Propulsion Laboratory]] || no ||
 ||Paul Loikith|| Paul dot C dot Loikith at jpl dot nasa dot gov
 ||[[http://www.jpl.nasa.gov/|NASA Jet Propulsion Laboratory]] || no ||
 ||Daniel J. Crichton||crichton at apache dot
 org||[[http://www.jpl.nasa.gov/|NASA Jet Propulsion Laboratory]] || yes ||
 ||Kim Whitehall||Kim dot D dot Whitehall at jpl dot nasa dot gov
 ||[[http://www.physics1.howard.edu/~pmisra/HUPAS/HUPAS/HUPAS%20Jenkins.html
 |Howard University]] || no ||
 ||Paul Zimdars||pzimdars at apache dot
 org||[[http://www.jpl.nasa.gov/|NASA Jet Propulsion Laboratory]] || yes ||
 ||Chris Jack||cjack at csag dot uct dot ac dot
 za||[[http://www.csag.uct.ac.za/|University of Cape Town]] || no ||
 ||Bruce Hewitson||hewitson at csag dot uct dot ac dot
 za||[[http://www.csag.uct.ac.za/|University of Cape Town]] || no ||
 ||Lluis Fita Borrell||l dot fitaborrell at unsw dot edu dot
 au||[[http://unsw.edu.au/|University of New South Wales]] || yes ||
 ||Jason Evans||jason dot evans at unsw dot edu dot
 au||[[http://unsw.edu.au/|University of New South Wales]] || no ||
 ||Estani Gonzalez||estanislao dot gonzalez at met dot fu-berlin dot de
 ||[[http://www.geo.fu-berlin.de/met/|Free University Berlin]] || yes ||
 ||Luca Cinquini||luca dot cinquini at jpl dot nasa dot gov
 ||[[http://www.jpl.nasa.gov/|NASA Jet Propulsion Laboratory]] || yes ||
 ||J. Sanjay||sanjay at tropmet dot res dot in ||
 [[http://tropmet.res.in/|Indian Institute of Tropical Meteorology]] || yes
 ||
 ||M. V. S. Rama Rao||ramarao at tropmet dot res dot in
 ||[[http://tropmet.res.in/|Indian Institute of Tropical Meteorology]] ||
 yes ||
 ||Tsengdar Lee||tsengdar dot j dot lee at nasa dot gov ||
 [[http://hq.nassa.gov/|NASA HQ]] || no ||
 ||Laura Carriere||laura dot carriere at nasa dot gov
 ||[[http://www.gsfc.nasa.gov/|NASA Goddard Space Flight Center]] || no ||
 ||Denis Nadeau|| denis dot nadeau at nasa dot
 gov||[[http://www.gsfc.nasa.gov/|NASA Goddard Space Flight Center]] || no
 ||
 ||Michael Joyce|| Michael dot J dot Joyce at jpl dot nasa dot
 gov||[[http://www.jpl.nasa.gov/|NASA Jet Propulsion Laboratory]] ||yes||
 ||Shakeh Khudikyan||Shakeh dot E dot Khudikyan at jpl dot nasa dot
 gov||[[http://www.jpl.nasa.gov/|NASA Jet Propulsion Laboratory]] ||yes||
 ||Maziyar Boustani||Maziyar dot Boustani at jpl dot nasa dot
 gov||[[http://www.jpl.nasa.gov/|NASA Jet Propulsion Laboratory]] ||no||
 ||Suresh Marru||smarru at apache dot org||[[http://pti.iu.edu/|Indiana
 University]] ||yes||


 == Sponsors ==
 Champion

  * Chris Mattmann (mattmann at apache dot org)

 Nominated Mentors

  * Chris A. Mattmann (mattmann at apache dot org)
  * Chris Douglas (cdouglas at apache dot org)
  * Paul Ramirez (pramirez at apache dot org)

 Sponsoring Entity

  * Apache Incubator



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



-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com 


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

Re: [VOTE] Graduate Syncope podling from Apache Incubator

[Emmanuel Lécharny]

a big +1 !

Excellent work, guys !

Le 11/2/12 10:00 AM, Francesco Chicchiriccò a écrit :

Hi all,
this is a call for vote to graduate the Syncope podling from Apache
Incubator.

Syncope entered the Incubator in Feb 2012. Since then it has added two
new committers and PPMC members, picked up a couple of new contributors,
and made some releases following the ASF policies and guidelines. The
community of Syncope is active, healthy and growing and has demonstrated
the ability to self-govern using accepted Apache practices.

The Syncope community has voted to proceed with graduation [1] and the
result can be found at [2].

Please cast your votes:

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

This vote will be open for at least 72 hours. Please find the proposed
board resolution below.

[1] http://s.apache.org/up
[2] http://s.apache.org/A8u

Regards.


Resolution:

X. Establish the Apache Syncope 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, for managing
digital identities in enterprise environments.

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

RESOLVED, that the Apache Syncope Project be and hereby is
responsible for the creation and maintenance of software
related to the Identity Management and be it further

RESOLVED, that the office of Vice President, Apache Syncope 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 Syncope Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache Syncope 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 Syncope Project:

   * Colm O Heigeartaigh cohei...@apache.org
   * Emmanuel Lécharny  elecha...@apache.org
   * Fabio Martelli fmarte...@apache.org
   * Francesco Chicchiriccò ilgro...@apache.org
   * Jan Bernhardt jbernha...@apache.org
   * Jean-Baptiste Onofré jbono...@apache.org
   * Massimiliano Perrone ma...@apache.org
   * Marco Di Sabatino Di Diodoro mdisabat...@apache.org
   * Simone Tripodi simonetrip...@apache.org


NOW, THEREFORE, BE IT FURTHER RESOLVED, that Francesco Chicchiriccò
be appointed to the office of Vice President, Apache Syncope 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 Apache Syncope Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator Amber podling; and be it further

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




--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


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

Re: Shipping binary file in CloudStack release

[Emmanuel Lécharny]

Le 10/29/12 3:39 PM, Noah Slater a écrit :

Thanks for following up Chip. Though I do just want to clarify one
misconception.

On 29 October 2012 13:21, Chip Childers chip.child...@sungard.com wrote:


I actually have more than enough votes right now to close the thread
out on the project's dev list, and open up a vote for the IPMC.


No you don't.

To me, this sounds like you're saying to be honest, I could just close the
vote and ship this right now if I wanted to. I'm not sure if that was the
intended message. But regardless, you couldn't. A single -1 vote would be
enough to block the release.



Binding or not binding. It doesn't matter. If
somebody expresses a real, and justified, concern about the artefact, then
you don't release until you've addressed that concern.

Technically speaking, for releases, a -1 is not a veto :

http://www.apache.org/foundation/voting.html
 Votes on Package Releases

Votes on whether a package is ready to be released use majority approval 
http://www.apache.org/foundation/glossary.html#MajorityApproval -- 
i.e. at least three PMC members must vote affirmatively for release, and 
there must be more positive than negative votes. *Releases may not be 
vetoed.* Generally the community will cancel the release vote if anyone 
identifies serious problems, but in most cases the ultimate decision, 
lies with the individual serving as release manager. The specifics of 
the process may vary from project to project, but the 'minimum quorum of 
three +1 votes' rule is universal.


However, having -1 would be a sign that something goes wrong. Either on 
the community side, or on the voter side ;) Better try to see why a -1 
(or many) have been casted before going for the release in such a case.


--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


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

Re: Fwd: [ANN] Apache Syncope 1.0.0-RC3-incubating released

[Emmanuel Lécharny]

Le 7/27/12 1:02 AM, Joe Schaefer a écrit :

I believe Bill is complaining not about the venue,
but the choice of referring to this package as
a release candidate instead of simply dropping
the RC portion of the package name like other
projects typically do with approved candidates.


Ah, ok. Makes sense then.

My perception is that the Syncope guys are trying to cut a 1.0.0, 
instead of going through many 0.x.0 before, therefore they are iterating 
on RC atm.


It's pretty much semantic, IMHO.

Do incubator peeps think it's a wrong approach ?


--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


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

Re: Fwd: [ANN] Apache Syncope 1.0.0-RC3-incubating released

[Emmanuel Lécharny]

Here, I would argue that unless we have some written direction about 
what release numbering scheme  the incubating should use at The ASF, 
then whatever a project decides to use is fine.


I wish the proposal made my Jukka includes this matter.


Le 7/27/12 11:32 AM, sebb a écrit :

On 27 July 2012 08:22, Francesco Chicchiriccò ilgro...@apache.org wrote:

On 27/07/2012 08:13, Emmanuel Lécharny wrote:

Le 7/27/12 1:02 AM, Joe Schaefer a écrit :

I believe Bill is complaining not about the venue,
but the choice of referring to this package as
a release candidate instead of simply dropping
the RC portion of the package name like other
projects typically do with approved candidates.


Ah, ok. Makes sense then.

My perception is that the Syncope guys are trying to cut a 1.0.0, instead
of going through many 0.x.0 before, therefore they are iterating on RC atm.


Indeed, yes.



It's pretty much semantic, IMHO.

In other ASF projects I've seen, the convention is to use -alpha1 or
-beta2 etc. to designate such stages.

Release Candidate (RC) has a specific meaning in the ASF, as it is
what is voted on before release.

So one would vote on

1.0.0-beta3-incubating-RCn

and a successful vote would result in the release of

1.0.0-beta3-incubating

A failed vote for RCn would normally result in trying again with RCn+1
to address the cause of the failure.


Thanks!



Do incubator peeps think it's a wrong approach?


I hope it's not: anyway, this RC3 should be the last one before actual
1.0.0-incubating.

Regards.

--
Francesco Chicchiriccò

ASF Member, Apache Cocoon PMC and Apache Syncope PPMC Member
http://people.apache.org/~ilgrosso/



-
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




--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


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

Re: Fwd: [ANN] Apache Syncope 1.0.0-RC3-incubating released

[Emmanuel Lécharny]

Bill,

the very first incubating project that posted a mail on announce@a.o was 
Tuscany, back in 2007...


In the past 5 years, just checking the incubating projects having used 
annouance@a.o, I see 140 messages.

18/5/2007 : [ANNOUNCE] Apache Tuscany SDO Java 1.0-incubating-beta1 released
4/7/2009 : [ANNOUNCE] Apache CXF 2.0-incubator released!
23/8/2007 : [ANNOUNCE] Apache UIMA 2.2.0-incubating
25/3/2008 : [ANN] Apache NMaven 0.15-incubating Released
25/6/2008 : [ANNOUNCE] Apache CouchDB 0.8.0-incubating has been released
15/2/2009 : [ANNOUNCE] Sanslean 0.97-incubating
21/2/2009 : [ANNOUNCE] Apache Click 2.0.1-incubating released
etc, etc.

I don't think that suddenly something has changed in the announc@a.o 
usage policy, related to Incubator releases.



Le 7/27/12 12:30 AM, William A. Rowe Jr. a écrit :

This seems very odd to me, certainly unusual among Apache projects.

The -dev and -user lists (and even general@incubator) are used to announce that
a release candidate is available and should be tested for readiness to become
an actual release.  Some projects use differently-numbered alpha and beta
designations in a similar manner.

A release candidate is, by definition, something which is not yet a release.
It doesn't seem like annou...@apache.org is an appropriate channel.  The amount
of traffic that list would carry if every 'might become a release' candidate
was offered over what is supposed to be a lower-bandwidth, higher priority list
for users to pick up released updates.

My 2c nonbinding.

Bill


 Original Message 
Subject:[ANN] Apache Syncope 1.0.0-RC3-incubating released
Date:   Thu, 26 Jul 2012 21:43:06 +0200
From:   Fabio Martelli fmarte...@apache.org
To: annou...@apache.org



The Apache Syncope team is pleased to announce the release of Syncope 
1.0.0-RC3-incubating
from the Apache Incubator.

Apache Syncope is an Open Source system for managing digital identities in 
enterprise
environments, implemented in JEE technology .

The release will be available *within 24h from*:
http://incubator.apache.org/syncope/downloads.html

The full change log is available here:
http://s.apache.org/tah
https://cwiki.apache.org/confluence/display/SYNCOPE/Espressivo#Espressivo-1.0.0RC1incubating(June1st,2012)

We welcome your help and feedback. For more information on how to report 
problems, and to
get involved, visit the project website at

http://incubator.apache.org/syncope/

The Apache Syncope Team

Best regards,
F.



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




--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


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

Re: [VOTE] Retire AWF from incubation

[Emmanuel Lécharny]

+1 (binding)

Le 7/4/12 11:18 PM, Roger Schildmeijer a écrit :

Hi,

The AWF community has voted to retire the project.
Following the retirement guide [1], I now call the Incubator PMC to vote on 
confirming this decision. (Will be open for 72 hours).

[ ] +1 Retire the AWF project
[ ] -1 Do not retire the project, because ...

[1] http://incubator.apache.org/guides/retirement.html

WBR
Roger





--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


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

Re: Vote or embedded in discussion? (was Re: [VOTE] Retire AWF from incubation)

[Emmanuel Lécharny]

Le 7/5/12 11:44 AM, Martijn Dashorst a écrit :

On Wed, Jul 4, 2012 at 11:18 PM, Roger Schildmeijer
schildmei...@gmail.com wrote:

The AWF community has voted to retire the project.
Following the retirement guide [1], I now call the Incubator PMC to
vote on confirming this decision. (Will be open for 72 hours).

As a drive-by interested party in the incubator (with a couple of
mentored podlings) I noticed something that struck me as a bit off.

I just looked through the archives to see what was happening as AWF
has been in the incubator for not too long and I couldn't find the
vote to retire the project you mentioned.

I noticed that you did not undertake a formal vote but rather relied
on a note as a reply for a board report notification [1]. While the
mentors did acknowledge a +1 for retirement, I think retirement of
your development effort should not be discussed under the rug.


The rug is pretty thin here :)


A subject Re: Incubator PMC/Board report for Jul 2012 ([ppmc])
sounds a lot less noticeable than [DISCUSS] Retire AWC or [DISCUSS]
No future for AWC development.

In any case if the project really is dead in the water I would not
expect a discussion from my proposed headlines as well, but that would
at least have given lurking community members to speak up now.


Last time we discussed about the potential for the project to be dead in 
march, nobody but Seven expressed the desire to continue the effort. We 
kept the project going for one more quarter, for Seven to get a chance 
to catch in, but sadly, he now have no more time...


I don't think the projects members will be surprised if we shutdown the 
project. I do agree, though, that we should have followed the procedure.


Hope it clarifies the current decision !


--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


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

Re: AWF status

[Emmanuel Lécharny]

Le 7/1/12 9:00 PM, Niklas Gustavsson a écrit :

On Sun, Jul 1, 2012 at 5:01 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:

In preparation for reviewing the hopefully upcoming report, I gave a
brief look at how things are in the AWF podling.

Unfortunately l see zero activity since April, which suggests that the
temporary activity drop mentioned in the April report has become a
more permanent state.

AWF mentors, can you raise this issue with the community and report
back with a plan of action (possibly to retire) ideally already in
time for the July report?

There is indeed a suggestion to retire the project on the awf-dev list:
http://mail-archives.apache.org/mod_mbox/incubator-awf-dev/201207.mbox/browser

Personally, I think it's time for retirement as activity has not
picked up despite some previous discussions about the projects future.

I do agree.


--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


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

Re: Board will be proposing a new TLP

[Emmanuel Lécharny]

Le 6/30/12 2:23 PM, Jim Jagielski a écrit :

Since all code was developed w/i the ASF, by ASF people, and
is under the ALv2 (either implied/confirmed by the authors or
explicit in the code itself), there is some debate on whether
or not Incubation is even required...
Sure we should go through incubation, to make sure the peeps being STV 
code *knows* about the Apache Way...


Or is this simple non-sense ?

My +1 to the TLP without going through incubation...


--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


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

Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 3)

[Emmanuel Lécharny]

Le 6/24/12 10:46 AM, Chris Douglas a écrit :

Kevan-


Hi, jumping on this thread, because we have had similar discussions on 
another incubating project I'm mentoring...


This argument is logical, but that doesn't make it legal and thus
required. It is also a constraint foreign to most TLPs, making its
rigid enforcement in the incubator unfair and arbitrary. Not to be
glib, but you clearly do have time to pursue this broadly and across
the foundation if, in fact, you're right and many- if not most- ASF
projects are improperly managing this obligation.
The fact that many projects at the ASF are not releasing correctly is 
not a good reason for not doing it correctly for Kafka. Moreover, I'm 
pretty sure that sooner or later, those projects will have to comply to 
what seems to be a reasonable requirement.


The references provided do not make the argument you're forwarding, at
least they do not distinguish it from the criteria we used for
evaluating Kafka 0.7.0. The claim is that Kafka distributes the
transitive closure of its dependencies NOT because they're mentioned
in the build source (where you carve out an exemption), but because
these deps are mentioned AND Kafka's build produces a server. This
distinction between applications and libraries is unmentioned in
the documentation. In fact, I cannot create an argument for
documenting the transitive closure of dependencies using those
references. The argument (as forwarded) requires this step to reach
its conclusion, but it appears to be novel and unsupported. The
passages you quote are already common ground; we both agree that the
artifact must contain an appropriate LICENSE and NOTICE file, but we
disagree on the scope of appropriate. I continue to disagree; I
don't think the case has been made.

The closest documentation I could find was here:
http://www.apache.org/legal/3party.html

Which claims to be a draft of a document that also doesn't give
concrete guidance on this point.


AFAICT, the important thing is that those who will download Kafka (or 
any other ASF project) can't be fooled when includig it into their own 
projects. The NL files are here to facilitate our user's work, by 
listing all the external third party components we depend on, and that 
includes transitive dependencies.


It's also a guarantee that we have checked that no depency contains a 
transitive dependency that is *not* compatible with our licence. How 
good will it be to include a dependency that includes a GPL3 licensed 
3rd party itself ?


Having checked all the transitive dependencies ourself is the only way 
to provide a guarantee to your users, and by listing those transitive 
dependencies in the  NL files is the only way to go.


At least this is my interpretation on the various discussions we have 
had in the ast two months while tryibg to cut a release on Syncope 
(incubator) and SSHD (a MINA subproject).


Hope it helps...

--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


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

Re: [VOTE] Release Kafka 0.7.1-incubating (Candidate 3)

[Emmanuel Lécharny]

Le 6/24/12 4:32 PM, sebb a écrit :

On 24 June 2012 14:11, Emmanuel Lécharnyelecha...@gmail.com  wrote:


AFAICT, the important thing is that those who will download Kafka (or any
other ASF project) can't be fooled when includig it into their own projects.
The NL files are here to facilitate our user's work, by listing all the
external third party components we depend on, and that includes transitive
dependencies.

-1

The NL files only apply to what is included in the release archive itself.

If there are other dependencies, these can be listed in a
DEPENDENCIES or README file.


Thanks for the clarification, and the corrections you have made on my mail.



--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


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

Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating / 3rd attempt

[Emmanuel Lécharny]

[X] +1  approve (binding)


--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


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

Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating / 2nd attempt

[Emmanuel Lécharny]

Le 5/16/12 9:45 AM, Francesco Chicchiriccò a écrit :

Hi all,

Hi Francesco

as far as I've understood we are quite in an impasse here: is there any
quick way out?
Thinking twice about the third party components, I came to the 
conclusion that we should include the license of those requiring that it 
should be done, even if we have some transitive dependencies.


The reason is that if a direct 3rd party does not have a NL containing 
transitive 3rd party, then those direct 3rd party are faulty. But 
because they are faulty does not mean we should also be (transitively) 
faulty !


That also means some of the ASF projects (including ApacheDS I'm working 
on !) have to double check their NL files, something I'll do asap.


I'll be a bit busy the next 4 days, but I'll try to get a clear decision 
about this problem before next week, as it may impact many other projects.


Thanks !


I've performed some more analysis and I've come to the following findings:

1. XPP3 is pulled in by XStream (syncope-core and syncope-console WAR files)

[INFO] +- com.thoughtworks.xstream:xstream:jar:1.4.2:compile
[INFO] |  \- xpp3:xpp3_min:jar:1.1.4c:compile

and by ApacheDS (syncope-build-tools WAR file)

[INFO] +- org.apache.directory.server:apacheds-all:jar:1.5.7:compile
[INFO] |  +- org.apache.directory.shared:shared-ldif:jar:0.9.19:compile
[INFO] |  \-
org.apache.directory.shared:shared-dsml-parser:jar:0.9.19:compile
[INFO] | \- xpp3:xpp3:jar:1.1.4c:compile

XStream says that other XML parsers can be used (
http://xstream.codehaus.org/download.html#optional-deps), I don't know
about ApacheDS - but guess Emmanuel does.

2. The following are all the transitive dependencies currently not
mentioned in LN files:

org.livetribe:livetribe-jsr223:jar:2.0.6
org.mybatis:mybatis:jar:3.0.6
xmlpull:xmlpull:jar:1.1.3.1
xpp3:xpp3_min:jar:1.1.4c / xpp3:xpp3:jar:1.1.4c
aopalliance:aopalliance:jar:1.0
asm:asm:jar:3.3.1
antlr:antlr:jar:2.7.7
dom4j:dom4j:jar:1.6.1
joda-time:joda-time:jar:2.0


Can we found a simple and shared way to assess what is the legal,
correct and complete, content of Syncope LN files?
Is there any other ASF project distributing WAR files we can check?

If not: what if just include in LN files all the deps reported above?
Is this harmful in any way?

Please help: we'd really like to cut out first release...

Best regards.

On 15/05/2012 11:36, Christian Grobmeier wrote:

The point is that we don't vote binaries, we vote sources. Generated
binaries are just by-products of the build.

That we distribute binaries is just for convenience.

which does not change anything imho


Now, I do think that we should include into the NL files the licenses for
3rd parties we *directly* include, but not those that are transivitely
included. I may be wrong though. I understand your position, too.

It may be worthful to ask beside this thread what is the correct way to
refer those transitive dependencies...

+1

Did not know there were other positions actually.


http://incubator.apache.org/guides/releasemanagement.html#best-practice-license
All the licenses on all the files to be included within a package
should be included in the LICENSE document. 

But as soon as we include the deps' licenses we include, even if they
themselves include some 3rd party licenses, my understanding is that they
already have done the job...

If they did it it. I have not opened all the files to be honest, but
is this something we can rely on (that they have done their job
proberly)?


It says to me, it does not matter who depends on what, it does only
matter whats inside your war.

Btw, I am still unsure which license XPP has. This is worse, because:
http://www.apache.org/dev/release.html#distribute-other-artifacts
Again, these artifacts may be distributed only if they contain
LICENSE and NOTICE files

See on
http://www.extreme.indiana.edu/dist/java-repository/xpp3/distributions/,
unzip the
http://www.extreme.indiana.edu/dist/java-repository/xpp3/distributions/xpp3-1.1.4c_src.tgz
tarball and check the included license.

Thanks! I opened the jar from the Syncope war, there was no info included.

Is that compatible? Indiana University Extreme! Lab Software License
I think its fine, but I am not very good with that boring stuff:
http://apache.org/legal/3party.html

Btw, this phrase is interesting:
Redistributions in binary form must reproduce the above copyright notice

This includes the provided war file. There is no copyright notice of
XPP and my guess is the license holders are not interested if we are
having it as transitive lib or not.



--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


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

Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating / 2nd attempt

[Emmanuel Lécharny]

Le 5/15/12 9:31 AM, Francesco Chicchiriccò a écrit :

On 14/05/2012 20:45, Christian Grobmeier wrote:
On Mon, May 14, 2012 at 7:56 PM, Emmanuel 
Lécharnyelecha...@gmail.com  wrote:

Le 5/14/12 6:42 PM, Christian Grobmeier a écrit :

Can you please let me know which license XPP uses? I could not find 
informatino in NOTICE and did not find a website which helped me. 
its necessary to clarify that as xpp3 is in the war file release. 
Once you told me, I will give my +1

Clearly missing in the NL files.

OK. Guess this should be fixed with a new attempt then.


Will do ASAP - guess we are trying to beat some record at Syncope: I 
know that Flex made it in seven attempts, we are approaching... ;-)


Jokes apart, we are talking here about XPP3, a transitive dependency 
of XStream which is instead a declared dependency of Syncope (core).
We honestly did not consider at all such dependencies in LN files, 
and there are quite some: what's the best practice for such cases? I 
see no option but using the maven dependency plugin in order to find 
all transitive dependencies and update LN files consequently.


Is this correct? Basically, I feel this like breaking the Maven 
dependency resolution...

I must admit I'm a bit puzzled.

IMO, the LN files should only contain the required licenses and notice 
for deps we are explicitely declaring in the poms, as they are part of 
the build. The fact that the built wars include transitive dependencies 
is a by-product of the build. In other words, if a 3rd party we include 
itself depends on some other libs, then it's this 3rd party LN files to 
explicitely include the required LN, not ours.


So XPP is not included by us, and should not be added in the NL, as I 
initially (wrongly) thought.


Regarding the distinction between sources vs binary NL files, my 
perception is that we should keep all the required (ie if it's 
explicitely asked by the 3rd party license) 3rd party Licenses, and 
nothing more. I do think we are pretty much ok here. Sebastian, if you 
have some libs that you think should not be present in the NL files, 
could you name them ?


Thanks !


--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


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

Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating / 2nd attempt

[Emmanuel Lécharny]

Le 5/14/12 1:03 AM, sebb a écrit :

On 12 May 2012 23:59, Emmanuel Lécharnyelecha...@gmail.com  wrote:

Le 5/12/12 1:42 AM, sebb a écrit :


On 11 May 2012 16:29, Francesco Chicchiriccòilgro...@apache.orgwrote:

I've created a 1.0.0-RC1-incubating release, with the following artifacts
up
for a vote:

SVN source tag ( r1335495):

https://svn.apache.org/repos/asf/incubator/syncope/tags/syncope-1.0.0-RC1-incubating/

If this is the second attempt, why is it called RC1 ?

Surely it should be called RC2 ?


Depends. As the first vote has been canceled, there was nothing like an
official RC1.

RC means Release candidate; if the vote passes, it becomes the release.


As noted in the subject, this is the 2nd attempt for RC1.

Does not make sense.

The second attempt is the second release candidate, i.e. RC2.
This is not the semantic we are using. A RC is just a relese that we 
expect to become the GA if no major issue is encountered. It's not 
something like an attempt to release.


See 
http://en.wikipedia.org/wiki/Software_release_life_cycle#Release_candidate


The fact that we have to check that a RC is a valid RC against the ASF 
croteria does not impede the numbering scheme we use : we keep trying to 
cut a release, with the same number, until we get it correct. At least, 
that's my opinion, which may not be shared.


In any case, it should not be a blocker...

Thanks !

--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


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

Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating / 2nd attempt

[Emmanuel Lécharny]

Le 5/14/12 4:05 PM, sebb a écrit :

On 14 May 2012 08:47, Francesco Chicchiriccòilgro...@apache.org  wrote:

On 14/05/2012 01:03, sebb wrote:

On 12 May 2012 23:59, Emmanuel Lécharnyelecha...@gmail.com  wrote:

Le 5/12/12 1:42 AM, sebb a écrit :


On 11 May 2012 16:29, Francesco Chicchiriccòilgro...@apache.orgwrote:

I've created a 1.0.0-RC1-incubating release, with the following artifacts up 
for a vote:

SVN source tag ( r1335495):

https://svn.apache.org/repos/asf/incubator/syncope/tags/syncope-1.0.0-RC1-incubating/

If this is the second attempt, why is it called RC1 ?

Surely it should be called RC2 ?

Depends. As the first vote has been canceled, there was nothing like an 
official RC1.

RC means Release candidate; if the vote passes, it becomes the release.

As noted in the subject, this is the 2nd attempt for RC1.

Does not make sense.

The second attempt is the second release candidate, i.e. RC2.

We agreed on a version scheme where RCi are full releases (from release
process point of view) while not including everything planned on JIRA
for the corresponding version: hence, our 1.0.0-RC1-incubating doesn't
have all fixes planned for 1.0.0-incubating.

In other words, RC1 is referring to the completeness of the code against
the issues, not to the completeness of the release against the release
requirements.

At least, this is how we defined Syncope release numbering scheme;
moreover, it seems to me that every project is defining its own
versioning ([1] [2] [3] for example), and I personally think it's correct.

Release numbers are just labels, after all, isn't it?

Yes, they are just a convention, but if the convention is not in
general use, then  it is potentially confusing.

Other projects use alphaN / betaN suffixes, or Mnn for milestone releases.

It's particularly confusing that the same SVN tag is used for both
source releases

This release vote uses:
https://svn.apache.org/repos/asf/incubator/syncope/tags/syncope-1.0.0-RC1-incubating/

Previous release vote:
https://svn.apache.org/repos/asf/incubator/syncope/tags/syncope-1.0.0-RC1-incubating/
A tag is just a name. We don't vote tags, we vote a source package, ie a 
SVN revision number.


The reason we add the number of attempt in the subject is just to avoid 
a possible confusion.




Tags should ideally be immutable.

SVN revisions are immutable.


Similarly for the source archives - the names are identical:
syncope-root-1.0.0-RC1-incubating-source.zip
syncope-root-1.0.0-RC1-incubating-source.zip


Anyway, is there also other IPMC available to check the release to bind
his vote? Thanks!

I think there are some problems with the NL files in the source archive.

The NL files are supposed to relate to the actual items included in
the archive; however the NL in the source archive include references
to binaries which are clearly not included in the archive.
Syncope generates war files, which include those binaries. Using the 
source per se does not give you anything usabe, and those using the war 
files will have those binaries included. Not having the full NL 
(including for binaries) would be harmfull for users, IMO.


I'll check against some other projects that have the same kind of 
distribution to double check.


Holding my vote atm.

--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


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

Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating / 2nd attempt

[Emmanuel Lécharny]

Le 5/14/12 6:42 PM, Christian Grobmeier a écrit :

Can you please let me know which license XPP uses? I could not find
informatino in NOTICE and did not find a website which helped me. its
necessary to clarify that as xpp3 is in the war file release. Once you
told me, I will give my +1

Clearly missing in the NL files.


Release looks ok so far.

I have found files like that:
syncope-build-tools-1.0.0-RC1-incubating-classes.jar.asc.md5


This is a maven bug. The signature plugin does sign everything, 
including the .asc file, AFAIK.


Other question: the projects I know vote upon a website too. Is this
not the case with Syncope?


Hmmm... Good question. I never voted against any web site on the various 
projects I worked or mentored. Where does it come from ?



--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


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

Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating / 2nd attempt

[Emmanuel Lécharny]

Le 5/12/12 1:42 AM, sebb a écrit :

On 11 May 2012 16:29, Francesco Chicchiriccòilgro...@apache.org  wrote:

I've created a 1.0.0-RC1-incubating release, with the following artifacts up
for a vote:

SVN source tag ( r1335495):
https://svn.apache.org/repos/asf/incubator/syncope/tags/syncope-1.0.0-RC1-incubating/

If this is the second attempt, why is it called RC1 ?

Surely it should be called RC2 ?


Depends. As the first vote has been canceled, there was nothing like an 
official RC1.


As noted in the subject, this is the 2nd attempt for RC1.



--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


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

Re: [VOTE] Apache Syncope 1.0.0-RC1-incubating

[Emmanuel Lécharny]

Le 5/9/12 2:27 AM, sebb a écrit :

On 8 May 2012 13:06, Emmanuel Lécharnyelecha...@gmail.com  wrote:

Comments inline

Le 5/8/12 11:05 AM, sebb a écrit :

On 8 May 2012 09:13, Francesco Chicchiriccòilgro...@apache.orgwrote:

Hi Sebb,
you can find my replies embedded below.

I am going to send a [CANCEL] reply to this thread, remove Nexus staging
repo and SVN tag, fix everything and start again the release process for
1.0.0-RC1-incubating from scratch.

Regards.






The NOTICE file is very long; I suspect that not all of the entries are
*required*.


The LICENSE and NOTICE files were written against the parent POM: all the
dependencies with scope != test were considered, then.

The NL files must relate to what is actually included in the archive.


We release sources, so making a distinction between scope != test
dependencies and scope=test dependencies does not make sense, AFAICT. If we
use a 3rd party product to test Syncope, then I think we must refer their
licenses in NOTICE and LICENSE.

No, AIUI the NL files only relate to what is being released, not any
external dependencies.
See JDBM example in 
http://incubator.apache.org/guides/releasemanagement.html#note-license-and-notice. 
Typically, JDBM will be a dependencies, but still it requires you to 
include the needed references into NL files.


I'm a bit lost here, as the idea is to allow users to download the 
source package we release, and not infringe any of the 3rd party 
software Licences, by including in our own NL files what the 3rd party 
product requires us to include.


--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com


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