Re: [DISCUSS] Weex for Apache Incubator

[Richard S. Hall]

Given that wix.com gets by with the name, I'm not sure it 
matters...there's probably more of a concern over confusion with Wix 
than it referring to masturbation in German... :-)



On 11/21/16 09:04 , Markus Geiß wrote:

Hey ... I'm a native German speaker too ...

The referenced word is pronounced with a short 'i' and is referring to 
something a boy would do alone at night ...

Given that Weex is pronounced with a long 'i', it could lead to some fun 
situations.

Cheers

Markus

-Original Message-
From: Bertrand Delacretaz [mailto:bdelacre...@apache.org]
Sent: Monday, November 21, 2016 02:55 PM
To: Incubator General 
Subject: Re: [DISCUSS] Weex for Apache Incubator

On Sun, Nov 20, 2016 at 11:17 PM, Edward J. Yoon  
wrote:

...We'd like to start a discussion on accepting the Weex...

A native German speaker tells me Weex means or sounds something between LOL and 
NSFW in German - if that's correct that's probably not a good name for an 
Apache project.

-Bertrand

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


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



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

Re: PPMC versus commiter

[Richard S. Hall]

On 12/19/12 11:40 , Bertrand Delacretaz wrote:

On Wed, Dec 19, 2012 at 5:35 PM, Mattmann, Chris A (388J)
chris.a.mattm...@jpl.nasa.gov wrote:

...Making someone a C without PPMC gives them the power to evolve the code,
but not to help make decisions about how can maintain it, or when to
release it. Something about that, I just don't find right

As I said, in general I agree, but as a temporary situation that might
allow a project to elect someone as a committer early, while taking a
bit more time before granting them PMC power.


Agreed.

Considering we've given people commit access to create documentation or 
examples, I think you shouldn't assume that C == evolve the code.


I think we're better off only implementing one size fits all rules 
when absolutely necessary. I don't think this is one of those situations.


- richard


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

Re: [VOTE] Release Apache OpenOffice 3.4.1 (incubating) RC2

[Richard S. Hall]

On 8/18/12 08:24 , Andre Fischer wrote:

Hi all,

this is a call for vote on releasing the following candidate as Apache
OpenOffice 3.4.1 (incubating). This will be the second incubator 
release for Apache OpenOffice after the 3.4 release with already more 
than 11 million downloads.



This release candidate provides the following important key changes
compared to the OpenOffice 3.4 release:

(1) Five more translations: Finnish, British English, Khmer, Slovak, 
and Slovenian.


(2) As of 2012/08/16, there were 69 verified issues that have been
resolved. (Complete list at http://s.apache.org/Huv)


Do I actually need a bugzilla account to view the issue list? The above 
link directs me to a login screen...


- richard



(3) Update of the NOTICE file: it now properly mentions CoinMP as 
numerical equation solver.


(3) Most external source archives are now downloaded from their 
project servers.
For all of them exists a fallback at 
http://ooo-extras.apache-extras.org.codespot.com/files/.

The Apache SVN repository is only used as secondary fallback and
is not used in practice.
It will be removed in the next release.


For a detailed feature overview please see the release notes at
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4.1+Release+Notes. 



The release candidate artifacts (source release, as well as binary
releases for 20 languages) and further information how to verify and
review Apache OpenOffice 3.4.1 (incubating) can be found on the following
wiki page:


https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds#DevelopmentSnapshotBuilds-AOO3.4.1 



Please vote on releasing this package as Apache OpenOffice 3.4.1 
(incubating).


The vote starts now and will be open until:

Tuesday, August 21st: 2012-08-21 15pm UTC+2.

The PPMC vote took already place on the public ooo-dev mailing list.
There where 11 +1 votes including
   one IPMC member binding +1,
   10 +1 votes fro PPMC members (this includes the one IPMC member),
   one +1 vote from a community member.
No abstinations, no -1 votes.

Vote thread:
http://mail-archives.apache.org/mod_mbox/incubator-ooo-dev/201208.mbox/%3C502B8FCD.4050100%40googlemail.com%3E 




The vote will be open for 3 days.

[ ] +1 Release this package as Apache OpenOffice 3.4.1 (incubating)
[ ]  0 Don't care
[ ] -1 Do not release this package because...

-
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 ACE from the Apache Incubator

[Richard S. Hall]

On 11/21/11 10:11 , ant elder wrote:

On Mon, Nov 21, 2011 at 3:03 PM, Richard S. Hallhe...@ungoverned.org  wrote:

On 11/21/11 09:41 , ant elder wrote:

On Mon, Nov 21, 2011 at 2:18 PM, Karl Paulskarlpa...@gmail.comwrote:

On Mon, Nov 21, 2011 at 3:08 PM, ant elderantel...@apache.orgwrote:

Well IMHO i don't think this release demonstrates that the poddling
has an understanding of making or reviewing ASF releases and thats the
point of requiring releases during incubation.

So you want us to do a new release? Fine, whatever, we can just roll a
new release which has the source distribution configured. That was a
mistake in the first place as it makes the bundles not easily
individually buildable.

However, we still will not have a combined source release as we want
to be able to release our bundles individually. Is that the resolution
then? All we have to do is a do a micro release with the source
distribution configured on a per artifact level?


I agree the requirement for a single source release doesn't seem
totally clear, I've said I think you should have one and so has sebb,
it would be good to hear what other Incubator PMC people think. I
think you need one for two main reasons:

1) The ASF deals with source and the releases are how users get hold
of that source. If a user is going to do development with the released
ACE source they likely aren't going to be able to do very much useful
with just single things like org.apache.ace.repository.imp. At the
very least they're probably going to want
org.apache.ace.repository.api too but likely there is a big network of
the 60 something ACE modules that anyone doing most non-trivial ACE
development is going to want. One source distribution makes this easy,
making them have to download them all separately isn't particularly
practical. That https://svn.apache.org/repos/asf/incubator/ace/trunk/
is structured so the ASF committers can work with them as one single
buildable checkout i think shows thats true.

2) If there is only individually buildable source for each jar how are
people really going to verify that the release is actually buildable
and the artifacts match the SVN tag source when reviewing and voting
on release votes? No one reviewing is really likely to download 60
separate distros and build them all one by one are they?

I disagree. There seems to be some misunderstanding that there is one single
product that must be built.

When you develop independently evolving modules, big bang releases do not
make sense. Each module has its own release cycle. Occasionally you may end
up creating some sort of distribution out of the modules and release that,
but that is just one potential distribution.


I agree thats an approach used and works in many projects but if that
was really the case _here_  then surely the SVN would be structured so
that there were separate trunk/branch/tag folders for each module,


Why do we need separate trunk/branch/tag folders for each module? We 
don't do it that way in Felix either. I don't see anything magical about 
having separate folders for each. Are you purely worried about the 
overhead of looking through a long directory listing?


- richard


there would have been more releases than just the single 0.8.0
release, and there would be separate release votes for each module
being released.

...ant

-
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

[RESULT] Re: [IP CLEARANCE] OSGi Service Diagnostics Contribution

[Richard S. Hall]

Closing this (on behalf of Carsten) as cleared for import. Thanks.

- richard

On 10/19/11 04:39 , Carsten Ziegeler wrote:

Please review the following contribution for IP clearance:

   http://incubator.apache.org/ip-clearance/felix-service-diagnostics.html

Thank you.

Carsten


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

[RESULT] Re: [IP CLEARANCE] Lightweight OSGi HttpService implementation contribution

[Richard S. Hall]

Cleared for import. Thanks.

- richard

On 9/30/11 12:55 PM, Richard S. Hall wrote:

Please review the following contribution for IP clearance:


http://incubator.apache.org/ip-clearance/felix-lightweight-httpservice.html


Thank you.

- richard



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

[IP CLEARANCE] Lightweight OSGi HttpService implementation contribution

[Richard S. Hall]

Please review the following contribution for IP clearance:


http://incubator.apache.org/ip-clearance/felix-lightweight-httpservice.html


Thank you.

- richard


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

Re: [VOTE] Accept OpenOffice.org for incubation

[Richard S. Hall]

+1

- richard

On 6/10/11 12:02, Sam Ruby wrote:

*** Please change your Subject: line for any [DISCUSSION] of this [VOTE]

As the discussions on the OpenOfficeProposal threads seem to be 
winding down, I would like to initiate the vote to accept 
OpenOffice.org as an Apache Incubator project.


At the end of this mail, I've put a copy of the current proposal.  
Here is a link to the document in the wiki:


http://wiki.apache.org/incubator/OpenOfficeProposal?action=recallrev=207

As the proposal discussion threads are numerous, I encourage people to 
scan and review the archives for this month:


http://mail-archives.apache.org/mod_mbox/incubator-general/201106.mbox/browser 



Please cast your votes:

[  ] +1 Accept OpenOffice.org for incubation
[  ] +0 Indifferent to OpenOffice.org incubation
[  ] -1 Reject OpenOffice.org for incubation

This vote will close 72 hours from now.

- Sam Ruby

= OpenOffice.org - An open productivity environment =
== Abstract ==
!OpenOffice.org is comprised of six personal productivity 
applications: a word processor (and its web-authoring component), 
spreadsheet, presentation graphics, drawing, equation editor, and 
database. !OpenOffice.org is released on Windows, Solaris, Linux and 
Macintosh operation systems, with more 
[[http://porting.openoffice.org/|communities]] joining, including a 
mature  [[http://porting.openoffice.org/freebsd/|FreeBSD port]]. 
!OpenOffice.org is localized, supporting over 110 languages worldwide.


== Proposal ==
Apache !OpenOffice.org will continue the mission pursued by the 
!OpenOffice.org project while under the sponsorship of Sun and Oracle, 
namely:


To create, as a community, the leading international office suite 
that  will run on all major platforms and provide access to all 
functionality and  data through open-component based APIs and an 
XML-based file format.


In addition to to building the !OpenOffice.org product, as an end-user 
facing product with many existing individual and corporate users, this 
project will also be active in supporting end-users via tutorials, 
user forums, document template repositories, etc.  The project will 
also work to further enable !OpenOffice.org to be used as a 
programmable module in document automation scenarios.


== Background ==
!OpenOffice.org was launched as an open source project by Sun 
Microsystems in June 2000.  !OpenOffice.org was originally developed 
under the name of StarOffice by Star Division, a German company, which 
was acquired by Sun Microsystems in 1999.  Sun released this as open 
source in 2000.  !OpenOffice.org is the leading alternative to 
MS-Office available.  Its most recent major version, the 3.x series 
saw over 
[[http://www.webmasterpro.de/portal/news/2010/02/05/international-openoffice-market-shares.html|100 
million downloads]] in its first year.  The 
[[http://www.webmasterpro.de/portal/news/2010/02/05/international-openoffice-market-shares.html|most 
recent estimates]] suggest a market share on the order of 8-15%.


The !OpenOffice source is written in C++ and delivers language-neutral 
and scriptable functionality. This source technology introduces the 
next-stage architecture, allowing use of the suite elements as 
separate applications or as embedded components in other applications. 
Numerous other features are also present including XML-based file 
formats based on the vendor-neutral !OpenDocument Format (ODF) 
standard from OASIS and other resources.


== Rationale ==
!OpenOffice.org core development would continue at Apache following 
the contribution by Oracle, in accordance with Apache bylaws and its 
usual open development processes. Both Oracle and ASF agree that the 
!OpenOffice.org development community, previously fragmented, would 
re-unite under ASF to ensure a stable and long term future for 
OpenOffice.org. ASF would enable corporate, non-profit, and volunteer 
stakeholders to contribute code in a collaborative fashion.


Supporting tooling projects will accompany the !OpenOffice.org 
contribution, providing APIs for extending and customizing 
!OpenOffice.org.


Both !OpenOffice.org and the related tooling projects support the 
OASIS Open Document Format, and will attract an ecosystem of 
developers, ISVs and Systems Integrators. ODF ensures the users of 
!OpenOffice.org and related solutions will own their document data, 
and be free to choose the application or solution that best meets 
their requirements.


The !OpenOffice.org implementation will serve as a reference 
implementation of the Open Document Format standard.


= Current Status =
== Meritocracy ==
We understand the intention and value of meritocracy at Apache.  We 
are particularly gratified to learn, during the discussion on this 
proposal, that there is a strong role for non-coders to participate in 
this meritocracy and as they demonstrate their sustained commitment 
and merit, to take on additional community responsibilities.


The initial developers are very familiar 

Re: Request: Can proposed committers introduce themselves?

[Richard S. Hall]

On 06/08/2011 04:16 AM, Christian Lippka wrote:

Moin Moin [1],

my name is Christian Lippka and I work on the donnated code base since 
1998

when I was hired by StarDivision which was then consumed by Sun and later
bought by Oracle. Oracle is also my current employer. I am here as an 
individual,
so everything I do and say is based on my own opinions and 
motivations. Please
note that I can not and will not discuss decisions made by Sun/Oracle 
now or in the
past. I also obviously do not speak for Oracle in any way and I'm not 
in any way

involved in the donation process that is currently going on.

That said, my past work was to lead the Sun/Oracle internal 
development of the

Impress and Draw application. My work includes

- the creation of the flash export
- the down stripping of code to create the (discontinued before open 
sourcing) stand alone StarOffice Impress Player
- the specification of the presentation and graphic parts of the 
OpenOffice.org xml format which later became the base for ODF
- driving development of the UNO API for impress and draw so it is now 
possible to have an xml filter for impress that does not link to the 
application code

- adding native table support to impress and draw
- bootstrapping the graphics part of the native mac port by fixing 
open issues in the vcl sal layer for aqua (spare time project)
- working on the renaissance project to modernize the overal UI 
experience of impress


At heard I'm a C/C++ hacker but I nowadays often use Java for small 
private projects out of convenience and
I started to get some experience in Objectice-c. I am not an idealist 
at all, I tend to use the tool that does the job at hand best.
This makes me currently a desktop user of a windows pc, an ubuntu box 
and a lovely old mac pro.
As someone coming originally from the hardware world I still have a 
huge interest in embedded and mobile and would

love to see an OOo derivate on a tablet.

My personal motivation to join this proposal as a committer is based 
on my bounding with the underlying source code and
also the people involved. You can not work 12 years on the same thing 
without getting to either hate or love it. So for me
it is obviously love and passion and it would make me sad to not even 
try to make this proposal a success.


Now a valid question could be, why ASF and not TDF. For me, this is 
not a binary question. I have already contributed
to OpenOffice.org in my spare time. I have also already (though small) 
contributed to LibreOffice in my spare time.
While I have some different opinions, I do not oppose the TDF or 
LibreOffice. I am not here to make this project win
and another project fail. I am not here to dishonor the good work that 
good people put into something that they
think is the best way to go. But I hope that people will respect 
others for trying to do something different, even

so we may share many of the same goals.

I'm happy with healthy competition. Not competition in the sense that 
the same work needs to be done multiple
times. But competition in the sense to try different things, provide 
diversity and something to choose from.
At least this is my understanding of liberty, the freedom to be able 
to choose from different options. If there
is only one option to choose from, even if this is the perfect option, 
this is still no longer freedom.


My opinion on the split/unite community is very simple. For me, there 
is but one open office community.
If you are working on any branch, fork, clone, sibling, 
successor,predecessor of what is OpenOffice.org, you
are part of that community. If you are a teacher at a school and 
promote the use of any odf based office
suite, you are part of this community. If you hate to see a world 
where there is only one vendor dominating
something that is essential for everyone in the digital age, you are 
part of the community.
And yet, inside this community there are other communities, formed 
around goals, opinions, motivations.

And I think that is perfectly valid.

I also think that while it is hard some times it is a good thing that 
this heats up so much emotions. This shows
that OpenOffice.org did not just start something that is useful. It 
started something that people are passionate

about. And this makes me so exited to be part of it.

My technical vision (as in, not plans, no facts, no I tell you how to 
do it) for this particular project under the umbrella
of the ASF is as follows. I see this as an opportunity to do some bold 
moves that will jumpstart the free office world to
the next level. One such bold move in the past was the switch to XML. 
I think this changed everything, and I usually hate such
marketing speech :) What I would love to see is a major rework 
concerning modularization and configurability.
In the past I was part of many discussions on what would be the best 
UI framework for OpenOffice.org to solve all
problems including world peace. Obviously there was no such thing. 
This is 

Re: A little OOo history

[Richard S. Hall]

On 6/7/11 12:31, William A. Rowe Jr. wrote:

On 6/7/2011 11:11 AM, Niall Pemberton wrote:

On Tue, Jun 7, 2011 at 4:52 PM, William A. Rowe Jr.wr...@rowe-clan.net  wrote:

Just to clarify, only source code is released by the ASF.  Yes, there may

I don't believe this is true - we have to release the source, but
anything we distribute is considered released and needs to be
checked/approved - and the release FAQ seems to agree with that

http://www.apache.org/dev/release.html#what

Really?  Where do you get that?

The Apache Software Foundation produces open source software. All releases are 
in the
form of the source materials needed to make changes to the software being 
released. In
some cases, binary/bytecode packages are also produced as a convenience to 
users that
might not have the appropriate tools to build a compiled version of the source. 
In all
such cases, the binary/bytecode package must have the same version number as 
the source
release and may only add binary/bytecode files that are the result of compiling 
that
version of the source code release.


Well, we do have to verify that the binaries (i.e., the JAR files for 
Java) have the correct legal files, etc. Things may be different for 
native languages...I don't know.


- richard


-
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: OpenOffice: were are we now?

[Richard S. Hall]

On 6/6/11 2:48, Phil Steitz wrote:

On 6/5/11 11:26 PM, William A. Rowe Jr. wrote:

On 6/6/2011 1:06 AM, Sanjiva Weerawarana wrote:

On Mon, Jun 6, 2011 at 11:17 AM, Phil Steitzphil.ste...@gmail.com  wrote:


On 6/5/11 10:16 PM, William A. Rowe Jr. wrote:

Wow.  Did it occur to you that the original project, Apache httpd,
was commercially exploited by vendors *even prior to the creation
of the Apache Software Foundation*?

There is a difference between commercial entities using code vs
manipulating communities.  Clearly we disagree on this and what the
ASF is for.  Fine.  I hope there is room for both of our views.

I'm totally in agreement with Phil. There is a BIG difference in the two
positions and I for one would not support ASF being exploited. ASF products
being used for commercial success is absolutely superb.

Let's clarify exploitation.  This is a code dump (exploitative) with
another group (IBM folks + OOo folks) to accept responsibility for it
(counter-exploitative).

No exceptions are made to our process, changes to the language of the
the grant letter were not accepted.  The proposers submit their idea
to the incubator, just as all others must submit their ideas for the
incubator to consider, vote upon, mentor and guide, and hopefully,
graduate to a TLP.  No exceptions.

The code is not available to developers under a permissive license,
this offer is to incubate the code under a permissive license.  It has
willing committers, and mentors.

So what I'm asking is, what is the exploitation?  That is a charged
allegation.  I initially thought the same until I read all of the
background on the history and current composition of OOo consumers.


ASF members wish to devote considerable time and energy to this
project, so exactly who the hell are you to decide what they should
and shouldn't devote that time and energy to?

Um Bill you really should cool it a bit .. why are you getting so hot about
it? Phil too is a long standing member of the ASF and has every right to
comment on this!

Yes, if he will clarify what is exploitative, otherwise the post is FUD.

To be clear; OOo was not part of LO, although it was consumed by LO.
OOo has players which use the code differently and under more flexible
license than LO has.  If Oracle incorporated OOo as a 501(c) and granted
OOo an AL to all of the code and divested itself of the OOo foundation,
would that have been exploitative?  If not, then where is the exploitation
of the ASF facing the same prospects as an independent OOo organization?


I am just a volunteer who has seen the ASF struggle with
growth-related issues for several years now.  I think it is a fair
question to ask whether we should think about different / more
selective criteria for entrance to the incubator.  Sorry if asking
that question offends you.

+1. Those (esp. members) who find that question offensive need to take a
cold shower.

Or rather, the incubator needs to evaluate current proposals on its current
methodology, and (in a quiet time between proposals) generate more specific
criteria for incubation, independent of any particular proposal.  I just
find it rude to change the rules of the game during the match.

That is a fair point and I will shut up about this now, other than
to answer your question about exploitation that is germane to this
proposal.   One way to look at this proposal is to see it as an
attempt to use the ASF brand and infrastructure to fork a
community.  That is exploitative.


Disclaimer: I work for Oracle, but certainly don't speak for them and I 
knew nothing about this other than what i've read on these mailing lists...


However, it seems like we have lost sight of the fact that TDF split the 
community from OOo. Sure, Oracle is the perceived villain and TDF the 
perceived good guy, but it doesn't change the fact that OOo created the 
community in the first place.


Further, if it really is true that Oracle/IBM were in talks with TDF but 
could not come to agreement, then how is it even remotely possible to 
conclude that this proposal is an attempt to fork a community? Give me a 
break.


- richard


Other threads have argued both
sides of this fully.  People can come to their own conclusions. My
point was that we can't really assess this without getting clearer
on what we mean by exploitation and how much of it we are willing to
tolerate.  Again, read the post carefully and you will understand my
intent.

Phil

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




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



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

Re: OpenOffice: were are we now?

[Richard S. Hall]

On 6/6/11 10:41, Manfred A. Reiter wrote:

Hi Richard, *

2011/6/6 Richard S. Hallhe...@ungoverned.org

On 6/6/11 2:48, Phil Steitz wrote:

On 6/5/11 11:26 PM, William A. Rowe Jr. wrote:

On 6/6/2011 1:06 AM, Sanjiva Weerawarana wrote:

On Mon, Jun 6, 2011 at 11:17 AM, Phil Steitzphil.ste...@gmail.comwrote:


[...]


Disclaimer: I work for Oracle, but certainly don't speak for them and I knew 
nothing about this other than what i've read on these mailing lists...

However, it seems like we have lost sight of the fact that TDF split the 
community from OOo. Sure, Oracle is the perceived villain and TDF the perceived 
good guy, but it doesn't change the fact that OOo created the community in the 
first place.


Fact: Your employer provoked the split, by a absolute
non-communication on the existing mailinglist.
Now, to say that TDF has split the Communtiy is dishonest!


Forking splits communities. Whether you feel you had a justified reason 
for doing so does not change this fact. I am not weighing in on whether 
it is right or wrong in this case, since I think that is immaterial to 
where we are now.


I am only going by the facts as presented on the various Apache 
mailing lists. If it is true that TDF was engaged by Oracle/IBM before 
the Apache proposal, but failed to come to terms, then I cannot see how 
one can claim that the Apache proposal was merely an attempt to split 
the community.



Under these conditions, I'll change my entry in the wiki.


That's your call. I'm not trying to be offensive. I was just responding 
to someone else's statement of fact with my own. Don't let it bother 
you that people see things differently.


- richard


Best regards

Manfred, ex german Co-Lead OOo

-
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: OpenOffice: were are we now?

[Richard S. Hall]

On 6/6/11 10:33, Florian Effenberger wrote:

Hi,

Richard S. Hall wrote on 2011-06-06 16.19:


However, it seems like we have lost sight of the fact that TDF split the
community from OOo. Sure, Oracle is the perceived villain and TDF the
perceived good guy, but it doesn't change the fact that OOo created the
community in the first place.


wrong perception.

If a vast majority of the community steps away, because the main 
sponsor refuses to talk to them, amongst these community members *all* 
community council members who do not work for the main sponsor, plus 
nearly all other officials (i.e. leads or co-leads) from the 
community, you may allow the question who split and who is to blame.


If you don't believe that, feel free to have a look into the mailing 
list archives. And if the people in charge respected the community 
that much as you seem to suggest, then I wonder why the Apache 
proposal has not been discussed with this community in the first place.


I'm not sure what you mean. Did you want Oracle/IBM to discuss the 
Apache proposal with TDF before submitting it to Apache? Because 
otherwise, this is how proposals work, they get submitted and we discuss 
them, which is what we are doing.




So please stop spreading FUD like this. It won't help the further 
discussion here at all and just confirms the perception many of us had 
back in September: Some people simply do not have the slightest clue 
about communities. Or they *do* want to be blind.


Again, it was reported on this list that the parties could not come to 
terms, is this true or not? If so, then it is clear that there isn't a 
single community, because otherwise terms would have been reached. So, 
where is the FUD?


- richard



As said in my first mail: Do not look into the past. Look into the 
future.


Florian



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

Re: OpenOffice: were are we now?

[Richard S. Hall]

On 6/6/11 11:26, Simos Xenitellis wrote:

On Mon, Jun 6, 2011 at 6:02 PM, Richard S. Hallhe...@ungoverned.org  wrote:

On 6/6/11 10:41, Manfred A. Reiter wrote:

Hi Richard, *

2011/6/6 Richard S. Hallhe...@ungoverned.org

On 6/6/11 2:48, Phil Steitz wrote:

On 6/5/11 11:26 PM, William A. Rowe Jr. wrote:

On 6/6/2011 1:06 AM, Sanjiva Weerawarana wrote:

On Mon, Jun 6, 2011 at 11:17 AM, Phil Steitzphil.ste...@gmail.com
  wrote:


[...]


Disclaimer: I work for Oracle, but certainly don't speak for them and I
knew nothing about this other than what i've read on these mailing lists...

However, it seems like we have lost sight of the fact that TDF split the
community from OOo. Sure, Oracle is the perceived villain and TDF the
perceived good guy, but it doesn't change the fact that OOo created the
community in the first place.


Fact: Your employer provoked the split, by a absolute
non-communication on the existing mailinglist.
Now, to say that TDF has split the Communtiy is dishonest!

Forking splits communities. Whether you feel you had a justified reason for
doing so does not change this fact. I am not weighing in on whether it is
right or wrong in this case, since I think that is immaterial to where we
are now.


That's an example of denial. I do not see a conductive environment here
if such attitudes are tolerated.


I am only going by the facts as presented on the various Apache mailing
lists. If it is true that TDF was engaged by Oracle/IBM before the Apache
proposal, but failed to come to terms, then I cannot see how one can claim
that the Apache proposal was merely an attempt to split the community.


You should read more about free and open-source software, from diverse sources.
Get a lwn.net subscription.

Similar example, there was XFree86 long time ago that behaved just
like the Oracle developers.
Then, it was forked into X.Org and everyone moved to X.Org.
XFree86 is a distant memory.



Ok, forget the first part of what I originally said, since it doesn't 
really matter and apparently it prevents any discussion of the second 
part...


The second part was, was TDF actually engaged and failed to come to 
terms or not? That is what I've read, so I accepted this as true.


If so, do you actually believe the Apache proposal is just a stick in 
the eye of the TDF by Oracle/IBM because they were angry they couldn't 
come to terms? Or do you believe that because they couldn't come to 
terms they created this proposal to form their own community of 
like-minded people?


I would have to assume the latter, not the former.

- richard



Simos

-
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: OpenOffice: were are we now?

[Richard S. Hall]

On 6/6/11 13:50, Greg Stein wrote:

On Mon, Jun 6, 2011 at 13:37, Simos Xenitellis
simos.li...@googlemail.com  wrote:

On Mon, Jun 6, 2011 at 6:39 PM, Richard S. Hallhe...@ungoverned.org  wrote:

On 6/6/11 11:26, Simos Xenitellis wrote:

On Mon, Jun 6, 2011 at 6:02 PM, Richard S. Hallhe...@ungoverned.org
  wrote:

On 6/6/11 10:41, Manfred A. Reiter wrote:

Hi Richard, *

2011/6/6 Richard S. Hallhe...@ungoverned.org

On 6/6/11 2:48, Phil Steitz wrote:

On 6/5/11 11:26 PM, William A. Rowe Jr. wrote:

On 6/6/2011 1:06 AM, Sanjiva Weerawarana wrote:

On Mon, Jun 6, 2011 at 11:17 AM, Phil Steitzphil.ste...@gmail.com
  wrote:


[...]


Disclaimer: I work for Oracle, but certainly don't speak for them and I
knew nothing about this other than what i've read on these mailing
lists...

However, it seems like we have lost sight of the fact that TDF split
the
community from OOo. Sure, Oracle is the perceived villain and TDF the
perceived good guy, but it doesn't change the fact that OOo created the
community in the first place.


Fact: Your employer provoked the split, by a absolute
non-communication on the existing mailinglist.
Now, to say that TDF has split the Communtiy is dishonest!

Forking splits communities. Whether you feel you had a justified reason
for
doing so does not change this fact. I am not weighing in on whether it is
right or wrong in this case, since I think that is immaterial to where we
are now.


That's an example of denial. I do not see a conductive environment here
if such attitudes are tolerated.


I am only going by the facts as presented on the various Apache mailing
lists. If it is true that TDF was engaged by Oracle/IBM before the Apache
proposal, but failed to come to terms, then I cannot see how one can
claim
that the Apache proposal was merely an attempt to split the community.


You should read more about free and open-source software, from diverse
sources.
Get a lwn.net subscription.

Similar example, there was XFree86 long time ago that behaved just
like the Oracle developers.
Then, it was forked into X.Org and everyone moved to X.Org.
XFree86 is a distant memory.


Ok, forget the first part of what I originally said, since it doesn't really
matter and apparently it prevents any discussion of the second part...

The second part was, was TDF actually engaged and failed to come to terms or
not? That is what I've read, so I accepted this as true.


Double fault.

I suppose you rather wanted to say “TDF actually engaged [with Oracle]
[but the negotiations] failed to [to reach an agreement]”.

My personal interpretation:
1. Oracle wanted to give away OpenOffice.org, even transfer the copyrights.
2. The TDF is really happy to receive OpenOffice.org, as a copyleft
project (LGPLv3+MPLv2).
3. [lots of cheap speculation, 1p each] There might be an agreement
between IBM and Oracle/Sun
for access to the OOo source code for the proprietary Lotus Symphony,
so Oracle had to oblige to IBM
and go to the Apache Foundation. Or, less interestingly, ODF/OOo is a
huge investment inside IBM
that they would rather not relinquish control and ability to create
proprietary products.
4. A lot of people unhappy.

How about we drop these lines of discussion, and simply follow Ross'
advice and focus on what is needed by the Incubator PMC to accept
this proposal?


While I agree that a lot of this discussion is pointless, I guess it is 
just difficult to know where to precisely draw the line since my 
original response was to Phil Steitz (who is on the IPMC), where he at 
least implied if not directly stated that this proposal was exploitative 
and that was potential grounds for rejecting it.


The difficulty in discussing this is because there are so many emotional 
minefields (and probably rightly so) for those involved so it is easy 
for some people to assume the worst in what gets said/written. For me, I 
have no emotion invested in this at all. I'm just a user of OOo since 
2000 and a guy who likes the Apache license.


- richard


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

Re: OpenOffice: were are we now?

[Richard S. Hall]

On 6/6/11 14:26, Greg Stein wrote:

On Mon, Jun 6, 2011 at 14:17, Richard S. Hallhe...@ungoverned.org  wrote:

On 6/6/11 13:50, Greg Stein wrote:
...

How about we drop these lines of discussion, and simply follow Ross'
advice and focus on what is needed by the Incubator PMC to accept
this proposal?

While I agree that a lot of this discussion is pointless, I guess it is just
difficult to know where to precisely draw the line since my original
response was to Phil Steitz (who is on the IPMC), where he at least implied
if not directly stated that this proposal was exploitative and that was
potential grounds for rejecting it.

The difficulty in discussing this is because there are so many emotional
minefields (and probably rightly so) for those involved so it is easy for
some people to assume the worst in what gets said/written. For me, I have no
emotion invested in this at all. I'm just a user of OOo since 2000 and a guy
who likes the Apache license.

Agreed. Personally, I use OOo sparingly, as I prefer Google Docs. My
interest is largely spurred by the attraction of being able to apply
ALv2 to this awesome piece of software. I believe that will be a
*huge* enabler for the software world. It is vanishingly rare to have
such a situation. Epic might be a good word :-) ... and who
*doesn't* want to be part of something like that?


I couldn't have said it better myself... :-)

- richard


Cheers,
-g

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



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

Re: OpenOffice: were are we now?

[Richard S. Hall]

On 6/5/11 16:50, Jochen Wiedmann wrote:

On Sun, Jun 5, 2011 at 8:21 PM, Niall Pemberton
niall.pember...@gmail.com  wrote:


IMO the only negative thing then about LibreOffice is the copyleft
license - everything else about them is great. When deciding whether
to accept OO we should consider whether that and facilitating BigCos
interests is worth splitting the FOSS community.

I am considering voting -1 to this proposal for those reasons.

Thanks for expressing my feelings so well, Niall!


I'll lend a voice to the contrary.

I can't see why splitting a community should be a factor in entry to the 
incubator. Just about every new open source community is trying to pull 
away developers from another community doing similar stuff. That's the 
nature of the beast.


For me, getting the OOo code fully available under AL is reason enough 
to +1 it as far as I'm concerned...if I were on the IPMC... :-)


- richard


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

Re: OpenOffice: were are we now?

[Richard S. Hall]

On 6/5/11 6:45 PM, Niall Pemberton wrote:

On Sun, Jun 5, 2011 at 10:30 PM, Richard S. Hallhe...@ungoverned.org  wrote:

On 6/5/11 16:50, Jochen Wiedmann wrote:

On Sun, Jun 5, 2011 at 8:21 PM, Niall Pemberton
niall.pember...@gmail.comwrote:


IMO the only negative thing then about LibreOffice is the copyleft
license - everything else about them is great. When deciding whether
to accept OO we should consider whether that and facilitating BigCos
interests is worth splitting the FOSS community.

I am considering voting -1 to this proposal for those reasons.

Thanks for expressing my feelings so well, Niall!

I'll lend a voice to the contrary.

I can't see why splitting a community should be a factor in entry to the
incubator. Just about every new open source community is trying to pull away
developers from another community doing similar stuff. That's the nature of
the beast.

True, but when its essentially the same software, rather than
different software solving the same problem? If I proposed a new
project that was a fork of the HTTP project, how would that go down?


Of course they software is essentially the same because LO is a fork of 
what is being granted. If I wanted to experiment with an HTTP project 
that was going to go in a different direction and attract a different 
community from Apache HTTP Server, I assume I would be able to, even if 
I started as fork from the current HTTP Server code.


I don't think the proposal here is for OOo to enter incubation and then 
try to copy everything that TDF/LO does. I assume the proposers have a 
vision for where they want to go, even though they may be starting from 
the same place.


Seems this is what the incubator is for, finding out if their vision 
hold water.


- richard


For me, getting the OOo code fully available under AL is reason enough to +1
it as far as I'm concerned...if I were on the IPMC... :-)

License is important, but thats not all the ASF is about. Community is
important too. I respect you're right to vote however you wish but if
all its down to is license then I'm not sure.

Niall



-  richard

-
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: OpenOffice: were are we now?

[Richard S. Hall]

On 6/5/11 7:38 PM, Richard S. Hall wrote:

On 6/5/11 6:45 PM, Niall Pemberton wrote:
On Sun, Jun 5, 2011 at 10:30 PM, Richard S. 
Hallhe...@ungoverned.org  wrote:

On 6/5/11 16:50, Jochen Wiedmann wrote:

On Sun, Jun 5, 2011 at 8:21 PM, Niall Pemberton
niall.pember...@gmail.comwrote:


IMO the only negative thing then about LibreOffice is the copyleft
license - everything else about them is great. When deciding whether
to accept OO we should consider whether that and facilitating BigCos
interests is worth splitting the FOSS community.

I am considering voting -1 to this proposal for those reasons.

Thanks for expressing my feelings so well, Niall!

I'll lend a voice to the contrary.

I can't see why splitting a community should be a factor in entry to 
the
incubator. Just about every new open source community is trying to 
pull away
developers from another community doing similar stuff. That's the 
nature of

the beast.

True, but when its essentially the same software, rather than
different software solving the same problem? If I proposed a new
project that was a fork of the HTTP project, how would that go down?


Of course they software is essentially the same because LO is a fork 
of what is being granted. If I wanted to experiment with an HTTP 
project that was going to go in a different direction and attract a 
different community from Apache HTTP Server, I assume I would be able 
to, even if I started as fork from the current HTTP Server code.


I don't think the proposal here is for OOo to enter incubation and 
then try to copy everything that TDF/LO does. I assume the proposers 
have a vision for where they want to go, even though they may be 
starting from the same place.


Seems this is what the incubator is for, finding out if their vision 
hold water.


For me, getting the OOo code fully available under AL is reason 
enough to +1

it as far as I'm concerned...if I were on the IPMC... :-)

License is important, but thats not all the ASF is about. Community is
important too. I respect you're right to vote however you wish but if
all its down to is license then I'm not sure.


One other point to make, I said for me it is basically sufficient to +1 
this proposal just to get all of the OOo code under AL. One reason why I 
see this as adding significant value is because it opens up a 
possibility (I won't say freedom, since this is far too noble of a 
term for the crap we are talking about) to modify and use the code in 
proprietary products that wouldn't otherwise exist if only LO existed. 
Again, this last issue is just my opinion, not out of any religion, but 
for the possibilities that may arise because of it...who knows, maybe 
one day I might come up with an idea that could use some of the code... 
;-) It's always nice to have options.


- richard



Niall



-  richard

-
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: OpenOffice: were are we now?

[Richard S. Hall]

On 6/5/11 7:49 PM, Simon Phipps wrote:

On Mon, Jun 6, 2011 at 12:38 AM, Richard S. Hallhe...@ungoverned.orgwrote:


I don't think the proposal here is for OOo to enter incubation and then try
to copy everything that TDF/LO does. I assume the proposers have a vision
for where they want to go, even though they may be starting from the same
place.


I'm not clear how safe that assumption is - that's what I have been waiting
to see explained for quite a while actually. Rob has been strong on
long-term abstract vision (clearly more omniscient than me), but any time
specifics of what (  how) is going to happen in the immediate future in
terms of maintaining the important consumer end-user presence OpenOffice.org
delivers, things get pretty fuzzy and hand-wavey.


Even if the answer is, We don't have a short-term plan for all of the 
consumers. I don't really see that as some smoking gun that says they 
can't enter incubation. Granted, it would be nice if the brand weren't 
hurt in the process, but at the same time I don't see how we can hold an 
incubator project accountable for all of that...even if it is their goal 
to do so.


- richard


S.



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

Re: OpenOffice.org: Question to IBM regarding license of Lotus Symphony

[Richard S. Hall]

On 06/04/2011 09:40 AM, Andreas Kuckartz wrote:

Another possible consequence of that option would be that both die.


Which is a possible consequence of any software...

How many times can we go around in circles? I agree with Ian. Accept 
that there are two communities and move on either together or 
separately, but quit debating/wishing that there should only be one 
community.


- richard


Cheers,
Andreas
---

Am 04.06.2011 15:10, schrieb Ian Lynch:

1. TDF and LO goes its own way completely separate from Apache/OOo.

...

Possible consequences of Option 1.  ApacheOOo gets insufficient

support and

stagnates, TDF LO carry on developing what becomes the main used code

base.

Or ApacheOOo attracts developers from TDF and it thrives and TDF dies. Or
both thrive as two separate projects in their own right.


-
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: OpenOffice.org Apache Incubator Proposal: Are we required to make everyone happy?

[Richard S. Hall]

On 6/2/11 11:40, Davide Dozza wrote:

Robert,

Il 02/06/2011 17:11, robert_w...@us.ibm.com ha scritto:

Despite TDF press releases, there was never unanimous support for
LibreOffice among members of the OpenOffice.org community.  We're seeing
some of them stand up now and be counted.

As OOo italian native lang maintainer and TDF supporter I don't really
understand why you keep minimizing and ridiculizing TDF and what they
have done instead to try to understand how they can be useful for the
project.


As a complete outsider, I didn't read Robert's quoted comment as 
ridiculing TDF. From my understanding, he was just saying that TDF 
wasn't exactly what he wanted in an OOo fork, so he is pursuing this 
fork because it more suits his needs and the needs of some other 
members in the OOo community. I don't think this is ridicule, it is just 
the very nature of forking in the open source world and what makes it 
so great, right?


When the original OOo project wasn't working well, the community forked 
to create TDF. So, for some people, TDF still isn't working well for 
them and they want to create something else. That's just the nature of 
open source and is nothing to worry about...let a thousand flowers bloom 
and let the users decide.


- richard


People from ASF are trying to build a bridge while you keep to destroy
any tentative.

Don't you think it will be a great value *at least* to try to build a
fruitful collaboration?
Reading your blog, I can understand your critics but why don't try a
step back and let it be a chance?

Davide











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

Re: [VOTE] Accept Wave into the incubator

[Richard S. Hall]

+1

- richard

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

Re: [PROPOSAL] Boot strapping Android projects @ Apache

[Richard S. Hall]

+1

- richard


On 11/9/10 10:13, Noel J. Bergman wrote:

About a half dozen or so of us met up at ApacheCon after the lightning talks
to talk briefly about Android @ the ASF.

The proposal is to create an android-inter...@i.a.o (we also thought about
@labs, but the general consenus seemed to be the Incubator due to some of
the Labs' restrictions, which we think are good restrictions).

We want to encourage others working on Android-related code to share
experience and existence with their fellow Committers.  For example, did you
know that Felix  Aries already work with Android?  What else does?  What
else should?  Etc.

In other words, we want to provide a gathering point for all of the people
working in isolation -- to provide a meeting place for those intersted in
expanding Android-based activity at the ASF.  It is not so much an umbrella
as a vital nexus, and breeding ground for importing or creating projects,
which would then stand on their own.

--- Noel



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



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

Re: [PROPOSAL] Boot strapping Android projects @ Apache

[Richard S. Hall]

On 11/9/10 13:20, Noel J. Bergman wrote:

One other project that already works on Android is Apache ACE

Sorry, I meant ACE when I said Aries.


And here I was thinking how cool it was that those EE guys were still 
thinking about the mobile phone space... :-o


- richard


--- Noel


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



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

Re: [VOTE] Accept Celix for incubation

[Richard S. Hall]

+1

- richard


On 10/28/10 15:42, Marcel Offermans wrote:

After the initial discussions about Celix have finished, we now have three 
mentors and would like to call a vote to accept Celix into the Apache Incubator.

The proposal is included below and can also be found at:
http://wiki.apache.org/incubator/CelixProposal

Please cast your votes:

[ ] +1 Accept Celix for incubation
[ ] +0 Don't care
[ ] -1 Reject for the following reason:

Greetings, Marcel



Celix

= Abstract =
Celix is a OSGi like implementation in C with a distinct focus on 
interoperability between Java-OSGi and Celix.

= Proposal =
Celix will be an implementation of the OSGi specification adapted to C. It will 
follow the API as close as possible, but since the OSGi specification is 
written primarily for Java, there will be differences (Java is OO, C is 
procedural).
An important aspect of the implementation is interoperability between Java-OSGi 
and Celix. This interoperability is achieved by porting and implementing the 
Remote Services specification in Celix. These Services will be made available 
in separate bundles.

= Background =
In embedded/realtime situations software is mostly implemented in C. In 
situations where interoperability and dynamics are important, a good 
architecture and design principle is needed. OSGi provides such middleware for 
Java based systems.
To be able to have such dynamic environment implemented in C, a OSGi like 
implementation is needed. Besides a dynamic environment, OSGi also makes it 
easier to reuse parts of the system, reducing time needed to implement and 
maintain software.
The implementation started with the basics to make it possible to load 
libraries dynamically, and steadily grown towards an implementation where large 
parts of the OSGi framework API is implemented.
The implementation of Celix is heavily based on Apache Felix (where appropriate 
it is even a direct port of the Apache Felix code (Java) to C).
Since distributed systems are used more and more in services based 
environments, a scalable and transparent solution is needed for remote 
communication. The OSGi specification describes remote services, this 
specification will be a part of the first release.
Remote services also make it possible to communicate between Java-OSGi and 
Celix. To achieve this interoperability, both Java and C implementations of 
remote services for a common protocol are needed. For local services JNI can be 
used, for remote services SOAP and/or REST can be used. In the latter case, 
Apache CXF can be used to implement the Remote Services API in Java.

= Rationale =
In embedded/realtime/distributed environments there is a need to be able to 
create dynamic and maintainable software. Currently there are no off the shelf 
middleware/frameworks for this. Celix tries to provide such a framework.
The choice to base the implementation on the OSGi specification makes it 
possible for a developer to use Celix as well as Java OSGi implementation 
without much differences and without a steep learning curve.
The community and user driven platform created by Apache provides a great base 
for middleware such as Celix. Also the fact that Celix is based on Apache 
Felix, and Apache Felix is hosted by Apache, makes it a logical choice to have 
Apache as home for this project.

= Initial Goals =
 * Provide a basic implementation of the OSGi Framework API
 * Provide an implementation of Remote Services to be able to create distributed 
systems (and Celix-  OSGi interoperability).
 * Build/Expand a community using/developing Celix
 * OSGi like implementation in C
 * Provide a module/component based software solution for embedded Platforms
   o Real-Time software
   o Distributed systems
   o Provide Services based solution
 * Investigate if Apache Portable Runtime can be used for platform 
abstraction

= Current Status =
== Meritocracy ==
Celix was created by Alexander Broekhuis. While he is no active 
committer/participant of Apache projects, he has used Open Source and is well 
known with it and how a meritocracy works. Currently there are several other 
possible committers.
To be able to create and maintain complex middleware (such as Celix) a good 
structure is needed. A meritocracy following the rules and traditions of the 
ASF is a good choice for Celix.

== Community ==
Currently the Celix community exists out of the core developers, and the users 
integration Celix in an end-user product (all from Thales).

== Core Developers ==
 * Alexander Broekhuis (Luminis)
 * Jasper Gielen (Humiq)
 * Herman ten Brugge (Thales)

== Alignment ==
Celix is heavily based on Apache Felix. Since Apache Felix is an Apache project 
it makes sense to develop Celix under Apache.
Also, Celix is a complex and large middleware project, it makes sense to have a 
supporting/developing community. Apache provides a solid base, with established 
processes and rules, to create such 

Re: [PROPOSAL] Celix to enter the Incubator

[Richard S. Hall]

 I think this is interesting. However, I'd like to point out that you 
may need to take care in how you position this. I believe the OSGi specs 
allow for compliant open source implementations, but it is unlikely this 
implementation will ever be fully compliant. So, you'd probably be best 
to just position it as a C-based module system that provides OSGi 
interoperability.


And definitely don't call the mailing lists cosgi anything. :-)

- richard


On 9/24/10 10:45, Alexander Broekhuis wrote:

Hello,

I would like to announce  the following proposal as a new incubator project.
Abstract

Celix is a OSGi like implementation in C with a distinct focus on
interoperability between Java-OSGi and Celix.
Proposal

Celix will be an implementation of the OSGi specification adapted to C. It
will follow the API as close as possible, but since the OSGi specification
is written primarily for Java, there will be differences (Java is OO, C is
procedural).
An important aspect of the implementation is interoperability between
Java-OSGi and Celix. This interoperability is achieved by porting and
implementing the Remote Services specification in Celix. These Services will
be made available in separate bundles.
Background

In embedded/realtime situations software is mostly implemented in C. In
situations where interoperability and dynamics are important, a good
architecture and design principle is needed. OSGi provides such middleware
for Java based systems.
To be able to have such dynamic environment implemented in C, a OSGi like
implementation is needed. Besides a dynamic environment, OSGi also makes it
easier to reuse parts of the system, reducing time needed to implement and
maintain software.
The implementation started with the basics to make it possible to load
libraries dynamically, and steadily grown towards an implementation where
large parts of the OSGi framework API is implemented.
The implementation of Celix is heavily based on Apache Felix (where
appropriate it is even a direct port of the Apache Felix code (Java) to C).
Since distributed systems are used more and more in services based
environments, a scalable and transparent solution is needed for remote
communication. The OSGi specification describes remote services, this
specification will be a part of the first release.
Remote services also make it possible to communicate between Java-OSGi and
Celix. To achieve this interoperability, both Java and C implementations of
remote services for a common protocol are needed. For local services JNI can
be used, for remote services SOAP and/or REST can be used. In the latter
case, Apache CXF can be used to implement the Remote Services API in Java.
Rationale

In embedded/realtime/distributed environments there is a need to be able to
create dynamic and maintainable software. Currently there are no off the
shelf middleware/frameworks for this. Celix tries to provide such a
framework.
The choice to base the implementation on the OSGi specification makes it
possible for a developer to use Celix as well as Java OSGi implementation
without much differences and without a steep learning curve.
The community and user driven platform created by Apache provides a great
base for middleware such as Celix. Also the fact that Celix is based on
Apache Felix, and Apache Felix is hosted by Apache, makes it a logical
choice to have Apache as home for this project.
Initial Goals

- Provide a basic implementation of the OSGi Framework API
- Provide an implementation of Remote Services to be able to create
distributed systems (and Celix-  OSGi interoperability).
- Build/Expand a community using/developing Celix
- OSGi like implementation in C
- Provide a module/component based software solution for embedded
Platforms
   - RealTime software
   - Distributed systems
   - Provide Services based solution
- Investigate if Apache Portable Runtime can be used for platform
abstraction

Current Status Meritocracy

Celix was created by Alexander Broekhuis. While he is no active
committer/participant of Apache projects, he has used Open Source and is
well known with it and how a meritocracy works. Currently there are several
other possible committers.
To be able to create and maintain complex middleware (such as Celix) a good
structure is needed. A meritocracy following the rules and traditions of the
ASF is a good choice for Celix.
Community

Currently the Celix community exists out of the core developers, and the
users integration Celix in an end-user product (all from Thales).
Core Developers

- Alexander Broekhuis (Luminis)
- Jasper Gielen (Humiq)
- Herman ten Brugge (Thales)

Alignment

Celix is heavily based on Apache Felix. Since Apache Felix is an Apache
project it makes sense to develop Celix under Apache.
Also, Celix is a complex and large middleware project, it makes sense to
have a supporting/developing community. Apache provides a solid base, with
established processes and 

Re: Interest in Android-based projects?

[Richard S. Hall]

I think it'd be cool. I have been wanting to find the time (yeah, right) 
to do some Android programming...I'd love to replace their contact 
manager with a better one...


- richard

On 2/16/10 4:56 AM, Noel J. Bergman wrote:

Would there be interest in a project to develop Android-based apps?

know that it sounds like an umbrella, and perhaps it would be until we
developed some critical mass, but it would provide us with a place to
collaborate.

--- Noel



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

   


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

Re: [PROPOSAL] Chatterbot, a lightweight framework for chat responders

[Richard S. Hall]

On 1/29/10 10:38, Donald Whytock wrote:

I have an overview of the current Chatterbot architecture at

http://www.imtower.net/chatterbot/doku.php?id=overview

Chatterbot is different from JMS inasmuch as it's currently built to
receive messages from chat IDs and turn them into messages from
Chatterbot-internal IDs, and vice versa.  My intent was to allow
multiple chat IDs (same protocol or different protocols) to translate
into a single Chatterbot ID, so that a user could choose how he
accessed the bot.  Which protocol a message comes in over should be
totally transparent to the Parsers, and the Parsers should be able to
send messages out using Chatterbot IDs and not worry what protocol is
used to deliver them.

Looking briefly over Felix (http://felix.apache.org), I'd say the
Chatterbot Listener and Parsers would be equivalent to the Felix Shell
and Commands, if the Shell was fed a JMS stream consolidated from
multiple message streams, and if its output was then dispersed over
multple message streams.  Though there would also need to be a way to
set up a Command to respond to any input string, rather than one
starting with a particular word.
   


Just to be clear, there are two shells at Felix:

http://felix.apache.org/site/apache-felix-shell.html

And

http://felix.apache.org/site/apache-felix-gogo.html

Although they basically do the same thing, I think Christopher was 
referring to the latter shell, which is more sophisticated than the 
former and may eventually become and OSGi standard.


- richard


Chatterbot Parsers also have the capacity to originate messages to
users other than the one whose message the Parsers are responding to,
so that they can serve as chatrooms; this would be the equivalent of
Felix sending out notifications to other users when a given user
performed a command.  Would this compare to Felix Event Admin?

That pretty much just leaves the global namespace, which is
essentially volatile JDO.  This is where the Chatterbot IDs are stored
and the Modules are defined; it gets updated by Channels, and can be
referenced and updated by Parsers.  I've implemented that as a TreeSet
of TreeSets, due to the key structure, but of course the internal
structure of the namespace is largely transparent to the modules.

So all in all I'd say there's no inherent barrier to building
Chatterbot with Felix.  Especially if it'll still run off my USB
drive.

Don

On Fri, Jan 29, 2010 at 3:44 AM, Christopher Brindbri...@brindy.org.uk  wrote:
   

Hi,

I have read through the proposal and I like the idea of it.

The only issues I have are around modularity and shell/console.  Apache
already has a modularity solution (Felix) based on an open standard (OSGi) I
don't think the Java community as a whole needs yet another modularity
solution. =)   Felix also provides a shell which allows you to manage module
(bundle) lifecycle (install, start, stop, update, uninstall) and while I
don't know what the status is regarding the 'Standard Shell' (OSGi RFC 132)
it is quite easy to add new commands to the Felix shell.   Felix is also
very lightweight, so it wouldn't add much to your footprint, but would give
you a sophisticated dynamic module contain in which to work as well as
making it compatible with various environments already using OSGi now (e.g.
Application Servers, etc).

I could see potential uses for this project in my own work, but as I've
implied, it would have to be compatible with OSGi which is where I spend
most of my time.  I'd even offer to assist that effort on this project.

This is more of a question, is there any Java API standard abstraction for
chat protocols?  e.g. javax.chat?  I don't think there is but there is of
course JMS, is ChatterBot significantly different from JMS?  If so, perhaps
a low priority side goal of the project should be to develop a standard Java
API standardisation for chat?

Cheers,
Chris


On 29 January 2010 03:32, Donald Whytockdwhyt...@gmail.com  wrote:

 

Hello all...

As discussed before, here is the current wiki text of the proposal for
Chatterbot, a lightweight framework for chat responders.  The proposal
is at

http://wiki.apache.org/incubator/ChatterbotProposal

Interested in comments, feedback and participation.

Thanks...

Don

- wiki text -

Abstract

ChatterBot is a lightweight, multiprotocol framework and container for
chat responders.

Proposal

ChatterBot is a framework for developing chat responders (applications
that respond to messages received via online chat) and a container for
deploying them. It is written in Java SE, and runs as a Java
application. Chat responders are built by extending a single class and
modifying a configuration file to reference the new class.
ChatterBot's focus is on the following characteristics:

- Small: The current framework consists of eight core classes.

- Standalone: ChatterBot does not require external servers to operate.

- Portable: ChatterBot should work as run from any Java-capable
machine. For full 

[IP CLEARANCE] User Admin contribution to Felix

[Richard S. Hall]

Adam Wojtuniak contributed an implementation of the OSGi User Admin 
specification to Felix. This message is a request for IP clearance 
verification. The pertinent information is here:


http://incubator.apache.org/ip-clearance/felix-user-admin.html

Thanks.

- richard

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

Re: [IP CLEARANCE] User Admin contribution to Felix

[Richard S. Hall]

Thanks.

- richard

On 12/1/09 15:27, Robert Burrell Donkin wrote:

On Tue, Dec 1, 2009 at 8:13 PM, Richard S. Hallhe...@ungoverned.org  wrote:
   

Adam Wojtuniak contributed an implementation of the OSGi User Admin
specification to Felix. This message is a request for IP clearance
verification. The pertinent information is here:

http://incubator.apache.org/ip-clearance/felix-user-admin.html
 

took a quick look and everything seems in order but approval is lazy
if there any problem i've missed hopefully someone will jump in...

- robert

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

   


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

Re: [PROPOSAL][VOTE] Subversion

[Richard S. Hall]

+1

- richard

On 11/4/09 15:50, Felix Meschberger wrote:

+1

Regards
Felix

Greg Stein schrieb:
   

  Subversion is a version control system.  You probably know it well as
it is the version control system employed by the Apache Software
Foundation.

  The Subversion project would like to join the Apache Software
Foundation to remove the overhead of having to run its own
corporation.  The Subversion project is already run quite like an
Apache project, and already counts a number of ASF Members amongst
its committers.

  Work on Subversion was originally started at CollabNet; Karl Fogel
was hired in January 2000.  Jim Blandy, at RedHat, already had an
initial design for the storage system, which was incorporated into the
FS design.  In February Brian Behlendorf invited Greg Stein to
contribute his WebDAV experience to Subversion.  Ben Colins-Sussman
was hired in April 2000 to work on the project.  In that same month
the first all hands meeting was held, where a number of interested
people came together to talk about the project.

  Subversion was run as an open source project since the early days.
Now, more than nine years later, it retains a healthy community,
and has a good number of committers.  In the life span of Subversion,
several committers have switched employers and have maintained involvement.
The committership is diverse, both geographically as well as in terms of
employment.

  The equivalent of the PMC consists of all the full committers to the
Subversion project (currently around 55 people).  The community uses the
voting process also used at the ASF.  Releases are signed off by gathering
votes/digital signatures of each committer who verified the release
candidate.

  We feel the ASF and Subversion communities are very compatible,
witness the cross interest that already exists. There is both a
vibrant developer as well as a large and active user community.
Technology-wise, Subversion builds on APR, and implements two Apache
HTTP Server modules.

  Note that Subversion has a number of related projects, which are not
part of this proposal (e.g. cvs2svn, TortoiseSVN, Subclipse).

  More information on Subversion can be found at
http://www.subversion.org/ and http://subversion.tigris.org/.

  The Subversion Corporation has a license to all source code, and has
CLAs on file for nearly all it's committers.  That is, we have all but
one or two full committers, and some percentage of partial committers.

  We have a number of *user-configurable* dependencies which are not
compatible with the AL:
  - Neon, a HTTP client library, used by libsvn_ra_neon, is LGPL.
(An alternative HTTP client library, libsvn_ra_serf uses the Serf
 library under ALv2.)

  - Qt, KDE and GNOME libraries are also under LGPL-2.1. D-Bus (which
is also used by libsvn_auth_gnome_keyring and libsvn_auth_kwallet) is
under Academic Free License 2.1 or=GPL-2.
(This support is for integration for KDE and GNOME's authentication
 providers.)

  - libintl
(This library provides translation support for systems without
 a proper internationalization library.)

  - BDB
(This is used by the libsvn_fs_base system which stores its data
 in BDB; an alternative repository system called fs_fs does not
 have this dependency.)

---
Required Resources
  - Mailing lists
- dev
- issues
- users
- private
- commits
- announce
- breakage (see
http://subversion.tigris.org/ds/viewForumSummary.do?dsForumId=552)
- We will work with the Infrastructure team to transfer the subscriber
  listings to the new destinations.
  - Subversion:
- We have not made a decision whether we prefer Subversion should be
  imported into the main ASF Subversion repository or be hosted as a
  separate repository to enable early testing of the repository code.  We
  intend to discuss this during the Incubation process before the code is
  imported.  It is also understood that ASF infrastructure team may be
  willing to run custom pre-release Subversion server builds for the
  entire ASF, so this separate repository option may not be required.
- The Subversion source code can be found at:
  http://svn.collab.net/repos/svn/.
  - Issue tracking
- We haven't made a decision between JIRA or Bugzilla at this time and
  expect this decision to be made as part of the Incubation process.  Our
  current issue tracking system uses Issuezilla (a fork of Bugzilla) and
  we have not yet decided whether we want to import our previous issues
  into the new system and will decide this in the course of the Incubation
  process.
- Our current issue tracker is at
  http://subversion.tigris.org/issue-tracker.html.
  - Buildbot
- We currently use buildbot across a number of platforms and configurations
  for automated builds and testing.  Over time, we would like to migrate
  these services to Apache infrastructure where appropriate.
- Our 

Re: [IP CLEARANCE] Apache Felix Improved Http Service

[Richard S. Hall]

On 9/7/09 17:41, Felix Meschberger wrote:

Hi,

Richard S. Hall schrieb:
   

We need the software grant on file for this, did I miss it?
 

The grant has been recorded and I have updated the IP-Clearance page [2]
   


Great, I see it has been recorded. So, I guess the 72 hour IP clearance 
starts now...


- richard


Regards
Felix

   

-  richard

On 9/4/09 7:25, Felix Meschberger wrote:
 

Hi,

The Apache Felix project has received a contribution of an Improved OSGi
   HttpService implementation

* The code is attached to the FELIX-1456 JIRA issue [1]

* The IP Clearance form has been committed to the Incubator website. [2]

* A vote has passed on the d...@felix mailing list [3]

The clearance passes by lazy consensus if no -1 votes are cast within
the next 72 hours.

Thanks and Regards
Felix

[1] https://issues.apache.org/jira/browse/FELIX-1456
[2] http://incubator.apache.org/ip-clearance/felix-httpservice.html
[3] http://www.mail-archive.com/d...@felix.apache.org/msg11895.html


   
 


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

Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi

[Richard S. Hall]

On 9/5/09 13:36, Niall Pemberton wrote:

On Wed, Sep 2, 2009 at 3:30 PM, Richard S. Hallhe...@ungoverned.org  wrote:
   

I will try to keep this short.

The OSGi Service Platform is composed of the core and compendium specs. The
EEG specs are not in any way special and will ultimately end up as part of
the compendium spec. Apache Felix was incubated to build a community at
Apache around implementing the OSGi specs.

Now we are being told that this mission is too tainted because we implement
the framework spec, which is part of the core spec. I find this unfathomable
given the nature of OSGi and the efforts to which the Felix community goes
to be good OSGi citizens...we even allow for competing implementations
within our community.

It is also particularly odd, since the Equinox and Knopflerfish communities
are in the same situation, implementing both core and compendium specs with
their frameworks largely synonymous with their project name.

I am not naive enough to expect this discussion to change much, since I
imagine there has already been a fair amount of political calculation around
this proposal, otherwise the Felix community in general would have been
engaged earlier.

So, here's my vote:

   * -1 for the portion of the proposal creating yet another community
 for implementing OSGi specs at Apache since the Felix community
 would happily welcome more contribution (just like recently
 occurred with ServiceMix members being accepted as Felix
 committers and PMC members for the Karaf subproject)
 

Voting against a bunch of people forming a new community here at the
ASF is v.disappointing and goes against what IMO the ASF is all about.
   


It is also very disappointing to have my position mischaracterized, 
since I have been pretty consistent:


   I support the creation of a new community around an EE component
   model for OSGi and OSGi specs dependent upon this technology;
   however, I believe the Felix project is the best choice to work on
   independent OSGi specs since we have been doing it for years and it
   would guarantee cross-project collaboration.

If you find this position disappointing, then I am not sure what to say. 
On the other hand, if you just disagree with it, that's fine, since I 
disagree too. And it is my understanding that this is the forum to 
discuss disagreements about project proposals.


One thing we can all agree on, is this thread is rather tiresome, so 
let's move on.


- richard



If the Felix community wants to get involved with their efforts then
great, if not then don't try to block what they want to do. As others
have said there are various options for graduation, but I think you've
made Felix less rather than more likely by your antagonism to this
proposal.

I'm +1 to this proposal and hoping Felix members with shared interests
get involved.

Niall

   

   * +1 for the rest of the proposal to explore how to build an
 enterprise component model on OSGi and the other non-spec related
 topics.

-  richard


On 9/1/09 22:53, Kevan Miller wrote:
 

On Sep 1, 2009, at 2:08 PM, Richard S. Hall wrote:

   

On 9/1/09 13:59, Martin Cooper wrote:
 

On Tue, Sep 1, 2009 at 10:51 AM, Richard S. Hallhe...@ungoverned.org
  wrote:

I'm not sure I understand the issue here. Whether Aries becomes its
own TLP, or a sub-project of Felix or some other TLP, isn't relevant
until the project is ready to exit incubation. Why does it warrant
such apparently intense discussion before the project is even accepted

   

We are actually discussing something else. We are discussing the scope of
the proposal, which includes hosting OSGi standard service implementations,
which is part of Felix' scope.

If we are developing standard OSGi services within Apache, then Felix
provides an enthusiastic community to do this and there is no need to start
another incubator project for such a purpose. On the other hand, stuff like
a set of pluggable Java components enabling an enterprise OSGi application
programming model makes perfect sense to be incubated.
 

Thanks for the clarification... So, your issue is mainly with It is a
goal of the Aries project to provide a natural home for open source
implementations of current and future OSGi EEG specifications...?
Personally, I tend to think of Felix in terms of OSGi Core Platform. I
certainly hadn't expected it to be the source for all OSGi standard
implementations from Apache -- not for implementations of Enterprise Expert
Group specs, anyway. I'm sure there are flaws with my perceptions...

So, we have a group that is interested in working on an enterprise OSGi
application programming model at Apache (including implementations of at
least some EEG specifications). An incubator project would seem to be an
excellent place for this work to start. Interested Felix community members
would certainly be able to join this effort.

It then becomes a question of, assuming successful incubation

Re: [IP CLEARANCE] Apache Felix Improved Http Service

[Richard S. Hall]

We need the software grant on file for this, did I miss it?

- richard

On 9/4/09 7:25, Felix Meschberger wrote:

Hi,

The Apache Felix project has received a contribution of an Improved OSGi
  HttpService implementation

* The code is attached to the FELIX-1456 JIRA issue [1]

* The IP Clearance form has been committed to the Incubator website. [2]

* A vote has passed on the d...@felix mailing list [3]

The clearance passes by lazy consensus if no -1 votes are cast within
the next 72 hours.

Thanks and Regards
Felix

[1] https://issues.apache.org/jira/browse/FELIX-1456
[2] http://incubator.apache.org/ip-clearance/felix-httpservice.html
[3] http://www.mail-archive.com/d...@felix.apache.org/msg11895.html

   


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

Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi

[Richard S. Hall]

On 9/4/09 9:05, Daniel Kulp wrote:

As a point of note, not all OSGi spec implementations live in Felix even at
Apache today.   The Remote Services/Distributed OSGi reference implementation
is a sub project of CXF. I think Tuscany has an implementation as well.

So far, there hasn't been any discussion about moving those into Felix.  Your
argument below makes it sound like they should be.
   


Actually, I had conversations with the CXF/DOSGi team at IONA during its 
development. We discussed the technological approach as well as the 
potential home. My position was/is:


  1. If it is tied to CXF and it not generally useful without it, then
 it is reasonable for it to be hosted at CXF.
  2. If it is completely general and of interest to a general user, not
 just a CXF user, then it is reasonable for it to be hosted at Felix.

Since they felt it was fairly specific to CXF, that's where it ended up.

So, no, I am not saying everything should, but in general, it would be 
nice if the spec impls started there since we have a community of OSGi 
users and OSGi experts who are very active and receptive, many of whom 
also work in the EE space.


In short, it makes sense for spec impls tied to the Aries component 
model (for example), to be hosted there, but there is little need to 
create another project to incubate generic OSGi spec impls, since the 
Felix community was set up for that. The reality is, most OSGi specs are 
not huge projects so we likely wouldn't want TLPs for all of them, but 
nothing stops a subproject started at Felix from going TLP if it takes 
on a life of its own.


- richard


Dan


On Thu September 3 2009 1:33:04 pm Richard S. Hall wrote:
   

There was no attempt to contact the Felix PMC in general that I am aware
and I certainly didn't know about it in advance.

And there seems to be a continued attempt to construe my original
criticisms as all of Aries should go into Felix.

I, personally, do not believe that all of Aries should go into Felix, I
too think it should have its own identity. I was always only ever
referring to the independent OSGi spec implementations. I was arguing
that Felix is a good place to work on them, since it is part of what it
is trying to achieve.

Further, I don't really understand the implication that somehow the
burden is now on the Felix community to go and contribute to Aries on
OSGi spec implementations just because of this proposal, when there was
no attempt to work with the Felix community on creating OSGi spec
implementations in the first.

The only conclusions I see being drawn by people who have invested very
little in Felix is that we should dismantle the Felix charter so that we
can accommodate the fact that some people don't want to play with us.

At that rate, I stand by my previous vote and otherwise people can do
whatever they want in Aries.

-  richard

On 9/3/09 13:23, Niclas Hedhman wrote:
 

Kevan,

Was a contact with Felix made prior to dropping the proposal here? I got
the impression that wasn't the case, which I find surprising... If I am
wrong, what was the meat of such?

I'm also less happy with the rhetoric here repeated over and over,
seemingly uninterested in discussion of reaching a solution everyone can
accept. (From both camps, btw)

-- Niclas

On Sep 4, 2009 12:53 AM, Kevan Millerkevan.mil...@gmail.com   wrote:

On Sep 3, 2009, at 12:53 AM, Niclas Hedhman wrote:   On Thu, Sep 3, 2009
at 3:19 AM, William A. Ro...
Totally agree. Had certainly hoped that Felix committers would be
interested in joining...

--kevan

- To
unsubscribe, e-mail: gene...
   

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

 
   

Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi

[Richard S. Hall]

On 9/4/09 16:10, Davanum Srinivas wrote:

Richard,

On 09/04/2009 03:49 PM, Richard S. Hall wrote:

So, no, I am not saying everything should, but in general, it would be
nice if the spec impls started there since we have a community of OSGi
users and OSGi experts who are very active and receptive, many of whom
also work in the EE space.


Will the people mentioned not participate if Aries is a separate 
podling to start with? After all destination PMC can be determined 
during graduation process. Also the incubation process is to show new 
incoming team how Apache works etc..is that better done as a podling 
or as a felix sub project? If we continue the same thought process, 
will there every be any incubator podling with for any OSGi related 
activity?


Yes, and I mentioned this, but that seems to get lost somehow.


In short, it makes sense for spec impls tied to the Aries component
model (for example), to be hosted there, but there is little need to
create another project to incubate generic OSGi spec impls, since the
Felix community was set up for that. The reality is, most OSGi specs are
not huge projects so we likely wouldn't want TLPs for all of them, but
nothing stops a subproject started at Felix from going TLP if it takes
on a life of its own.


Choices are

1) Podling - TLP
2) Podling - Felix Sub project
3) Podling - Felix Sub project - TLP
4) Felix Sub project
5) Felix Sub project - TLP

The first 3 effectively uses incubator process(es) to educate the 
incoming folks and provides a strong grounding in ASF-land (at least 
that is what the intention is :)


So, why should we bypass incubator?


Again, there was already a project incubated to educate incoming folks 
on how to create open source OSGi spec impls at Apache, so why do we 
need to repeat that process?


Your phrasing of this question implies we are trying to somehow skirt 
the Apache way, but educating incoming people via contributions and 
meritocracy to an existing project is not some shortcut.


- richard



thanks,
dims

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



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

Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi

[Richard S. Hall]

On 9/4/09 16:49, Davanum Srinivas wrote:

Richard,

I see your viewpoint better now. Thanks.

One more question, Will there be a problem of folks on d...@felix not 
being able or willing to participate in a new podling? (If the folks 
presenting this proposal do wish to start off as a podling)


Dims, since I don't speak for all Felix community members, I can't 
really answer that question. I imagine that interested parties would 
contribute, but certainly a benefit of at least doing any independent 
OSGi spec impls at Felix is you will automatically get the oversight of 
people who have been doing it for years, if not their contribution. The 
separation could possibly make life simpler too for those willing to 
help, since:


  1. People interested only in the OSGi spec impls do not necessarily
 have to be involved on Aries mailing lists that will likely
 incorporate a lot of discussion about the Aries component model
 and related content.
  2. Finished impls could quickly be released as non-incubator artifacts.

- richard



thanks,
dims

On 09/04/2009 04:31 PM, Richard S. Hall wrote:

On 9/4/09 16:10, Davanum Srinivas wrote:

Richard,

On 09/04/2009 03:49 PM, Richard S. Hall wrote:
So, no, I am not saying everything should, but in general, it 
would be

nice if the spec impls started there since we have a community of OSGi
users and OSGi experts who are very active and receptive, many of whom
also work in the EE space.


Will the people mentioned not participate if Aries is a separate
podling to start with? After all destination PMC can be determined
during graduation process. Also the incubation process is to show new
incoming team how Apache works etc..is that better done as a podling
or as a felix sub project? If we continue the same thought process,
will there every be any incubator podling with for any OSGi related
activity?


Yes, and I mentioned this, but that seems to get lost somehow.


In short, it makes sense for spec impls tied to the Aries component
model (for example), to be hosted there, but there is little need to
create another project to incubate generic OSGi spec impls, since the
Felix community was set up for that. The reality is, most OSGi 
specs are

not huge projects so we likely wouldn't want TLPs for all of them, but
nothing stops a subproject started at Felix from going TLP if it takes
on a life of its own.


Choices are

1) Podling - TLP
2) Podling - Felix Sub project
3) Podling - Felix Sub project - TLP
4) Felix Sub project
5) Felix Sub project - TLP

The first 3 effectively uses incubator process(es) to educate the
incoming folks and provides a strong grounding in ASF-land (at least
that is what the intention is :)

So, why should we bypass incubator?


Again, there was already a project incubated to educate incoming folks
on how to create open source OSGi spec impls at Apache, so why do we
need to repeat that process?

Your phrasing of this question implies we are trying to somehow skirt
the Apache way, but educating incoming people via contributions and
meritocracy to an existing project is not some shortcut.

- richard



thanks,
dims

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



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



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

Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi

[Richard S. Hall]

There was no attempt to contact the Felix PMC in general that I am aware 
and I certainly didn't know about it in advance.


And there seems to be a continued attempt to construe my original 
criticisms as all of Aries should go into Felix.


I, personally, do not believe that all of Aries should go into Felix, I 
too think it should have its own identity. I was always only ever 
referring to the independent OSGi spec implementations. I was arguing 
that Felix is a good place to work on them, since it is part of what it 
is trying to achieve.


Further, I don't really understand the implication that somehow the 
burden is now on the Felix community to go and contribute to Aries on 
OSGi spec implementations just because of this proposal, when there was 
no attempt to work with the Felix community on creating OSGi spec 
implementations in the first.


The only conclusions I see being drawn by people who have invested very 
little in Felix is that we should dismantle the Felix charter so that we 
can accommodate the fact that some people don't want to play with us.


At that rate, I stand by my previous vote and otherwise people can do 
whatever they want in Aries.


- richard

On 9/3/09 13:23, Niclas Hedhman wrote:

Kevan,

Was a contact with Felix made prior to dropping the proposal here? I got the
impression that wasn't the case, which I find surprising... If I am wrong,
what was the meat of such?

I'm also less happy with the rhetoric here repeated over and over, seemingly
uninterested in discussion of reaching a solution everyone can accept. (From
both camps, btw)

-- Niclas

On Sep 4, 2009 12:53 AM, Kevan Millerkevan.mil...@gmail.com  wrote:

On Sep 3, 2009, at 12:53 AM, Niclas Hedhman wrote:  On Thu, Sep 3, 2009 at
3:19 AM, William A. Ro...
Totally agree. Had certainly hoped that Felix committers would be interested
in joining...

--kevan

- To
unsubscribe, e-mail: gene...

   


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

Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi

[Richard S. Hall]

On 9/3/09 14:37, Ian Robinson wrote:
The discussion on this part of the proposal reflects the origins of it 
- people with an interest in AppServers and integration runtimes that 
are looking to the new EEG specs to provide additional capability in 
their world so that existing applications can begin to take advantage 
of OSGi with minimum barrier to entry. There will be tensions in 
implementing the specs to work in a way that reflects how these apps 
are built today vs how we'd start afresh given that opportunity. When 
the question why do we need to accomodate the baggage of XYZ in the 
servlet/JNDI/JTA/JMX/JPA/... spec comes up it will be the AppServer 
and integration runtime folks who have the need for accomodating the 
quirkier corners of legacy Java EE behaviour. They are going to have 
a perspective that is a little different from one whose success 
criteria is OSGi spec compliance without a need to additionally 
accomodate some of the warts, or integrate with some of the other 
features, of Java EE. Given this slightly different perspective (and 
the warts) it is perhaps understandable that a community with this 
interest might see value in developing its own culture within the laws 
of the (Apache) land, while living in peace with its neighbours.


Agreed it is important goal for your spec impls to support legacy, but 
you seem to have some misconception about the amount of top-down control 
exerted on Felix subprojects. Each subproject is pretty much free to do 
whatever it wants as far as the implementation approach is concerned, 
which is why we allow competing implementations within Felix.


- richard



Ian Robinson

Richard S. Hall wrote:
There was no attempt to contact the Felix PMC in general that I am 
aware and I certainly didn't know about it in advance.


And there seems to be a continued attempt to construe my original 
criticisms as all of Aries should go into Felix.


I, personally, do not believe that all of Aries should go into Felix, 
I too think it should have its own identity. I was always only ever 
referring to the independent OSGi spec implementations. I was arguing 
that Felix is a good place to work on them, since it is part of what 
it is trying to achieve.


Further, I don't really understand the implication that somehow the 
burden is now on the Felix community to go and contribute to Aries on 
OSGi spec implementations just because of this proposal, when there 
was no attempt to work with the Felix community on creating OSGi spec 
implementations in the first.


The only conclusions I see being drawn by people who have invested 
very little in Felix is that we should dismantle the Felix charter so 
that we can accommodate the fact that some people don't want to play 
with us.


At that rate, I stand by my previous vote and otherwise people can 
do whatever they want in Aries.


- richard

On 9/3/09 13:23, Niclas Hedhman wrote:

Kevan,

Was a contact with Felix made prior to dropping the proposal here? I 
got the
impression that wasn't the case, which I find surprising... If I am 
wrong,

what was the meat of such?

I'm also less happy with the rhetoric here repeated over and over, 
seemingly
uninterested in discussion of reaching a solution everyone can 
accept. (From

both camps, btw)

-- Niclas

On Sep 4, 2009 12:53 AM, Kevan Millerkevan.mil...@gmail.com  wrote:

On Sep 3, 2009, at 12:53 AM, Niclas Hedhman wrote:  On Thu, Sep 3, 
2009 at

3:19 AM, William A. Ro...
Totally agree. Had certainly hoped that Felix committers would be 
interested

in joining...

--kevan

- To 


unsubscribe, e-mail: gene...



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




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



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

Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi

[Richard S. Hall]

I will try to keep this short.

The OSGi Service Platform is composed of the core and compendium specs. 
The EEG specs are not in any way special and will ultimately end up as 
part of the compendium spec. Apache Felix was incubated to build a 
community at Apache around implementing the OSGi specs.


Now we are being told that this mission is too tainted because we 
implement the framework spec, which is part of the core spec. I find 
this unfathomable given the nature of OSGi and the efforts to which the 
Felix community goes to be good OSGi citizens...we even allow for 
competing implementations within our community.


It is also particularly odd, since the Equinox and Knopflerfish 
communities are in the same situation, implementing both core and 
compendium specs with their frameworks largely synonymous with their 
project name.


I am not naive enough to expect this discussion to change much, since I 
imagine there has already been a fair amount of political calculation 
around this proposal, otherwise the Felix community in general would 
have been engaged earlier.


So, here's my vote:

   * -1 for the portion of the proposal creating yet another community
 for implementing OSGi specs at Apache since the Felix community
 would happily welcome more contribution (just like recently
 occurred with ServiceMix members being accepted as Felix
 committers and PMC members for the Karaf subproject)
   * +1 for the rest of the proposal to explore how to build an
 enterprise component model on OSGi and the other non-spec related
 topics.

- richard


On 9/1/09 22:53, Kevan Miller wrote:


On Sep 1, 2009, at 2:08 PM, Richard S. Hall wrote:


On 9/1/09 13:59, Martin Cooper wrote:
On Tue, Sep 1, 2009 at 10:51 AM, Richard S. 
Hallhe...@ungoverned.org  wrote:


I'm not sure I understand the issue here. Whether Aries becomes its
own TLP, or a sub-project of Felix or some other TLP, isn't relevant
until the project is ready to exit incubation. Why does it warrant
such apparently intense discussion before the project is even accepted



We are actually discussing something else. We are discussing the 
scope of the proposal, which includes hosting OSGi standard service 
implementations, which is part of Felix' scope.


If we are developing standard OSGi services within Apache, then Felix 
provides an enthusiastic community to do this and there is no need to 
start another incubator project for such a purpose. On the other 
hand, stuff like a set of pluggable Java components enabling an 
enterprise OSGi application programming model makes perfect sense to 
be incubated.


Thanks for the clarification... So, your issue is mainly with It is a 
goal of the Aries project to provide a natural home for open source 
implementations of current and future OSGi EEG specifications...? 
Personally, I tend to think of Felix in terms of OSGi Core Platform. I 
certainly hadn't expected it to be the source for all OSGi standard 
implementations from Apache -- not for implementations of Enterprise 
Expert Group specs, anyway. I'm sure there are flaws with my 
perceptions...


So, we have a group that is interested in working on an enterprise 
OSGi application programming model at Apache (including 
implementations of at least some EEG specifications). An incubator 
project would seem to be an excellent place for this work to start. 
Interested Felix community members would certainly be able to join 
this effort.


It then becomes a question of, assuming successful incubation, where 
does the community graduate to? TLP, Felix subproject(s), or 
elsewhere. All successful outcomes, IMO.


--kevan

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

Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi

[Richard S. Hall]

The Apache Felix project, since its inception, has been intended to host 
implementations of the OSGi specifications, which includes both the 
framework as well as other standard services. A framework implementation 
was just one of the goals.


This proposal seems to be saying a separate project is needed to create 
some illusion of independence from Apache Felix, but the whole point of 
OSGi is to be vendor neutral, so I am not sure I follow the rationale. 
Apache Felix subprojects are not tied to the Apache Felix framework 
subproject and by us pretending that they are, it only serves to 
perpetuate this myth.


I have no issues with new efforts around and on top of OSGi being 
incubated, but it gets a little trickier when we are talking about 
implementing standard OSGi specs which was the intended community goal 
of the Apache Felix project. Are we supposed to compete now for standard 
service implementations? Or come to some sort of cartel-like agreement 
about who gets what?


- richard

On 9/1/09 10:38, Jeremy Hughes wrote:

Hi, we would like to propose a new incubator podling called Aries.

http://wiki.apache.org/incubator/AriesProposal

Here is a quick summary of the proposal

The Aries project will deliver a set of pluggable Java components
enabling an enterprise OSGi application programming model. This
includes implementations and extensions of application-focused
specifications defined by the OSGi Alliance Enterprise Expert Group
(EEG) and an assembly format for multi-bundle applications, for
deployment to a variety of OSGi based runtimes.

Aries aims to build a community of developers interested in the
definition and delivery of software components that support an
enterprise OSGi programming model and which can be integrated into a
number of different runtime environments.

We appreciate any feedback and comments on the proposal.

Here is a plain text copy of the whole proposal:

Apache Aries
Abstract

The Aries project will deliver a set of pluggable Java components
enabling an enterprise OSGi application programming model. This
includes implementations and extensions of application-focused
specifications defined by the OSGi Alliance Enterprise Expert Group
(EEG) and an assembly format for multi-bundle applications, for
deployment to a variety of OSGi based runtimes.
Proposal

It is a goal of the Aries project to provide a natural home for open
source implementations of current and future OSGi EEG specifications,
including the opportunity for the collaborative development of
compliance tests, and an environment to demonstrate the composition of
these technologies and to explore areas where EEG specifications lack
coverage. A further goal of this project is to leverage experience
gained from it to inform contributions to OSGi EEG requirements and
specification documents.

Aries will offer an enterprise OSGi application programming model that
enables applications to leverage Java EE and other enterprise
technologies and to benefit from the modularity, dynamism and
versioning capabilities of OSGi. A significant feature of Aries will
be a container for OSGi Blueprint components - an implementation of
the new OSGi v4.2 Blueprint component model that defines a standard
dependency injection mechanism for Java components, which is derived
from the Spring framework and extended for OSGi to declaratively
register component interfaces as services in the OSGi service
registry.

In addition, the Aries project will develop a model for assembling an
application/subsystem into a deployable unit, consisting of multiple
bundles, as an archive which may include metadata that describes the
version and external location of the application's constituent bundles
or which may contain the bundles directly.

The Aries project will deliver run-time componentry that supports
applications, running in an OSGi framework, exploiting enterprise Java
technologies common in web applications and integration scenarios
including web application bundles, remote services integration and
JPA. The project is not expected to deliver a complete application or
integration server runtime but will instead deliver enterprise
application componentry that can be integrated into such runtimes. The
project will develop extensions that go beyond the OSGi EEG
specifications to provide a more complete integration of OSGi
modularity with Java enterprise technologies, in particular delivering
support that includes but is not restricted to:

* isolated enterprise applications composed of multiple, versioned
bundles with dynamic lifecycle.
* declarative transactions and security for Blueprint components
* Container-managed JPA for Blueprint components
* Message-driven Blueprint components
* Configuration of resource references in module blueprints.
* Annotation-based Blueprint configuration
* Federation of lookup mechanisms between local JNDI and the OSGi
service registry.
* Fully declarative application metadata to 

Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi

[Richard S. Hall]

I don't think we disagree in principle, but in approach. Apache Felix 
was charted to host Apache licensed implementations of OSGi 
specifications. So, what makes sense to me is:


  1. Having Apache community members work on standard spec
 implementations at Apache Felix.
  2. Then if those subproject take on a life of their own, the
 subproject participants can look into going through incubator to
 go TLP.

Creating another project to host OSGi spec implementations seems 
unnecessary. And, from my point of view, only serves to foster this 
mentality that Felix projects are framework specific. I do not buy your 
argument that we cannot educate the non-techie that this is not true. Do 
such work at Felix is exactly how we educate them. Of course, we could 
also discuss other ways to improve this.


I wholeheartedly encourage OSGi-realted proposals to the incubator. That 
makes sense. Apache Ace is one example, yes, and they do use Deployment 
Admin, however, luminis contributed Deployment Admin to Felix.


The very nature of the OSGi specs almost dictates lots of small 
subprojects. Admittedly, this causes some level of umbrella-ness with 
which we must cope. I believe the Apache Felix PMC is open to such 
discussions if you wanted to start them. Likewise, the Felix PMC is 
definitely open to new contributors and new subprojects.


From my point of view, it is better to foster a cohesive OSGi community 
here at Apache, rather than fracture off in advance.


- richard

On 9/1/09 11:45, Guillaume Nodet wrote:

Not sure how to articulate my thoughts here.

First, it's not about competing against Felix, though you'll find in the ASF
multiple competing products (Axis vs CXF to mention only this one) and the
ASF has never stated as a goal that it would provide a coherent offer or
anything like this.

The problem I have with Felix is really a branding problem.  While *we* (as
developers) very well know that all the subprojects of Felix are not tied to
the Felix Framework itself, it's really difficult to spread this word around
to non techies.  The name Felix is often associated to the OSGi framework
implementation itself, and it's kinda hard to remove this tie unless either
the project or the framework change its name to something else.  For
example, the framework could be referred to as Apache Foo and other
subprojects as Apache iPojo or Apache Karaf.  I think it would help removing
this tie.   The other way around is possible too, rename the project to
something else, and keep Apache Felix as referring to the framework itself
(which might be even better, but slightly more difficult to actually
achieve).  I'm not sure there is a very easy way, but d...@felix.a.o would a
better place to discuss that.

Another thought that comes to my mind is that over the past years, the ASF
has tried to dismantle umbrella projects when it makes sense: i.e. when one
of the subproject has sufficient momentum to create a community on its own.
ACE is another podling related to OSGi and AFAIK it implements the
DeploymentAdmin OSGi spec.   I also see Karaf as a possible TLP at some
point.   That would become a problem with Felix, as the communities are
rather disjoint between the subprojects (not all, I do agree).  Not sure
what the good size for a TLP is and other members can join the discussion
and provide feedback.   I don't think felix is oversized right now, but it
might become a problem if it goes too far.Given this proposal includes
more than 20 committers and most of them are not felix committers, we'd need
the incubator for building up this community anyway.   And btw, as any other
incubator proposal, everyone interested is free to join the proposal and we
would particularly welcome any felix committer here.

That said, Aries wants to focus on application focused enterprise OSGi
specs, which I do agree, could fit in the Felix scope, as could Ace do
too.   I guess in all cases, things can be discussed at the time the podling
will graduate out of the incubator.  The current goal is to aim to TLP as we
think the size of the project can back that, but this is not written in
stone.

On Tue, Sep 1, 2009 at 17:03, Richard S. Hallhe...@ungoverned.org  wrote:

   

The Apache Felix project, since its inception, has been intended to host
implementations of the OSGi specifications, which includes both the
framework as well as other standard services. A framework implementation was
just one of the goals.

This proposal seems to be saying a separate project is needed to create
some illusion of independence from Apache Felix, but the whole point of OSGi
is to be vendor neutral, so I am not sure I follow the rationale. Apache
Felix subprojects are not tied to the Apache Felix framework subproject and
by us pretending that they are, it only serves to perpetuate this myth.

I have no issues with new efforts around and on top of OSGi being
incubated, but it gets a little trickier when we are talking about
implementing standard 

Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi

[Richard S. Hall]

On 9/1/09 12:14, Guillaume Nodet wrote:

On Tue, Sep 1, 2009 at 18:06, Richard S. Hallhe...@ungoverned.org  wrote:

   

Creating another project to host OSGi spec implementations seems
unnecessary. And, from my point of view, only serves to foster this
mentality that Felix projects are framework specific. I do not buy your
argument that we cannot educate the non-techie that this is not true. Do
such work at Felix is exactly how we educate them. Of course, we could also
discuss other ways to improve this.


 

Well, the problem I see here is that we *need* to educate non-techies.  This
obvisouly mean that there is a confusion.  Education is just a work around
the need to remove the confusion imho.  So let's discuss that on
d...@felix.a.o, I don't think this thread belongs here.
   


Hmm. The sole reason all of our communities exist is to educate people 
about what we are doing...to d...@felix...


- richard

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

Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi

[Richard S. Hall]

As I said on d...@felix and will repeat here:



I don't agree about renaming the [Felix] TLP. There are so many examples 
of similar situations. I cannot believe we are truly in a unique 
situation here:


   * Apache typically means the HTTP Server project, but it also
 refers to the foundation and all of its independent projects.
   * Eclipse typically means the IDE, but there is also a runtime and
 foundation with independent projects.

Acting like this isn't normal or something that is too confusing to ever 
resolve seems a bit preposterous.




While I don't believe the situation is as confusing as is contended, I 
have no issue with coming up with a different name for the Apache Felix 
Framework (its name is technically Framework right now), so that the 
Apache Felix project can continue to pursue its original charter.


- richard

On 9/1/09 12:58, Niclas Hedhman wrote:

I'm not subscribing to d...@felix.a.o at the moment, but would still like to
hear the outcome of this...

Richard, we (you and I at least) have discussed this more than once in the
past and I totally agree with Guillaume that the perception is there, it is
everything and near impossible to change. I ALSO agree with Richard that
spec implementations should reside with Felix.

Now, I think name manipulations are going to be necessary. My take is;

Apache Felix = a OSGi framework, runtime, installers, binaries, bells and
whistles. The whole kitchen sink if you like. The framework implementation
itself probably lives here, with the Core spec service implementations.

Apache Foo = a foundry to dev OSGi spec implementations. One or many. Most
will be dependencies to Felix, but the detach shows that they are intended
for all.

Apache Bar = a component foundry outside the spec suite.

And let Aries, Karaf, Ace and what else in future to go TLP if/when they are
ready.

I think ServiceMix has with its friends shown how nice eco-systems can work,
and with OSGi's modularity strengths it should be even more so... In fact,
instead of seeing this as a weakening of Felix position (which is what I
think Richard sees), I think it will strengthen OSGi's natural place in the
Apache Landscape.

Don't forget, you are free to participate at as many places as you wish.

-- Niclas

P.S. Sorry for poor quoting. On mobile...

On Sep 2, 2009 12:14 AM, Guillaume Nodetgno...@gmail.com  wrote:

On Tue, Sep 1, 2009 at 18:06, Richard S. Hallhe...@ungoverned.org  wrote:
   

Creating another pr...
   

Well, the problem I see here is that we *need* to educate non-techies.  This
obvisouly mean that there is a confusion.  Education is just a work around
the need to remove the confusion imho.  So let's discuss that on
d...@felix.a.o, I don't think this thread belongs here.

-- Cheers, Guillaume Nodet  Blog:
http://gnodet.blogspot.com/ --...

   

Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi

[Richard S. Hall]

On 9/1/09 13:59, Martin Cooper wrote:

On Tue, Sep 1, 2009 at 10:51 AM, Richard S. Hallhe...@ungoverned.org  wrote:

I'm not sure I understand the issue here. Whether Aries becomes its
own TLP, or a sub-project of Felix or some other TLP, isn't relevant
until the project is ready to exit incubation. Why does it warrant
such apparently intense discussion before the project is even accepted
   


We are actually discussing something else. We are discussing the scope 
of the proposal, which includes hosting OSGi standard service 
implementations, which is part of Felix' scope.


If we are developing standard OSGi services within Apache, then Felix 
provides an enthusiastic community to do this and there is no need to 
start another incubator project for such a purpose. On the other hand, 
stuff like a set of pluggable Java components enabling an enterprise 
OSGi application programming model makes perfect sense to be incubated.


- richard


into incubation?

--
Martin Cooper


   

As I said on d...@felix and will repeat here:



I don't agree about renaming the [Felix] TLP. There are so many examples of
similar situations. I cannot believe we are truly in a unique situation
here:

   * Apache typically means the HTTP Server project, but it also
 refers to the foundation and all of its independent projects.
   * Eclipse typically means the IDE, but there is also a runtime and
 foundation with independent projects.

Acting like this isn't normal or something that is too confusing to ever
resolve seems a bit preposterous.



While I don't believe the situation is as confusing as is contended, I have
no issue with coming up with a different name for the Apache Felix Framework
(its name is technically Framework right now), so that the Apache Felix
project can continue to pursue its original charter.

-  richard

On 9/1/09 12:58, Niclas Hedhman wrote:
 

I'm not subscribing to d...@felix.a.o at the moment, but would still like
to
hear the outcome of this...

Richard, we (you and I at least) have discussed this more than once in the
past and I totally agree with Guillaume that the perception is there, it
is
everything and near impossible to change. I ALSO agree with Richard that
spec implementations should reside with Felix.

Now, I think name manipulations are going to be necessary. My take is;

Apache Felix = a OSGi framework, runtime, installers, binaries, bells and
whistles. The whole kitchen sink if you like. The framework implementation
itself probably lives here, with the Core spec service implementations.

Apache Foo = a foundry to dev OSGi spec implementations. One or many. Most
will be dependencies to Felix, but the detach shows that they are intended
for all.

Apache Bar = a component foundry outside the spec suite.

And let Aries, Karaf, Ace and what else in future to go TLP if/when they
are
ready.

I think ServiceMix has with its friends shown how nice eco-systems can
work,
and with OSGi's modularity strengths it should be even more so... In fact,
instead of seeing this as a weakening of Felix position (which is what I
think Richard sees), I think it will strengthen OSGi's natural place in
the
Apache Landscape.

Don't forget, you are free to participate at as many places as you wish.

-- Niclas

P.S. Sorry for poor quoting. On mobile...

On Sep 2, 2009 12:14 AM, Guillaume Nodetgno...@gmail.comwrote:

On Tue, Sep 1, 2009 at 18:06, Richard S. Hallhe...@ungoverned.org
  wrote:

   

Creating another pr...

   

Well, the problem I see here is that we *need* to educate non-techies.
  This
obvisouly mean that there is a confusion.  Education is just a work around
the need to remove the confusion imho.  So let's discuss that on
d...@felix.a.o, I don't think this thread belongs here.

-- Cheers, Guillaume Nodet  Blog:
http://gnodet.blogspot.com/ --...


   
 

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

   


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

Re: [PROPOSAL] Apache Aries incubator for Enterprise OSGi

[Richard S. Hall]

How is it that so many people already use Felix subprojects on other 
frameworks if there isn't already some understanding on this already? 
Just because some people perceive it to not be that way, doesn't mean we 
should throw the baby out with the bathwater. It is a poor argument. 
Just starting walking the walk and people will figure it out...they 
aren't that stupid.


- richard

On 9/1/09 14:27, Niclas Hedhman wrote:

Uhhh... So you intend to re-educate the 'masses' in two ways;

1. NO, NO, NO, Felix is not an OSGi framework, it is a group of OSGi
projects... Apache Foo is an OSGi framework...

2. NO, NO, NO, Felix bundles works on other things than Felix, I mean the
Apache Foo...

Or did I misunderstand something here?

That way is just plain stupid, and serves no purpose at all. Either keep
Felix what it represents to people (the framework) and rename/move/juggle
the other bits, or don't do anything.

Yes, you are right that for most non-Java software developers in the world,
Apache == web server, and I think this is a general problem...

Good Luck with whatever tack you guys choose on this.

As for Aries, I would like to see the scope arrive at ASF, and I would hope
now is the time to review the organization in this field.

+1 for Incubation, btw. I might sign up as Mentor, if I can squeeze in the
time...

-- Niclas

On Sep 2, 2009 1:52 AM, Richard S. Hallhe...@ungoverned.org  wrote:

As I said on d...@felix and will repeat here:



I don't agree about renaming the [Felix] TLP. There are so many examples of
similar situations. I cannot believe we are truly in a unique situation
here:

   * Apache typically means the HTTP Server project, but it also
 refers to the foundation and all of its independent projects.
   * Eclipse typically means the IDE, but there is also a runtime and
 foundation with independent projects.

Acting like this isn't normal or something that is too confusing to ever
resolve seems a bit preposterous.



While I don't believe the situation is as confusing as is contended, I have
no issue with coming up with a different name for the Apache Felix Framework
(its name is technically Framework right now), so that the Apache Felix
project can continue to pursue its original charter.

-  richard

On 9/1/09 12:58, Niclas Hedhman wrote:I'm not subscribing to
d...@felix.a.o at the moment, but...

   


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

Re: New Terms [was; VOTE....]

[Richard S. Hall]

On 8/12/09 5:44, Niclas Hedhman wrote:

On Wed, Aug 12, 2009 at 5:30 PM, Jukka Zittingjukka.zitt...@gmail.com  wrote:

   

PS. Why we're inventing new terms? We've been using retire for
years, and it's consistently mentioned in existing documentation (see
[1] and [2]).
 

*I* don't know, nor do I really care. Other people can do the bikeshedding ;-)

And I agree that the people who argue for some other term also commit
to updating the docs. (That should stop it... )
   


+1

I'm would be perfectly happy with retire...

- richard


Cheers
   


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

Re: [VOTE] Mothball/Pause Lokahi

[Richard S. Hall]

+1

On 8/12/09 0:50, Niclas Hedhman wrote:

PMC and others,

Lokahi's community has collapsed long time ago and albeit Noel's
repeated efforts to create interest around the project, there is no
signs of any improvement.
I am therefor calling a vote to mothball/pause the project. Please
place your votes.

[ ] +1, go ahead and mothball/pause Lokahi,
[ ] -1, don't mothball/pause Lokahi, because... (reason is optional,
but appreciated)


Cheers
   


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

Re: Reports are soon due!!

[Richard S. Hall]

On 8/11/09 14:38, Noel J. Bergman wrote:

The following projects have not yet written a line in there;
 
   

Lokahi
 

We should probably vote to pause it.

   

XAP - Robert notes that this project is being paused
 

He means suspended, archived, recognized as dormant, etc.

If paused is the accepted word, let's just get on with it.  We already
held the vote.
   


Maybe someone else mentioned it already, but the perfect word just 
dawned on me:


   * mothballed -
 o stop using (a piece of equipment or a building) but keep it
   in good condition so that it can readily be used again
 o cancel or postpone work on (a plan or project)

:-)

- richard


--- Noel



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

   

[IP CLEARANCE] Sigil sub-project contribution to Apache Felix

[Richard S. Hall]

Hello,

I would like to request IP clearance for the Sigil sub-project 
contribution to Felix from Paremus; the IP clearance form is here:


http://incubator.apache.org/ip-clearance/felix-sigil.html

Thanks a lot.

- richard

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

IP clearance question

[Richard S. Hall]

Hello,

I am trying to perform IP clearance on the Sigil project to Felix.

The contributed archive contains some embedded JAR files, one of which 
is covered by AGPL, which is a modified version of GPL. I am told by 
Paremus (the contributors) that only two minor classes depend on this 
JAR and it could be easily removed from Sigil with very minor impact.


So, the question I have is, do we need them to submit a new archive that 
doesn't contain this code or is it sufficient for us to strip this code 
before importing the contributed code to SVN?


Thanks.

- richard

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

Re: IP clearance question

[Richard S. Hall]

Ok, thanks.

- richard

On 7/6/09 12:50 PM, William A. Rowe, Jr. wrote:

Richard S. Hall wrote:
   

Hello,

I am trying to perform IP clearance on the Sigil project to Felix.

The contributed archive contains some embedded JAR files, one of which
is covered by AGPL, which is a modified version of GPL. I am told by
Paremus (the contributors) that only two minor classes depend on this
JAR and it could be easily removed from Sigil with very minor impact.

So, the question I have is, do we need them to submit a new archive that
doesn't contain this code or is it sufficient for us to strip this code
before importing the contributed code to SVN?
 


GPL [AGPL] is viral.  The entire archive is copyleft.

You need clear AL 2.0 submission by the original authors, with no pieces
of GPL code whatsoever.

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

   

Re: IP clearance question

[Richard S. Hall]

Follow up question, I assume our vote to accept the contribution is 
still acceptable as well as the software grant from Paremus. So, the 
only necessary action is to have Paremus submit a new, Apache compatible 
archive. Is that correct?


- richard

On 7/6/09 12:52 PM, Richard S. Hall wrote:

Ok, thanks.

- richard

On 7/6/09 12:50 PM, William A. Rowe, Jr. wrote:

Richard S. Hall wrote:

Hello,

I am trying to perform IP clearance on the Sigil project to Felix.

The contributed archive contains some embedded JAR files, one of which
is covered by AGPL, which is a modified version of GPL. I am told by
Paremus (the contributors) that only two minor classes depend on this
JAR and it could be easily removed from Sigil with very minor impact.

So, the question I have is, do we need them to submit a new archive 
that

doesn't contain this code or is it sufficient for us to strip this code
before importing the contributed code to SVN?


GPL [AGPL] is viral.  The entire archive is copyleft.

You need clear AL 2.0 submission by the original authors, with no pieces
of GPL code whatsoever.

-
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: IP clearance question

[Richard S. Hall]

On 7/6/09 5:49 PM, Robert Burrell Donkin wrote:

On Mon, Jul 6, 2009 at 5:55 PM, Richard S. Hallhe...@ungoverned.org  wrote:
   

Follow up question, I assume our vote to accept the contribution is still
acceptable as well as the software grant from Paremus. So, the only
necessary action is to have Paremus submit a new, Apache compatible archive.
Is that correct?
 


IMHO the vote, yes and - providing that it doesn't include a checksum
- the grant should be ok too
   


There was no checksum mentioned in the grant, just a project 
description. So, I guess we are fine with a new archive.


- richard


- robert

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

   

[IP CLEARANCE] OSGi Shell

[Richard S. Hall]

The Apache Felix PMC request an IP check for the OSGi Shell contribution 
from Peter Kriens:


http://incubator.apache.org/ip-clearance/felix-osgi-shell.html

Thank you.

- richard

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

Re: [VOTE] Accept Apache Ace into the Incubator

[Richard S. Hall]

+1

- richard

On 4/19/09 11:35 AM, Karl Pauls wrote:

Please vote on accepting Apache Ace for incubation at the Apache
Incubator. The full proposal is available at the end of this message
and as a wiki page at http://wiki.apache.org/incubator/AceProposal. We
ask the Incubator PMC to sponsor it, with Karl as the Champion, and
Carsten, Niclas and Bertrand volunteering to be mentors.

Please cast your votes:

[ ]  +1, bring Ace into Incubator
[ ]  +0, I don't care either way,
[ ]  -1, do not bring Ace into Incubator, because...

The vote is open for the next 72 hours and only votes from the
Incubator PMC are binding.

- - - - - - - - - -

Abstract

Apache Ace is a software distribution framework based on OSGi that
allows you to manage and distribute artifacts, like e.g. software
components.


Proposal

Apache Ace is a software distribution framework that allows you to
centrally manage and distribute software components, configuration
data and other artifacts to target systems. It is built using OSGi and
can be deployed in different topologies. The target systems are
usually also OSGi based, but don't have to be.


Background

When assembling software out of reusable components, the task of
deploying software onto an ever increasing number of targets is not
trivial to solve. This becomes even harder when these targets require
different components based on who's using them.

A key technology in the Java space for developing component based
applications is OSGi. The OSGi specification, which has been around
since 1999 and by now has matured into the de facto module system for
Java, allows you to write components that can interact through
services and that allows components to be updated individually,
without disturbing the rest of the components.

Although the OSGi specification describes how software distribution
should be done, it does not actually prescribe any protocols or
implementations. Apache Ace implements a software distribution system
based on, but not limited to OSGi. It is setup so it can deal with
different target types, using different protocols. Also, it can handle
an extensible number of artifact types (bundles, configurations,
resources, ...).


Rationale

When you start using OSGi to build reusable components, the task of
managing those components and their use in various applications
becomes non-trivial. Apache Ace allows you to group those components
and assign them to a managed set of targets. This allows you to
distribute updates and new components easily, while keeping a full
history of what was installed where during what period. It also helps
you setup an automated development, QA/testing, staging and production
environment.


Initial Goals

The initial goals for Apache Ace are:

* Donate the existing codebase and import it.
* Setup the incubation infrastructure (svn repository, build system,
website) so we can run continuous builds with automated tests and
publish all available documentation.
* Get people involved in advancing the code base in different
directions, integrating it with other projects at Apache.
* Prepare for an initial release that demonstrates the systems core
capabilities.
* Present the project to the community at ApacheCon 2009 US.


Current Status

The current codebase is developed and tested in various
configurations. It was developed at luminis over the last couple of
years using Scrum, so we have internally demonstrated we can release
often and produce working code using a transparent process.
Documentation for the project is now available on an internal wiki,
which can be donated and converted to the Apache Ace website. We did
not yet use mailing lists as the primary colaborative process, as the
whole team met face to face on a daily basis.


Meritocracy

Some of the core developers are already committers and PMC members at
Apache, so they understand what it means to have a process based on
meritocracy.


Community

In the past, luminis has been talking to various interested users and
developers about Apache Ace, and we believe there is an interest in
this project. Feedback at ApacheCon EU 2009 and afterwards on the
Apache Felix mailing list confirmed that. The problem that is being
solved is one that many software developers run into, so it should
appeal to them. Our list of initial committers already includes people
from different backgrounds.


Core Developers

The core development team is a mix of people that work for luminis and
have been involved in the project up til now and new committers, some
of which have previous experience at Apache.


Alignment

The initial codebase makes use of Apache Felix as its core framework.
It also uses various other components of that project. As a project
that builds on components we are constantly looking out for existing
components that can accelerate our implementation and we want to
actively work with other projects to make that happen. For building
and testing we use Apache Ant and have developed a couple of

Re: [PROPOSAL] Apache Ace

[Richard S. Hall]

Jason,

Although, we keep trying to point out that OBR != p2, you seem to keep 
missing that point.


OBR is a simple repository model and API for accessing it, that's all it 
is...it is not a provisioning system. As such, OBR has been done for a 
long time. All other functionality should be hopefully be buildable as 
layers on top, such as what Luminis has done with their provisioning work.


You act like there is some gotcha that OBR is not an OSGi spec, but 
OBR has always existed outside of the OSGi specs, so who cares? The 
proposal literally only mentions the letters OBR once as a dependency 
and nothing more. It is hardly the main selling point.


No one was shouting about OBR or p2, that was only you.

Also, the notion that we should just lay down because we can't compete 
with some big company and all these man years they have invested is 
somewhat ridiculous. If we all bought into that, then none of us would 
be here.


If you just wanted to point out that p2 should be mentioned as a 
competing technology in the proposal, I think you could have 
accomplished that in a more reasonable manner.


Lastly, it is somewhat difficult for me to take community building 
lessons from someone who claims to have had an OSGi awakening and is 
willing to cull all of their own personal projects as a result, yet I 
can count on probably a couple fingers how many discussions you've 
instigated (or even responded to) regarding OSGi, OBR, or any topic in 
the Felix community in all the years it has existed.


- richard

On 4/5/09 2:11 PM, Jason van Zyl wrote:
I'm suggesting that  you two groups figure out how to work together on 
a very hard problem.


I'm also saying that you are unlikely to out do the 5 man years in p2 
already.


As I said in the previous email if you want to make a competing system 
that's fine. But don't couch the proposal as something that's new and 
hasn't been addressed elsewhere because it has.


You might want to be more clear in the proposal about p2 being a 
competitor, also make it clear that OBR has gone back to 
specification, and what it is you're actually working from. So when a 
user or potential developer looks at this and says what specification 
are you working from they can see there isn't one yet, and if they 
ask what about p2?, then it's clear you decided not to collaborate 
with them. I think you can even point out that they didn't collaborate 
with you either. Give people all the information.


When I walked into the OSGi BOF at Eclipse I was dumbfounded. The same 
dose of sniping and grin fucking as other groups I've worked with 
which was disappointing but I guess I'm not surprised. There were 
attacks abound at EclipseCon. The way p2 came into existence probably 
could have been handled better, no doubt. But I don't find guys like 
Hal very compelling with his melodrama 
(http://www.tensegrity.hellblazer.com/2009/03/osgi-rfp-122---the-osgi-bundle-repository.html). 



Make it clear to people looking at the proposal that provisioning is a 
hard problem. These arguments about the Eclipse way of p2 and 
non-focus on server side or other types of systems is nonsense. If you 
actually  have a pointer to p2 in your proposal -- which is 
conspicuously absent -- siting them as a direct competitor users will 
have a clear point of reference. If people had the background story 
they will probably go WTF just like I did.


Both sides of the p2/OBR seem to be equally obstinate and 
non-collaborative. I used p2 because from a technical level as an end 
user because it worked. There are nightly builds, lots of 
documentation and at least 5 people working on it full-time at any 
given point in time. If you look at the p2 code and the OBR spec they 
are 90% the same thing and any differences are easily compensated for 
with a little effort.


Competition is fine, I would just be more open about that aspect of it 
in the proposal.


On 5-Apr-09, at 8:47 AM, Karl Pauls wrote:

On Sun, Apr 5, 2009 at 5:00 PM, Jason van Zyl jvan...@sonatype.com 
wrote:


On 5-Apr-09, at 2:46 AM, Marcel Offermans wrote:


Hello Jason,

On Apr 5, 2009, at 1:09 , Jason van Zyl wrote:


Equinox p2 was designed to replace the aging Update Manager in
Eclipse. It focusses on installing Eclipse-based applications from
scratch and updating them and can be extended to manage other types
of artifacts. If you look at the agent part, it is geared towards
desktop environments


Not true.



Jeff McAffer's demo at EclipseCon is a case in point. He provisioned
an EC2 node using p2. [...] Jeff is very much focused on server side
provisioning as am I.


Let me rephrase that, it's geared more towards desktop and server
environments, as compared to smaller (embedded, mobile) 
environments. That

was the point I was trying to make here.


Note though, I'm no Equinox p2 expert. :)



Then why are you proposing this when you don't even know what p2 is
capable of?


We started working on this system when p2 did not even exist. 

Re: [PROPOSAL] Apache Ace

[Richard S. Hall]

+1

- richard

On 4/2/09 3:52 PM, Marcel Offermans wrote:

Hello all,

I would like to formally present the incubator proposal for Apache 
Ace, a software distribution framework based on OSGi that allows you 
to manage and distribute artifacts, like e.g. software components.


The full proposal can be found on the wiki at: 
http://wiki.apache.org/incubator/AceProposal


I'm looking forward to all questions and feedback, positive or negative.

Greetings, Marcel


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



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

Re: [PROPOSAL] Apache Ace

[Richard S. Hall]

On 4/4/09 7:09 PM, Jason van Zyl wrote:


On 4-Apr-09, at 12:30 PM, Marcel Offermans wrote:


Hello Martin,

On Apr 4, 2009, at 20:39 , Martin Cooper wrote:


On Thu, Apr 2, 2009 at 12:52 PM, Marcel Offermans 
marcel.offerm...@luminis.nl wrote:


Hello all,

I would like to formally present the incubator proposal for Apache 
Ace, a
software distribution framework based on OSGi that allows you to 
manage and

distribute artifacts, like e.g. software components.

The full proposal can be found on the wiki at:
http://wiki.apache.org/incubator/AceProposal

I'm looking forward to all questions and feedback, positive or 
negative.


Could you comment on how this compares to Equinox p2? It'd be 
interesting to

understand the similarities and differences.


Let's start with the similarities. Both systems are designed to 
distribute software components, and both are based on OSGi.


Equinox p2 was designed to replace the aging Update Manager in 
Eclipse. It focusses on installing Eclipse-based applications from 
scratch and updating them and can be extended to manage other types 
of artifacts. If you look at the agent part, it is geared towards 
desktop environments


Not true.

Jeff McAffer's demo at EclipseCon is a case in point. He provisioned 
an EC2 node using p2. Jeff's goal from the start with p2 was 
provisioning server's. Anyone looking at the mailing lists would know 
this. Much of what he showed was the dynamic discovery of nodes for 
provisioning from the server side. Now Pascal may have focused on 
desktop and SDK provisioning but Pascal was not the only one involved. 
Jeff is very much focused on server side provisioning as am I.


(their agent download is about 12 MB) and focusses on having a user 
on the target system selecting the components or plugins that need to 
be installed or updated. Looking at the server side, they manage 
update sites that contain the files the agent can download. As far as 
I know they don't yet have tooling to show an overview of all 
targets, nor ways to directly monitor or manage them.


Apache Ace was designed to be a framework for provisioning based on 
OSGi standards (whenever available). The agent is small (100kB) 
and is based on OSGi's DeploymentAdmin which also allows you to 
install any type of artifact in an extensible way. Being that small, 
it can also run on small targets like embedded systems and mobile 
phones. We also don't assume a user on the target system. On the 
server side, we support OSGi's Bundle Repository (OBR) and we can 
actively manage targets and push software onto them without user 
interaction. Also, you can have a central overview of these targets 
and their complete life cycle. There are even mechanisms for doing 
updates when the target systems are never in direct contact with the 
provisioning server (because they're in environments where internet 
access is not allowed). Finally we have complety separated the 
meta-data necessary for provisioning from the actual components, 
which means it's possible to host the provisioning server on an 
internet server whilst keeping the actual components on local 
networks. This means you can set it up in such a way that you never 
expose any IP on the internet (assuming you don't consider meta-data 
about software components to be IP).


There's probably lots more I can explain, so feel free to keep asking 
questions, I hope this gives a high level comparison of both systems. 
Note though, I'm no Equinox p2 expert. :)




Then why are you proposing this when you don't even know what p2 is 
capable of?


OBR has also gone back to RFC so there is no OBR really. There's Hal's 
initial specification and that's it.


As far as I could tell at EclipseCon a bunch of peopled seemed jilted 
to me that IBM went and made p2. I don't know what politics played out 
but OBR is just going to replicate most of what p2 does. For me I 
don't care insofar as Nexus because OBR (when it's actually finished 
being specified and implemented) is just as easy to support on the 
server side as p2. So I honestly don't care and I don't have any 
business relationship with IBM or EclipseSource. I just used what 
worked. p2 worked for our desktop uses cases -- which is incredibly 
important -- and our server side use cases. Maven is now using the 
same solver that p2 is using but that's just general artifact resolution.


I usually try to stay out of this shit, but...

I have no idea what you are talking about Jason. To set the record 
straight, p2 replicated what OBR had started years ago. Certainly, p2 
has gone further in some areas than OBR now, but OBR was never intended 
to go into those areas, which were always planned as layers to be built 
on top of OBR.


When Hal started to push the OBR RFC again (which was actually spec'ed 
by Peter and I four years ago or so), there was no mention or discussion 
of p2 at all. It is not like Oracle doesn't work with IBM and use 
Equinox extensively already. The fact of the 

Re: [VOTE] Suspending Projects -- XAP

[Richard S. Hall]

+1


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

[RESULT] Re: [IP CLEARANCE] Apache Felix File Install contribution

[Richard S. Hall]

It has been a week, so I guess it is time to close this IP clearance 
request. It passes via lazy consensus.


- richard

Richard S. Hall wrote:
I have finished the paperwork for a contribution from Peter Kriens to 
the Apache Felix project, the resulting IP clearance form is here:


   http://incubator.apache.org/ip-clearance/felix-file-install.html

I'd appreciate it if someone could check it. Thanks.

- richard

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[IP CLEARANCE] Apache Felix File Install contribution

[Richard S. Hall]

I have finished the paperwork for a contribution from Peter Kriens to 
the Apache Felix project, the resulting IP clearance form is here:


   http://incubator.apache.org/ip-clearance/felix-file-install.html

I'd appreciate it if someone could check it. Thanks.

- richard

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: moving a failed incubation project

[Richard S. Hall]

Michael Wechner wrote:

J Aaron Farr wrote:



If the fork wishes to do more than patch up the original or wishes to
create its own identity unique from the Apache original, then it would
be wise to rename the packages, but there is no legal requirement to
do so.
 



believing you that there is no legal requirement (I am no lawyer ;-), 
but that's also my understanding of the ASF license and incubator 
agreement), then that's how it is for the moment.


But for the future I think it's in the best interest of the ASF to 
think about this more thoroughly, because it can be very misleading if 
one is using Java packages with org.apache.*, but this code


- might have nothing to do with the ASF
- might be a fork of existing ASF, but has been changed quite a bit in 
the meantime


This is the nature of open source, so I think we have to suck it up. If 
someone forks OpenJDK, do you think they are going to change all the 
package names to something else?


We have knowingly allowed this because we think it is the right thing to do.

If some company took our code, modified it, and started distributing it 
as part of a commercial (but freely downloadable) project, we wouldn't 
complain if they encouraged their customers to write to their modified 
version of our code as part of their project. So, why would it be any 
different if someone was only forking and not including it in a project?


In both cases, the main thing for us is to make sure they clearly state 
that it is a fork, not an official Apache project.


- richard


To me the first step would be to talk to these people and ask them 
kindly to change the package names.
If they will change it, then almost everyone will be happy, except 
people with dependencies, but that can be fixed by keeping previous 
versions available and adding a note.


The problem is when people don't want to change and this is where the 
ASF should ask itself do we care (well, I do) and if the ASF does 
care, then what can be done? Are there legal means? Are there other 
means?


Cheers

Michi


--
 J Aaron Farr jadetower.com[US] +1 724-964-4515
   馮傑仁  cubiclemuses.com [HK] +852 8123-7905


[1] this is trademark, not copyright issue.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

 






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: IP clearance for contributed code

[Richard S. Hall]

Kevan Miller wrote:


On Jan 24, 2008, at 4:40 AM, Trustin Lee wrote:


Hi Richard,

IIUC, yes, the owner of the donated code needs to update the source
code.  Probably you could send some patch to him and he could apply
the patch.  When I import AsyncWeb, I just did it by myself because I
was a committer of the project.


Section 1. of http://www.apache.org/legal/src-headers.html#headers 
addresses this case...


Cool. So, what form can written approval take? Is it sufficient for him 
to say yes on the JIRA issue on which he has attached the donated 
code? If not, I guess I will just ask he to resubmit the modified code.


- richard


--kevan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: IP clearance for contributed code

[Richard S. Hall]

Kevan Miller wrote:


On Jan 24, 2008, at 10:02 AM, Richard S. Hall wrote:


Kevan Miller wrote:


On Jan 24, 2008, at 4:40 AM, Trustin Lee wrote:


Hi Richard,

IIUC, yes, the owner of the donated code needs to update the source
code.  Probably you could send some patch to him and he could apply
the patch.  When I import AsyncWeb, I just did it by myself because I
was a committer of the project.


Section 1. of http://www.apache.org/legal/src-headers.html#headers 
addresses this case...


Cool. So, what form can written approval take? Is it sufficient for 
him to say yes on the JIRA issue on which he has attached the 
donated code? If not, I guess I will just ask he to resubmit the 
modified code.


Well, IANAL ;-), but I don't think the Grant license to ASF... 
button gives you permission to remove the copyright. In the past, I've 
asked the the patch provider to remove the copyright and resubmit the 
patch. I think that's the best (and easiest).


I wasn't referring to the button...I was referring to whether it would 
be acceptable for him to give written approval as a JIRA comment. 
Regardless, you are probably correct that it is easier to have him 
modify it. :-)


- richard


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: moving a failed incubation project

[Richard S. Hall]

James Carman wrote:

I guess the big point here is what is the big issue with changing the
package name in the code?  When people see a class that's in an
org.apache.*package, they assume that it's from the ASF.  Leaving it
in an
ASF-namespaced package has two problems here:

1.  People will assume that it's ASF code.
2.  The ASF never put its stamp of approval on this code, since it never
made it out of the incubator.

Neither one of these problems is a legal problem based on the license (from
what folks have said here).  But, there are certain conventions in the Java
community which we follow.  If someone sees that code and they want to learn
more about it, they'll probably go to www.apache.org and try to find some
information.  Leaving that code in an ASF-namespaced package is kind of like
putting words into someone else's mouth.
  


I didn't say that I was against asking people to change it nicely, but I 
think there is nothing we can do if they don't. Section 4.b states:


   You must cause any modified files to carry prominent notices stating 
that You changed the files; and


So, if they make any changes, they must prominently say so, so they 
wouldn't be putting words into anyone's mouth.



Another interesting point to all of this is the question of whether the
package name really is part of the code.  Is the code everything that's
in the source file or is the code the actual logic inside the file?  The
package statement could only be seen as a namespace facility and not
necessarily code.  I'm no lawyer, but one might try to make that
distinction.
  


I don't see how you could argue that it is not part of the code, when it 
impacts the API.


- richard


On 1/23/08, Richard S. Hall [EMAIL PROTECTED] wrote:
  

Niall Pemberton wrote:


On Jan 23, 2008 11:26 AM, Simon Kitching [EMAIL PROTECTED] wrote:

  

Niall Pemberton schrieb:



On Jan 23, 2008 7:23 AM, Paul Fremantle [EMAIL PROTECTED] wrote:


  

Niall

Asking someone politely to rename the package is hardly throwing our
weight around.




Well you were talking about need to change the package name and
rigorous protection rather than some kind of hey we'd prefer
it

If people are so keen on *protecting* apache in this way then rather
than starting with a failed incubator project, then how about this
stuff:


  

https://glassfish.dev.java.net/source/browse/glassfish/appserv-webtier/src/java/org/apache/

  

Again, that is a bit different from the original TCIK issue. It
*appears* that here they are not doing this in order to *distribute* a
forked copy of tomcat, but instead to support tomcat as an alternative
internal servlet-engine implementation within their own j2ee server. In
other words, I would think that:
(a) you could not normally download this code except by downloading the
entire glassfish server, and
(b) they are not actively developing this code to add new features
(forking) but simply adding a few patches to make it integrate better
with Glassfish.

The alternate implementations of commons-logging have also been
mentioned in this thread. This is not the same IMO. Commons-logging is
both an API and an implementation. People should be able to provide
alternate implementations of an API, and that is what slf4j are doing
for example; they are not providing a patched or forked
commons-logging, but instead a complete alternative implementation, and
are distributing just the minimum amount of code to provide the same


api


to users.

So:
* distributing a few classes in order to implement an apache API : ok
* distributing a copy of apache code for the convenience of users of a
larger package, perhaps with a few minor tweaks for better integration:


ok


* publishing code to the world which bears no resemblance to code
approved by the ASF: not ok



My advice to anyone - read the license yourself, take advice if you
feel you need it and ignore all the stuff being spouted here:

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

  

That would be my feeling too. The license pretty much allows people to
do whatever they want with the code and the package name is part of the
code.

- richard



Niall


  

All this just just my opinion of course..

Regards,
Simon



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


  

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





  


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

IP clearance for contributed code

[Richard S. Hall]

I am performing the IP clearance paperwork for some code from Peter 
Kriens. The IP clearance form here:


   http://incubator.apache.org/ip-clearance/ip-clearance-template.html

Asks me to fill in the date for:

   Check and make sure that the files that have been donated have been 
updated to reflect the new ASF copyright.


The donated code currently does not have ASF copyright, it has Peter's 
copyright. Is the implication here that Peter is supposed to change the 
copyright on all source files? I assumed that we would just modify the 
source files to have the proper header as part of bringing them into our 
repo, but this implies that this must be done beforehand.


Which is the case?

Thanks.

- richard

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: moving a failed incubation project

[Richard S. Hall]

James Carman wrote:

On 1/23/08, Richard S. Hall [EMAIL PROTECTED] wrote:
  

James Carman wrote:


I guess the big point here is what is the big issue with changing the
package name in the code?  When people see a class that's in an
org.apache.*package, they assume that it's from the ASF.  Leaving it
in an
ASF-namespaced package has two problems here:

1.  People will assume that it's ASF code.
2.  The ASF never put its stamp of approval on this code, since it never
made it out of the incubator.

Neither one of these problems is a legal problem based on the license (from
what folks have said here).  But, there are certain conventions in the Java
community which we follow.  If someone sees that code and they want to learn
more about it, they'll probably go to www.apache.org and try to find some
information.  Leaving that code in an ASF-namespaced package is kind of like
putting words into someone else's mouth.

  

I didn't say that I was against asking people to change it nicely, but I
think there is nothing we can do if they don't. Section 4.b states:

You must cause any modified files to carry prominent notices stating
that You changed the files; and

So, if they make any changes, they must prominently say so, so they
wouldn't be putting words into anyone's mouth.




If someone downloads the binaries, they don't have the source code, so
they'd have to look at the NOTICE file to know what's going on.  I
doubt many folks actually read those (I typically don't).  To me,
publishing classes in someone else's namespace (that they didn't
author) is like putting words in someone else's mouth.  I would
imagine other folks feel that way also.  The fact that they legally
take care of their obligations with respect to the license wouldn't
change my perception either.  I would still feel uneasy about it.
  


It seems that there are two discussions going on at the same time:

  1. Whether it is cool for people to do this.
  2. Whether we should try to stop people from doing this.

I am pretty sure that we all agree that it is not cool (1), so I wasn't 
talking about this. Regarding (2), I think we shouldn't and can't do 
much to stop it.


- richard



  

Another interesting point to all of this is the question of whether the
package name really is part of the code.  Is the code everything that's
in the source file or is the code the actual logic inside the file?  The
package statement could only be seen as a namespace facility and not
necessarily code.  I'm no lawyer, but one might try to make that
distinction.

  

I don't see how you could argue that it is not part of the code, when it
impacts the API.




The API is the way you talk to the object, or the interface (thus the
I in API).  The interface consists of the name of the class itself and
the names of the methods and fields of the class (whether they be
instance or class level).  You can change the package name of a
library without changing the client logic code.  You'll have to use a
different namespace to address it (change imports or fully-qualified
class names), but the manner in which you use the objects/classes
doesn't change.  I don't know that I necessarily agree with what I'm
saying. I'm just playing devil's advocate.  :)  In any case, I merely
said it was interesting and I don't really know if it's worth wasting
anyone else's time here on it (many things I find interesting aren't
worth others' time).

The main point in this discussion is that not changing the package
names is not illegal, but it's definitely uncool and goes against a
pretty well adhered to convention.  Legally, all we can do is ask them
to change the package names and if they don't, there's nothing we can
do (at least that's what we're hearing from other folks in this
discussion).


  

- richard



On 1/23/08, Richard S. Hall [EMAIL PROTECTED] wrote:

  

Niall Pemberton wrote:



On Jan 23, 2008 11:26 AM, Simon Kitching [EMAIL PROTECTED] wrote:


  

Niall Pemberton schrieb:




On Jan 23, 2008 7:23 AM, Paul Fremantle [EMAIL PROTECTED] wrote:



  

Niall

Asking someone politely to rename the package is hardly throwing our
weight around.





Well you were talking about need to change the package name and
rigorous protection rather than some kind of hey we'd prefer
it

If people are so keen on *protecting* apache in this way then rather
than starting with a failed incubator project, then how about this
stuff:



  

https://glassfish.dev.java.net/source/browse/glassfish/appserv-webtier/src/java/org/apache/



Again, that is a bit different from the original TCIK issue. It
*appears* that here they are not doing this in order to *distribute* a
forked copy of tomcat, but instead to support tomcat as an alternative
internal servlet-engine implementation within their own j2ee server. In
other words, I would think that:
(a) you could not normally download this code

[RESULT] Re: [IP CLEARANCE] Deployment Admin for Felix

[Richard S. Hall]

The IP clearance for Felix' Deployment Admin contribution is 
successfully closed.


Thank you to those who looked into it.

- richard

Richard S. Hall wrote:

Could someone check IP clearance on the following contribution:

   http://incubator.apache.org/ip-clearance/felix-deployment-admin.html

Thanks.

- richard

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[IP CLEARANCE] Deployment Admin for Felix

[Richard S. Hall]

Could someone check IP clearance on the following contribution:

   http://incubator.apache.org/ip-clearance/felix-deployment-admin.html

Thanks.

- richard

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Accept Bluesky Project into the Incubator

[Richard S. Hall]

+1

- richard

Bill Stoddard wrote:
Thanks to everyone who made contributions to this proposal and special 
thanks to Niclas and Aaron for stepping up as mentors. The project is 
documented here:


http://wiki.apache.org/incubator/BlueSky

Please vote on accepting Bluesky into the Apache Incubator.  The vote 
will run 1 week, beginning now, and will conclude Saturday, January 
12, 2008.


[ ] +1 Accept BlueSky for incubation

[ ] 0 Don't care

[ ] -1 Reject for the following reason :


Thanks,
Bill

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Didn't we kick these guys out?

[Richard S. Hall]

D'oh!

I will be traveling for a few days, but will look into upon my return.

- richard

William A. Rowe, Jr. wrote:

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

:)  I'm just noticing some of these status files don't actually
indicate their Graduated status.

Bill

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] RAT to enter incubator

[Richard S. Hall]

+1

- richard

Robert Burrell Donkin wrote:

i'd like to propose that the IPMC sponsors the entry of RAT into the incubator

- robert

--8-
[ ] +1 Allow RAT to enter incubator, sponsored by IPMC
[ ] +0
[ ] -0
[ ] -1 Do no allow RAT to enter incubator
---

Rat Proposal
==
Abstract

RAT is comprehension and auditing for distributions and source code.

Proposal
--
RAT will provide a focus for components, applications and integration
tools for the comprehension and audit of distributions and source
code. It will collect data and meta-data as required. It will create
suitable schemas for this data and meta-data as required.

Background
--
RAT began as an attempt to automate the technical part of reviewing
releases in the incubator. Following requests for access from release
managers, RAT was developed as an open source project under the Apache
License 2.0.

Rationale
---
Reviewing releases for compliance with Apache technical criteria and
policies is time consuming. The Incubator requires that all releases
are reviewed. Though small mistakes are common, this process typically
adds only a little value. It is common for candidates to be presented
with small but significant defects which then must be fixed and the
candidate represented. Significant energy and good will is wasted by
this process.

This is unnecessary. Given effort, these technical criteria are
capable of automation.

Automated continuous checking of the source would allow the Incubator
PMC to be alerted promptly to potential issues. Integration with build
tools (such as Apache Ant and Apache Maven) would allow releases to be
checked automatically and continuously.

Initial Goals
--
* Read standard license meta-data for documents without license headers
* Improved RAT reporting
* RAT source reporting for major build tools
* Continuous RAT
* RAT analytics: using meta-data to verify rules
  o Apache third party documents policy analysis
  o license compatibility analysis
* Discordia integration to allow distributed binaries to be recognised
* RAT analytic integration for major build tools
* Improved recursive RAT scripts for better analysis of release
with many distributables

Current Status
===
Meritocracy
--
I'm very happy to move from a solo development model towards a
collective one as more active developers are recruited.

Community
--
The RAT community needs to be developed. Having RAT here at Apache
will hopefully encourage release managers to take a more active role
in developing RAT.

Core Developers
--
It has been developed principally by myself but with significant
contributions of small amounts of code from other Apache members and
committers.

Alignment

RAT has found itself becoming a standard part of the Apache release
infrastructure. The Incubator needs fully featured release tools. It
makes sense to bring the project here.

Known Risks
==
Orphaned Projects
-
This is a project with a set of definite goals aimed at serving the
wider Apache community. There may well come a time when the coding is
actually finished. It has a small set of developers who all have many
other calls on their time. The target user audience is relatively
small. So, this risk is real.

I think that it's clear that something similar to RAT is required. So,
unless another better product is developed, time will be found to push
RAT forward. Even if one day, RAT is orphaned then it will have done
it's job.

Inexperience With Open Source
-
The contributors are Apache members or experienced Apache committers.

Reliance On Salaried Developers

I know of no one who's paid to work on RAT.

Relationships with Other Apache Products
--
RAT contains an Ant reporting plugin. Codehaus hosts a Maven reporting
plugin. Analytic plugins for Ant and Maven will be developed. There
are overlaps with Tika and there has been some talk of collaboration.
The discordia lab will likely be used for license and artifact
meta-data. RAT may integrate with Gump for continuous code scanning.

Initial Source

* [WWW] http://code.google.com/p/arat/source
* [WWW] http://mojo.codehaus.org/rat-maven-plugin

External Dependencies

Compliant with current Apache policy.

Cryptography
-
Required to check signatures.

Required Resources

Mailing lists:
* rat-private
* rat-dev
* rat-commits

Re: Project status updates

[Richard S. Hall]

Jukka Zitting wrote:

Hi,

I just cleaned some retired and graduated projects (Heraldry, mod_ftp,
wadi, Kabuki) from the Incubator status page and the reporting
schedule. I didn't want to touch more recent changes, hoping that the
people more involved would take action. The list of missing updates I
noticed is below.

1) The following recently graduated projects still have their entries
under Currently in incubation:

   Felix
   Wicket
   Trinidad


I am traveling right now, but I will put this on my to do list to fix 
for Felix when I get back.


- richard



2) The RCF project does not yet have an entry on the projects page.

3) The log4php project is still listed as retired.

This list might be both incorrect and incomplete.

BR,

Jukka Zitting

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: PPMC guidance on new committers

[Richard S. Hall]

Niclas Hedhman wrote:

On Tuesday 05 June 2007 07:48, Craig L Russell wrote:
  

Hi Niclas,

There is one issue that still bothers me about your proposed ways of
voting. At some point, the nominee has to be asked, and accept, to
become a committer. This would have to be after the private votes are
done and before the public vote. So after the nominee accepts, they
suddenly see a [vote] thread regarding their candidacy on the dev
list and wonder what *that* is about.

I think a public welcome to the new committer would be sufficient
feel good instead of the phony public vote.



I don't know all the communities around ASF, but what I have seen is that 
the acceptance/decline happens after the public vote. Entries to PMCs 
seems more like private vote - accept/decline - welcome in the 
communities I know of.


Mind you, my own opinion in the matter differs from how things are done, for 
instance; IMHO either the vote is public OR private, and if the latter then 
don't have the charade on the public list. That would simplify things at 
Incubator as well.


  1. [Discuss] on [EMAIL PROTECTED]
  2. [Vote] on [EMAIL PROTECTED]
  3. [Vote] on [EMAIL PROTECTED]
  4. [Accept/Decline] in private mail
  5. [Announce/Welcome] in [EMAIL PROTECTED]
  


+1

- richard


Cheers
Niclas

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

  


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[RESULT] Re: [VOTE] Felix Graduation

[Richard S. Hall]

This vote has been open over 5 days, so it can now be closed with the 
following votes:


   * +1 votes: Jean T. Anderson, Paul Fremantle, Bertrand Delacretaz,
 Alex Karasulu, Upayavira, Brian McCallister, Carsten Ziegeler,
 Niclas Hedhman, Enrique Rodriguez, Matthias Wessendorf, Robert
 Burrell Donkin, J Aaron Farr.
   * 0 votes: None.
   * -1 votes: None.

The vote passes.

We would like to thank everyone who voted and/or participated in any way.

We look forward to sending the resolution to the board, however, it 
would still be nice if we could receive some guidance as to how to 
proceed with the next steps or, more precisely, what the next steps are.


Thanks again.

- richard


Richard S. Hall wrote:
The Felix community feels that we are ready for graduation, as 
indicated by the following community vote to request graduation:


http://mail-archives.apache.org/mod_mbox/incubator-felix-dev/200612.mbox/[EMAIL PROTECTED] 



We would like to initiate a vote to graduate to a top level project. 
We would like the resolution attached to this email to be presented to 
the board for consideration at the next possible board meeting.


For additional information, the Felix status file is here: 
http://incubator.apache.org/projects/felix.html


Thank you in advance for your time and consideration.

- richard


## Resolution to create a TLP from graduating Incubator podling

Establish the Apache Felix 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 implementing the OSGi Service Platform
   and other software that is associated with or related to
   the OSGi Service Platform for distribution at no charge to
   the public.

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

   RESOLVED, that the Apache Felix Project be and hereby is
   responsible for the creation and maintenance of
   open-source software implementing the OSGi Service Platform
   and other software that is associated with or related to
   the OSGi Service Platform; and be it further

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

 * Alex Karasulu [EMAIL PROTECTED]
 * Berin Loritsch [EMAIL PROTECTED]
 * Carsten Ziegeler [EMAIL PROTECTED]
 * Matteo Demuru [EMAIL PROTECTED]
 * Enrique Rodriguez [EMAIL PROTECTED]
 * Francesco Furfari [EMAIL PROTECTED]
 * Stefano Lenzi [EMAIL PROTECTED]
 * Marcel Offermans [EMAIL PROTECTED]
 * Noel Bergman [EMAIL PROTECTED]
 * Karl Pauls [EMAIL PROTECTED]
 * Richard Hall [EMAIL PROTECTED]
 * Sylvain Wallez [EMAIL PROTECTED]
 * Timothy Bennett [EMAIL PROTECTED]
 * Trustin Lee [EMAIL PROTECTED]
 * Rob Walker [EMAIL PROTECTED]

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

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

   RESOLVED, that all responsibility pertaining to the Apache
   Incubator Felix podling encumbered upon the Apache Incubator
   PMC are hereafter discharged.

  Special Order 6E, Establishing the Apache Felix Project, was
  approved by Unanimous Vote.

  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [RESULT] Re: [VOTE] Felix Graduation

[Richard S. Hall]

robert burrell donkin wrote:

On 1/22/07, Richard S. Hall [EMAIL PROTECTED] wrote:

snip


We look forward to sending the resolution to the board, however, it
would still be nice if we could receive some guidance as to how to
proceed with the next steps or, more precisely, what the next steps are.


there is some documentation under development:
http://incubator.apache.org/guides/graduation.html

i'll try to find some time to tidy up and commit some more content
i've been working on in the next few days

but please feel free to ask questions here


Thanks. Will do.

- richard


- robert

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Felix Graduation

[Richard S. Hall]

robert burrell donkin wrote:

On 1/16/07, Richard S. Hall [EMAIL PROTECTED] wrote:

snip


## Resolution to create a TLP from graduating Incubator podling

Establish the Apache Felix Project


snip


  Special Order 6E, Establishing the Apache Felix Project, was
  approved by Unanimous Vote.



a little premature...?

(sorry, couldn't resist)

probably want to delete that bit before submitting to the board


That was part of the template we were told to use...if it is not 
supposed to be included, then perhaps it should be deleted from the 
template too.


- richard

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Felix Graduation

[Richard S. Hall]

robert burrell donkin wrote:

On 1/16/07, Richard S. Hall [EMAIL PROTECTED] wrote:

The Felix community feels that we are ready for graduation, as indicated
by the following community vote to request graduation:

http://mail-archives.apache.org/mod_mbox/incubator-felix-dev/200612.mbox/[EMAIL PROTECTED] 



We would like to initiate a vote to graduate to a top level project. We
would like the resolution attached to this email to be presented to the
board for consideration at the next possible board meeting.


+1

(RAT finds quite a number of document which probably should have
license notices. be good to tidy them up before moving to top level)


Every artifact that has been released has the appropriate license files 
and notices. Other non-released subprojects generally have the 
appropriate source headers, but may be missing other pieces. These will 
be resolved as the subprojects proceed toward a release. The status of 
each is maintained here:


   
http://cwiki.apache.org/confluence/display/FELIX/Subproject+Release+Status


We will continue to track each subproject's status here, but please let 
us know if you notice any specific issues that we are missing.


- richard


- robert

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Felix Graduation

[Richard S. Hall]

Apparently we had inadvertently left Upayavira off the PMC list, even 
though we reviewed the board resolution twice...thanks to Niclas Hedhman 
for catching this. I have attached the updated board resolution to this 
message.


Please consider it when casting your vote.

- richard

Richard S. Hall wrote:
The Felix community feels that we are ready for graduation, as 
indicated by the following community vote to request graduation:


http://mail-archives.apache.org/mod_mbox/incubator-felix-dev/200612.mbox/[EMAIL PROTECTED] 



We would like to initiate a vote to graduate to a top level project. 
We would like the resolution attached to this email to be presented to 
the board for consideration at the next possible board meeting.


For additional information, the Felix status file is here: 
http://incubator.apache.org/projects/felix.html


Thank you in advance for your time and consideration.

- richard


## Resolution to create a TLP from graduating Incubator podling

Establish the Apache Felix 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 implementing the OSGi Service Platform
   and other software that is associated with or related to
   the OSGi Service Platform for distribution at no charge to
   the public.

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

   RESOLVED, that the Apache Felix Project be and hereby is
   responsible for the creation and maintenance of
   open-source software implementing the OSGi Service Platform
   and other software that is associated with or related to
   the OSGi Service Platform; and be it further

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

 * Alex Karasulu [EMAIL PROTECTED]
 * Berin Loritsch [EMAIL PROTECTED]
 * Carsten Ziegeler [EMAIL PROTECTED]
 * Matteo Demuru [EMAIL PROTECTED]
 * Enrique Rodriguez [EMAIL PROTECTED]
 * Francesco Furfari [EMAIL PROTECTED]
 * Stefano Lenzi [EMAIL PROTECTED]
 * Marcel Offermans [EMAIL PROTECTED]
 * Noel Bergman [EMAIL PROTECTED]
 * Karl Pauls [EMAIL PROTECTED]
 * Richard Hall [EMAIL PROTECTED]
 * Sylvain Wallez [EMAIL PROTECTED]
 * Timothy Bennett [EMAIL PROTECTED]
 * Trustin Lee [EMAIL PROTECTED]
 * Rob Walker [EMAIL PROTECTED]

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

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

   RESOLVED, that all responsibility pertaining to the Apache
   Incubator Felix podling encumbered upon the Apache Incubator
   PMC are hereafter discharged.

  Special Order 6E, Establishing the Apache Felix Project, was
  approved by Unanimous Vote.

  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
## Resolution to create a TLP from graduating Incubator podling

Establish the Apache Felix 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 implementing the OSGi Service Platform
   and other software that is associated with or related to
   the OSGi Service Platform for distribution at no charge to
   the public.

   NOW, THEREFORE

[VOTE] Felix Graduation

[Richard S. Hall]

The Felix community feels that we are ready for graduation, as indicated 
by the following community vote to request graduation:


http://mail-archives.apache.org/mod_mbox/incubator-felix-dev/200612.mbox/[EMAIL 
PROTECTED]

We would like to initiate a vote to graduate to a top level project. We 
would like the resolution attached to this email to be presented to the 
board for consideration at the next possible board meeting.


For additional information, the Felix status file is here: 
http://incubator.apache.org/projects/felix.html


Thank you in advance for your time and consideration.

- richard
## Resolution to create a TLP from graduating Incubator podling

Establish the Apache Felix 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 implementing the OSGi Service Platform
   and other software that is associated with or related to
   the OSGi Service Platform for distribution at no charge to
   the public.

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

   RESOLVED, that the Apache Felix Project be and hereby is
   responsible for the creation and maintenance of
   open-source software implementing the OSGi Service Platform
   and other software that is associated with or related to
   the OSGi Service Platform; and be it further

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

 * Alex Karasulu [EMAIL PROTECTED]
 * Berin Loritsch [EMAIL PROTECTED]
 * Carsten Ziegeler [EMAIL PROTECTED]
 * Matteo Demuru [EMAIL PROTECTED]
 * Enrique Rodriguez [EMAIL PROTECTED]
 * Francesco Furfari [EMAIL PROTECTED]
 * Stefano Lenzi [EMAIL PROTECTED]
 * Marcel Offermans [EMAIL PROTECTED]
 * Noel Bergman [EMAIL PROTECTED]
 * Karl Pauls [EMAIL PROTECTED]
 * Richard Hall [EMAIL PROTECTED]
 * Sylvain Wallez [EMAIL PROTECTED]
 * Timothy Bennett [EMAIL PROTECTED]
 * Trustin Lee [EMAIL PROTECTED]
 * Rob Walker [EMAIL PROTECTED]

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

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

   RESOLVED, that all responsibility pertaining to the Apache
   Incubator Felix podling encumbered upon the Apache Incubator
   PMC are hereafter discharged.

  Special Order 6E, Establishing the Apache Felix Project, was
  approved by Unanimous Vote.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Incubate new podling, River (nee Braintree, nee..., nee Jini)

[Richard S. Hall]

+1

- richard

Geir Magnusson Jr. wrote:
It is with great relief and hope that I propose that the Apache 
Incubator PMC vote to incubate a new podling, to be known as River. 
You may be familiar with this project as it has been discussed under 
other names, including Braintree and Jini.  I've actually lost track 
of the Quest for a Name, and actually feel very responsible for this 
naming mess, for which I apologize.


Therefore, please vote on the proposal that follows :

[ ] +1 Accept River as a new podling as described below
[ ] -1 Do not accept the new podling (provide reason, please)

The proposal can be found here :

  http://wiki.apache.org/incubator/RiverProposal

and is included below for archival purposes :



 RiverProposal

*Proposal for new project River*

8 December 2006

(0) rationale

Jini technology is a service oriented architecture that defines a 
programming model which both exploits and extends Java technology to 
enable the construction of secure, distributed systems consisting of 
federations of services and clients. Jini technology can be used to 
build adaptive network systems that are scalable, evolvable and 
flexible as typically required in dynamic computing environments.


Quoting from The Jini Specifications 
(http://java.sun.com/docs/books/jini/spec/) book:


Jini technology is a simple infrastructure for providing services in a
network, and for creating spontaneous interactions between programs 
that use these services. Services can join or leave the network in a 
robust fashion, and clients can rely upon the availability of visible 
services, or at least upon clear failure conditions. When you interact 
with a service, you do so through a Java object provided by that 
service. This object is downloaded into your program so that you can 
talk to the service even if you have never seen its kind before - the 
downloaded object knows how to do the talking. That's the whole system 
in a nutshell.


Sun Microsystems originally introduced the technology in January, 1999 
by providing a Jini Technology Starter Kit 
(http://starterkit.dev.java.net/). This includes a contributed 
implementation of all of the specifications, as well as helpful 
utilities and tools. The source code was made available through the 
Sun Community Source License (SCSL) as an attempt to make the code 
widely available and accessible to both individuals and companies. Sun 
has continued to innovate throughout the years, releasing many 
versions of the starter kit. The license associated with the starter 
kit was changed 
(http://archives.java.sun.com/cgi-bin/wa?A2=ind0503L=jini-usersO=AP=36217) 
in March, 2005 to the Apache License, Version 2.0.


Since its beginning, there was desire and effort to form a developer 
community around the technology. This has helped to create an 
interesting, active, and passionate community - the Jini Community. 
This global Community has engaged on technology projects, discussions 
and debates, events, and a decision making process. It has contributed 
to, and helped influence the direction of the starter kit. Some of the 
collaborative technology projects have led to key contributions being 
used by other technology projects as well as commercial products. One 
example is the Service UI API (http://www.artima.com/jini/serviceui/), 
which is a way to attach user interfaces to Jini services.


Despite the obvious successes of the technology and Community, some 
changes are in store as outlined in a recent note to the Community: A 
New Day 
(http://archives.java.sun.com/cgi-bin/wa?A2=ind0604L=jini-usersF=S=P=4029). 
The most critical part of the new plan is to find the right place for 
the future development and advancement of the core Jini technology. We 
wanted an environment that was synergistic with our exisiting 
Community culture -- so one that is active, with open communication 
and collaboration, and a reputation for producing high quality 
software. We think we've found that place with the Apache Software 
Foundation.


(0.1) criteria

/Meritocracy:/

The River project will be meritocractic. The project will follow the 
guidelines 
(http://apache.org/foundation/how-it-works.html#meritocracy) of the 
Apache Software Foundation. In order to achieve this, we plan on 
proactively recruiting individuals in the Community to get involved in 
the project: specifying work that needs to be done, encouraging bug 
fixes, enhancements, and advancements, and engaging in discussion on 
how the code works and is structured. In the end, we are committed to 
creating an environment to foster a meritocracy.


/Community:/

There has been a diverse and active Community built around Jini 
technology since it was first introduced in January, 1999. The Jini 
Community consists of a global set of individuals, companies, 
non-profit organizations, and universities. The Community communicates 
primarily through various email 

Re: [VOTE] Apache Felix 0.8.0 Incubator Release

[Richard S. Hall]

As a follow up, we resolved every issue raised by Daniel except the 
signing portion. A new snapshot of the release is available at:


   http://people.apache.org/~rickhall/felix-0.8.0-incubator.html

I was able to fix one minor bug in our maven bundle plugin that was 
causing LICENSE/NOTICE files to not get copied.


Hopefully the majority vote can continue...

- richard

Daniel Kulp wrote:

I'm not going to vote (would be non-binding anyway), but some issues I see:

1) The felix.jar itself does not have the DISCLAIMER in it.   I think that's 
fine as long as you don't plan on putting it in any maven repository.   That 
said, being a maven user, I'd like to see it fixed so it COULD be deployed 
there.


2) The LICENSE and NOTICE files in the felix jar are right in the root of the 
jar.   I think we've been recommending they go into the META-INF dir.  

3) None of the three jars in bundle directory have the license,notice, or 
disclaimer files.


4) I don't see and asc files on the web page.   The release needs to be signed 
and KEYS made available.


Dan


On Sunday 10 December 2006 08:47, Karl Pauls wrote:
  

The Felix PPMC has voted on an incubator release and we would like to
call an Incubator PMC vote to get final approval.

We hope that this release represents the final step for Felix'
graduation, but wish to pursue this official incubator release since we 
do not know how long graduation will take and feel it is important to

make a public release available. We hope to request graduation once this
incubator release is approved.

The candidate incubator release can be found here:

   http://people.apache.org/~rickhall/felix-0.8.0-incubator.html

We ask that you please vote to approve this release:

[ ] +1 Approve the Felix 0.8.0-incubator release.
[ ] -1 Veto the release (please provide specific comments)

Thanks in advance for your effort in examining the release.

- The Felix Team

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



  


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Apache Felix 0.8.0 Incubator Release

[Richard S. Hall]

Daniel Kulp wrote:

On Monday 11 December 2006 10:57, Richard S. Hall wrote:
  

As a follow up, we resolved every issue raised by Daniel except the
signing portion. A new snapshot of the release is available at:

http://people.apache.org/~rickhall/felix-0.8.0-incubator.html

I was able to fix one minor bug in our maven bundle plugin that was
causing LICENSE/NOTICE files to not get copied.



Not quite there yet.   The incubator DISCLAIMER file is still missing from the 
jars.   That would prevent them going into maven repositories.
  


Is that just a recommendation or a requirement? Our NOTICE files contain 
the incubator disclaimer text.


For the signing part, you really need gnupg installed.Create a key if you 
don't already have one. (I think it's gpg --gen-key, but it's been a while 
since I looked into that part)   Then you just need to run gpg -a -s 
filename.tar.gz to produce the asc files.


You would also need to do:
gpg --list-keys  username  KEYS
gpg -a --export username  KEYS

and get that KEYS file added into the root of your SVN repository.   Ideally, 
you would also upload it to one of the public keyservers as well.   Longer 
term, you should also attend an apache keysigning party or similar to get 
your keys signed by enough apache people so that apache people can trust 
that those keys really are yours.
  


Thanks for this info. We will work on it.

- richard



Dan



  

Hopefully the majority vote can continue...

- richard

Daniel Kulp wrote:


I'm not going to vote (would be non-binding anyway), but some issues I
see:

1) The felix.jar itself does not have the DISCLAIMER in it.   I think
that's fine as long as you don't plan on putting it in any maven
repository.   That said, being a maven user, I'd like to see it fixed so
it COULD be deployed there.

2) The LICENSE and NOTICE files in the felix jar are right in the root of
the jar.   I think we've been recommending they go into the META-INF dir.

3) None of the three jars in bundle directory have the license,notice, or
disclaimer files.

4) I don't see and asc files on the web page.   The release needs to be
signed and KEYS made available.

Dan

On Sunday 10 December 2006 08:47, Karl Pauls wrote:
  

The Felix PPMC has voted on an incubator release and we would like to
call an Incubator PMC vote to get final approval.

We hope that this release represents the final step for Felix'
graduation, but wish to pursue this official incubator release since we
do not know how long graduation will take and feel it is important to
make a public release available. We hope to request graduation once this
incubator release is approved.

The candidate incubator release can be found here:

   http://people.apache.org/~rickhall/felix-0.8.0-incubator.html

We ask that you please vote to approve this release:

[ ] +1 Approve the Felix 0.8.0-incubator release.
[ ] -1 Veto the release (please provide specific comments)

Thanks in advance for your effort in examining the release.

- The Felix Team

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



  


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Tomcat's servlet code in Felix (WAS: Re: Podling Release Requirement)

[Richard S. Hall]

Justin Erenkrantz wrote:
  

It also seems that Felix has forked Tomcat's servlet code - which is okay:

http://svn.apache.org/repos/asf/incubator/felix/trunk/javax.servlet/src/main/java/javax/servlet/GenericServlet.java

However, the copyright years have been altered from the original file
- removing 2004 and adding 2005 - which isn't okay:

http://svn.apache.org/repos/asf/tomcat/servletapi/branches/servlet2.3-jsp1.2-tc4.x/src/share/javax/servlet/GenericServlet.java


(Ideally, Felix should resync with Tomcat once they update their
license block to remove the copyright years; but Tomcat may not be
updating Servlet 2.3.  I'm unsure if an ASF project can relicense
forked code from another project - I'll ask on [EMAIL PROTECTED])



I am a little confused as to the exact solution to Felix' use of 
Tomcat's javax.servlet code.


The reason why the copyright was changed is because the subproject is a 
derivative work based on Tomcat's javax.servlet 2.4 code. The subproject 
downgraded javax.servlet 2.4 to 2.1, which is the version used by the 
OSGi HTTP Service. BJ Hargrave did the downgrade and said he used the 
servlet 2.4 code because it was licensed under Apache license v2, where 
servlet 2.3 and older was under Apache license v1.


Because servlet 2.1 is required, I doubt there will ever be a re-syncing 
of code with Tomcat.


So, what is the appropriate thing to do here? Leave the header unchanged 
or to change it? If we are not supposed to change it, then we can easily 
revert to the old header, but it seems misleading since we modified it. 
If we are supposed to change it, then I imagine we should change it to 
reflect the header at http://www.apache.org/legal/src-headers.html.


Clarification is desired.

- richard

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]