[STATUS] (incubator) Wed Aug 9 23:52:54 2006

[Rodent of Unusual Size]

APACHE INCUBATOR PROJECT STATUS:  -*-indented-text-*-
Last modified at [$Date: 2006-02-05 04:40:19 -0500 (Sun, 05 Feb 2006) $]

Web site:  http://Incubator.Apache.Org/
Wiki page: http://wiki.apache.org/incubator/

[note: the Web site is the 'official' documentation; the wiki pages
 are for collaborative development, including stuff destined for the
 Web site.]

Pending Issues
==

o We need to be very very clear about what it takes to be accepted
  into the incubator.  It should be a very low bar to leap, possibly
  not much more than 'no problematic code' and the existence of a
  healthy community (we don't want to become a dumping ground).

o We need to be very very clear about what it takes for a podling
  to graduate from the incubator.  The basic requirements obviously
  include: has a home, either as part of another ASF project or as
  a new top-level project of its own; needs to be a credit to the
  ASF and function well in the ASF framework; ...

See also:

  https://issues.apache.org/jira/browse/INCUBATOR

Resolved Issues
===

o The policy documentation does not need ratification of changes
  if there seems consensus. Accordingly, the draft status of these
  documents can be removed and we will use the lazy "commit first,
  discuss later" mode common across the ASF for documentation
  (http://mail-archives.apache.org/eyebrowse/[EMAIL 
PROTECTED]&by=thread&from=517190)

o Coming up with a set of bylaws for the project
  (http://mail-archives.apache.org/eyebrowse/[EMAIL 
PROTECTED]&by=thread&from=517190)

o All projects under incubation must maintain a status Web page that
  contains information the PMC needs about the project.
  (http://incubator.apache.org/guides/website.html)

o Projects under incubation should display appropriate "disclaimers"
  so that it is clear that they are, indeed, under incubation
  (http://mail-archives.apache.org/eyebrowse/[EMAIL 
PROTECTED]&by=thread&from=504543)

o Clearly and authoritatively document how to edit, generate,
  and update the Web site (three separate functions)
  (http://incubator.apache.org/guides/website.html).

The Incubation Process
==

TODO: this does not belong in the STATUS file and probably was integrated into
other documentation a while ago. That should be double-checked and then this
section should be removed.

This tries to list all the actions items that must be complete for a project
before it can graduate from the incubator. It is probably incomplete.

Identify the project to be incubated:

  -- Make sure that the requested project name does not already exist
 and check www.nameprotect.com to be sure that the name is not
 already trademarked for an existing software product.

  -- If request from an existing Apache project to adopt an external
 package, then ask the Apache project for the cvs module and mail
 address names.

  -- If request from outside Apache to enter an existing Apache project,
 then post a message to that project for them to decide on acceptance.

  -- If request from anywhere to become a stand-alone PMC, then assess
 the fit with the ASF, and create the lists and modules under the
 incubator address/module names if accepted.

Interim responsibility:

  -- Who has been identified as the mentor for the incubation?

  -- Are they tracking progress on the "project status" Web page?

Copyright:

  -- Have the papers that transfer rights to the ASF been received?
 It is only necessary to transfer rights for the package, the
 core code, and any new code produced by the project.

  -- Have the files been updated to reflect the new ASF copyright?

Verify distribution rights:

  -- For all code included with the distribution that is not under the
 Apache license, do we have the right to combine with Apache-licensed
 code and redistribute?

  -- Is all source code distributed by the project covered by one or more
 of the following approved licenses:  Apache, BSD, Artistic, MIT/X,
 MIT/W3C, MPL 1.1, or something with essentially the same terms?

Establish a list of active committers:

  -- Are all active committers listed in the "project status" file?

  -- Do they have accounts on cvs.apache.org?

  -- Have they submitted a contributors agreement?

Infrastructure:

  -- CVS modules created and committers added to avail file?

  -- Mailing lists set up and archived?

  -- Problem tracking system (Bugzilla)?

  -- Has the project migrated to our infrastructure?

Collaborative Development:

  -- Have all of the active long-term volunteers been identified
 and acknowledged as committers on the project?

  -- Are there three or more independent committers?

 [The legal definition of independent is long and boring, but basically
  it means that there is no binding relationship between the individuals,
  s

Re: IRC Channel?

[Sanjiva Weerawarana]

On Wed, 2006-08-09 at 18:12 -0700, Igor Vaynberg wrote:
> in wicket we use irc quiete a lot. we dont post all transcripts to the list
> because in general they are too noisy to be of any use to anyone. we do have
> them available for browsing on the web [1] though. we also have a search
> engine that indexes our mailing list, wiki, irc logs, and a few select
> websites to give a single point entry into all those resources [2].

The problem is one of timezones .. IRC works if most of the people are
in the same/similar TZ. If you want people from the other side of the
world to become part of the project then please don't use IRC all the
time; its a PITA to read logs and have to deal with stuff thru that. 

A regularly scheduled IRC chat does work but if IRC is a key part of
day-to-day execution then IMO that's a problem from the global
perspective. Of course YMMV.

Sanjiva.


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

Re: Jini?

[Craig L Russell]

I'd like to point out that Apache does have tolerance for "brand  
names" coming in from the outside, in particular "J-word projects"  
from Sun.


Java(TM) Data Objects a.k.a. JDO is an official Apache project [1].

JDO is not trademarked but the name is well-known in its space. The  
Apache JDO project includes the official API for both JSR-12 and  
JSR-243; and the official TCK for both JSRs.


Sun donated JDO to Apache for continued development, and Apache JDO  
released the API and TCK according to the official JCP rules, under  
the Apache license.


There is room for development of a JDO implementation as an Apache  
project, but it seems more likely that other Apache projects will  
provide a JDO implementation outside of the Apache JDO project. (e.g.  
OpenJPA or Cayenne might well provide a JDO-compliant interface, just  
as they might offer a JPA-compliant interface).


There is precedent for Apache adopting Jini as a project, regardless  
of whether you are talking about "just an implementation" or "the  
official Jini".


Craig

[1] http://db.apache.org/jdo

On Aug 7, 2006, at 11:13 AM, Jim Hurley wrote:


On Aug 7, 2006, at 12:19 PM, Sanjiva Weerawarana wrote:
So whatever happened to the Jini proposal?? I just remembered that  
there

was a lot of discussion but don't recall the conclusion.


Sorry - we hit a snag around the name, and have been working to
try and get untangled.

There seemed to be two discussion points around the "Jini" name on
our Proposal:  1) trademark concerns, 2) potential confusion on
the Jini project at Apache and other Jini Community related web
places (Jini.org, jini.dev.java.net).

Part of our delay in re-engaging on this list was to get a better
understanding of the options around the Jini trademark (that Sun
currently owns). It seems there are two viable choices: contribute
the trademark to Apache (along with the code), or 'abandon' the
trademark registration. We would prefer to contribute it, but I'd
like some discussion on this list on whether that's a viable
option.

As for potential confusion with other "Jini areas" (Jini.org,
jini.dev.java.net) -- that's a reasonable point, but we believe
we can put context on those other sites so it's clear how they
fit into the overall Jini Community picture and core infrastructure
being built in the Apache Jini project.

We did start considering alternative names, but there's a strong
reluctance to changing names. That's primarily because of the name
recognition we've built up around the technology and Community
during the past number of years, as well as the difficulty (ref
the many posts on this list in the last month on choosing names)
with picking a new name.

Assuming this reasoning makes sense... we'd like to proceed with
"Jini" as the name of the Proposal and get some discussion going
to better understand if we can contribute the TM and if it would
be okay for those other Jini -related site (Jini.org,  
jini.dev.java.net)

to continue to use the Jini name.

thanks -Jim


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



Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!



smime.p7s
Description: S/MIME cryptographic signature

Re: IRC Channel?

[Jason van Zyl]

On 9 Aug 06, at 9:06 PM 9 Aug 06, William A. Rowe, Jr. wrote:


Craig L Russell wrote:
Has anyone ever considered making IRC chats available (on some  
basis) as
an Apache archive? Seems that Apache (myself included) doesn't  
like IRC
so much because it is not available to those of us who because of  
time

zone or other reasons can't attend.


No - mostly because IRC CANNOT BE USED to make project decisions.

It's lovely for beating down a problem, kicking around ideas, but  
those
ideas MUST COME BACK TO [EMAIL PROTECTED]  Decisions themselves must be made on  
[EMAIL PROTECTED]


It's the responsibility of the project participants to grab any useful
log thread, forward it on to the dev@ list to get people thinking and
voting.

Automatically capturing IRC logs undermines this responsibility and  
harms

the project (for exactly the reasons you point out above).



How does automatically capturing the logs undermine anything. It is  
convenient to point at threads of discussion in IRC and even though  
summaries can be provided there's nothing like reading the source  
material. Just as we often summarize threads on [EMAIL PROTECTED], it's still  
nice to go back to the archives and read over the messages.


We keep our messages here:

http://dev.rectang.com/logs/codehaus/

And I think they are pretty handy and provide the source material for  
any summaries. Good evidence of how this works in practice is #cxf  
where the XFire and Celtix folks have been chatting about ideas and  
then you see the summary on the mailing list. If you want to go see  
the IRC log in question you can:


http://dev.rectang.com/logs/codehaus/%23cxf/20060809.html

I think accountability is actually promoted by logging the channel  
because if people notice the logs continually growing with no  
corresponding chatter on the mailing lists then you can identify a  
problem. If you the channels aren't logged you're never going to know  
and it probably wouldn't be because a group intentionally trying to  
undermine the standard channels of communication, it would probably  
just be habit. You could point at the log and give a gentle nudge to  
push the discussion to the mailing list.


I personally don't see any downside to logging the channels.



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




Jason van Zyl
[EMAIL PROTECTED]




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

Re: Glasgow - new name proposal

[Craig L Russell]

URQPD.

Craig

On Aug 9, 2006, at 2:14 PM, Brian McCallister wrote:


AMQPD

-Brian

On Aug 9, 2006, at 1:06 PM, Rafael Schloming wrote:

How about Qpid? It could mean Queuing Protocol for Information  
Delivery or something like that.


Carl Trieloff wrote:

+1 for Kyma  easy to say, read and use in code.
Archit Shah wrote:

More name ideas for Glasgow (and maybe for others as well):

Bernoulli (messages flow)
Cumin (spice)
Kyma (wave)
Leno (an open-woven fabric)
Linum (flax)
Pharos (lighthouse)
Subito (at once)

 -- Archit Shah

--- 
--

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]




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



Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!



smime.p7s
Description: S/MIME cryptographic signature

Re: IRC Channel?

[Eelco Hillenius]

i think in general it works out well. we formulate and refine ideas on irc
for a couple of hours and then post a summary to the devel list. after a few
hours of real time communication the idea is usually flashed out enough to
be a good base for a longer/slower-paced discussion on the list.


I second that. Usually about half of the developers are on the chat
channel. Furthermore, we don't have to officially (via votes/ list)
agree on every little issue. For things like fixing smaller bugs,
working on new components, brainstorming etc, IRC works really well.
In the year or so we are using it we definitively sped up our
development pace, are better able to support our users, and imo got a
more community feel in general. And like Igor said, it reduces the
noise on the mailing lists as we generally fleshed out our ideas/
proposals better before sending them in.

Did that sound like I am trying to sell something? ;)

Eelco

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

Re: IRC Channel?

[Craig L Russell]

Hi,

On Aug 9, 2006, at 6:06 PM, William A. Rowe, Jr. wrote:


Craig L Russell wrote:
Has anyone ever considered making IRC chats available (on some  
basis) as
an Apache archive? Seems that Apache (myself included) doesn't  
like IRC
so much because it is not available to those of us who because of  
time

zone or other reasons can't attend.


No - mostly because IRC CANNOT BE USED to make project decisions.


I understand and agree.


It's lovely for beating down a problem, kicking around ideas, but  
those
ideas MUST COME BACK TO [EMAIL PROTECTED]  Decisions themselves must be made on  
[EMAIL PROTECTED]


Sure, but lots of discussion on dev@ doesn't result in a decision  
either.


It's the responsibility of the project participants to grab any useful
log thread, forward it on to the dev@ list to get people thinking and
voting.


I don't think that even 5% of the dev@ discussion is decision-making,  
voting, or anything more than chat.


Automatically capturing IRC logs undermines this responsibility and  
harms

the project (for exactly the reasons you point out above).


I'm not sure what part of capturing IRC logs undermines anything.

Perhaps what I'm suggesting is that IRC can be more useful if there  
were some tool that the participants could use to summarize the  
discussion. Given that everyone knows that IRC is not a decision- 
making tool but a communications tool.


If the state of the art is that someone on IRC has to take  
responsibility to log the chat and people by nature are lazy  
(Malthus, anyone?) it's more likely than not that IRC chats won't be  
logged. Wicket excluded. How do they do this?


Craig


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



Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!



smime.p7s
Description: S/MIME cryptographic signature

Re: IRC Channel?

[Igor Vaynberg]

in wicket we use irc quiete a lot. we dont post all transcripts to the list
because in general they are too noisy to be of any use to anyone. we do have
them available for browsing on the web [1] though. we also have a search
engine that indexes our mailing list, wiki, irc logs, and a few select
websites to give a single point entry into all those resources [2].

i think in general it works out well. we formulate and refine ideas on irc
for a couple of hours and then post a summary to the devel list. after a few
hours of real time communication the idea is usually flashed out enough to
be a good base for a longer/slower-paced discussion on the list.

so i think irc is a valuable tool even though not everyone can get into the
conversation at the same time.

[1] http://ginandtonic.org/wicket
[2] http://woogle.billen.dk/search

-Igor


On 8/9/06, Craig L Russell <[EMAIL PROTECTED]> wrote:


Has anyone ever considered making IRC chats available (on some basis)
as an Apache archive? Seems that Apache (myself included) doesn't
like IRC so much because it is not available to those of us who
because of time zone or other reasons can't attend.

If it's added to an Apache archive, it is searchable and immediately
available to search engines.

Surely Web 2.0 has solved this simple issue!

?

Craig

On Aug 9, 2006, at 3:49 PM, Kevin Menard wrote:

>> -Original Message-
>> From: Andrus Adamchik [mailto:[EMAIL PROTECTED]
>> Sent: Tuesday, August 08, 2006 11:57 AM
>> To: cayenne-dev@incubator.apache.org
>> Subject: Re: IRC Channel?
>>
>> I am not a big fan of IRC, besides all consequential discussions will
>> have to be logged on the mailing list anyways. But I certainly have
>> no objections for the channel being there.
>
> Right.  It's nicer for more casual conversation.  Sometimes it's
> easier for
> real-time interaction as well.
>
> As another idea, we could try to do a developer Skype chat or
> something.  I
> think the Tapestry folks did it once and it sounded like kind of a
> neat
> idea.  I know my interaction with just about everyone here has been
> email
> only.
>
> --
> Kevin
>

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!

Re: IRC Channel?

[William A. Rowe, Jr.]

Craig L Russell wrote:
> Has anyone ever considered making IRC chats available (on some basis) as
> an Apache archive? Seems that Apache (myself included) doesn't like IRC
> so much because it is not available to those of us who because of time
> zone or other reasons can't attend.

No - mostly because IRC CANNOT BE USED to make project decisions.

It's lovely for beating down a problem, kicking around ideas, but those
ideas MUST COME BACK TO [EMAIL PROTECTED]  Decisions themselves must be made on 
[EMAIL PROTECTED]

It's the responsibility of the project participants to grab any useful
log thread, forward it on to the dev@ list to get people thinking and
voting.

Automatically capturing IRC logs undermines this responsibility and harms
the project (for exactly the reasons you point out above).

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

Re: IRC Channel?

[Craig L Russell]

Has anyone ever considered making IRC chats available (on some basis)  
as an Apache archive? Seems that Apache (myself included) doesn't  
like IRC so much because it is not available to those of us who  
because of time zone or other reasons can't attend.


If it's added to an Apache archive, it is searchable and immediately  
available to search engines.


Surely Web 2.0 has solved this simple issue!

?

Craig

On Aug 9, 2006, at 3:49 PM, Kevin Menard wrote:


-Original Message-
From: Andrus Adamchik [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 08, 2006 11:57 AM
To: cayenne-dev@incubator.apache.org
Subject: Re: IRC Channel?

I am not a big fan of IRC, besides all consequential discussions will
have to be logged on the mailing list anyways. But I certainly have
no objections for the channel being there.


Right.  It's nicer for more casual conversation.  Sometimes it's  
easier for

real-time interaction as well.

As another idea, we could try to do a developer Skype chat or  
something.  I
think the Tapestry folks did it once and it sounded like kind of a  
neat
idea.  I know my interaction with just about everyone here has been  
email

only.

--
Kevin



Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!



smime.p7s
Description: S/MIME cryptographic signature

Re: Glasgow - new name proposal

[Martin van den Bemt]

There is even a song about that :)

Mvgr,
Martin

Thomas Dudziak wrote:

On Aug 9, 2006, at 1:06 PM, Rafael Schloming wrote:


How about Qpid? It could mean Queuing Protocol for Information
Delivery or something like that.


or Qupid

Tom

-
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: Glasgow - new name proposal

[Noel J. Bergman]

> Pharos (lighthouse)

-1

Already the name of a software (GPS) company.  :-)

--- Noel


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

Re: Wicket again (was Re: incubation process for open development open source projects)

[Upayavira]

Igor Vaynberg wrote:
> pardon me for being so ignorant, but all i know of apache is what i read
> online and what i have observed from this list.

That is fair enough - we all start somewhere.

> it seems to me that there are a few recurring concerns about these items,
> even in the short period that i have been subscribed.
> 
> the incubation, the releases, and the user lists - and the general feeling
> toward projects that are in the incubator.
> 
> here are a few snippets that cast a lot of doubt on where things actually
> stand:
> 
>> Jeremy Hughes wrote:
>> Then, in its README Axis2 should make very clear which function relies
>> on Woden and that this function isn't production ready because it is
>> reliant on an incubator podling.
> 
> statements like these are always answered by stating that incubation does
> not reflect on code quality or whether or not a project is production ready
> - but the general negative sentiment is clearly there even if not true in
> the eyes of apache folks. and it comes up often.

This is one fact (the possibility of misinterpretation of the term
'incubating') that Wicket would need to face head on. Make sure it is
clearly documented up front the code maturity level that Wicket has, and
that incubation refers to the process of joining Apache, and is not a
statement about the quality, or otherwise, of the code itself.

Of course, if it makes life easier, you could make me a committer, and
I'm sure I could make sure that your code isn't production ready :-)

> here is another example.
> 
>> Noel J. Bergman
>> Most users should not be using Incubator code.  Only those who are
> committed
>> and willing to trust that the project will do well here and eventually
>> become an ASF project.
> 
>> Remember that most people don't believe that Incubator projects should
>> even have a user@ list, only a dev@ list.

My suspicion there is that Noel is being somewhat idealistic in that
sentiment. Especially given the number of incubating projects that do
have user lists!

> where does this leave us?

> so i guess what i would like to confirm is the following:
> 
> a) we will have a user list in the incubator and our users will not be
> discouraged from joining it

That seems fair enough to me. Hopefully others (particularly Noel) will
chime in.

> b) if we have a final release ready even though we were in the incubator
> for a short time ( lets say a month ) it will not be blocked just because of
> its timeframe.

So long as the other criteria that are required in order to do a release
are met, I do not see any problem with that.

In this case, the criteria are objective ones, such as: all contributor
CLAs have been received by ASF; licenses are correctly placed on all
source code, license files (NOTICES.txt, LICENSE.txt) are correctly
placed within the release file, etc, etc. Nothing that should be too
hard to manage (esp as I'd intend to do most of the CLA gathering before
actually shifting to Apache - without doing so you'd have committers
without commit access to your codebase, which really wouldn't work)

Hopefully that is clearer still?

Regards, Upayavira

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

Re: Wicket again (was Re: incubation process for open development open source projects)

[Igor Vaynberg]

pardon me for being so ignorant, but all i know of apache is what i read
online and what i have observed from this list.

it seems to me that there are a few recurring concerns about these items,
even in the short period that i have been subscribed.

the incubation, the releases, and the user lists - and the general feeling
toward projects that are in the incubator.

here are a few snippets that cast a lot of doubt on where things actually
stand:


Jeremy Hughes wrote:
Then, in its README Axis2 should make very clear which function relies
on Woden and that this function isn't production ready because it is
reliant on an incubator podling.


statements like these are always answered by stating that incubation does
not reflect on code quality or whether or not a project is production ready
- but the general negative sentiment is clearly there even if not true in
the eyes of apache folks. and it comes up often.

here is another example.


Noel J. Bergman
Most users should not be using Incubator code.  Only those who are

committed

and willing to trust that the project will do well here and eventually
become an ASF project.



Remember that most people don't believe that Incubator projects should

even

have a user@ list, only a dev@ list.


where does this leave us?

so i guess what i would like to confirm is the following:

a) we will have a user list in the incubator and our users will not be
discouraged from joining it
b) if we have a final release ready even though we were in the incubator for
a short time ( lets say a month ) it will not be blocked just because of its
timeframe.

thanks,
-Igor





On 8/9/06, Upayavira <[EMAIL PROTECTED]> wrote:


Igor Vaynberg wrote:
> personally i am fine with "incubation takes as long as it takes"
statement.
> it is your organization and it is up to you whether or not you want to
let
> the project into the incubator and into graduation. i also understand
the
> "need to observe open development style on apache ground" argument.

Good.

On the subject of 'as long as it takes' - there's nothing to stop us
planning, scheduling and setting up goals - there are a clear list of
criteria we would need to meet and we can 'manage' those. We may well
find that, having covered those criteria, we've done it.

There just remains, and always will remain, the possibility of new
issues arising - ones that haven't yet arisen for other projects and
thus haven't yet made it into the guidelines - but that need to be dealt
with before graduation. I don't forsee any with Wicket, but then, if I
did, I'd be adding them to the guidelines :-)

> what i
> do not understand are a few points regarding incubation of existing
> projects
> with established user bases, such as the release policy and the brand
abuse
> concerns which to me seem to go hand in hand. the concern i have with
> bringing wicket over into the incubator is the feeling of the project
> stagnating. we cant do any releases unless they are done through the
> incubator and we cannot release a final release until we graduate.

I suspect something needs clarifying here (Noel refered to this in an
earlier mail) - you can do releases in the incubator, and you can call
them whatever you like - 2.0alpha, 2.0beta, 2.0final. The only
requirements are (a) that they are labelled 'incubating', and that the
legal requirements for releases are met (which you're probably okay with
already).

So, you certainly can do the releases you plan - they'd just need to be
labelled 'incubating'.

> we are
> only a few months away from releasing versions that our users are
waiting
> for so the incubation process, as it stands right now, would seriously
hurt
> us. furthermore the general consensus that incubation takes between six
> months to a year also does not work for existing projects who release
more
> often then that. you are basically expecting the project to halt until
> graduation. the development might continue but you cannot release any
final
> releases which makes users itchy.

Does my above explanation relieve some of these concerns? No-one is
saying you can't release - in fact, releasing code is one way in which
you will demonstrate your appreciation of the way Apache works.

> also releases marked -incubating raise
> concerns and give the impression the code is not production ready, yes
we
> know its not true because we are "educated" in the apache jargon - but
many
> users are not nor do they have the desire.

I don't think it is quite as straight-forward as that. Some users (those
more committed to Wicket) will listen to what is being said. Some will
worry. Others will love it. Some people's bosses may start considering
Wicket where they wouldn't have done so before.

So, you might find your demographics change a little, but I see no
reason why incubation, in this regard, should harm Wicket.

> so my proposal to improve the incubator situation is to do this:
>
> let the project into the incubator and let them release at their current
> inf

Wicket again (was Re: incubation process for open development open source projects)

[Upayavira]

Igor Vaynberg wrote:
> personally i am fine with "incubation takes as long as it takes" statement.
> it is your organization and it is up to you whether or not you want to let
> the project into the incubator and into graduation. i also understand the
> "need to observe open development style on apache ground" argument.

Good.

On the subject of 'as long as it takes' - there's nothing to stop us
planning, scheduling and setting up goals - there are a clear list of
criteria we would need to meet and we can 'manage' those. We may well
find that, having covered those criteria, we've done it.

There just remains, and always will remain, the possibility of new
issues arising - ones that haven't yet arisen for other projects and
thus haven't yet made it into the guidelines - but that need to be dealt
with before graduation. I don't forsee any with Wicket, but then, if I
did, I'd be adding them to the guidelines :-)

> what i
> do not understand are a few points regarding incubation of existing
> projects
> with established user bases, such as the release policy and the brand abuse
> concerns which to me seem to go hand in hand. the concern i have with
> bringing wicket over into the incubator is the feeling of the project
> stagnating. we cant do any releases unless they are done through the
> incubator and we cannot release a final release until we graduate. 

I suspect something needs clarifying here (Noel refered to this in an
earlier mail) - you can do releases in the incubator, and you can call
them whatever you like - 2.0alpha, 2.0beta, 2.0final. The only
requirements are (a) that they are labelled 'incubating', and that the
legal requirements for releases are met (which you're probably okay with
already).

So, you certainly can do the releases you plan - they'd just need to be
labelled 'incubating'.

> we are
> only a few months away from releasing versions that our users are waiting
> for so the incubation process, as it stands right now, would seriously hurt
> us. furthermore the general consensus that incubation takes between six
> months to a year also does not work for existing projects who release more
> often then that. you are basically expecting the project to halt until
> graduation. the development might continue but you cannot release any final
> releases which makes users itchy.

Does my above explanation relieve some of these concerns? No-one is
saying you can't release - in fact, releasing code is one way in which
you will demonstrate your appreciation of the way Apache works.

> also releases marked -incubating raise
> concerns and give the impression the code is not production ready, yes we
> know its not true because we are "educated" in the apache jargon - but many
> users are not nor do they have the desire.

I don't think it is quite as straight-forward as that. Some users (those
more committed to Wicket) will listen to what is being said. Some will
worry. Others will love it. Some people's bosses may start considering
Wicket where they wouldn't have done so before.

So, you might find your demographics change a little, but I see no
reason why incubation, in this regard, should harm Wicket.

> so my proposal to improve the incubator situation is to do this:
> 
> let the project into the incubator and let them release at their current
> infrastructure outside of apache. that way the incubation period doesnt
> hurt the project and can take as long as you guys want. the releases will of
> course not contain any apache branding. once the project graduates the
> branding (such as package names) can be applied to the first release
> available through apache itself.

That way you route around the benefit of demonstrating your
understanding of releasing code within Apache, which would slow down
incubation. Hopefully my explanation above alleviates the concerns you
were trying to address here.

> another concern i have is about not letting the user lists onto the
> incubator, this is once again a problem for existing projects, especially
> for frameworks where users are in fact developers themselves. we tweak
> wicket's api a lot based on the users feedback so not having that resource
> available will hurt us. also a lot of issues that start out on the user
> list turn into development issues like bugs, improvements, etc. the user list 
> is
> an invaluable resource for us and probably for other projects as well.

Looking down the list of projects: http://incubator.apache.org/projects/
most of them seem to have users lists. So bringing the user list along
wouldn't, to my mind, be a problem. The suggestion of leaving the user
list at SF was, to my mind, just one attempt to find an approach for
Wicket - by no means a requirement of the Incubator.

> the incubator process as it stands right now works perfectly well for new
> projects that come to the incubator without a community or code, but it
> just doesnt work for projects that are being "adapted" rather then "incubated"

I think we can find 

Re: Glasgow - new name proposal

[Thomas Dudziak]

On Aug 9, 2006, at 1:06 PM, Rafael Schloming wrote:


How about Qpid? It could mean Queuing Protocol for Information
Delivery or something like that.


or Qupid

Tom

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

Re: Glasgow - new name proposal

[Brian McCallister]

AMQPD

-Brian

On Aug 9, 2006, at 1:06 PM, Rafael Schloming wrote:

How about Qpid? It could mean Queuing Protocol for Information  
Delivery or something like that.


Carl Trieloff wrote:

+1 for Kyma  easy to say, read and use in code.
Archit Shah wrote:

More name ideas for Glasgow (and maybe for others as well):

Bernoulli (messages flow)
Cumin (spice)
Kyma (wave)
Leno (an open-woven fabric)
Linum (flax)
Pharos (lighthouse)
Subito (at once)

 -- Archit Shah

 
-

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]




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

Re: Glasgow - new name proposal

[Rafael Schloming]

How about Qpid? It could mean Queuing Protocol for Information Delivery 
or something like that.


Carl Trieloff wrote:


+1 for Kyma  easy to say, read and use in code.

Archit Shah wrote:

More name ideas for Glasgow (and maybe for others as well):

Bernoulli (messages flow)
Cumin (spice)
Kyma (wave)
Leno (an open-woven fabric)
Linum (flax)
Pharos (lighthouse)
Subito (at once)

 -- Archit Shah

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

Re: Glasgow - new name proposal

[Davanum Srinivas]

megha (cloud) - Message ExchanGe Hyper Architecture (or some something
else equally lame :)

-- dims

On 8/9/06, Archit Shah <[EMAIL PROTECTED]> wrote:

More name ideas for Glasgow (and maybe for others as well):

Bernoulli (messages flow)
Cumin (spice)
Kyma (wave)
Leno (an open-woven fabric)
Linum (flax)
Pharos (lighthouse)
Subito (at once)

  -- Archit Shah

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





--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)

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

Re: Glasgow - new name proposal

[Carl Trieloff]

+1 for Kyma  easy to say, read and use in code.

Archit Shah wrote:

More name ideas for Glasgow (and maybe for others as well):

Bernoulli (messages flow)
Cumin (spice)
Kyma (wave)
Leno (an open-woven fabric)
Linum (flax)
Pharos (lighthouse)
Subito (at once)

 -- Archit Shah

-
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: Glasgow - new name proposal

[Archit Shah]

More name ideas for Glasgow (and maybe for others as well):

Bernoulli (messages flow)
Cumin (spice)
Kyma (wave)
Leno (an open-woven fabric)
Linum (flax)
Pharos (lighthouse)
Subito (at once)

 -- Archit Shah

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

Re: Jini?

[Sanjiva Weerawarana]

On Wed, 2006-08-09 at 13:51 -0400, Jim Hurley wrote:
> Thanks, Mark, for following up with some of the thinking.

+1.

> I am unclear on what the process is... can someone shed some
> light?  As far as the naming goes:
>- how can we determine if the "Jini" name is acceptable to Apache?

With Mark's long explanation of the bazillion things called "Jini", I'd
say that its unlikely to be acceptable. But then ... we're a weird bunch
and YMMV. (And I'm *really* sorry for that but that's the way we work
yet :(.)

>- whether contributing the TM would be welcomed?

My personal opinion: probably not needed.

>- whether use of "Jini" by other community sites, etc would be
>  acceptable?

If the name's changed here of course. If not hmm probably not; we're
currently in the habit of giving grief of that nature to Geronimo stuff.

> We're anxious to get going, but the path we must take is unclear
> to us.

I think there was generally enthusiastic interest in Jini (from me too
personally) here, so other than for sorting out the legal issues we
should be ok. But then I'm one of many with an opinion and one of (a
smaller) many with a vote. 

Best path is be patient, keep pushing (gently), try to make adjustments
as consensus is apparently falling into place, and finally when you feel
the need to pull your hair out, pull only one each time .. that way you
won't look like me by the time this proposal gets accepted. ;-).

Sanjiva.



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

Re: Glasgow - new name proposal

[Carl Trieloff]

I think we should maybe try get 3 or 4 top picks for names, and then 
check that these meet
the incubator sniff test and then do a trademark search on those, which 
will most likely

narrow the search to 1 out of the 4.

Carl.


Kim van der Riet wrote:

In the acronym dept., how about:

AMQE (Advanced Messaging, Queues and Exchanges), pronounced "am-queue".
EMQE (Enterprise/Extensible  Messaging, Queues and
Exchanges), pronounced "em-queue".

Kim

On Tue, 2006-08-08 at 20:17 +0100, Joyce, Sean (Sam) wrote:
  

Hi Folks,

 


As we appear to need a new name for Glasgow, I've got a proposal:
"Twister"

 


Thoughts?

 


Regards,

Sam.





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

  

Re: Glasgow - new name proposal

[Kim van der Riet]

In the acronym dept., how about:

AMQE (Advanced Messaging, Queues and Exchanges), pronounced "am-queue".
EMQE (Enterprise/Extensible  Messaging, Queues and
Exchanges), pronounced "em-queue".

Kim

On Tue, 2006-08-08 at 20:17 +0100, Joyce, Sean (Sam) wrote:
> Hi Folks,
> 
>  
> 
> As we appear to need a new name for Glasgow, I've got a proposal:
> "Twister"
> 
>  
> 
> Thoughts?
> 
>  
> 
> Regards,
> 
> Sam.
> 


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

Re: Jini?

[Jim Hurley]

Besides the 'name question' -- are there any other questions or issues
associated with the JiniProposal that we could be discussing?  For  
reference,

the submission from the incubator archives is at:



I've also placed it in the wiki at:

which I'll update as we go along.

thanks -jim

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

Re: Jini?

[Jim Hurley]

Thanks, Mark, for following up with some of the thinking.

I am unclear on what the process is... can someone shed some
light?  As far as the naming goes:
  - how can we determine if the "Jini" name is acceptable to Apache?
  - whether contributing the TM would be welcomed?
  - whether use of "Jini" by other community sites, etc would be
acceptable?

We're anxious to get going, but the path we must take is unclear
to us.

Thanks for any help.

-Jim


On Aug 8, 2006, at 6:29 AM, Mark Brouwer wrote:

Sanjiva Weerawarana wrote:

I know changing the name is a *really* tough thing for Jini.  
However, is
Jini a *technology* or an *implementation*? If its the prior I'm  
afraid

our current guidelines are not to do technology names.


I understand for those not very involved with the Jini Technology  
it is
hard to pinpoint what Jini exactly is and why some of us are  
willing to

go through great lengths to take this name with us, so let me try.

First Jini is a Technology, but with an extra handicap as the borders
where Jini begins and ends are not very well defined, even while in
1999/2000 there was already a document that described the Jini
Architecture and the Jini Technology Core Platform. It just lacks a
clear definition, when you ask 10 people to describe Jini chances are
high that you will get 10 different answers; some that will make you
happy or smile, and some that make you foam with rage ...

Many consider the implementation of Sun JTSK (Jini Technology Starter
Kit) as being 'Jini' but this is not correct (if you would ask me) and
while the proposal mainly centers around their code the proposal also
includes another Jini Community Approved Standard, namely ServiceUI  
(the

other trademark involved).

What is part of this proposal are most of the Jini Community Approved
Standards and the IMHO 'sad' thing is that the Jini Decision Process
that ratified these specifications as community approved standards
ceased to exist. Sun is no longer willing to provide the Executive to
run the process and there are not enough people in the community that
want to take it over (read don't want to spend time on it). The  
current
owner of the Standards also doesn't believe they can get accepted  
as JSR

in the JCP based on experience with some of the specifications that
ended up as Jini Standard while they should have become J2SE
specifications in the first place. The net result is that some really
important Jini Community aspects [1] (the Standards) we all circle
around are part of this proposal, and if we can stay clear of forks it
should be seen as the foundation on top of which the rest of the Jini
community will build their own stuff.

[1] as Jim mentioned the new http://jini.org/ is another aspect of the
community and is there for everything one could see as Jini related
(really open ended), http://jini.dev.java.net/ should be seen as the
yellow pages with regard to Jini related development projects and news
around that.

Renaming the Technology itself would be suicidal in my opinion as  
there

are dozens of people/companies that develop products/specifications on
top of 'Jini' so it would be harming them too. Of course it would be
possible to give the TLP a different name, but then again almost every
sentence would have a reference to the Jini Technology for which I  
guess

nobody could say where the 'Jini Technology' itself lives. Given the
fact the ASF project would be closest to defining the 'Jini  
Technology'

I think it is good to emphasize this by the name of the TLP.

IANAL and have no idea what the impact would be of handing over the  
Jini
trademark to the ASF, how the ASF will deal with other communities  
that
have Jini in their name, or other specifications that have Jini in  
their

name. I'm reluctant to say this given the fact that Sun has to protect
its trademarks, but I have the feeling that Jini has become rather
generic in the past years. People say I wrote a Jini service, I
developed a Jini Service Container, I do Jini, it is the Jini way,  
etc.

I also don't understand the implications of abandoning the trademark
itself, but I would like to see that Jini can be used in the future as
it is today, even when it makes your mouth foam.

To summarize as *I* see it at this very moment:

  - Jini is not a product.
  - Jini can't be used as a noun.
  - Jini in combination with another noun could serve as a  
specification

name for which one can have multiple implementations, such as
'Jini Helper and Utility Classes', 'Jini Platform',
'Jini Service Container', etc.
  - the deliverables of an Apache Jini TLP should get their own  
distinct

name without Jini in it, except when it represent a 'Jini ...
Specification'.
  - Jini itself only represents the magic of doing distributed  
computing
in a proper way and comes in a lamp, these are already hard to  
find

these days so please don't make it even harder :-)

I would like to know whether people object against

Re: [vote] Accept Glasgow (revised vote)

[William A. Rowe, Jr.]

Carl Trieloff wrote:
> William A. Rowe, Jr. wrote:
>> Last and final objection, I want to make sure I am not missing
>> something...
>> the contract between the spec participants is or is not public?  If
>> public,
>> was there a link I missed?  If so, can it be added to the proposal for
>> completeness sake?
> 
> I have to say partially public.

With your very detailed explanation, I grok the dynamics at work.  Although
I can't support the proposal until I understand all of the NDA's at work,
the extent to which the project will be 'controlled' by private traffic, and
by traffic they may or may not successfully influence ...

... I'm very pleased with all of the efforts to resolve entirely reasonable
confusion on the part of the submittors, and fully believe the project can
succeed as it addresses the remaining issues ...

... my vote is retracted, count me +/- 0 until we determine the rules by which
the spec committee is playing, at which point I would likely support the
proposal.  But please don't let my earlier negative vote impede your progress
if there's sufficient support for the proposal as-is, the -1 is reverted.

Bill

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

Re: [rant] seperate policy change from proposal discussion

[Danny Angus]

On 08/08/06, Leo Simons <[EMAIL PROTECTED]> wrote:


The latest example is all the debate surrounding whether or not the
"glasgow" name is appropriate. Up until about a week or two ago, it
certainly was accepted practice (just look around), and now 'suddenly'
there's messiness. Its ok if opinions change (we had a lng debate
a few years ago about "geronimo" as a name and that made it), but it
must be very confusing.



Perhaps we should have two mailing lists.



WDYT?


Mea culpa.
I made the mistake of provoking a debate on name policy within the
Glasgow threads. This, with hindsight, was wrong. I should have
started a new thread and used Glasgow as an example instead.
I understand that this must have confused and pissed off the Glasgow
folks. Please believe that this was never my intention. If I was
having a go at anyone it was at the incubator's ASF folks who are much
more immune to this kind of random venting in any case. I suppose I
expected my voice to be largely ignored, not to whip up a mailstorm.

Glasgow folks, please accept my appologies for being a bit ham fisted
about the way I did that.

d.

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

Re: Can't access Glasgow/AMQP subversion

[Carl Trieloff]

Read Only access to the source code can be done with

userid - etpguest
password - guest

Wiki is also updated with this change, to fix Paul's access issue.

Carl.

Carl Trieloff wrote:


I thought I had fixed this, will get guest reset shortly
Carl.

Paul Fremantle wrote:

Hi Glasgow Proposers

I tried to check out the AMQP code from the Redhat website:

svn checkout https://etp.108.redhat.com/svn/etp/trunk/blaze/ 
--username guest

with the empty password for guest as described on
https://etp.108.redhat.com/servlets/ProjectSource#cmdlinesvn

And it didn't work. I can browse the tree using the website but I
would like to look at the code.

Paul




-
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: Axis2 inclusion of Woden incubator podling

[Davanum Srinivas]

I guess the question is - What if any disclaimers/notices/readme stuff
has to be in Axis2 distribution to warn users about jars from projects
under incubation.

thanks,
dims

On 8/9/06, Guillaume Nodet <[EMAIL PROTECTED]> wrote:



Jeremy Hughes wrote:

> Hi,
> Axis2 are starting to get ready for a 1.1 release. Since 1.0, it has a
> new dependency on the Woden incubator podling. This is a similar issue
> to Geronimo including ActiveMQ back in March [1]. Except, unlike
> ActiveMQ, Woden was never a project existing outside the ASF.
>
> Does anyone know of any general guidance resulting from that
> discussoin since then?
>
> If not then this is my proposal: Axis2 currently depends on a snapshot
> of Woden, so I think that *has* to change at least for an official
> release. ie. Woden to make a new milestone release (like it's been
> doing successfully for some time now) and for Axis2 1.1 to depend on
> that. Of course the newly proposed incubating maven repo would be a
> nice place for us to put Woden milestone releases :-)
>
> Then, in its README Axis2 should make very clear which function relies
> on Woden and that this function isn't production ready because it is
> reliant on an incubator podling.

Incubation does not mean anything on code quality (or did I miss
something ?).
So saying that it's not production ready is just out of topic imho.

Cheers,
Guillaume Nodet

>
> Does anyone see an issue for an official ASF project release (ie
> Axis2) to contain jars from a podling (of course the jars will have
> "incubating" in their name).
>
> Any comments appreciated.
>
> [1]
> http://mail-archives.apache.org/mod_mbox/incubator-general/200603.mbox/[EMAIL 
PROTECTED]
>
>
> Thanks,
> Jeremy
>
> -
> 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]





--
Davanum Srinivas : http://www.wso2.net (Oxygen for Web Service Developers)

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

Re: Axis2 inclusion of Woden incubator podling

[Guillaume Nodet]

Jeremy Hughes wrote:


Hi,
Axis2 are starting to get ready for a 1.1 release. Since 1.0, it has a
new dependency on the Woden incubator podling. This is a similar issue
to Geronimo including ActiveMQ back in March [1]. Except, unlike
ActiveMQ, Woden was never a project existing outside the ASF.

Does anyone know of any general guidance resulting from that
discussoin since then?

If not then this is my proposal: Axis2 currently depends on a snapshot
of Woden, so I think that *has* to change at least for an official
release. ie. Woden to make a new milestone release (like it's been
doing successfully for some time now) and for Axis2 1.1 to depend on
that. Of course the newly proposed incubating maven repo would be a
nice place for us to put Woden milestone releases :-)

Then, in its README Axis2 should make very clear which function relies
on Woden and that this function isn't production ready because it is
reliant on an incubator podling.


Incubation does not mean anything on code quality (or did I miss 
something ?).

So saying that it's not production ready is just out of topic imho.

Cheers,
Guillaume Nodet



Does anyone see an issue for an official ASF project release (ie
Axis2) to contain jars from a podling (of course the jars will have
"incubating" in their name).

Any comments appreciated.

[1] 
http://mail-archives.apache.org/mod_mbox/incubator-general/200603.mbox/[EMAIL PROTECTED] 



Thanks,
Jeremy

-
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: Can't access Glasgow/AMQP subversion

[Carl Trieloff]

I thought I had fixed this, will get guest reset shortly
Carl.

Paul Fremantle wrote:

Hi Glasgow Proposers

I tried to check out the AMQP code from the Redhat website:

svn checkout https://etp.108.redhat.com/svn/etp/trunk/blaze/ 
--username guest

with the empty password for guest as described on
https://etp.108.redhat.com/servlets/ProjectSource#cmdlinesvn

And it didn't work. I can browse the tree using the website but I
would like to look at the code.

Paul




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

Can't access Glasgow/AMQP subversion

[Paul Fremantle]

Hi Glasgow Proposers

I tried to check out the AMQP code from the Redhat website:

svn checkout https://etp.108.redhat.com/svn/etp/trunk/blaze/ --username guest
with the empty password for guest as described on
https://etp.108.redhat.com/servlets/ProjectSource#cmdlinesvn

And it didn't work. I can browse the tree using the website but I
would like to look at the code.

Paul

--
Paul Fremantle
VP/Technology, WSO2 and OASIS WS-RX TC Co-chair

http://bloglines.com/blog/paulfremantle
[EMAIL PROTECTED]

"Oxygenating the Web Service Platform", www.wso2.com

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

Axis2 inclusion of Woden incubator podling

[Jeremy Hughes]

Hi,
Axis2 are starting to get ready for a 1.1 release. Since 1.0, it has a
new dependency on the Woden incubator podling. This is a similar issue
to Geronimo including ActiveMQ back in March [1]. Except, unlike
ActiveMQ, Woden was never a project existing outside the ASF.

Does anyone know of any general guidance resulting from that
discussoin since then?

If not then this is my proposal: Axis2 currently depends on a snapshot
of Woden, so I think that *has* to change at least for an official
release. ie. Woden to make a new milestone release (like it's been
doing successfully for some time now) and for Axis2 1.1 to depend on
that. Of course the newly proposed incubating maven repo would be a
nice place for us to put Woden milestone releases :-)

Then, in its README Axis2 should make very clear which function relies
on Woden and that this function isn't production ready because it is
reliant on an incubator podling.

Does anyone see an issue for an official ASF project release (ie
Axis2) to contain jars from a podling (of course the jars will have
"incubating" in their name).

Any comments appreciated.

[1] 
http://mail-archives.apache.org/mod_mbox/incubator-general/200603.mbox/[EMAIL 
PROTECTED]

Thanks,
Jeremy

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