Apache Composer - vote outcome

[Paul Hammant]

In Favor (+1)

  James Strachan
  Bertrand Delacretaz
  Jukka Zitting
  Martijn Dashorst
  Leo Simons
  Davanum Srinivas
  Robert Burrell Donkin
  Craig L Russell
  Eelco Hillenius
  Matt Hogstrom
  Justin Erenkrantz
  J Aaron Farr
  Kevan Miller (with come comments about off-list activity -  
hopefully allayed)


In Favor (non binding)

  Luciano Resende

Don't care (0)

  Jim Jagielski (with some comments about muck raking - hopefully  
allayed)
  Niclas Hedhman (with some concern that our beloved IntelliJ IDEA  
may suffer because of PicoContainer's move)


Thanks for the approval folks.

Stand back and watch for the diffs in coming weeks ;-)

- Paul

Re: [VOTE] Accept Composer in the Incubator

[Paul Hammant]

But not all favorably it appears...



Was there a particular response you were trying to illicit with  
that quote?




Yes. It's called knowledge and background.



What do you want to know? And I can provide any background you  
feel people should know about.


You can't honestly expect to gather a whole lot from a cheeky  
remark uttered 4 years ago.




It's really not all that; I'm not sure what you're getting at.
The proposal makes note of the fact that several people are Apache
committers. Sometimes, people involved in Incubator podlings need
to make tough choices and decisions (like whether to tank it
or not should that ever happen), and so any background which
is appropriate to that discussion should be brought up and out
at the start, rather than it being a potential issue latter
on.



Yup its true that I wrote that. It is mitigated somewhat in  
successive sentences I think, and people (including Jim) that were  
around at the time will remember that I took a stance between two  
protagonists who were diametrically opposed on extension agenda for  
Avalon. I tried to implore the group to search for common ground in  
order to let the (ill fated) project go forward.  I did not agree  
with the boards decision then, but respected its right to make that  
decision.  Perhaps it was inappropriate to rake it over in a 'bio'  
segment for myself.  Or perhaps it would have been more appropriate  
to remove that reference years ago, when the event in question was  
less important to me.  Thus the obvious conclusion - fix it now  
(watch for changes).


Since that project schism, Inversion of Control (and its subset  
Dependency Injection) have gone mainstream for Java - even Sun have  
noticed ;-).  The fate of the idea is no longer dependent on harmony  
of one project.


I'm four years older now and much more able to spot the early signs  
of discord, and leverage better techniques for keeping all happy and  
joined-up in a common direction.  Not that I'll be leading 'Apache  
Composer' of course.


Regards,

- Paul



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

Re: [VOTE] Accept Composer in the Incubator

[Paul Hammant]

Well I'm back from vacation :)

The discussion was almost entirely done off-list.  First Jason and I  
kicking the tires of the idea, then with respective co-leads,  
committers etc.  It was pretty extensive.


Why secret ?  PicoContainer and Plexus are two containers in a field  
that is quite full them.  Spring Framework dominates, Guice (very  
very similar to PicoContainer's traditional ideals, but three years  
later) has the magic Google brand that makes it very successful.  We  
wanted to define our fate in private without bloggers pitching in  
with "Pico is crap compared to Spring", or "Pico is a cheap copy of  
Guice" (etc, etc).


Of course we're aware that the Apache way is not off-list activity,  
so consider it the last hurrah of the despot models for Pico/Plexus


- Paul

On Oct 23, 2007, at 10:14 PM, peter royal wrote:


On Oct 23, 2007, at 1:46 PM, Kevan Miller wrote:
I took a peek at plexus and picocontainer mailing lists. One thing  
of note is that there seems to have been little discussion on the  
picocontainer lists about a move to Apache. Perhaps discussions  
were offline, but it's not clear to me how their community, beyond  
Paul Hammant, feels about the move... I don't see a big issue with  
this (at least not anything that won't be sorted out by  
incubation), just passing along what I learned...


well, that's kinda par-for-the-course with the pico community.. its  
pretty darn silent :)


fwiw, there were offline discussions, and the entirety of the  
active committership was involved.


-pete

--
(peter.royal|osi)@pobox.com - http://fotap.org/~osi

Re: [VOTE] Retire AltRMI

[Paul Hammant]

The mentor and lead (cough) I mean person who made most commits. I've  
also voted +1 for retirement@ Apache.


There are tons of things wrong with AltRMI that precluded a 1.0  
release.   That notwithstanding the fact that it went out in a couple  
of releases of http://enterpriseobjectbroker.org/


  * the callback side of it (duplex if you like) had some flaws in  
that it would not scale very well and would create problems in the  
attempt to recover a connection
  * there are some logical holes in the client/server  
communication ... handshaking if you will

  * nothing about it is robust or hardened against hackers.
  * its Stub generator (Javac based) was well past in sell by date,  
and one could suggest in the age of dynamic proxies is not needed
  * 20% of its code was bound to Avalon which just ain't needed  
these days.
  * coverage was pretty low. no unit tests, although many  
integration tests

  * arcane naming of classes, methods and concepts.
  * I could go on..

As it happens a massively reworked version lives at Codehaus ->  
http://svn.jremoting.codehaus.org/ (no site) with many features  
deleted. It is a fork yes. Most of the code that survives has a  
copyright statement crediting Apache - like http:// 
svn.jremoting.codehaus.org/browse/jremoting/jremoting/trunk/api/src/ 
java/org/codehaus/jremoting/server/StubRetriever.java  A much smaller  
number of genuinely new classes are copyrighted to just "The  
JRemoting Committers" - http://svn.jremoting.codehaus.org/browse/ 
jremoting/jremoting/trunk/server/src/java/org/codehaus/jremoting/ 
server/transports/ServerXStreamDriver.java  All is Apache licensed of  
course rather than my more usual BSD


Regards,

- Paul


On Nov 6, 2006, at 10:06 PM, Leo Simons wrote:


On Nov 6, 2006, at 9:01 PM, peter royal wrote:
The AltRMI podling,  has become stagnant. Here is a vote to move it into  
retirement.


[ ] -1 : It lives on, you someone missed my recent commits on it  
last week

[ ]  0 : I don't do fall cleansing
[ ] +1 : Move to retirement

Here's my +1


+1.

Shame though. Such a great codebase it is. So much "just works"  
feeling attached to it no-one needs to work on it.


Heh. Perhaps we can prod some of its contributors (who moved on to  
bigger and greater things long ago as far as I know) to contribute  
some of the good bits as a replacement RMI module to Harmony, and  
have AltRMI eclipse RMI many years after it was first envisioned.


Or maybe not :)

cheers,

Leo




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

Re: [VOTE] Retire AltRMI

[Paul Hammant]

The AltRMI podling,  has become stagnant. Here is a vote to move it into  
retirement.


[ ] -1 : It lives on, you someone missed my recent commits on it  
last week

[ ]  0 : I don't do fall cleansing
[ ] +1 : Move to retirement


+1

-Paul


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

Re: [Ftpserver] Comments on the new code

[Paul Hammant]

IMHO, the basic design and implementation should be XML free and  
provide a
straight forward API for assembly, configuration (preferably  
atomic) and the
other stuff. Any runtime platform support can be added on top of  
that. Look

at Jetty for an example of this approach.

Now, Noel's suggestion for OSGi as the runtime platform is  
interesting, if for
no other reason than it allows for hot deploy and reloads. But I  
think it
would be possible to provide a BundleActivator and register the  
service(s)
even if FtpServer does not require OSGi by definition, if the above  
approach
is done well (again Jetty is an example of OSGi bundle on top of  
its API).


You're assuming that frameworks other that OSGi cannot do hot deploy,  
but yes the general idea is to have something akin to POJOs with no  
extends/implements/throws from any framework and optional enablers to  
other frameworks in separate classes or module etc.


It has to be said though that OSGi is on a different branch of the  
IoC family tree to DI favoring frameworks.


- Paul

Re: [Ftpserver] Comments on the new code

[Paul Hammant]

You should aim to ship with neither Spring nor PicoContainer.

It is perfectly possible to construct a set of DI components that  
comprise FtpServer and in a main method do :


  Foo foo = new Foo();
  Bar bar = new Bar(foo);
  Apple apple = new Apple();
  apple.setFoo(foo);
  apple.setBar(bar);

This way, open doors for others to take your components and ship  
standalone, or using Spring as part of a later app, using Pico as  
part of a larger app, using Geronimo or using EJB 3.0 (etc).   
Choosing a DI framework early is nuts.


- Paul

On Oct 1, 2005, at 5:52 PM, Niklas Gustavsson wrote:


Paul Hammant wrote:

OK, if we're keen about Dependency Injection, we'd need to change  
a  lot.  The basic FtpConfig component should have little  
knowledge of  UserManager (and others), and no coupling to it...




If we do aim for a DI/IoC approach (and I think we should), should  
we choose a DI implementation (Pico, Spring...) that we ship as the  
default implementation? Or, should we try to implement a  
specialized runtime ourselves? I would certainly go for the former  
option and would favour Spring but I'm guessing that Paul won't  
agree on this choice :-).


/niklas


-
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: [Ftpserver] Comments on the new code

[Paul Hammant]

The package ftplet is the basic API required to add
custom user specified ftplets. The server needs
slightly modified version of these APIs. Ftplet API is
somewhat fixed but server API may get changed in
future. This is the reason behind this difference. The
 following two hierarchy will clarify this.

FtpConfig <- IFtpConfig <- FtpConfigImpl
FtpStatistics <- IFtpStatistics <- FtpStatisticsImpl



OK, if we're keen about Dependency Injection, we'd need to change a  
lot.  The basic FtpConfig component should have little knowledge of  
UserManager (and others), and no coupling to it...


  class XStreamFtpConfig implements FtpConfig { }

  class FooUserManager implements UserManager {
FooUserManager( FtpConfig c ) {
  // whatever
}
  }

  class SomethingComponentThatRequiresUserManager {
SomethingComponentThatRequiresUserManager( UserManager um ) {
  // whatever
}
  }

Also, for the record, a reusable component should not make a logging  
framework choice :-)
Better would be a Monitor and an adapter to one of a number of  
Logging Framework implementations.


- Paul



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

Re: [Ftpserver] Paul Hammant's Observations

[Paul Hammant]

I did not get this mail in
[EMAIL PROTECTED] So I missed it.

Anyway, these are the points.

1. I can see ftplet directory src and binary
distributions. Which ftplet directory are you
mentioning?


my mistake, a cvs update -d did the trick.


2. Now I am working on maven support. When I tried to
merge Maven support patch by David DeWolf, I noticed
many checkstyle errors and I need to change all the
document xdoc files. So I would have missed 15th
September. I shall commit all Maven related changes
soon.


Kewl


3. In my opinion multiple subprojects complicate the
structure. So I have merged these into one. If
necessary we can change the build script to
include/exclude ftplet or gui folders to make separate
jar files.



Well we'll differ on that then.

In my opinion these are design goals:

1) Remote usage, requires remote API, but not server impl to be in  
the jar


2) Third party ftp-lets should, in terms of classloader, be  
completely hidden from the server implementation.  They should only  
see J2SE classes, plus the FtpLet API


This is the same design as the servlets.

Also, I've bumped the license rev to 2.0 as per Apache requirements.

- Paul



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

Re: cvs2svn: altrmi + ftpserver

[Paul Hammant]

Lets set a target date for completion of work against copy taken from  
CVS. People have work outstanding that is _much_ better applied to  
the SCM is was taken from than another.


Say cut over on or around 15th Sept ?

- Paul

On Aug 26, 2005, at 3:41 PM, Niklas Gustavsson wrote:


Paul Hammant wrote:


If we were
in Subversion there would be even more room !



How can we make this happen? Having FTPServer in SVN would be great.

Re: cvs2svn: altrmi + ftpserver

[Paul Hammant]

Rana,

Welcome back.


I was busy for the last 2 yesrs. So I could not touch
it. Anyway, I have started working on it about 2
months ago. I guess it will take one more month. These
are the things I have done.

1. Got rid of Avalon. As Avalon project is defunct,
there is no point using it.
2. Implicit and explicit SSL/TLS support.
3. Ftplet API has been implemented.
4. User defined message support.
5. Removed RMI based administrator UI. All these
things can be done using SITE command. So there is no
point complicating the server.
6. Whole new documentation.
7. Added provision to support i18n later.



Fantastic feature set.


The basic objective is simplicity and zero dependency
on other libraries. We should not complicate it unless
we have some compelling reasons. If you want to take a
look I can send the source code. But at this point it
is not ready to publish.


There is the big problem dude :-)

The code @ Apache is being slowly morphed by myself based on the  
contributions from some new friends of FtpServer.  Its great that so  
many people are interested, but please, one by one or all at a time,  
commit your changes to FtpServer here rather than continue with a  
long rework. We trust you to do great work, but in my experience  
there is plenty of room for people to commit to the same code-base.  
If we were in Subversion there would be even more room !




As I have done a massive refactoring, instead of
dumping the existing source we can dump the new source
after one month.



Confused ...


BTW, a logo and product name will be useful. I was
thinking about "Jadoo". Please do suggest what you are
thinking.


A new product name is alluring.  I suggest the time to finalize on  
one would be on exit from Incubator.


- Paul



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

Re: cvs2svn: altrmi + ftpserver

[Paul Hammant]

I'm listed ( paul ) as manager of FtpServer, but I can't close  
issues.  Can someone upgrade me :-)


- Paul


On Aug 24, 2005, at 12:18 PM, Leo Simons wrote:


Make your requests right here, if they're not
handled escalate to infrastructure at apache dot org, or file an  
issue in

the INFRA jira.

Re: cvs2svn: altrmi + ftpserver

[Paul Hammant]

Well FtpServer at least seems to have some activity all of a sudden.

Who is admin for issues.apache.org ?

Regards,

- Paul

On Jul 25, 2005, at 2:23 AM, Henri Yandell wrote:


Just wondering, are altrmi and ftpserver still active and planned for
subversion at some point, or are they more likely to be archived?

Hen

-
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]: On " PROPOSAL : Apache Harmony - J2SE 5 Project"

[Paul Hammant]

Yeah yeah, its a confusing Saturday so far. I was -ve to start with 
(pointless with given size of vote so far) thinking there were some 
legal problems. I read more before completing the mail (rules for J2SE 
implementations from the OSS community) and figured that the angles had 
been covered thoroughly by foundation lawyers, and send the +ve vote 
instead (as a new mail). Unfortunately, the -ve response I drafted 
earlier sat beckoning me to hit send as it languished in my drafts 
folder. In a moment sheer impudence, and unbeknownst to my conscious 
mind, my right hand released it from the Mac-Mail draft folder instead 
of deleting it.

Thus ignore the -1 mail.
The thing I think is most interesting, is the possibility of writing a 
JVM first, for language compatibility, then an AWT toolkit and all the 
things that bind the Java env to a machine ( 
http://java.sun.com/j2se/1.4.2/docs/api/java/awt/Toolkit.html etc).

At that stage, and well in advance of the completion the J2SE 
libraries, an individual in the privacy of their own home could 
experiment with the those two and the jars taken from a regular Sun 
download of J2SE. Of course nothing could be distributed with those 
jars, nor deployed or redistributed beyond that experimental basis as 
Java's download license precludes that.

- Paul
On May 7, 2005, at 4:32 PM, Geir Magnusson Jr. wrote:
On May 7, 2005, at 3:39 PM, Paul Hammant wrote:
-1 I'm not sure the

On May 7, 2005, at 4:06 PM, Paul Hammant wrote:
+1 provided copyright and trademark issues are appropriately 
considered.

So right now, you are at 0 :)
For instance, we may have to always mechanically  refer the project 
and product(s) as "Apache Harmony" rather than just Harmony.

http://tess2.uspto.gov/bin/showfield?f=doc&state=8rlf0q.2.1
If we have a name problem, we change it.  And yes, we refer to things 
that are Apache $foo projects as Apache $foo unless we can't use $foo 
for software

geir
- Paul
On May 6, 2005, at 6:18 PM, Noel J. Bergman wrote:

+1
--- Noel

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

--
Geir Magnusson Jr  +1-203-665-6437
[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]

Re: [VOTE]: On " PROPOSAL : Apache Harmony - J2SE 5 Project"

[Paul Hammant]

+1 provided copyright and trademark issues are appropriately considered.
For instance, we may have to always mechanically  refer the project and 
product(s) as "Apache Harmony" rather than just Harmony.

http://tess2.uspto.gov/bin/showfield?f=doc&state=8rlf0q.2.1
- Paul
On May 6, 2005, at 6:18 PM, Noel J. Bergman wrote:
+1
	--- Noel

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

Re: [VOTE]: On " PROPOSAL : Apache Harmony - J2SE 5 Project"

[Paul Hammant]

-1 I'm not sure the
On May 6, 2005, at 6:18 PM, Noel J. Bergman wrote:
+1
--- Noel
-
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: Harmony: project purpose

[Paul Hammant]

If we want to integrate any new code produced by the Harmany effort 
into
any of the existing projects, many of which are under the GPL or only
accept code compatible with the GPL, and since the Apache Incubator
terms allow modern BSD, MIT/X or MIT/W3C terms I think that is probably
the best we can do for now. But as said before if we can (ab)use the
Harmony project to get a strong signal to BOTH the FSF and ASF to fix
any remaining incompatabilities between (L)GPL and ASL then lets do
that!
Unless I am mistaken, Apache licensed code will never be able to 
'legally' import GPL code.

The logic behind this -
GPL code can can import BSD, MIT, X11, W3C (etc) code but cannot 
currently Apache licensed.  That may well be worked out with an 
revision to the Apache Software License 2.0.

BSD (etc) is not currently able to import GPL licensed code.
Why would Apache licensed code be any different even if the current 
issue were worked thru?

Its the lack of a reciprocal arrangement on legal/allowed importing 
that is the long term blocker on ASF / FSF cooperation.

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

FtpServer in the incubator - help needed!

[Paul Hammant]

Geronimo Folks,
Once upon a time, in the very early days of the incubator, a small 
project was moved there from the Avalon codebase. It was a bit of an 
unusual way for a project to move to the Incubator, and it did not come 
with the usual community dynamics expected of projects arriving in 
Apache. Essentially it was Rana Battacharyya and me. Rana used to work 
in the US, but returned home to India after the downturn (got married 
etc etc etc) and now dials up.

The project in question was called FtpServer.  It is wholly dependant on 
Avalon-Framework and the former Phoenix container.

I'm half way thru refactoring the code to *also* be Constructor 
Dependency Injection (CDI) capable. That will mean that essential at the 
simplest, an embeddor could do ..

 FtpServer ftpServer = new FtpSeverImpl();
 ftpServer.start();
Anyway, this stuff is too good to languish there uncompleted.
*What is needed is some new committers*
Given that it would be so cool to run this puppy integrated with 
Geronimo (an optional GBean plugin), I think it would be great to 
solicit interest here.  Now, we can't just say "you, you and you, you're 
in as committers" - Apache does not work that way, at least not for 
non-committers.  What we can say is that patches will be recieved 
gratefully and in time, and on merit, invitations for committer /may/ be 
offered. That's the case for all Apache committerships - they're 
informally offered, never sought.  In the mean time, from the Geronimo 
developers, those with a hankering to do more than they are doing - 
please duck into the [EMAIL PROTECTED] list.

TODO ...
1) Complete refactoring to so that FtpServer may be deployed without 
Avalon - note this is not the removal of Avalon capability
2) Put in GBean enablers (I say this thru gritted teeth Dain :-)
3) Work on Ftplet (think Servlet but for FTP instead of HTTP)
4) Unit / Integration tests :-)
5) Loom/Phoenix/Merin compatability work
6) Mavenisation

Any others ?
Avalon people - get interested too :-)
- Paul & Rana
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: status of FTP Server project

[Paul Hammant]

I need to be able to use the FTPServer within my process (for junit-based
testing purposes). Is there a way I can do that ?
 

Yes you can (with some level of effort) instantiate Avalon components 
from a normal class without a container such as Phoenix or Merlin. See a 
class called "Standalone" in the source of Enterprise Object Broker at 
Sourceofrge. 

From reading the Phoenix docs, I would have start up the Phoenix server
with FTPServer deployed (as a block). This would be an impediment.

Any pointers would help.

thanks,
raghu
ps: I need to be able to ftp files (in junit tests) and do some 
verification. So,
am exploring if I can use FTP Server as an in-memory service.
 

There is a jftp client at sourceforge. maybe that is what you want.

- Paul







Rana Bhattacharyya <[EMAIL PROTECTED]>



10/28/2003 11:35 PM
Please respond to general
T
To: [EMAIL PROTECTED]
cc: 

bcc: 
Subject:Re: status of FTP Server project

Hi,
The FTP server project is very much active. The code
base is very much stable and the doc is also available
(may not be very exhaustive). 

You can check the site 
http://incubator.apache.org/projects/ftpserver/

Thanks,
Rana


--- [EMAIL PROTECTED] wrote:
 

Hello,

I would like to know the status of the FTP Server
project in terms of
releases, timeline, usage docs etc.
Also, are there any other alternative open-source
Java-based
FTP Servers out there ?
thanks,
raghu
   



__
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




 



--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...


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

Re: [VOTE] New Chair (Re: cvs commit : incubator STATUS)

[Paul Hammant]

In ThoughtWorks we try to pair (no need 
to introduce XP is there?) on as much as possible... works well.  It can 
even work distributed.

- ph

Hi,

On Thu, 18 Sep 2003 14:51:13 +0200
"Sander Striker" <[EMAIL PROTECTED]> wrote:
 

I thought the same thing. Also, to tell the truth, I think that 
in Incubator, there need at least two or three persons who
have real power. (One Chair and two Vice Chair?)
 

 

Why would we need more people with 'real power'?  Or, more importantly,
what powers do you see that others should be able to wield aswell?
   

I've just implied :) 
the "check and balance" deterrent
as well as
the propelling *energy*
for the Incubator project in open and good manner.

The number "3" would be also nice. Eastern cultures would 
prefer to use this number ;-) [OT].
 



--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...


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

Re: XNode 1.1 API submission

[Paul Hammant]

Murray,

Please have a little patience with us dude.  We're embroilled in 
discussion on PMC chair, and other incoming projects presently.

- Paul

Since I've had no reply to my request, could somebody at least
point me to any existing process by which submissions to the
incubator are made? I realize you're all busy with this voting over
leadership, so I could begin putting together whatever package is
expected for a proposal. I've read the online docs, but they're
currently pretty minimal -- I understand this is all in the works,
but I would like to submit XNode to be a part of Xindice 1.1 if at
all possible.
The XNode 1.1 API is under ASF license, there are AFAIK no current
IPR issues with it, and I've filled out the contributor license.
What next?
Thanks for any assistance,

Murray

... 

Murray Altheim 
http://kmi.open.ac.uk/people/murray/
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, 
UK.

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




--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...


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

My candidacy for Incubator PMC chair.

[Paul Hammant]

As with the others I nominated myself :-)  After Nicola, but before Ken.

  
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgId=793128

Just a reminder that I'm not some rumor, and that I am up for it :-)

I stand for ...
* helping projects/teams come in, provided the fit is good.
* ensuring the incoming commmunity is well founded.
* protecting the Apache brand.
* helping people understand that Apache will not rush committers on to 
their project, solve their problems.

I also believe in (twisting Kennedy) "Ask not what Apache can do for 
you, but what you can do for Apache".

Regards,

- Paul

--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...


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

Re: [VOTE] New Chair (Re: cvs commit : incubator STATUS)

[Paul Hammant]

== == == == == == == == == == == == == ==

Note:

"Who is Nicola Ken Barozzi?"
...  http://www.apache.org/~nicolaken/
...  http://jakarta.apache.org/site/whoweare.html
"Who is Ken Coar?"
...  http://www.apache.org/~coar/
...  http://ken.coar.org/
"Who is Paul Hammant?"
...  http://www.apache.org/~hammant/
...  http://www.thoughtworks.com/
 

"Who is Paul Hammant?"
http://www.thoughtworks.com/profiles/?Hammant,+Paul
http://www.thoughtworks.com/
- Paul

--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...


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

Re: Proposal: JaxMe as an implementation of JAXB

[Paul Hammant]

Nicola,

Section 4: identify the initial set of committers

#  Jochen Wiedmann (JaxMe? project founder, formerly perl.apache.org)
# Robert Burrell Donkin (jakarta.apache.org/commons)
With a couple of Apache old hands on board, perhaps the Incubator PMC 
can have a light steerage of this one.  Robert and Jochen (still an 
Apache committer?) can lend calm shepherding to this?  It is not as if 
this is a project founded from people entirely new to Apache. That with 
some small reporting obilgation to the Incubator PMC

Thoughts?

- Paul

--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...


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

Re: Official Apache Directory Project Proposal Submission

[Paul Hammant]

Noel,

I would personally recommend to ask the hsqldb guys (http://hsqldb.sf.net)
   

Absolutely.  I had that in my original post, pre-editting.  The license is
compatible except, as I understand it, for the fact that the original author
wants his name
 

Thomas works for a commercial RDBMS company. License change has been 
raised before :-(  I'm a part time committer on that project.

- Paul

--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...


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

Re: Proposal: JaxMe as an implementation of JAXB

[Paul Hammant]

+1

Proviso :-

CVS repos should be incubator prefixed not ws ..
ws.apache.org  should be incubator.apache.org
Regards,

- Paul
[ Incubator PMC member, not in this reply speaking on behalf of the PMC ]

Hello,

in compliance with a previous vote on webservices-general (see 
http://marc.theaimsgroup.com/?t=10619838661&r=1&w=2 and 
http://nagoya.apache.org/wiki/apachewiki.cgi?JaxbProposal for details) 
I would like to propose the JaxMe project for incubation. The proposal 
is available on

http://nagoya.apache.org/wiki/apachewiki.cgi?JaxMeProposal

I'll add it also below.

Regards,

Jochen





 

JaxMe - Proposal for an Apache implementation of JAXB

10 Sep 2003 : Davanum Srinivas ([EMAIL PROTECTED]) and Jochen Wiedmann 
([EMAIL PROTECTED])

Section 0 : Rationale

The specification for Java/XML binding (JAXB) describes a customizable 
mapping between an instance of XML Schema and a set of Java classes 
being generated by the JAXB implementation. A JAXB compliant binding 
compiler creates

   - a SAX 2 handler that is able to parse a conforming XML instance
   - a Java bean that allows to store the information read by the parser
   - a Marshaller that is able to convert the Java bean back into an
 XML instance which is equivalent to the original XML instance
Details on JAXB can be found on http://java.sun.com/xml/jaxb/.

From the view of the Apache project, JAXB is important, because it is 
going to be a requirement in a series of upcoming Java standards, in 
particular JAX-RPC 2.0 (in planning stage at JCP - 
http://jcp.org/en/jsr/detail?id=224) and J2EE 1.5. In other words, a 
JAXB implementation will be required by Axis and Geronimo.

From the view of the JAXB users, an Apache sponsored implementation is 
important, because it would be open: Source generators tend to be 
usefull only as far as you can extend and customize them to your 
individual needs. A proprietary implementation like the JAXB reference 
implementation can be open to a certain extent only.

Section 0.1 : criteria

Meritocracy: The project will be based on JaxMe 2 (see below), which 
is already following meritocratic guidelines. The usual Apache 
meritocracy rules would apply in the future.

Community: The existing community is small, because the project didn't 
have much audience in the past. However, it can be said to be 
constantly growing. The user community for this project is potentially 
massive, because JAXB is the first standard for Java/XML binding.

Core Developers: The initial developers are listed below and consist 
of existing and emerited Apache comitters. Some other developers have 
already expressed their wish to help and become committers.

Alignment: Axis requires a JAXB implementation as part of JAX-RPC 2.0. 
Geronimo requires JAXB as part of J2EE 1.5. However, JAXB is obviously 
usefull as a standalone project, because its place is whereever XML 
marshalling and/or unmarshalling is happending.

Section 0.2 : warning signs We feel that this project has a good 
chance for success as the following warning signs do not apply to the 
project we are proposing :

Orphaned products: The code base being used was rewritten from scratch 
just some months ago. The predecessor has been used as a mature 
product in large scaled applications.

Inexperience with open source: The initial community is made up of 
existing Apache committers.

Homogeneous developers: The current list of committers consists of 
individuals which found themselves on the JaxMe mailing list simply 
because of interest in JAXB.

Reliance on salaried developers: None.

No ties to other Apache products: At first glance JaxMe might seem in 
conflict to Betwixt or XMLBeans. However, JaxMe is clearly different. 
Betwixt is using Java Beans as the origin. XMLBeans is also using an 
XML Schema, but doesn't currently have a runtime or a code generator 
implementing JAXB. In contrary, it seems reasonable to combine 
XMLBeans and JaxMe at some point: XMLBeans might use JaxMe internally 
as a generator to implement JSR-31.

A fascination with the Apache brand: The JaxMe development will 
continue, regardless of the acceptance by the ASF.

Section 1 : scope of the project As a possible part of Geronimo, JaxMe 
is aimed to become a fully compliant implementation of JSR-31. Again, 
as part of Geronimo, it should even be able to pass the JAXB 
compliance kit (JCK).

Section 2 : initial source from which the project is to be populated

The following modules are being included into the Apache CVS:

* JaxMeXS, the JaxMe parser for XML Schema; this is an extensible 
XML schema parser, particularly developed for implementation of XML 
schema extensions like JAXB. The parser can be replaced at a later 
time. See http://jaxme.sf.net/JaxMeXS/ for details.

* JaxMeJS, the JaxMe java source generation framework, a generic 
framework for complex Java source generators. Unlike typical J

Re: We want to donate a XML / Cocoon / EJB / WebStart - based CMS

[Paul Hammant]

Sascha,

Yes, thats ok. I just want to make sure that at least one of our
developers needs to be a committer for the project.
 

A small problem

Apache is concerned that teams arrive, and healthy communitys form and 
continue. The manner in which the project arrives drives how many (if 
any) committers arrive.

If you are donating code to an existing project (project at the level of 
a build file) it is likely that the code will arrive before the 
committers do.  The normal rule of thumb for a person submitting patches 
on an frequent basis to a project is that after a few months they may be 
proposed and voted on for committer status. For a person that donates a 
considerable amount of code or someone who's already an Apache committer 
it could be shortened I guess.  Tis a little muddy concerning a group 
who donate code to a project.

For group/projects applying for Apache project status themselves (under 
Incubator, Cocoon, etc etc), the team would all arrive (or a sensible 
subset of people active for the last six months of the project in its 
prior incarnation). They'd fill out the forms and get accounts. A aulity 
control should be applied by the team to only really take the people who 
are active. The polite thing to do one exit from, say, sourceforge would 
be for all in the team to agree who is dropping off the project before 
arrival to Apache. An assumption of course that the project is accepted 
on application.  Please do your research (mail archives etc), before 
embarking on this route.

The point is that "I just want to make sure that at least one of our 
developers needs to be a committer for the project" is not a usual 
posting. You have to be mindful that the community around the code (for 
new projects) is more important that the code or the needs of one 
person. And mindful that a collection of classes to and existing 
codebase is just a large patch.  As such and "..I need.." and "..one 
developer.." is undesirable wordage.

I'm not trying to discourage, just set expectations.

Regards,

- Paul H
(with Nicola, Incubator PMC member)
--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...


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

Re: JIRA @ ASF (was: Re: policy question)

[Paul Hammant]

Jeff,

I think the 'empowered' part is where Bugzilla falls down.  I don't know
about Scarab, but JIRA administration is mostly done through the web
interface.  Project-specific admins can be specified, who are allowed to
create new versions/components for their project.
 

Don't forget that the import and export can be in XML via the web-admin 
forms. That's how we (commercial install) handle some of our upgrades on 
versions of Jira. Can handle huge import files very happily.

As such, lock-in was not on the feature list for Jira.

- Paul

--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...


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

Re: JIRA @ ASF

[Paul Hammant]

Though there's no reason, given some hardware and a volunteer, why we 
couldn't install JIRA at Apache.
   

I volunteer :)  Hacking JIRA is my day job.

I don't really see the need though.  Bob is doing a fine job hosting JIRA
on werken.com.  I'm sure that backups to ASF hardware could be arranged
if that were really an issue.
But if a) Bob would like to offload the job, b) infrastructure peeps
prefer to keep bugtrackers on ASF hardware, then if someone can toss me a
nagoya account I'll set up a pilot JIRA installation.
 

I'm using Jira at a client site, and it is really sweet. All that use it 
love it.

+1 FWIW

- Paul

--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...


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

Re: [PROPOSAL] Creating graveyard.apache.org

[Paul Hammant]

Andy,

What are we planning to put in the morgue ?

- Paul

What about "morgue".
   

The things may be dead, but the living still want to poke them about a bit
before they are finally buried.. or perhaps brought back to life again in
the "return-of-the-living-dead.apache.org" project.
 



--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...


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

Re: Updating the incubator site (Re: [geronimo] geronimo website)

[Paul Hammant]

Greg,

Paul -- please set your umask [on login] to enable group-write on the files
in /www/incubator.apache.org. It is making it very difficult for others to
update the site :-)
 

I've 755'd all in my name. I think that is enough..

- Paul

--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...


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

Re: Updating the incubator site (Re: [geronimo] geronimo website)

[Paul Hammant]

Geir,


http://incubator.apache.org/updating_docs.html


Site now updated.


Thx - problem is, I didn't check in the html and pdf - I figured that  
you'd use forrest to regen.  Can it be done again?

This time genned and updated. Great work.
Sigh, my hastily penned words did not last long! 

- Paul

--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...


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

Re: [VOTE] create a new geronimo@incubator.apache.org mail list

[Paul Hammant]

Richard ,

I think the vote is restricted to PMC and board members (my +1 for the 
former) rather than committers (in waiting or otherwise), but welcome 
aboard anyway :-)

- Paul

+1

James Strachan wrote:

 

Wow. There's already been a ton of mail and its not even been 24 hours
of being public yet. I expect the traffic to keep rising, especially
when the sites up etc.
So to avoid drowning out other general-incubator discussions and to
help keep the noise down for folks who only want to keep track of
geronimo I'd like to propose a new geronimo-only mail list be created.
How about

   [EMAIL PROTECTED]

Here's my +1

(and I notice as I'm about to send, Sander's already +1'd too :)

James
---
http://radio.weblogs.com/0112098/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
   

--
Richard Monson-Haefel
Author of J2EE Web Services (Addison-Wesley 2003)
Author of Enterprise JavaBeans, 3rd Edition  (O'Reilly 2001)
Co-Author of Java Message Service (O'Reilly 2000)
http://www.Monson-Haefel.com


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


 



--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...


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

Re: Updating the incubator site (Re: [geronimo] geronimo website)

[Paul Hammant]

> I've added a page documenting this.  When the site refreshes, it will
> appear at:
> 
> http://incubator.apache.org/updating_docs.html

Site now updated.

-ph


Want to chat instantly with your online friends?  Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/

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

Re: JBoss people are asking to review the code

[Paul Hammant]

And also, should this happen before the code is posted in a CVS
repository.
Hen

On Wed, 6 Aug 2003, Ceki [iso-8859-1] G?lc? wrote:

 

Hello,

I have received a request from Sacha Labourey (from the JBoss group) to
review the existing code in our J2EE project to check whether there any IP
issues with respect to the JBoss group. Sounds like a reasonable request to
me. Are we ready to allow this, and if not, why not?
Please note that Sacha is copied on this message.
   

Not necessarily in either case.  One for the lawyers to decide, as NDAs (prior to publication under ASF License) may be required.  

- Paul
(not an authority)
--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...


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

Re: [PROPOSAL] An Apache J2EE server project

[Paul Hammant]

Geir,

+1

If voting on this is required at all. The Board deems this strategic, 
and thus I believe it is in already. A vertable who's who of J2EE 
computing seems to be on the ticket, Geronimo!

- Paul Hammant
Incubator PMC

Proposal for an Apache J2EE server project
==
05 Aug 2003 : Geir Magnusson Jr., James Strachan and Richard 
Monson-Haefel

Section 0 : Rationale
-
The Java 2, Enterprise Edition (J2EE) platform is employed widely by
organizations implementing enterprise applications. It is commonly 
used in
business-to-consumer and most recently in Web service deployments.  
Most of
the largest business organizations today have deployed applications on a
J2EE platform.

While the J2EE specification is implemented by a number of large and 
small
vendors, there is no open source J2EE container available with a BSD or
BSD-derived licence nor is there an open source project today that 
provides
a fully compliant implementation.  Verifiable compliance with the J2EE
specification is important to business because it ensures that 
applications
deployed by developers are portable and interoperable across J2EE 
providers.
As a result organizations large and small have felt compelled to pay
thousands of dollars to commercial vendors in order to deploy 
applications
based on J2EE compliant servers.

The Apache foundation supports several projects that implement pieces 
of the
J2EE platform such as Servlets, JSP, Tag Libraries, and a Web services
stack. However, Apache does not currently support a J2EE project.

The aim of the project is to produce a large and healthy community of 
J2EE
developers tasked with the development of an open source, certified J2EE
server which is ASF licensed and passes Sun's TCK reusing the best 
ASF/BSD
licensed code available today and adding new code to complete the J2EE
stack.

Section 0.1 : criteria
--
We feel that this project has a good chance for success as the following
project aspects are carefully considered :
a) Meritocracy: The project will be meritocratic - the usual Apache
meritocracy rules would apply.
b) Community: The user community for this project is potentially massive.
The initial developer community for this project consists of 
developers from
Apache,  Castor, JBoss, mx4j, and OpenEJB projects. The aim is for this
community to grow considerably once this project goes public.

c) Core Developers: The initial developers are listed below and 
consist of
some existing Apache committers together with committers from Castor,
JBoss, mx4j  and OpenEJB.  We believe that as the project grows, the 
modular
nature of the J2EE stack will require steady expansion of the committer
group that is considered 'core' - thus providing a healthier, more robust
developer community.

d) Alignment: There is clear alignment with many existing Apache 
projects.
From Jakarta projects such as Tomcat, James and log4j initially as 
well as
possibly others along the way. J2EE now includes a web services stack 
and so
there will be some alignment with the WS project, Axis in particular, 
along
with the reuse of several XML projects. In addition the J2EE Server 
project
may reuse other ASF/BSD licensed code which is not currently hosted in
source form at Apache such as (at time of writing) mx4j, openjms and 
tyrex.

However we see the J2EE Server project as a separate project to existing
Apache projects, serving two primary roles
* integration of various existing and new code bases into a J2EE stack,
with those codebases existing both inside and outside of the project
* certification of the J2EE stack
Note that the J2EE server project can happily support competition 
within the
J2EE services stack (for example, offering choices for elements such 
as the
servlet engine like Tomcat or Jetty, or some new JTA implementation 
versus
Tyrex or some new JMS implementation versus OpenJMS etc).

Section 0.2 :  warning signs

We feel that this project has a good chance for success as the following
warning signs do not apply to the project we are proposing :
a) Orphaned products: This project is starting with a new code base 
together
with reusing lots of the currently available high quality J2EE open 
source
code out there which is ASF/BSD licensed.

b) Inexperience with open source: The initial community is made up of
existing Apache, Castor, JBoss, mx4j , and OpenEJB committers.
c) Homogeneous developers: The current list of committers represents
developers from various backgrounds and open source projects, employed by
various companies and based around the globe in the US, Europe, Asia and
Australia.  There will be no majority bloc, at least from the start.
d) Reliance on salaried developers: None of the initial developers are
currently paid to work on the J2EE project.
e) No ties to other Apache products: The J2EE Server project is
complementary to existing technologies 

Re: [For All] Participation in Geronimo

[Paul Hammant]

Place holding geronimo page put up -> 
http://incubator.apache.org/projects/geronimo.html

-ph

Welcome everyone that has expressed interest in the Apache Geronimo 
project.

As it was just announced today, we are just getting started - please 
watch this mail list, as this is where we'll be doing all Geronimo 
work for now.

Thanks again for your patience.

geir



--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...


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

Re: Project involvement

[Paul Hammant]

Tetsuya

P.S. Also, I think this page
http://incubator.apache.org/projects/index.html
is better to be slightly changed.
XMLBeans: http://xml.apache.org/xmlbeans/   ;-)
 

Done.

-ph

--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...


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

Re: Project involvement

[Paul Hammant]

Tetsuya,

Is there any chance you chould (cheekily) rewrite the URL listed to 
http://incubator.apache.org/projects/geronimo.html from 
http://incubator.apache.org ?

It might (if we improve the page gradually) stave off a lot of this 
newbieism. Tis very interesting the number of postings we are getting. 
If Geronimo is going to fly (or jump/fall ;) it is going to have to be 
highhly componentized.

Regards,

- Paul

I have the same opinion, however, I am not a committer of
incubator project.
The only one thing I could do was to put this news to
jakarta website.
(With the mail address for the subscription)
http://jakarta.apache.org/
http://jakarta.apache.org/site/elsewhere.html#20030805.1
It will be shown up in a few hours.

-- Tetsuya ([EMAIL PROTECTED])

P.S. I can rewrite to the place only which I have a karma for ;-)

--

On Wed, 6 Aug 2003 03:39:57 +0200
(Subject: Re: Project involvement)
Erik Abele <[EMAIL PROTECTED]> wrote:
 

I wonder if someone should collect the addresses of all the interested 
people coming in here with absolutely no clue and send them a 
standardized mail with some instructions on how to get involved 
(mailing list subscription, incubator site and so on)? They are clearly 
asking for further information!

Is it possible for the moderators to estimate the ratio of post-only 
msgs compared to subscription requests? That would indicate if it's 
clear how to participate...

Perhaps it'd be also helpful to get an own mailing list for Geronimo? 
I'd suggest something like [EMAIL PROTECTED] or similar 
to a) ensure that the incubation status is clearly visible and b) 
prevent [EMAIL PROTECTED] from cluttering up too much. Is someone from 
infrastructure@ already working on setting up this stuff?
   



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


 



--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...


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

Re: Updating the incubator site (Re: [geronimo] geronimo website)

[Paul Hammant]

Greg,

Paul -- please set your umask [on login] to enable group-write on the files
in /www/incubator.apache.org. It is making it very difficult for others to
update the site :-)
 

Will do.

-ph

--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...


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

Re: Cron job to update incubator docs?

[Paul Hammant]

Jeff,

For the xml-site, avalon-site (and I assume jakarta-site?) modules, there
is a cron job that synchronises daedalus with the CVS module contents.
I think this is Sam Ruby's script.
Does anyone know if a similar cron job exists for incubator-site, or does
someone have to do a 'cvs update' in daedalus manually?
 

Presently we're doing manual cvs updates.  Cron job would be cool.

-Paul

--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...


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

Incubator PMC chair.

[Paul Hammant]

Tis probably not the done thing to nominate yerself for PMC chair, but 
given that we have a vacancy, and nobody is popping my name into the 
fray, I'd like to propose me.

Who Am I ?

 * Paul Hammant? Aged 35, London based consultant
 * PMC Member for Incubator for a couple of months.
 * Apache committer for a few years.
 * Thoughtworks employee. Self appointed OSS zealot inside TW.
 * Co-Convener of GeekNight in London - 
http://www.c2.com/cgi/wiki?GeekNight
 * Frequenter of eXtreme Tuesday Club - 
http://xpdeveloper.com/xpdwiki/Wiki.jsp?page=ExtremeTuesdayClub
 * With Java since the beginning, .C# liker (boo!).

What do I stand for ?

 * Peace / Harmony
   - language that unites all, high-esteem.
 * Incubator per se (t'was me with the original imperfect ApacheForge 
idea).
 * Empowerment
 * Agile practices (though not to the preclusion of a team empowering 
itself to use RUP/Nothing for a methodology at Apache)
 * Short punchy emails (OK OK, I know)

 Any questions?

- Paul

--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...


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

Re: [VOTE] Policy for incubating project resources (was Re: xmlbeansproject )

[Paul Hammant]

Folks,

It seems there is enough discord over XMLBeans here, to warrant letting 
one slide for the sake of the peace.

If CVS is set-up, let it be as is.
If Mail lists are set-up, let them be as they are.
- - -

For future projects the PMC has decided that whilst in incubator, how 
about the following? It's refactored from prior chat, and common sense ?

1) [EMAIL PROTECTED] is the designated email address for 
user and developer chatter. A third-party or other apache hosted mail 
list is not within the Apache spirit and the intent of Incubator as set 
up, thus is not approved.

2) CVS module will be 'incubator-subProjectName' (not with standing that 
there was some chatter about directories inside 'incubator-projects' for 
each sub project).  All code is to come from the outside and be 
relabelled and relicensed at the outset. Any modules/jars depended on 
are to be clearly listed and appropriately licensed. The project team 
bringing code to the incubator are not to leave some subtle dependency 
to an external to Apache bit of code which may be essentially under the 
control of the committers and designed for the sub-project.

3) Web sites will be hosted at 
http://incubator.apache.org/projects/subProjectName.  Project teams will 
desist and redirect web sites formerly the home of the project.  The new 
site hosted at Apache will not refer to any commercial or open source 
'value added' site dedicated to the new sub-project in anything other 
than a secondary links page.

4) Downloads will be hosted at Apache under the usual mechanisms

Thoughts ?

- Paul

--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...


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

Re: xmlbeans project

[Paul Hammant]

Ted,

Ok,

Is the issue here being @xml vs being @incubator?  If they need to 
be @incubator that's totally fine with me.
Or is there something that I'm missing?


IIUC it's all there is to it. 


If you look at this message in the [EMAIL PROTECTED] mailing list 
it seems clear that they went into the incubator @jakarta

http://archives.apache.org/eyebrowse/ReadMsg?listId=129&msgNo=2

So incubator folks, what is the correct policy here?
Both Tapesptry and Lenya were special cases. We've set policy since 
then. All new projects come through Incubator (mail lists, sites, CVS). 
Best to just go with the flow.  One would also hope that future projects 
coming in take a while to incubate, and don't declare "success" and exit 
a mere couple of months after arriving. There is no allegation there of 
course :-)

- Paul
(Incubator PMC member).
--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...


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

Re: Board Report

[Paul Hammant]

Jim,

Finally, I have noted my intention to step down as PMC Chair, [...]
For what it is worth I though the light touch on Incubator was working 
well. Our biggest problems have been those of expectations of applying 
groups. The problem was one that affected general@ before us, so almost 
no-problem. Assuming there is no way that you'd reconsider, thanks for 
your efforts.

- Paul

--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...


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

Re: Some sparse nots about changes to the incubation process

[Paul Hammant]

Nicola,

...
No change necessary.
...

As is happening presently. 


Nope.

@see http://cocoon.apache.org/lenya/community/mailing-lists.html

No Incubator logo, no @incubator.apache.org mailing lists, no 
reference to the incubation status.
I stand corrected.

> No need for vote?

These are sparse notes, not a VOTE, man. ;-)

Other before me voted :-)

- Paul

--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...


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

Re: Some sparse nots about changes to the incubation process

[Paul Hammant]

Nicola,

> As I told Steven some mails back, I understand the point. Hence I agree 
> with the incubator-projectname CVS module name and separate mailing 
> list(s) if the project is big enough (as I gather this is).
> 
> Here is a rewrite of those points:
> 
> ...
> 
> 4. Making the incubating project have it's own CVS module with the final 
> destination name is a terrible idea. It gives the incubating project and 
> the new users the idea that the project is already a full-apache 
> project. This is the same problem that had arised on Avalon, where 
> projects that were really sandbox code started appearing in the main 
> excalibur CVS, making users use them as they were properly released, 
> which was not true.

-1: reason No change necessary.

This is not happening currently. The Lenya case ariving inside Cocoon was special 
because it was
more assimmialtion than incuation.  The Tapestry case was special because Incubator 
was still
being set up at the time. All other modules in Incubator are stigmatised by the word 
incubator in
their module name.

> All incubating projects therefore should reside in a module that is 
> names incubator-projectname.
> I'd also propose that all committers of the sponsoring PMC can have 
> access to it, as well as all the committers from other incubating 
> projects (so they can eventually lend a hand in need).

As is happening presently. No need for vote?
 
> 6. Making a separate mailing list right from the start that is in the 
> final destination address is again IMHO not a good idea. I would propose 
> that all incubating projects start de-facto on the 
> [EMAIL PROTECTED] ML if they have low traffic, and 
> eventually migrate to [EMAIL PROTECTED] In case the 
> project has already sustained traffic, we will create MLs of type 
> nameoftheproject-(dev|user|cvs)@incubator.apache.org.

As is happening presently. No need for vote?
 
> 7. The webpage of the incubatong project should have the incubator logo 
> and the project one. The final PMC may link to it, and have their logo 
> somewhere else on the page, but not as part of the header.

As is happening presently. No need for vote?
 
> 7-b. The final PMC project should not link to the incubating project 
> page, but only to the incubator main page.

Projects ultimately fork away to jakarta, avalon, xml etc ?  Or will Incubater 
eternally host
once-incubated projects.
 
> ...
> >>Use what you prefer for your project, there is no rule to which 
> >>build-document-whatever system you use; just don'ìt impose it on others.
> >>
> >>(Forrest is much more advanced for Documentation BTW)
> > 
> > Knew that. But clover, pmd, simian, checkstyle and other reports are magic :-)
> 
> They are not Maven, are they? ;-P

No, obviously, but the maven experience gives them to you more or less free.
 
> > When will that Forrest plugin for Maven be ready ?
> 
> ASA Leo gets actively working on it.

Kewl.

- Paul


Want to chat instantly with your online friends?  Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/

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

Re: Some sparse nots about changes to the incubation process

[Paul Hammant]

Nicola,

> > What is the problem you are trying to solve here? 
> 
> There have been discussions on the PMC lists; mainly the problem is 
> about having a project look like and act like a normal Apache project, 
> while in fact it's not. It's *becoming* an Apache Project, but it might 
> as well fail. This has to be made very clear for the developers that 
> help it and for our users.

OK. Here's the deal. Incubator projects are not listed immediately off the main site, 
like jakarta
ones are. There is already some clarity with that design :-)
 
> I'm not advocating changes to the current projects. I'm advocating a 
> different way of handling the next one, XMLBeans.

One depot will get mightily noisy dude. Especially for new-and-refactoring projects.
 
> > Let us also consider the downsides to CVS
> > conglomeration.
> > 
> > So -1.
> > 
> > Also, I think our charter mentions Forrest for docs specifically? 
> 
> Nope. If it does, it shouldn't.
> 
> > I see Maven becoming prevalent,  and it offeres so much
> >, that I think it would be a good idea to all projects to switch to it. 
> > Thoughts?
> 
> Use what you prefer for your project, there is no rule to which 
> build-document-whatever system you use; just don'ìt impose it on others.
> 
> (Forrest is much more advanced for Documentation BTW)

Knew that. But clover, pmd, simian, checkstyle and other reports are magic :-)

When will that Forrest plugin for Maven be ready ?

- Paul


Want to chat instantly with your online friends?  Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/

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

Re: Some sparse nots about changes to the incubation process

[Paul Hammant]

Nicola,

> Looking at how Lenya is now incubating, here are some notes, that aim to 
> resolve some problems that have arised in incubation.

Lenya is marked (at least in CVS copy opf xdocs) as being affiliated to Incubator. 
It's code is in
Cocoon CVS.
 
> 1,2,3,4,5

What is the problem you are trying to solve here?  I things are working quite sweetly, 
albeit
quietly. Lets avoid CVS and mail-list surgery please.  Let us also consider the 
downsides to CVS
conglomeration.

So -1.

Also, I think our charter mentions Forrest for docs specifically? I see Maven becoming 
prevalent,
and it offeres so much, that I think it would be a good idea to all projects to switch 
to it. 
Thoughts?

Regards,

- Paul


Want to chat instantly with your online friends?  Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/

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

Re: [vote] XMLBeans to enter XML incubation [was: Re: Vote for XMLBeans proposal in the XML Project (was RE: Vote for XMLBeans proposal)]

[Paul Hammant]

> > On behalf of the other committers, I would like to ask the XML PMC to 
> > consider accepting XMLBeans into the XML project.  We expect to address
> > any remaining concerns that the community has during the incubation 
> > period.
> 
> Dear committers,
> 
> as outlined in the xml.apache.org charter (section 6.2), and in 
> collaboration with the Incubator 
> (http://cvs.apache.org/viewcvs.cgi/incubator/STATUS?rev=HEAD)

+1

- Paul

([EMAIL PROTECTED], PMC member for Avalon and Incubator).




Want to chat instantly with your online friends?  Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/

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

[Vote] Paul Hammant on to PMC of Incubator.

[Paul Hammant]

My credentials are that I've been here (Apache) for three years or so,  
I am currently a member of the PMC of Avalon and have a track record of 
dabbling in many many sub-projects there. More than many I've polinated 
across many of those projects and encouraged newbies in their efforts.  
One of those is Rana Bhattacharyya whose FtpServer is here.  The project 
I stared AltRMI (groan, need a better name) is here too.  Since arriving 
I've worked on both and the documents for Incubator (well a little, cos 
they needed doing). 

--
http://www.thoughtworks.com -> The art of heavy lifting.
Home for many Agile practicing, Open Source activists...


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

Re: [VOTE] Sam Ruby to join Incubator (was re: Website update)

[Paul Hammant]

Can I get voted into the incubator group?  I think most people around 
here know who I am ;-)

...and I have been subscribed since the beginning and do participate 
in incubation activities...

...besides, I need access if I am going to help out with the cvs updates.


You not got karma for everywhere ?

+1

-ph

--
http://www.thoughtworks.com -> The art of heavy listing.
Home for many Agile practicing, Open Source activists...


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

Re: Website update

[Paul Hammant]

Nicola,

I'd propose that Sam sets up FTPServer and AltRMI projects for 
automatic  updates by his script, as this is how was initially 
requested by Paul and how we are used to at Jakarta. If there is no 
objection, please go ahead Sam.
+1

We'll keep the main site manually updated though.
Not sure why it needs to be different.  The commiters list for the main 
site is a smaller set of people.

'cvs up' works very well, especially when done by cron.

- Paul

PS - thanks for doing the final bits. My fingers were really hurting!

--
http://www.thoughtworks.com -> The art of heavy listing.
Home for many Agile practicing, Open Source activists...


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

FtpServer

[Paul Hammant]

Folks,

Reporting back from the Avalon PMC (Nicola and myself on the PMC), and 
after having gained the concensus of the committers for Avalon, we have 
decided that a more appropriate home for our most excellent FtpServer 
server app would be here in incubator. Alternatives were discussed, but 
Incubator was felt to be best.

If it is OK with the PMC here, could a module be set up 
'incubator-ftpserver'.  The initial committers would be rana_b, hammant 
and jvanzyl, (plus the usual Incubator supremos).

We'll be pushing in the year-old+ FtpServer as a fresh commit

Regards,

- Paul H

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

Re: cvs commit: incubator-site/build/site/projects/altrmi/api/org/apache/altrmi/server/impl/socket AbstractCompleteSocketStreamServer.html AbstractPartialSocketStreamServer.html CompleteSocketCustomStreamPipedBinder.html CompleteSocketCustomStreamPipedConnection.html CompleteSocketCustomStreamServer.html

[Paul Hammant]

Nicola,

> Well, Gump does it already.
> 
> Make your build produce the javadocs, add the  tag in the 
> descriptor and it will publish them on the Gump results site every night.
> 
> It doens't solve the problem that users sometimes need the released 
> version javadocs, but it's a good start.
> 
> http://jakarta.apache.org/gump/

It would be nice if we could gump on CVS labels as well then

Hmmm,

-ph

__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

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

Re: cvs commit: incubator-site/build/site/projects/altrmi/api/org/apache/altrmi/server/impl/socket AbstractCompleteSocketStreamServer.html AbstractPartialSocketStreamServer.html CompleteSocketCustomStreamPipedBinder.html CompleteSocketCustomStreamPipedConnection.html CompleteSocketCustomStreamServer.html

[Paul Hammant]

> > can the docs be reproduced locally into the same usable format
> > as they exist on the site, using a tool that anyone reading
> > the docs would automatically have?
> 
> yes.
> 
> with that said, I like having javadocs on a website. For new projects, 
> I will often go look at the online javadocs to get an overview of the 
> code and architecture to determine if I want to go to the effort of 
> downloading it and playing with it further.

It is true. Demonstrated this morning because James emailed me asking for teh api/ 
link. (Tis not
in the links).

I think we all agree on the fact that docs on site are good. Where Apache differs 
from, say,
SourceForge, is when we push the generated docs into CVS. Thats xdocs and javadocs. It 
would be
nice to have a forrest-gump-cruisecontrol thing to just get latest docs each night and 
shove them
to the /home/www/project/subproject site.

- Paul

__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

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

Re: cvs commit: incubator-altrmi/lib/optional excalibur-lifecycle-1.0.jar

[Paul Hammant]

> Do jars in CVS suck? They do.
> Does downloading all that stuff suck. Sure it does.
> 
> [EMAIL PROTECTED] already has working codebases that give a solution 
> to this problem to choose from. What we need is to set up the 
> infrastructure.

Or switch to Maven.

- Paul

__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

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

Re: cvs commit: incubator-site/build/site/projects/altrmi/api/org/apache/altrmi/server/impl/socket AbstractCompleteSocketStreamServer.html AbstractPartialSocketStreamServer.html CompleteSocketCustomStreamPipedBinder.html CompleteSocketCustomStreamPipedConnection.html CompleteSocketCustomStreamServer.html

[Paul Hammant]

Top add some historical context to this. I merely inherited the avalon-site setup for 
this
project. I'll go with whatever looks to be the most popular way. That could be build 
in-situ to
site, make a download, leave off completely (this is incubator), upload via SCP to 
site.  Looks
like we are not quite settled though.

- Paul

> what are the technical (not philosophical) objections to
> keeping generated data under cms?


__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

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

Re: cvs commit: incubator-site/build/site/projects/altrmi/api/org/apache/altrmi/server/impl/socketAbstractCompleteSocketStreamServer.html AbstractPartialSocketStreamServer.htmlCompleteSocketCustomStreamPipedBinder.html CompleteSocketCustomStreamPipedConnection.htmlCompleteSocketCustomStreamServer.html

[Paul Hammant]

Brian, Aaron,

[ ..] The rule that I've always
followed WRT version control is that derived products are never placed
under VC--it's redundant.
 

Can we build on the incubator box ?

- Paul

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

Re: cvs commit: incubator-site/build/site/projects/altrmi/api/org/apache/altrmi/server/impl/socketAbstractCompleteSocketStreamServer.html AbstractPartialSocketStreamServer.htmlCompleteSocketCustomStreamPipedBinder.html CompleteSocketCustomStreamPipedConnection.htmlCompleteSocketCustomStreamServer.html

[Paul Hammant]

Aaron Bannert wrote:

Sorry to be a nag, but are these all just autogenerated from
javadoc? Surely javadoc output need not be in CVS.
-aaron
Stricktly speaking, there is no need at all for a xxx-site CVS module 
for any Apache projects. You could build the lot to the dir it will be 
served from.

Anyone step in with policy for Javadocs for Incubator?

- Paul

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

Re: [altrmi] Bug in AbstractCompleteSocketStreamServer

[Paul Hammant]

Peter,

Ooooh, been looking for something like that. Marathon ( 
http://marathonman.sourceforge.net/ ) is being bugged by an issue that 
sounds like it be caused by that.

Lets go for START & STOP. The intermediate states were just just 
over-design anyway.

Clearly a case of a missing or malfunctionig unit test.

- Paul

I found a bug in the AbstractCompleteSocketStreamServer.

The code sets the internal state to STARTING, then fires off the 
thread to monitor the socket, then sets the state to STARTED.

The thread that monitors the socket does its thing as long as the 
state is STARTED. I'm seeing the monitor thread start and immediately 
exit since the state has not yet been changed to started.

My question is, what is the proper fix, skipping the STARTING state 
and going straight to STARTED? Or set STARTED right before spawning 
the monitor thread, or in the monitor thread go into a loop if the 
state is STARTING?
-pete



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

Re: Incubator DOA (Re: [STATUS] Tapestry [LACK-OF] Progress)

[Paul Hammant]

> > [..] I 
> > promise to answer emails directed at the PMC, and vote though whenever 
> > opportunities arise.  [ .. ]
 
> Second, please resend any questions to this list that you believe
> the PMC failed to respond to. It is possible we simply missed it,
> and also possible that some of the PMC didn't feel it was their
> jurisdiction.

Was not trying to make an accusation, more like trying to "I'll be there". An election 
manifesto
of sorts.

- Paul

__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

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

Re: Incubator DOA (Re: [STATUS] Tapestry [LACK-OF] Progress)

[Paul Hammant]

Greg,

...
Does anyone want to step down from Incubator PMC?  I'll step up (though 
like many I'm pressured for spare hours in the day).  I promise to 
answer emails directed at the PMC, and vote though whenever 
opportunities arise.  I'm on the Avalon PMC and have been an Apache 
committer for about three years.
   

Nobody needs to step down to "make room". The size of PMCs is unlimited. If
you want to participate, then do so. Simultaneous with your stepping up to
actually get stuff done, I would expect the Incubator Chair (Jim) to start a
vote on adding you to the PMC. (technically, he could just add you :-), but
I suspect he'd want to take a vote first)
As with any PMC participation, it is usually based on demonstrable effort.
And I don't think you have to be on the PMC to participate either...
 

OK, a little selling then..

I've already stepped up to work on incubator-site.  Clearly the need for 
me was to get AltRMI listed on the site, but I found it had not been 
updated in a while. I did a small amount of repair work and updated the 
whole site.  Unsung at that stage, though root was involved in giving me 
karma to the site. I generally take the attiude of if it needs doing 
then do it. 

Maybe part of my offer to chair swap with someone on the PMC, was 
perhaps to give anyone the opportunity to step down. Anyone who may lack 
the time to do anything for incubator presently 

- Paul

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

Re: Incubator DOA (Re: [STATUS] Tapestry [LACK-OF] Progress)

[Paul Hammant]

The vote on AltRMI received only one vote here (Nicola Ken's), that I saw. I 
may have missed others.
 

There was a very low vote, yes.  The project is quite active though.

This lack of action is the real issue in the incubator, ATM.
 

Perhaps.

Does anyone want to step down from Incubator PMC?  I'll step up (though 
like many I'm pressured for spare hours in the day).  I promise to 
answer emails directed at the PMC, and vote though whenever 
opportunities arise.  I'm on the Avalon PMC and have been an Apache 
committer for about three years.

Regards,

- Paul

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

Re: Incubator DOA (Re: [STATUS] Tapestry [LACK-OF] Progress)

[Paul Hammant]

Jeff,

There is more than just Tapestry in incubator.

- Paul

 --- Jeff Turner <[EMAIL PROTECTED]> wrote: > Feh.
> 
> Incubation was a dumb idea from the start.  It is busy failing in
> practice.
> 
> PMCs should manage the acceptance of new subprojects, not some
> disinterested Incubator PMC.
> 
> IMHO, scrap this failed experiment and let Tapestry migrate to Jakarta
> without being further jerked around.
> 
> I feel I'm stating the blindingly obvious.  Is it just me?
> 
> 
> --Jeff
> 
> On Mon, Mar 10, 2003 at 06:58:22PM -0500, Howard M. Lewis Ship wrote:
> > How, exactly, is Tapestry ever expected to exit the proposal stage?
> > 
> > Despite repeated attempts, Tapestry is NOT in BugZilla.  We're still forced
> > to use SourceForge for bug tracking.
> > 
> > Tapestry's mailing lists are not getting archived any more (not since 2/21).
> > 
> > Nobody seems to know ANY of the procedures for getting things done.  Nothing
> > is documented.  Simple things like the correct way to distribute a release
> > (including signing and mirroring) are just "known" by the right people ...
> > and I don't even know who is in the know.
> > 
> > Andrew and Dion have been helpful, both before the move and after.
> > 
> > The only other accomplishment of the incubation process has been a code
> > audit that resulted in a shuffling of the libraries checked into CVS and
> > distributed with the framework.
> > 
> > Jakarta infrastructure is non-existent. Worse, the Jakarta culture
> > erroneously expects things to get done based on e-mails, rather than
> > something organized, like using BugZilla to track infrastructure requests. 
> > 
> > The Incubator team has yet to provide a time table or a check list to
> > indicate what the exit criteria are.  In terms of Tapestry's commitments to
> > the Incubator, it looks like we're more than there (based on
> > http://incubator.apache.org/process.html).  In terms of Incubator's
> > commitments to Tapestry ... that is, to assist Tapestry in moving into
> > Jakarta, fitting in, and accessing infrastructure; very little has been
> > accomplished.
> > 
> > --
> > Howard M. Lewis Ship
> > Creator, Tapestry: Java Web Components
> > http://jakarta.apache.org/proposals/tapestry
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>  

__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

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

Re: Proposal for Lenya

[Paul Hammant]

Michael, Folks,


Dear Incubator List [...]


My take (not being on the incubator PMC) is that I'd like to see the 
code.  I want to see how componentized it is - I might like to use some 
of the comps outside of Lenya or outside of Cocoon itself - I'm always 
excited by products that have internal comps for built reuse outside the 
product.

The overall proposition sounds interesting - a CM system would be cool 
for us, especially as it factors in WebDAV.

Regards,

- Paul


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

AltRMI ??

[Paul Hammant]

Hi folks,

So have we decided to move AltRMI here from Avalon?  I only saw votes in favour so can 
I assume
this is green-lighted?

- Paul
([EMAIL PROTECTED])

__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com

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