JSPWiki has been added.
Thank you. :-)
there were some personal circumstances which made me
forget to copy it to the wiki earlier today.
No worries. Just trying to make sure that it all gets done. :-)
--- Noel
Craig.Russell wrote:
For several months, the practice has been to have podling reports
posted to the wiki by the Wednesday prior to the board meeting, giving
5 days for the IPMC to review the reports
Just to be clear, the Boad report is due on Monday, so those five days would
be some part of
Lucene.NET posted now, too. Thank you.
--- Noel
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
Janne,
You and I had the same thought. I suggest going with org.apache.JSPWiki, as
suggested by you in
https://issues.apache.org/jira/browse/JSPWIKI-465?focusedCommentId=12660676#
action_12660676.
--- Noel
-
To
I do not see any entry related with the January 2009 report for the
incubator projects in the Wiki.
What is the last date to send January report?
I'll have to check the board calendat, but if it runs true to form, we need
everything the week of the 12th so that we can get the report into them
on a point of order, do mentors/champions need to formally '+1' the vote?
Yes. There are no implied votes.
--- Noel
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail:
Greg Brown wrote:
We'll put together a draft proposal
Which is now at http://wiki.apache.org/incubator/PivotProposal.
All in all, appears to be a very nice proposal. :-)
You might want to reorganize and elaborate a bit. In particular, you list
Flex, Silverlight, and OpenLazlo up top, but
Thanks, Kevan. Request submitted. That message I'd not noticed. Better
for such requests to go to priv...@.
--- Noel
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands,
As with Yoav, I am in favor of this project. It resonates with what I do
for a living. Also as with Yoav, I'd suggest a different name. And I am
personally hoping that more names with be at least marginally reflective of
what the project does.
I would ask that you take a look at Lokahi
What is the status? See the Board report for what I culled from the mailing
list and SVN, but we've not received a report from the project.
--- Noel
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
On Wed, Dec 3, 2008 at 2:20 AM, Daniel Kulp dk...@apache.org wrote:
Except Noel has been very bad lately about updating the committe-info
that is
used to generate this list.
As far as I know, that list is up to date, and was up-to-date weeks before
you posted that it wasn't (yes, there were
Bertrand Delacretaz wrote:
Robert Burrell Donkin
...IIRC (and it's been a while) any member can alter the paperwork once
there's been a board ACK. can anyone from boardland confirm or deny
this?...
maybe we should designate some official volunteers (Incubator
sheperds) to help the PMC
December 2008 Incubator Board Report
Just a generally nice month.
CouchDB, Qpid and Abdera have graduated from the Incubator. Stonehenge and
ESME are new entries into the Incubator. A candidate up for vote is
Cassandra. As discussed in last month's report,
Torsten Curdt wrote:
Isn't the champion expected to be the ubermentor anyway?
Oh, please, no. :-) Leave off the adjective. The Champion can be expected
to be a Mentor (see below, though). No extra uber anything. No greater (or
lessor) of equals.
Or to rephrase this: does the vote of the
Torsten Curdt wrote:
The Champion can be expected to be a Mentor (see below, though).
No extra uber anything. No greater (or lessor) of equals.
http://incubator.apache.org/incubation/Incubation_Policy.html#Mentor
From that document (redacted for clarity):
Champion: A Member of the
November 2008 Board
Overall a good month. A few items of note.
Several of us met with Michael Cote at ApacheCon to discuss the Incubator
with him. Bertrand was instrumental in instigating and facilitating the
meeting.
The most contentious, and it isn't very contentious at that, discussion is
Update:
The most contentious, and it isn't very contentious at that, discussion is
regarding the Helenus proposal, which is to incubate an already existing
fork of Facebook's Cassandra project, ostensibly because Cassandra is dead
from a community perspective, with Facebook being absentee
In general the Incubator is operating well.
The Bluesky project, which has been an area of concern, has submitted a
report this month.
A number of us have asked that the Maven Repository issues, which has
swamped the general@ list for more than a month almost to the exclusion of
all other
Niklas Gustavsson wrote:
Is the idea to do this in the POM or similar? Having something like:
Can we please move this discussion to [EMAIL PROTECTED] or
[EMAIL PROTECTED]
--- Noel
-
To unsubscribe, e-mail: [EMAIL
Jason van Zyl wrote:
Noel, your comments are completely out of whack with reality. You are
asking Maven to enforce something that no one does. Pretty much
almost no one.
Checking PGP signatures is obviously not something the vast majority of
people do.
Really? Try following the
Niclas Hedhman wrote:
Being in the camp I hate Maven too
I hate Maven's lack of authentication, the potential for widespread damage,
and am immensely frustrated by their *years* of willfully negligent handling
thereof.
I would like to swap Noel's statement around and ask; Why doesn't
Moved to the thread it belongs in ...
Jason van Zyl wrote:
Noel J. Bergman wrote:
Emmanuel Lecharny wrote:
Better a bad decision than no decision, otherwise, soon, nobody will
vote anymore...
Not really. Consider that there appears to be a clear consensus
that if Maven were to fix
Something else that needs to be considered is what happens if
someone's private key in the web of trust gets compromised?
Did you see what happened with Fedora last week (or two weeks ago at this
point)? They had to close down their repository system and re-issue new,
re-signed, artifacts.
Brett Porter wrote:
Currently, it has checking turned on by default, but that isn't going to
be
a reasonable setting for some releases to come until the signatures in the
repository are cleaned up.
Why not enforce checking, but provide the ability for users to manually
approve unsigned
The sources you build come either from svn or from a signed
release package.
We are concerned only with the latter, not what people do with code taken
directly from our SVN repository.
--- Noel
-
To unsubscribe,
Henning Schmiedehausen wrote:
There is a pretty nice proposal on
http://people.apache.org/~henkp/trust/, however this will again take a
piece of freedom of doing software at Apache away and introduce some
administrative overhead that all projects must implement and manage.
But, as you say,
Jason van Zyl wrote:
Noel J. Bergman wrote:
We don't need for you to implement any policy other than the
requirement for users to approve authorized signing keys. You
simply need to implement artifact signing and mandatory
authorization, which is why I've moved this to the thread Brett
William A. Rowe, Jr. wrote:
Jukka Zitting wrote:
This is a slight majority (of binding votes) for accepting the
proposed change, but given the clear lack of consensus and the
concerns voiced about that, I unfortunately need to conclude that this
issue should be tabled until better
Emmanuel Lecharny wrote:
Better a bad decision than no decision, otherwise, soon, nobody will
vote anymore...
Not really. Consider that there appears to be a clear consensus that if
Maven were to fix the download situation, requiring that users approve the
user of Incubator artifacts, rather
Matthieu Riou wrote:
Exactly - that's when actual users are software developers, which is
the case for many of our projects.
Precisely. And those should be aware of disclaimers if those serve any
purpose.
Maven is *too* transparent in what it does: it hides the disclaimer,
preventing the
Dan,
It is a policy matter, not a legal one. And enforcing artifact signing
would address this and other crucial, fatal, flaws in Maven's repository
management.
I still maintain that unless Maven makes swift strides to enforce signing,
the ASF should ban the use of the Maven repository for all
The current tally is extremely close (9 +1 vs. 8 -1 binding)
I don't want to close an issue with such a small margin.
I suggest that we should not change policy on anything like this lack of
concensus. I do, however, suggest that pressure be put on Maven to enforce
signing.
--- Noel
William A. Rowe, Jr. wrote:
Noel J. Bergman wrote:
The current tally is extremely close (9 +1 vs. 8 -1 binding)
I don't want to close an issue with such a small margin.
I suggest that we should not change policy on anything like this lack of
concensus. I do, however, suggest that pressure
[If you're going to DISCUSS, please don't use VOTE on the SUBJECT. :-)]
Emmanuel Lecharny wrote:
If a release has some problems (IP issues, etc), you can't
remove it from maven, as some projects might depend on it,
and the users will immediately carpet bomb the maven ML to
get the release
I don't know of anybody who goes to actual users and tell
them here you go, unzip that stuff there, set your
JAVA_HOME and your MAVEN_HOME properly, execute 'mvn install'
and once all test cases pass you're golden.
LOL Pretty much word for word:
$ cd PLUTO_SRCHOME
$ mvn install
$ mvn
Aidan Skinner wrote:
Noel J. Bergman wrote:
Aidan Skinner wrote:
Qpid has a really awesome piece of code developed for us by Lahiru
Gunathilake (one our of GSoC students) we'd like to bring in-tree.
He's already got an ICLA on file, as he's a committer
Do we need to go through the formal
The Incubator is running smoothly and largely trouble-free. The biggest
debates in the past month have been related to project names. In the large,
we have good participation and oversight from the PMC.
A number of projects, including Etch and the previously mentioned photo
gallery project have
Aidan Skinner wrote:
Qpid has a really awesome piece of code developed for us by Lahiru
Gunathilake (one our of GSoC students) we'd like to bring in-tree.
He's already got an ICLA on file, as he's a committer
Do we need to go through the formal code-grant process
to do this? It's a fairly
Bill,
I'd be very interested in seeing a report at least from BlueSky.
I'll write something up.
The Incubator PMC and the ASF Board would like a status report on Bluesky
every month until further notice, and expect to see substantial movement
towards resolving the issues.
--- Noel
The Heart group is looking for a couple of mentor volunteers. Heart
(Highly Extensible Available RDF Table) will develop a planet-scale
RDF data store and a distributed processing engine based on Hadoop
Hbase.
Have you spoken with Hadoop and Roller, possibly Abdera?
--- Noel
scott comer wrote:
in my opinion there isn't [a demand for name change]. certainly
names is a rich topic and the discussion would never die down on
it's own because it is so much fun. it's a wonder anything gets done.
You should have been around for the start of Geronimo. :-)
can we put
Scott Comer wrote:
as a scientist, i am getting somewhat bristly at all the rumor,
innuendo, and hyperbole around names.
Can you be more specific?
So far the best argument against Etch that I've seen is Grant's, and Les
makes a good point about the transient nature of such release labels.
William A. Rowe, Jr. wrote:
Noel J. Bergman wrote:
Scott Comer wrote:
the important thing right now is, i think, that searching now for etch
doesn't not reveal anything which is obviously competing technology
True, but were the debian community to make a federal case of the issue, I
don't
Angela Cymbalak wrote:
This hasn't been discussed but I don't think that there is a
trademark issue.
Picasa and PicaGalley? Why would there be any trademark issue at all? Pica
is hardly something that Google can claim as a prefix. Picasa is a play on
the artist's name, and would be
Upayavira wrote:
Noel J. Bergman wrote:
It should be fine to use our infrastructure to hold the source code, as
long
as we don't have license pollution issues. They cannot use it to do
releases.
Can you clarify what you mean by 'releases'?
They cannot use it to do ASF releases
As explained in INCUBATOR-80, the Table of Contents
of the policy document is inconsistent and contains
broken links.
OK. And nice of you to fix it. I don't believe that this requires a vote,
and can be addressed by lazy consensus.
--- Noel
Where I think that there is a problem is when they ditch their old
infrastructure and exclusively use ASF's infrastructure to build,
maintain, and release non-ASF releases. To be sure in the case of
JSecurity the final artifacts will not use the ASF mirrors but that
does not hide the fact
Craig Russell wrote:
Noel J. Bergman wrote:
As explained in INCUBATOR-80, the Table of Contents
of the policy document is inconsistent and contains
broken links.
OK. And nice of you to fix it. I don't believe that this requires
a vote, and can be addressed by lazy consensus.
-1
It's
Bertrand Delacretaz wrote:
While it was incubating, Wicket did a few non-ASF releases on their
old project site, to minimize disruption for their existing users
while they were repackaging and cleaning up for an ASF release.
If I recall correctly, the first project that had to address this
Martijn Dashorst wrote:
it really is a problem IMO when incoming *open source*
projects have to ditch their collected history. If we
care about code provenance, having the full history
available is best.
I concur, although I'm not sure that everyone does.
--- Noel
when [graduating] to a TLP, were you able to retain
the history while working in the Incubator when you
moved to an SVN repo of your own?
You don't move to an SVN repo of your own. You stay in the main ASF
repository, along with all other ASF projects and other public content.
---
Doug Cutting wrote:
There's no conspiracy here to steal Apacheness. Rather, Yahoo!, Intel
and CMU would like to collaborate on open source software. Intel and
CMU have a prototype, and Yahoo! is interested in helping to develop
this further. All three believe that other parties will also
Doug Cutting wrote:
I would expect that Tashi would use Xen command-line programs, not link
directly to Xen's C API's.
Why? Personally, I hope that you are wrong. I would expect Tashi to define
a vendor neutral layer to which Xen, VMware, KVM, etc., implementations
could be written.
Henning Schmiedehausen wrote:
The wording for the Yahoo! slot sounded to me like there has been a
decision at management level that CMU, Intel and Yahoo! want to do some
work on that subject [...]
I believe that we've made it clear that there are no corporate slots, and
that the language
[
https://issues.apache.org/jira/browse/INCUBATOR-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12613703#action_12613703
]
Noel J. Bergman commented on INCUBATOR-78:
--
As a suggestion, each incubating
July 2008 Board Incubator Report
THE major topic of discussion has continued to be the Maven repository. A
thread, Do we really need an incubator?, was started by Dims, but the real
issue raised was over the perceived watering down of Incubator seperation as
a consequence of Maven's repository
Bernd Fondermann wrote:
I just noticed that BlueSky did not report anything since being voted
into incubation in January and is not linked from the incubator
website.
Henning Schmiedehausen wrote:
Last time I looked, GTK, which is at the core of the code that I looked
at, is under LGPL,
Craig Russell wrote:
I guess I missed the update on the process.
What update? We've been using the Wiki to accumulate these reports since
pretty much the beginning.
I've been sending the reports for the podlings I'm mentoring to the
general at incubator list for a year now.
And I've been
David,
I just reviewed http://wiki.apache.org/incubator/TashiProposal.
Interesting. Has anyone been in touch with VMware, XenSource, Google,
Amazon, et al to invite them to participate?
With respect to Initially, we plan to start with one committer each from
Carnegie Mellon and Intel Research,
Please have them finalized by Sunday evening GMT at the latest.
--- Noel
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Roy T. Fielding wrote:
There is no reason for a separate repository. [A separate repo] does not
help protect users from incubator code, since users don't set the Maven
configs that define which repos to use and which modules are dependencies.
At best, what it does is add an irrelevant
Roy T. Fielding wrote:
Justin Erenkrantz wrote:
For Incubator releases, the releases aren't held to the same legal
standard
as releases from other PMCs.
Huh? The only difference I know of is the possible presence
of external dependencies on LGPL code, which is not a legal
question at
Justin Erenkrantz wrote:
IIRC, we have voted on precisely this matter in the past. It just
seems that the issue will constantly be reopened until folks get
their personally desired result.
I agree.
--- Noel
-
To
since currently this software project is merely an idea (along
with some previously tinkered with codebases), I'd say it's a
perfect candidate for a lab. It doesn't sound like it's ready
for a release just yet. :)
When were either of those two things criteria for Incubation? And there is
Can you dive into the idea a little more about not providing a
backend storage mechanism for the photo gallery?
Actually, it isn't an idea. I was simply asking a question of where the
project will hang its hat(s) and where it will be flexible. What are its
defining points, and where is it
o, does this photo gallery software currently exist or are you trying
to start a new project?
There are several codebases (Angie's, mine, and others), but basically, a
new project.
--- Noel
-
To unsubscribe, e-mail:
William A. Rowe, Jr. wrote:
Noel J. Bergman wrote:
we should remember and capture that Roy raised valid points about
having the *vote* be public, albeit after private discussion. It
seemed that the idea was to discuss it in private, and only vote
in public if it was clear that the vote
Angela Cymbalak wrote:
I am convinced that Jackrabbit is the direction to go for the
mid-tier of the application.
My only question is whether or not we lose anything from that decision, but
if I didn't think that the JCR was the right way to go, I wouldn't have
brought it up.
I just haven't
William A. Rowe, Jr. wrote:
Craig L Russell wrote:
Would it be worthwhile to capture this discussion in a patch to the
offending paragraph?
We can capture both sentiments.
Yes. But at the same time as Bill and I agree that:
there's a concrete basis as-policy for not having public
William A. Rowe, Jr. wrote:
I have one small problem, and was otherwise +1 on the final proposed text;
This approach is considered inferior by many because it is a source of
discord to have a public vote like this fail or take a very long time.
The reason public votes are inferior is that
Craig.Russell wrote:
Noel J. Bergman wrote:
Did anyone actually count the vote? I have no problem with Craig's
patch, but did anyone actually vote for it? ;-)
It's guide, not policy, so it's CTR.
Yes, I had that thought after the fact: we are clarifying the
documentation of what we do
+1
--- Noel
smime.p7s
Description: S/MIME cryptographic signature
Bertrand Delacretaz wrote:
It's been three days since Craig posted his patch, and no objections
have been raised.
Craig, could you commit your patch so that we can close this issue?
Did anyone actually count the vote? I have no problem with Craig's patch, but
did anyone actually vote for
Jukka Zitting wrote:
The Composer [and] Pig projects were missing from the reporting
schedule. I took the liberty of assigning them all to the March,
June, September, December schedule
And once again, Composer and Pig have failed to report, along with log4php,
RAT, and Shindig.
---
Pig did report: http://wiki.apache.org/incubator/June2008. Is there
anything else we need to do?
No, sorry. Brain cramp. My excuse is running a fever. :-)
I already have already included Pig in the June report.
--- Noel
Chris,
We reported feb, april and may of this year, and were living under the
assumption our next reporting moment would be further in the future.
Our apologies.
OK, if you reported Feb, April and May, you're fine. I'm going by what had
been put on the wiki for the schedule. This is the
The top two issues of discussion in the past month are textual revision(s)
to make it clearer that the Incubator runs the same as every other ASF
project: only PMC votes are binding, although we encourage everyone from the
broader community and the especially the PPMC to cast (non-binding) votes;
Craig,
-1
But as I've said earlier, there is no indication here that three +1
votes are needed from incubator PMC members.
Needs work.
I agree with your concerns, but how do you feel with the amendment I
posted a few minutes ago?
--- Noel
smime.p7s
Description: S/MIME
Craig Russell wrote:
Noel's proposed change to Justin's proposed change is better but I'd
prefer that the process be crisper in the case that the PPMC vote
fails to get the required three PMC member votes.
OK. But I find it difficult to see precisely what change(s) you're
proposing to the
Les Hazlewood wrote:
I've given presentations on JSecurity and had many discussions in
private, and I always ask my audience: How many people have heard
of JAAS? Maybe 40-50% of the listeners affirm they have. Then I
ask, how many of you have used the JAAS API or its constructs
How does JSecurity relate to existing standards, e.g., JAAS, JACC,
WS-Security, etc.?
The only reference I found is a comment in the slide show saying Simplify
or replace JAAS. Well JAAS is the Java standard in this space, and part of
the Java core, so are we proposing a replacement or
Justin Erenkrantz wrote:
Noel J. Bergman wrote:
Henri Yandell wrote:
I very much like the idea of the PPMC - Incubator PMC relationship
modeling the board whenever possible.
Keeping in mind that the PPMC has no actual standing, so the vote still
requires the standard 3 +1 and more +1 than
Justin,
To summarize you are proposing the following change:
After completing the vote on the PPMC list, the proposer
calls a vote on the Incubator PMC private list
to:
After completing the vote on the PPMC list, the proposer
*sends a note to* the Incubator PMC private list
And change:
Henri Yandell wrote:
I very much like the idea of the PPMC - Incubator PMC relationship
modeling the board whenever possible.
Keeping in mind that the PPMC has no actual standing, so the vote still
requires the standard 3 +1 and more +1 than -1 from PMC members. Which is
why we always
Guillaume Nodet wrote:
Maven is just a tool to build something, it's not used to launch a
process while downloading the binaries at the same time. At the
end, people check what ends up in their distribution (be it a war
or a tar.gz) and at this point, they know that there is an incubator
Gilles Scokart wrote:
Noel J. Bergman:
Implement that, and we're fine. We will
require Incubator artifacts to be signed by a designated key available
to
the PMC, and once a user has acknowledged that they accept such
Incubator
signed artifacts, maven can do what it wants with them
Robert Burrell Donkin wrote:
my conclusion was that meta-data signed by [keys in the] WoT would be good
enough.
there's no need to distribute a master key
+1
key management is tricky
Not that tricky. Let's not make as if this isn't done routinely elsewhere.
this is where the complexity
William A. Rowe, Jr. wrote:
Why is it not equally possible to validate against a short list of keys
(e.g. infra PMC members) and their immediate trust. This is what gpg is
good at.
First get the code built into Maven for actually checking the signatures and
we're golden, with multiple
Brian E. Fox wrote:
I think this thread belongs on the Maven lists as it's is only
tangential to the decision about the incubator repository.
Well, that's not entirely true. It is rather key to a satisfactory
resolution, with the possible exception of some interim measure.
The process for
Henri Yandell wrote:
While incubation status is not necessarily a reflection of the
completeness or stability of the code, it does indicate that
the project has yet to be fully endorsed by the ASF.
Which is crap and should be deleted.
If you, wearing your Director and/or ASF Member
Henri Yandell wrote:
Noel J. Bergman wrote:
I really do not know why we have to revisit this same topic year after
year
after year. We do not want people to be using any Incubator artifact
without explicit knowledge and action, so we do not want them polluting
the
standard repository
Robert Burrell Donkin wrote:
Every incubator release is also an Apache release
http://incubator.apache.org/guides/releasemanagement.html#rules
+1
every incubator release is an official apache release
While technically accurate, the way you are both using the term conveys a
false meaning
Jukka Zitting wrote:
Noel J. Bergman wrote:
I really do not know why we have to revisit this same topic year after
year
after year.
Because it's an arbitrary restriction that IMHO hasn't been properly
justified.
So in other words, we'll revisit this again everytime someone (relatively
Robert Burrell Donkin wrote:
it has now been clearly established that we need to move the
repository. we're now just asking: where?
As I said, Brett Porter's proposal, made early on in the thread, seemed
satisfactory.
asking podlings to publish through a secondary repository is both
Brett Porter wrote:
Noel J. Bergman:
I really don't care what cuts across the grain of Maven. I do care
about
the established principle that people must make a deliberate decision to
use
Incubator artifacts. If Maven would finally support enforcing signing
of
artifacts, as they have
Brian E. Fox wrote:
I really don't care what cuts across the grain of Maven. I do care
about the established principle that people must make a deliberate
decision to use Incubator artifacts. If Maven would finally support
enforcing signing of artifacts, as they have been asked to do for
James Carman wrote:
The bottom line is that incubator projects haven't (yet) gone through
all the hoops necessary to become official ASF projects. So, if they
are published to the main repository, that is in a way saying that the
ASF endorses the software. Since it has not graduated from
Jukka Zitting wrote:
Craig L Russell wrote:
1. The incubating repository is not mirrored to the world, so incubating
artifacts don't pollute the maven-o-sphere.
What's so bad about incubating artifacts that would pollute things?
We are perfectly happy distributing them on www.apache.org
Thilo Goetz wrote:
One might argue that incubator releases go through a very
thorough release screening process
So what? The issue isn't code quality. Incubator projects are not part of
the ASF, yet. It is due to arguments like yours that some people have
proposed removing the Incubator
Robert Burrell Donkin wrote:
Noel J. Bergman wrote:
The Legal Committee does not appear to have any concerns over Roy's
proposed
changes.
legal-hat
i don't recall being officially asked
/legal-hat
I was referring to
Message-ID: [EMAIL PROTECTED]
in [EMAIL PROTECTED] In any event
301 - 400 of 1628 matches
Mail list logo
