On May 15, 2007, at 12:26 AM, Brett Porter wrote:
Quick question (I hope). I was thinking about what will happen if the
NMaven podling would like to add a committer, make a release, etc.
Would votes by Maven PMC members (As the sponsoring project) be
considered binding in this case, or should
Niall,
many thanks for the fix. That's really helpful. With regards to the
license issue, in the future I believe OSOA will publish the SDO APIs, in a
maven repository, but that's not the case yet, and we need these artifacts
to publish an SDO release. I believe that we are compliant with
Craig,
[EMAIL PROTECTED] and [EMAIL PROTECTED] I think
On 5/14/07, Craig L Russell [EMAIL PROTECTED] wrote:
Now I'm confused. Could someone put some alias names to these
concepts? I thought we were talking about project-dev and project-
user. What aliases are others referring to?
Thanks,
On 5/14/07, Martin Ritchie [EMAIL PROTECTED] wrote:
Hi, just wanted to keep this thread alive as it has been almost a
month and we are still a mentor short.
I just saw this, I'd be happy to serve if needed, FWIW I work in
Glasgow so I have some degree of geographical proximity with the QPid
On 5/15/07, kelvin goodson [EMAIL PROTECTED] wrote:
Niall,
many thanks for the fix. That's really helpful. With regards to the
license issue, in the future I believe OSOA will publish the SDO APIs, in a
maven repository, but that's not the case yet, and we need these artifacts
to publish
Hi Brett,
+1 to most of what Leo says.
I'd point out that the main purpose of the PPMC is to get the podling
to the point of making decisions the Apache Way and the IPMC then
ratifies the decisions. This model should allow the decisions to be
made by the people who know and care the most,
Hi Danny,
Thanks for that. This does put a different slant on things.
I intend to discuss all of these mailing lists along with the email
alias file, posting to the lists, and subscribing to the lists, in
the update.
Craig
On May 15, 2007, at 5:33 AM, Danny Angus wrote:
Craig,
[EMAIL
I already did this a while back...
http://incubator.apache.org/projects/index.html
where else do i have to do it?
Remove it from incubator-info.txt (and from the Wiki reporting pages).
Again, the redundant data problem raises its ugly head.
--- Noel
It's not on the wiki pages either...i'll look into the incubator-info.txt (svn?)
thanks,
dims
On 5/15/07, Noel J. Bergman [EMAIL PROTECTED] wrote:
I already did this a while back...
http://incubator.apache.org/projects/index.html
where else do i have to do it?
Remove it from
Thanks folks. What Leo and Craig said is what I expected, though I was
a bit concerned about finding the IPMC people to ratify such
decisions. I'll still look for more mentors.
- Brett
On 15/05/07, Craig L Russell [EMAIL PROTECTED] wrote:
Hi Brett,
+1 to most of what Leo says.
I'd point out
On 6 May 07, at 11:11 AM 6 May 07, Shane Isbell wrote:
[ ] use standard repositories
[ x ] relocate repositories under /www.apache.org/dist/incubator
My reasons are as follows: First, NMaven does not follow the
standard repo
layout; second, the repository layout structure is still in a
On 6 May 07, at 8:56 PM 6 May 07, Daniel Kulp wrote:
Shane,
Honestly, it sounds like the NMaven stuff will need a complete new
set of
repositories for NMaven artifacts. There isn't any way, IMO, that
the
repo layout can change for the normal maven 1 and maven 2
repositories.
On 6 May 07, at 9:13 PM 6 May 07, Carlos Sanchez wrote:
I didn't have a chance to talk about this with Shane but the idea in
the end is to make the repository agnostic on how things are stored
and how the client uses them.
Right now is a simple directory, but could be a database with a web
Just to clarify, the implementation is now as follows: NMaven uses the
default repo format remotely and then transforms locally; this is the most
pragmatic approach, and I don't have any immediate concerns. The problem,
however, is that we are exposing the internal schema to the client; this
The ODE community held a vote for its first incubator release. See [1] for
the tally of 6 +1s (including one mentor vote) and no 0 or -1s. We're now
asking for a vote by the incubator PMC to authorize the publication of our
1.0 release.
The release consists of 3 different artifacts:
- A
Although HTTP GET with a URL may qualify as an API, under its
current form its really implementation (file-system) specific.
What makes it implementation specific? You can't store the files in a DB,
and map the URI to the resource? Isn't it really a URI, specifying the
package name and
On 5/15/07, Noel J. Bergman [EMAIL PROTECTED] wrote:
Although HTTP GET with a URL may qualify as an API, under its
current form its really implementation (file-system) specific.
What makes it implementation specific? You can't store the files in a DB,
and map the URI to the resource? Isn't
Hi Noel,
Correct, using a URI does not require a specific implementation; but in
today's environment, if someone needs a different repo format, they get one
of two responses: 1) create your own repo that uses a different repo format;
or 2) use the same repo format but transform the artifact
OK...I'll get it done for next month.
Darren
On 5/14/07, Noel J. Bergman [EMAIL PROTECTED] wrote:
Darren Middleman wrote:
Sorry about the incubator report, I didn't realize it was that time
already.
I'll get this together and post it to the Wiki tomorrow (Tuesday).
That will be too late.
19 matches
Mail list logo
