Mentor vs. Shepherd

[Berin Lautenbach]

Nicola and others,

I note in the DraftPolicy document you have done a s/shepherd/mentor/g.

Is this our final call on the title for these people?  I.e. should I 
make the same change to the Process Description?

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

Re: Disclaimer text for incubated projects

[Berin Lautenbach]

Sam Ruby wrote:
Can I ask that you document the process of updating the site?
Looks like it's already there, but not very obvious.  I will add to the 
side-bar, but in the interim :

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

I want to make sure that there is a set of requirements for what status 
files are expected to contain, and a description the necessary 
disclaimers that need to be present on the various sites.  I also want 
to update http://incubator.apache.org/projects/index.html .
There is already something (purposefully minimal) in the 
IncubatorPolicyDraft document on Wiki - you are more than welcome to 
modify/change/update.  This is the raw text for what will be the 
normative requirements, so would be the best place to put it.

Alternatively - if you still want to hit the Process document, it's 
about to get changed.  If you are able to hold on for 24 hours, I'll get 
the new version into the drafts section so that you can update what is 
going to get moved over.  If not - go mad and I'll try to incorporate 
your changes back into the new Process document.

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

Auto-update of incubator site

[Berin Lautenbach]

Peoples,

Is there a cron job anywhere that auto-updates the incubator site out of 
CVS?

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

doesn't mention one, but at the same time doesn't indicate that you have 
to log into the site to do a "cvs up".

If there isn't - does anyone mind if I set up a cron job to update the 
site from CVS every six hours?

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

Re: Disclaimer text for incubated projects

[Berin Lautenbach]

Sam Ruby wrote:
I'm under the weather, and a little irritable, but this is starting to 
get under my skin.

I am trying to follow http://incubator.apache.org/process.html

I have asked for this to be updated.

I have asked for information on how I can update this.
Sam,

I am 90% of the way through doing an overhaul of process.html that I am 
going to place (this weekend) in the drafts section of the incubator site.

In the interim, if you want to see what is going on in terms of content, 
have a look at :

(To be the Non-normative process description - nearly ready to go accross).

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

(To be the normative set of incubation requirements - still embryonic, 
and not yet ready to go into drafts on site)

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

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

Re: Disclaimer text for incubated projects

[Berin Lautenbach]

All,

FWIW - the following is the extract (at time of writing) from the draft 
Policy document relating to the current discussion.

I am about to move this into the drafts section of the site, so people 
can start hacking within CVS.

Cheers,
Berin
= Podling Constraints =

== Branding ==

Podlings are, by definition, not yet fully accepted as part of the 
Apache Software Foundation.  Podling web sites MUST include a clear 
disclaimer on their website and in all documentation stating that they 
are in incubation.

Podlings SHOULD use the following text for all disclaimers :

 is an effort undergoing incubation at the Apache 
Software Foundation (ASF), sponsored by the . 
 Incubation is required of all newly accepted projects until a further 
review indicates that the infrastructure, communications, and decision 
making process have stabilized in a manner consistent with other 
successful ASF projects. 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.

Podlings wishing to use a different disclaimer message MUST have the 
disclaimer approved by the Incubator PMC prior to use.

== Releases ==

As podlings are not yet fully accepted as part of the Apache Software 
Foundation, any software releases (including code held in publically 
available CVS) made by Podlings will not be endorsed by the ASF.

However, as software releases are an important part of any software 
project, they are permitted in certain circumstances, as follows.

Podlings in Incubation SHALL NOT perform any releases of software 
without the explicit approval of the Incubator PMC.  Such approval SHALL 
be given only after the Incubator PMC has followed the process detailed 
in (Reference to Charter), and SHALL NOT occur until all source has been 
legally transferred to the ASF.

Therefore, should a Podling decide it wishes to perform a release, the 
Podling SHALL formally request the Incubator PMC approve such a release. 
 The request SHALL have the endorsement of the Mentor.

Should the Incubator PMC, in accordance with (Reference to Charter) vote 
to approve the request, the Podling MAY perform the release under the 
following constraints :

* the release archive MUST contain the word "incubating" in the 
filename; and
* the release archive MUST contain an Incubation disclaimer (as 
described in the previous section), clearly visible in the main 
documentation or README file.



Sam Ruby wrote:
Tetsuya Kitahata wrote:

On Fri, 3 Oct 2003 19:00:57 -0400
"Noel J. Bergman" <[EMAIL PROTECTED]> wrote:
Judging from the move we made with james, CVS was easy.  ezmlm a bit 
more
involved, but our users seemed to find us easily enough when the list
address changed from [EMAIL PROTECTED] to
[EMAIL PROTECTED]  Moving the web site was easy.


I'd like to oppose this. (Sorry) 


I'd like us to all step back and take a look at the bigger picture.

Apparently, the root of this is a statement that something about the 
incubation process of Lenya raised hackles.  I suggest that there may be 
multiple root causes for this.

Putting incubator as a part of the name is a form of disclaimer.  One 
that is relatively expensive.  I, too, would rather we explore cheaper 
alternatives before we decided to require this for every project.

It seems to me a disclaimer on the website, perhaps also in the root 
directory of the associated CVS trees, and a process which prevents any 
official "release" to be created by projects in incubation should be 
more than sufficient.

- Sam Ruby

-
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: Disclaimer text for incubated projects

[Berin Lautenbach]

David Jencks wrote:
As podlings are not yet fully accepted as part of the Apache Software 
Foundation, any software releases (including code held in publically 
available CVS) made by Podlings will not be endorsed by the ASF.




Podlings in Incubation SHALL NOT perform any releases of software 
without the explicit approval of the Incubator PMC.
To me, one possible reading of these two statements is that explicit 
approval of the Incubator PMC is required for any change to code held in 
publicly available CVS.  I doubt that is what anyone intends.
Actually - yes and no :>.  The intent was that code can not go into the 
CVS until the Incubator PMC is comfortable that any legal issues have 
been worked through.

Whether that needs explicit approval or is up to the Shepherd/Mentor to 
determine is where the content is confusing.

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

Re: Disclaimer text for incubated projects

[Berin Lautenbach]

Noel J. Bergman wrote:
The draft seems to be using RFC 2119 (http://www.ietf.org/rfc/rfc2119.txt)
terminology.  If so, let's please reference the RFC early in the document so
that readers can find the operation definitions (thus establishing common
volcabulary).
Whoops.  There is a line in there :

"Where capitalised, these terms are to be used as per the definitions 
found in RFC 2119 (Reference)."

So I think I was thinking (which is a lot of thinking) the same thing :>.

Will fix.

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

Re: [PROPOSAL] fold incubator-site into incubator CVS ( Re: Posting and tracking project tasks )

[Berin Lautenbach]

Nicola Ken Barozzi wrote:
Since there seems to be agreement that we should have some sort of 
Mentor reporting to the PMC, it would be easy for Mentors to update the 
STATUS file at every report.

Does this sound reasonable?
+1.

One is a tool, the other is the processed information.  The PMC probably 
only cares about the information and the Mentor/Shepherd can keep that 
information in whatever way suits best, provided it is delivered in a 
standard format.

The STATUS file is the minimal requirement, allowing the Mentor the 
greatest possible flexibility in how they deliver that requirement.

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

Re: Disclaimer text for incubated projects

[Berin Lautenbach]

Stephen McConnell wrote:


Berin Lautenbach wrote:

 is an effort undergoing incubation at the Apache 
Software Foundation (ASF), sponsored by the .  Incubation is required of all newly accepted projects until 
a further review indicates that the infrastructure, communications, 
and decision making process have stabilized in a manner consistent 
with other successful ASF projects. 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. 


Berin:

I have a problem with the last sentence in the above paragraph as it 
implies a association between the incubator and project code completness 
and/or stability.  Here is a suggested replacement that eliminates the 
concern:

 is an effort undergoing incubation at the Apache 
Software Foundation (ASF), sponsored by the . 
Incubation is required of all newly accepted projects until a further 
review indicates that the infrastructure, communications, and decision 
making process have stabilized in a manner consistent with other 
successful ASF projects. As such, the project has not been formally 
endorsed by the ASF.
I am comfortable with this.  Any objections with this ammendment going 
in the policy draft?

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

Re: Disclaimer text for incubated projects

[Berin Lautenbach]

Noel J. Bergman wrote:
Whoops.  There is a line in there :
"Where capitalised, these terms are to be used as per the definitions
found in RFC 2119 (Reference)."
So I think I was thinking (which is a lot of thinking) the same thing :>.


Will fix.


Fix what?  Looks like you already did it.  I was looking at your e-mail, not
the site, and the line wasn't in the extract, but has been in the full
document since the third revision on Sept 28th.  :-)  Mea culpa.  :-)
The Incubator site version now also has a link to the RFC (which is what 
the "(Reference)" thing was there to remind me to do).

Which is what I fixed!

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

Re: STATUS file compared/contrasted with an issue tracker

[Berin Lautenbach]

Noel J. Bergman wrote:

cycle.  If the project chooses to copy the STATUS items into an issue
tracker so that they'll receive periodic reminders of outstanding items,
that would be their choice, but the only official document would be the
STATUS file.  Since you want to use XML, if the XML were defined properly,
someone could write a tool to generate a report of all outstanding items.
But I don't think that we want to get into the process of building yet
another ad hoc issue tracker.
Or we could stick with plain text.  From what I think we are saying
(including below), the original status file could come from a template,
customized if/as necessary by the PMC and placed into the incubator CVS
module.
Apologies for coming in late on the conversation - have been away from 
e-mail.

I think everyone is agreeing - but one other thought that comes to mind 
that supports a text STATUS file is that it is the minimal possible 
requirement.

So if we want to put a process/policy requirement in place, this is the 
one that makes sense.  It can be implemented using a status tracker, or 
by processing an XML file - i.e. in whatever way the mentor/podling 
think is best for their incubation effort.  If we start saying we want 
this tool or that then things start getting messy.

Doesn't mean that the Incubator can't point people to a favourite 
tracker as a tool - just means it's a suggestion, not a requirement.

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

Re: STATUS file compared/contrasted with an issue tracker

[Berin Lautenbach]

Nicola Ken Barozzi wrote:

BTW, I wrote two mails about it on this list, did you miss them? I mean, 
are we still having problems with mails?

I seem to be getting the odd mail bounced after five days of trying?

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

Re: New proposed incubator CVS layout

[Berin Lautenbach]

Nicola Ken Barozzi wrote:

Here is the layout I am now working on:

 - build/  (the built site)
 - site/   (the site docs)
 - resources/  (forms,project logos,etc)
In the root we will have:

  skinconf.xml   (needed for forrest)
  forrest.properties (needed for forrest)
  status.xml (the incubator project status)
  README.txt (that explains the structure and how to build
  the site)
The site would be divided like this:

- incubation/ (docs on teh incubation process)
- learn/  (learn about Apache)
- projects/   (incubation status of projects
  *one* file per project)
/success/ (projects that have exited positivly)
/failure/ (projects that have not made it out of incubation)
Does this sound good?
I noticed in the new version that Drafts now takes a reader to the Wiki, 
and there is a "Final Drafts" subsection of the main incubation pages.

Is this giving the Wiki pages a more official status than previously?  I 
kind of like the idea of a Drafts section, where documents close to 
completion go, with maybe a cover page that discusses the reason for the 
drafts section and points to the Wiki with a clear statement that this 
is where absolute first cuts get created.

I also noted when I looked that the status section talks about a 
Sponsor.  Should we talk about both the Sponsor and the Sponsoring 
Entity (to keep the terminology in line with documentation)?

Having said that, I like the layout (but then I already know Forrest, so 
I like it from that perspective too :>).

Cheers,
Berin


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

Re: Proposal: Sponsor becomes Mentor

[Berin Lautenbach]

> From: Nicola Ken Barozzi <[EMAIL PROTECTED]>

> The name "Sponsoring Entity" is wierd, and the more I think of it, the 
> more it seems artificial.

Yup.  It was the best I could think of at the
time :<.

> 
> What we need is something that sponsors the project, and will accept it, 
> and someone that mentors the project, which are 2 concepts, not 3 as now.
> 
> Hence I propose that we have:
> 
>   - Sponsor: the Apache entity (PMC) that sponsors the project
>  and that will recieve it upon succesfull incuabtion.
>   - Mentor:  the Apache member or Sponsor PMC member that will
>  assist in incubation. He will become part of the
>  Incubator PMC.
> 

The only issue then is that we loose the original
concept of the sponsor.  While the distinction
between sponsor and sponsoring entity was
artificial, I think it was useful.  

So the sponsor was the individual Apache member
who would champion the cause of the candidate
project with the relevant sponsoring entity,
help the candidate through those initial stages
and be a champion for the podling once it was
accepted.

We still need this role (at least prior to
acceptance by a "sponsoring entity" or whatever
we want to call it now) I think.  However I like
the idea of calling the "sponsoring entity" the
sponsor, as it's more natural.  For the purposes
of documentation why not something like the
candidate "champion" for the original sponsor 
idea?

Cheers,
Berin



This message was sent through MyMail http://www.mymail.com.au



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

Re: minimum advance notice for "review of activity"?

[Berin Lautenbach]

Rodney Waldhoff wrote:
Under
,
we state:
"The Incubator PMC SHALL inform Podlings of review dates at least 4 weeks
in advance."
and that

"At least one week prior to each review, the Mentor MUST produce a report
for the Incubator PMC detailing overall progress [...]"
Is it safe to assume that this time frame may be shortened based upon a
mutual agreement of the incubating project and the Incubator PMC?
Otherwise all review actions take at least a month, which depending upon
the reason for continuation, may be an inordinate amount of time.
Yes, I think you are correct.

The intent of the above was about creating some minimum reporting 
requirements.  I think it might be worth adding something in there about
"Podlings/Mentors MAY also request a review of activity or issues at any 
other time".  (Better worded, but it's dinner time and I'm in a hurry :>.)

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

Re: How to manage change in the Incubator rules

[Berin Lautenbach]

Nicola Ken Barozzi wrote:
Because of this, I would suggest that we remove the "draft" status on 
our policy docs and simply use them as our guide, that will change in 
need without having to go through tedious votes when there is good 
consensus.

Objections?

None - although by taking the "draft" off the policy, there are some 
MUST/SHALL requirements placed on the Incubator PMC that you might want 
to be comfortable with (in particular quaterly reviews of Podlings) :>.

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

Common naming accross policy/process/roles

[Berin Lautenbach]

Peoples,

In line with what I have seen in the last couple of weeks on preferred 
terms I have updated the Policy/Process and Roles and Responsibilities 
documents so that we have :

Champion (was Sponsor) - the Apache Member (or member of a Sponsoring 
PMC) who champions a new candidate prior to being accepted by a Sponsor.

Sponsor (was Sponsoring Entity) - the PMC or Board that accepts a 
candidate for incubation.

Mentor (was Shepherd) - the responsible Apache Member who works with a 
podling to see it through the incubation process.

As an aside - am getting an error :

Cannot open /home/cvs/CVSROOT/commitlogs/incubator: Permission denied

I suspect it's because I am not a member of the incubator group, but 
before I go to infrastructure@, I'm not sure whether I should be a member?

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

Re: Common naming accross policy/process/roles

[Berin Lautenbach]

> From: Nicola Ken Barozzi <[EMAIL PROTECTED]>

> 
> What about simply:
> 
> Sponsor (was Sponsoring Entity) - the PMC or Board that accepts a
> candidate for incubation.
> 
> Mentor (was Shepherd and Sponsor) - the Apache Member (or member of a 
> Sponsoring PMC) who champions a new candidate and works to see it 
> through the incubation process.

The only reason I left Champion (or whatever we
want to call it) was that the role does play a part in the 
start up of incubation, and is not necessarily the Mentor.

E.g. XMLBeans, where Steven Noels did most of the work to
help the candidate through the initial process and then
Ted took on the role of Shepherd.  (Note that this doens't
mean the Champion ducks out - Steve is still around in 
XMLBeans.)

There was a thread some time back from memory on this -
where we came to the conclusion that the kind of person that
makes a great Champion is not necessarily the person who
makes a great mentor, so we agreed to keep the two
separate - gives some flexibility.

Cheers,
 Berin



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

Re: Common naming accross policy/process/roles

[Berin Lautenbach]

> From: Jason van Zyl <[EMAIL PROTECTED]>

> > Champion (was Sponsor) - the Apache Member (or member of a Sponsoring 
> > PMC) who champions a new candidate prior to being accepted by a Sponsor.
> 
> Who has any idea what this actually means without looking up the
> definition? Why not call it what it is: Member Sponsor.

Because the role is probably more than this.  However am
happy to go with whatever the consensus is (just see me as 
the person documenting :>).

> 
> > Sponsor (was Sponsoring Entity) - the PMC or Board that accepts a 
> > candidate for incubation.
> 
> How about PMC Sponsor, again for the same reason as above.
> 

Because it could be the board.  I think Sponsor works OK,
personally.

> > Mentor (was Shepherd) - the responsible Apache Member who works with a 
> > podling to see it through the incubation process.
> 
> Are there actually cases where the member sponsoring the new project
> isn't the mentor? I mean, who is going to 'champion' a new project and
> then leave it to someone else to mentor?

Yes there have been cases.  And it's not as obvious as it
seems.  Different skills/desires involved.

Cheers,
Berin



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

RE: Common naming accross policy/process/roles

[Berin Lautenbach]

> From: "Noel J. Bergman" <[EMAIL PROTECTED]>

> Remind me, please.  With respect to Sponsor, why not just say that the
> Sponsor is either a Member or a PMC (via the PMC Chair or a Member who is a
> PMC member)?  If a PMC is bringing a project for incubation, it would be the
> Sponsor.  If a Member is sponsoring a project, the Member is the Sponsor.
> Remember that there need not be a known destination for the graduating
> project.  The Mentor/Shephard is a person, a member of the Incubator PMC,
> who will accepts the responsibility of guiding the project.

My understanding was that there will always be a PMC (or
the board) that accepts a candidate on behalf of the ASF.
Where there is no Sponsor, the Incubator PMC acts in that
role and votes to accept the candidate (thus becoming the
Sponsor).  The documentation is currently written this way,
with the caveat that where the Incubator PMC is the sponsor,
one of the exit criteria will be finding an owner on exit.
(Owner might be the board for a Pod/Podling that becomes a
TLP.)

Cheers,
 Berin



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

Re: Common naming accross policy/process/roles

[Berin Lautenbach]

BTW - Have checked changes in - how do I update the site?

Nicola Ken Barozzi wrote:

My understanding was that there will always be a PMC (or
the board) that accepts a candidate on behalf of the ASF.
Where there is no Sponsor, the Incubator PMC acts in that
role and votes to accept the candidate (thus becoming the
Sponsor).  The documentation is currently written this way,
with the caveat that where the Incubator PMC is the sponsor,
one of the exit criteria will be finding an owner on exit.
(Owner might be the board for a Pod/Podling that becomes a
TLP.)


I agree with Noel, the Sponsor is simply the entity or the person that 
*advocates* the project to be part of the ASF. But then we come back to 
the "Sponsoring Entity" thing to say who will accept it.
I am getting a bit lost here :>.  When I said "Sponsor" above, I meant 
in the sense of the "Sponsoring Entity".  So, as I understand what has 
been agreed, there must be some Sponsor (PMC or board) that agrees to 
the project on behalf of the ASF.  Which is all I was trying to say.

Or have I missed the point somewhere?  (Entirely possible, we have just 
moved to daylight savings and it's killing me :>).

In any case, do we *need* to define the "champion"? I mean, take the 
case in which a project proposes itself to a PMC, and the PMC votes to 
have it come in... there is no "champion", and no need for one.
Absolutely not...for the policy.  In the policy document it is only 
mentioned right at the start as there being a requirement for an Apache 
Member to nominate a project.  That's a carry over from previous 
documentation - I have tried not to remove requirements that were in the 
old versions, but am happy to do so on agreemetn from this list.

For the process description though, I *think* it's kind of useful to 
define.  Not because it is directly important from the ASF's 
perspective, but because it can be incredibly helpful for potential 
podlings to have someone who helps them understand the "Apache Way", and 
who helps them through that initial process.  Not something that is 
important to define formally, but something we might want to encourage 
potential candidates to do.

Hence, I'd simply remove the definition of "champion" at this point, as 
it seems irrelevent to the definition of the process from our POV.

This does not mean that there cannot be Apache members that actually 
champion a project, but it's not strictly necessary for incubation.
[same thing for issue trackers, they can be used but we don't require them]

So, to be absolutely clear on my perspective -

1.  The policy document is the normative reference to incubation.  It is 
lean and mean and defines only that which absolutely needs to be defined 
to satisfy ASF incubation requirements and to ensure the process is 
repeatable.  I would be happy to take Champion out of this.

2.  The process document is not for us - it is for those who might be 
thinking about incubation.  It is not normative, and it *should* have 
things like issue trackers and champions.  Not because we are mandating 
them, but because discussing these things might help candidates 
understand the process a bit better.  I believe champions have helped 
some, so lets keep it in the descriptive document to maybe help others.

As for Jason's comment, I agree. If we can get away with special jargon, 
it's better. We have done it with Shepherd->Mentor, and we may as well 
do it for /podling/.
Very happy to change it.  From my perspective I just picked it up from 
the earlier documentation :>.

This is what we mean:
http://www.geobaby.com/forum/showthread.php?threadid=103478
This is what users may find instead:
http://dict.die.net/podling/
Hence what about simply "Incubating Project" or "Incubated Project" or 
"Project being incubated"?
Incubee?

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

Re: Common naming accross policy/process/roles

[Berin Lautenbach]

Nicola Ken Barozzi wrote:
In essence, I agree that we should not change the current meaning of 
Sponsor, that is exactly what you mean.
Ahh - violent agreement :>.

Absolutely not...for the policy.  In the policy document it is only 
mentioned right at the start as there being a requirement for an 
Apache Member to nominate a project.  


Exactly.
OK - if I hear nothing from anyone over the next few days, I will remove 
Champion from the Policy document.

That's a carry over from previous documentation - I have tried not to 
remove requirements that were in the old versions, but am happy to do 
so on agreemetn from this list.

For the process description though, I *think* it's kind of useful to 
define.  Not because it is directly important from the ASF's 
perspective, but because it can be incredibly helpful for potential 
podlings to have someone who helps them understand the "Apache Way", 
and who helps them through that initial process.  


This is the definition of Mentor, if you take out the fact that the 
project is not in Incubation yet. If we assume that Mentors can change 
when the project is accepted, it's simply the Mentor, ie the one that 
guides the project into Apache.
Might that get a little confusing in the document?  Having said that, I 
can reword around no particular name at all for the process/how-to 
documents.

2.  The process document is not for us - it is for those who might be 
thinking about incubation.  It is not normative, and it *should* have 
things like issue trackers and champions.  Not because we are 
mandating them, but because discussing these things might help 
candidates understand the process a bit better.  I believe champions 
have helped some, so lets keep it in the descriptive document to maybe 
help others.


This distinction between policy and process is not clear to me at all. 
 From looking at the docs I don't see it, and it's some time that I ask 
myself why we have different docs. IMO to make things clear there should 
be only one document that is clearly normative.

It's not so much between policy and process (which could both be 
normative) as between "The current policy document" and "the current 
process document".  The latter is meant purely as a descriptive document 
to help people out.  Maybe "process" is the wrong name.  Maybe we should 
rename to "A guide to Incubation" and call it "The Guide".

Proposal:
We keep a single policy document as our reference and make the process 
doc into HOWTOs.

- Process HOWTO
Or "The guide".  Either way - yes.

- Mentor HOWTO
- Sponsor HOWTO
- Incubating Project HOWTO
- etc...
Works for me

Forrest has a HOWTO DTD, so we can use that.

As for Jason's comment, I agree. If we can get away with special 
jargon, it's better. We have done it with Shepherd->Mentor, and we 
may as well do it for /podling/.


Very happy to change it.  From my perspective I just picked it up from 
the earlier documentation :>.


Yup.

This is what we mean:
http://www.geobaby.com/forum/showthread.php?threadid=103478
This is what users may find instead:
http://dict.die.net/podling/
Hence what about simply "Incubating Project" or "Incubated Project" 
or "Project being incubated"?


Incubee?


Hmmm...

.  Can't believe you don't like it!  It's what you get when you 
cross a buzzing insect with a mythical demonic creature.  (A bee with 
attitude.)

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

Re: Common naming accross policy/process/roles

[Berin Lautenbach]

Leo Simons wrote:
Hi gang,

Okay, okay, I'm exaggerating. Its real cool there's people
volunteering to write all this stuff, and the drafts are not
*that* formal. I'm just suggesting we make it easy for ourselves
and don't try to write "perfect" and "waterproof" docs. We just
need "good enough".
back to my corner!
:>.  But I'll bite.  It's because you might be clear, the PMC might be 
clear and the board might be clear on what incubation is, but it is 
still truly astounding how much argument can be generated *every time* a 
project comes into incubation over items that should be simple and easy, 
and that everyone has agreed on in the past!

I've also been involved in standard review processes in other lives, and 
it also amazing (but understandable) how much bitterness and heat can be 
generated by different projects/products following different review 
paths.  If we document the requirements as we create them then firstly 
it's easier for those on the PMC down the track, and secondly there is 
something that everyone can point to and say "this is what was done in 
the past".

It's almost due-diligence on behalf of the incubator.  It has been given 
a task by the board.  How can it show it is performing that task 
adequately in each case if it cannot go back to a normative reference?

Cheers,
Berin


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

Re: Common naming accross policy/process/roles

[Berin Lautenbach]

Nicola Ken Barozzi wrote:

I also want to make sure that we well know where things stand in every 
incubation moment, as there has been enough confusion withdouble-triple 
PMC concurrent votes.
+1

That said, I also think that we need *one* document to guide us, and all 
the rest should be simply docs that complement it as HOWTOs.

+1 - although whether they are HOWTOs or some other format would I think 
depend on appropriateness of content.

Any objections to my changing the "Incubation" heading on the main side 
bar down into "Incubator Policy" and "Incubator Guideance".  The first 
has an intro page discussing what the policy is for and a single 
document (the policy) and the second has the other documents with an 
intro page discussing what they are for?

Cheers,
Berin


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

Re: Common naming accross policy/process/roles

[Berin Lautenbach]

Nicola Ken Barozzi wrote:



Hmmm... policy... guidance... really, I may seem paranoid, but they 
don't spark a clear distinction in my head.

Guideance to me is not a word that I would take to mean that something 
is a set of rules.  It definitely sparks a very clear distinction for me.

I want to see a single document, not more. Just one.
Call it Process, call it Policy, call it Rules, but just one.
I think we are both agreeing here?  I want one normative document and 
everything else is non-normative.  Currently I've called that the policy 
document.

The process document (or whatever we are going to call it) is guideance, 
howto - whaever you want to call it - but in particular it is 
*non-normative*.  I called it Process_Description because that's what it 
is - it describes the process, not because I wanted two normative documents.

I've tried to draw a very clear distinction in all my e-mails that there 
is one main document (that I've been calling normative, or the policy) 
only.  Everything else (such as the process document or roles and 
responibilities) is purely as an aid to end users.  Nothing more.

Proposal:

 - add a HOWTO section
 - rename Process_Description to Incubation_HOWTO
 - make a HOWTO doc from each paragraph of ROLES_AND_RESPONSIBILITIES
Why an I so keen on "HOWTO"? Because HOWTOS are well known to be 
non-normative.

I must admit, I'm not so keen on making everything a HOWTO - mainly 
because that implies a certain kind of document.

If we want to make sure something is non-normative, it's very simple 
(and appropriate) to put a rider paragraph in it stating that where it 
conflicts with the policy, the policy over-rides.  That's a common 
approach and gets over having to worry too much about what names we use.

In particular, I like calling the process description a "Process 
Description" because that is exactly what it is.

However - I have absolutely no wish to drag this out.  Given (I think) 
we have a general understanding that there is only one normative 
document, for the rest, whatever the general agreement is in terms of 
names, I'll run with it.

And as a final thought - I *hate* e-mail for these kinds of things. 
Give me a face-to-face meeting or a teleconference anyday.

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

Going on a trip!

[Berin Lautenbach]

Peoples,

Just to let you know that I'll be travelling for the next two weeks with 
the family.  Almost no access to e-mail, so if I don't reply to e-mail, 
I'm not being rude :>.

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

Re: [RT] Multiple Mentors

[Berin Lautenbach]

Nicola,

I suppose the only slight reservation would be who is accountable?  The 
old "Fred Bloggs is looking after that" can kick in.  I think the 
Incubator PMC also wants to be able to hold people accountable for 
inubation activities.  Gets harder with multiple people.

Does it have to be formally done?  There can be a single "Mentor" with 
others involved and helping out.

Cheers,
Berin
Nicola Ken Barozzi wrote:
 From the current incubations, it's becoming quite clear IMO that a 
single Mentor is not enough for most, if not all, incubated projects.

As PMCs are composed of more than one member, we need more Mentors or 
each project, so that there should be *at least* one of them active in 
every moment. In the projects where there are more than one Mentor 
already things have been going better in this regard, in fact.

What has been said though is that if more than one have to do something, 
then nobody does it, as they assume others did. From what I see at 
Apache this is generally false, as since all is done on mailing lists, 
it's easy to see if things are being done or not.

What I still don't know is if we need a "chair" Mentor, but since I 
really don't see ATM the real need for it, I would keep it simple and 
deny a different status between Mentors.

In practice, it all boils down just to change our docs to have more than 
one Mentor, and that all project members that abide to the Mentor 
definition should become Mentors.

What do you think?



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

Re: [RT] Multiple Mentors

[Berin Lautenbach]

Nicola Ken Barozzi wrote:
Berin Lautenbach wrote:

Nicola,

I suppose the only slight reservation would be who is accountable?  
The old "Fred Bloggs is looking after that" can kick in.  I think the 
Incubator PMC also wants to be able to hold people accountable for 
inubation activities.  Gets harder with multiple people.


If the accountable person fails, what can we do? Nothing.

Replace them!  That's what the board would do to a PMC chair for a PMC 
that was not delivering what the board requires.

Our goal is not to have one person accountable, as we are all 
"accountable" as PMC members, but to have more eyes and hands working on 
it that are also on our PMC.

Yes and no.  (My favourite kind of answer.)

As far as the board is concerned (which is where the PMC reports) - 
there *is* an accountable person.  The chair of the PMC.  That doesn't 
mean that the entire PMC doesn't get involved in any given issue though. 
 As I think Noel said in a later e-mail, this is all a community process.

So - I have no issue at all with having multiple mentors.  Completely 
the opposite - I think it's a good thing.  I'm just not sure it's worth 
making it overly official.  A single "official" mentor with multiple 
helpers?

As I said in the original post - it's only a slight reservation.  I've 
just always found that if there is some single person who has official 
responsibility for something, it's generally more likely to happen.

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

Re: Add 'practice' PMC structure to projects in incubation

[Berin Lautenbach]

Roy,

Thankyou.  Read with great interest, and it put a few things into 
perspective.  Particularly the fact that to me the Practice PMCs made no 
sense from my perspective (based in the XML project's world).  I think I 
now understand why.

Couple of things came to mind whilst I was ruminating on the contents.

Firstly - am not so sure that changing the name of PMC to Core Group is 
either necessary or sufficient to fix things.  I note that you mention 
the codification of the requirements placed on the Core Group into a 
universal Apache Guidelines document.  For this I am absolutely +1 - one 
of the biggest problems facing the PMCs is a lack of clear understanding 
of what is required.  The only way to overcome that problem is to 
clearly document requirements.  E-mails going over the issues every 6-12 
months 'aint going to cut it.  I suspect if there was a clear set of 
guidelines and a board that was brutal about enforcing them then things 
might change.

Secondly, given the original intent of the concept of a PMC, I am 
curious as to why the board permitted umbrella PMCs such as XML and 
Jakarta.  You can change the name of PMC to Core Group, and put strict 
guidelines in place, but the spirit what you want is not going to happen 
until everyone on a given PMC is on the -dev lists that the PMC is 
responsible for.  That sounds fair, but is impractical for the PMCs of 
the large, divided projects.

So a possible suggestion.  FWIW.  Maybe a step towards where things need 
to be?  (Evolution rather than revolution?)

Can we turn a project such as XML into a federation of projects rather 
than one big project?  In terms of infrastructure (web site, mailing 
lists, cvs etc.) leave it as it is, with maybe a bunch of volunteers 
from each member project helping out with those items.

Each sub-project gets turned into a formal TLP, but not in the sense 
that is implied today (where TLP = web site, = mailing lists etc.). 
Rather the TLPs simply report to the board, have their own PMCs and are 
responsible for the code decisions.  That puts the decision making 
requirements back where I think the board wants it to be.  With a small 
core group of individuals responsible for each particular code base.

It also helps the Foundation scale as it reduces the requirements placed 
on infrastructure@ (new web sites etc.)

As I said - FWIW.

Cheers,
Berin


Roy T. Fielding wrote:
[Moved from the PMC list -- folks have got to stop proposing such
things on the wrong list.]
A long time ago, the name PMC was created in an attempt to genericize
the way that the Apache Group operated, using terminology that would be
easily understood by a judge or IRS inspector.  Unfortunately, the
name seems to have overwhelmed its history.  I described that in a
message to the members on March 12, 2003, which I'll include below.
However, I've been so overwhelmed with issues/fires this past year
that I never got around to fixing it.
Geir has proposed that we create practice PMCs (a.k.a. subprojects)
as part of incubation, and that we call them "Project Committers"
lists rather than PMCs.  I am +1 on the notion in general, but I
would prefer to call them core groups instead.  My rationale is that
"committer" privilege is a mechanism that we frequently give to
people on the basis of what they are planning to do, whereas the
core group are those people who have earned long-term voting rights
whether or not they happen to code.  Jakarta got into a weird state
wherein committer == voter and commit-access was given out like candy,
thus leading to the notion that committers run ASF projects.  I don't
believe it is appropriate to link voting with cvs access.
The key thing to note is that voting is a decision-making process
and we want that decision to be an ASF decision.  Furthermore, we want
the decision to be made as close to the volunteers doing the work as
possible, preferably by the volunteers themselves, whatever that work
may be.
The ability to make ASF decisions starts with the board and is
delegated to officers and their associated committees.  Anyone casting
binding votes (meaning votes that are counted toward making a decision)
must be listed as a member of the committee on which they are voting,
even if their votes are limited to a subcommittee.  Therefore, my
preference is for a fluid structure of incubating subprojects wherein
every voter is listed as being in one or more core groups and the
entire set of voters is listed as the incubator pmc.
I am aware that this would mean incubating projects would be able to
vote themselves out of incubation.  I think that if such a project had
their shit together to the extent that they could run such a vote and
get it past the majority of incubator members, then they no longer
need to be incubated.
Roy

===
From: "Roy T. Fielding" <[EMAIL PROTECTED]>
Date: Wed Mar 12, 2003  9:46:04  PM America/Los_Angeles
To: members   at  apache.org
Subject: PMCs gone wild
I am getting a

Re: [VOTE] Incubate Apache Ruper (was about Repo)

[Berin Lautenbach]

+1

(Still curious about project Wonka)

Cheers,
Berin
Nicola Ken Barozzi wrote:
Since the "repo" moniker has a bad connotation to some, given that this 
is meant to be an implamantation of the repository effort, and since 
Rupert is too common in google, I change the proposed name to Ruper (for 
what it's worth).

Others have asked to be able to help, so the committers would probably 
be more than the prospected ones.

Till now we have (except Roy's -1 about the name):

 dims +1
 noel +1
Other votes? Are all PMC members on the general list?



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

Re: [VOTE] Official Name for "Geronimo" Project

[Berin Lautenbach]

Sam Ruby wrote:

The inevitable result of these two factors is an interminable discussion 
on the naming of a project.

IMHO, the right answer is *not* to buck this up to the incubator PMC, or 
to members, or *gasp* to the board.  A much better approach would be:

1) Have the incubator PMC identify a clear set of constraints that apply 
to *all* names.  Vote on them, document them, and move on.

Which should also be the minimum requirements for all names whether in 
the Incubator or without.

2) Identify the PPMC who gets to name this project - and hold them 
accountable for their decision.
+1.  I think the Incubator PMC is in a kind of unique position.  We are 
trying to ensure that new projects/new committers in new projects are 
working in "The Apache Way".  So for me, the Incubator PMC shouldn't 
actually be voting to make the decision for the incubating project.  It 
should simply be checking that the decision has been made appropriately. 
 If anyone in the PMC vetoes a PPMC decision it should be on the basis 
that the decision does not meet the ASF requirements, not on the basis 
that we do/don't like a name (for example).

Anything else takes the decision away from the project in inubation, and 
I'm not sure I see how that is fostering the Apache way.

Cheers,
Berin


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

Re: [RT] Incubator Reorg

[Berin Lautenbach]

Nicola Ken Barozzi wrote:

I've put it this way on the wiki proposal, it should suffice:

"Incubator PMC members not engaged in active discussion and development 
on a project are on the project PPMC in quality of observers. They 
should refrain from voting on PPMC decisions unless really necessary, 
thus acting as vetoers of last resort.".

+1.  I like this - it is putting the responsibility on the PPMC but 
providing the oversite.

I'm going to forward the basic idea of the PPMC into XML and see what it 
brings in terms of the current discussion there around PMC oversite.

Cheers,
Berin


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

Re: Looking for help from incubation

[Berin Lautenbach]

Ceki,

Realising that you don't necessarily need someone from the Incubator, 
I'd still be interested in helping out with the log4cxx piece.  I need 
something like this elsewhere, so it seems like a perfect match.

Cheers,
Berin
Ceki Gülcü wrote:

Hello,

We are looking for a member of the Incubator project to help the
Logging Services project to incubate some of the log4j sister projects
originating from outside the ASF. Are there any volunteers?



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

Re: [RESULT][VOTE] PPMCs for Incubating Projects

[Berin Lautenbach]

Nicola,

I only have one overall thought (and you're going to think it remarkable 
picky, especially at this late stage :>).  As an aside - is this on the 
wiki somewhere where we can do a bit of wordsmithing (if you don't 
object at such a late date :<.  Am also happy to play around once it is 
on the site if you would prefer.)

Onto the overall thought - do they have to be "Practice" PMCs?  To me it 
sounds very patronsing, although that might just be a culture thing.

On a more serious note however, to me PPMCs are more than practice - 
they are the real thing, it's just the Incubator PMC is double checking 
everything going on.  By calling them "practice", we are implicitly 
giving a message that what they are doing is not real.

Is there a better word?  "Provisional", "Preliminary" or some such?

Again - this is a very late stage.  Feel free to ignore, as I should 
have made this comment a long time ago.

Cheers,
Berin
Nicola Ken Barozzi wrote:

Apart from the general agreement on PPMCs, for this particular vote 
instance there has been a +1 from me, one from Noel, on with changes 
from Aaron and a positive comment from Leo.

Thus, and also given the rule we have tacitly agreed upon on the pmc 
list that the votes of this PMC are considered valid of there are not 
objections regardless the number of votes, I consider this vote passed.

Below is what I think is a sufficient summary of what PPMCs are. I'll be 
fixing the site with this info soon. If there are still things to 
change-fix, feel free to say so, they won't invalidate this vote but are 
just fixes that can be done as normal.

= PPMCs =

== Description ==

To make Incubating project learn to govern themselves and govern 
themselves at the same time, each project has a PPMC (a place where to 
practice having a PMC) that works similarly to a PMC but reports to the 
Incubator PMC instead of the board.
The is a construct

== Members of the PPMC ==

 * project developers-committers
 * landing PMC members that want to help (if there is a landing PPMC)
 * Incubator PMC members that want to help
The Mentors are the only ones /required/ to participate on the -dev 
list. The other Incubator members would have to "catch up" to the extent 
that PPMC discussion requires external context.

Incubator PMC members not engaged in active development or discussion on 
a project are still able to eventually intervene in quality of 
observers. They should refrain from voting on project decisions unless 
really necessary, thus acting as vetoers of last resort.

== Reporting the the main Incubator PMC ==

Development and discussions go on the dev lists, where the Mentors are 
the ones doing active oversight.

The status updates are posted to [EMAIL PROTECTED], prior ACK 
from any Incubator PMC member.

== FAQ ==

Joe Developer: "So, how does this 'incubation' thing work then?"
Website: "Well, we want to do our best to make new projects feel
welcome at the ASF, and we want the ASF to feel comfortable bringing
the new project under its hood. This requires a get-to-know-the-ropes
period, which we call incubation. We establish something dubbed a
PPMC, which is a mailing list where a project's core group learns how
to deal with all those 'serious' intricacies that come with being a part
of the ASF, like quarterly reports, voting in committers, STATUS
file management, voting procedures, etc etc.
Also, we'll take a good look at any IP/licensing/copyright/trademark
issues that may exist during the incubation process. As soon as it is
clear that a project has truely captured the ASF spirit and all legal
issues are sorted out, the project leaves incubation and lives on on
its own."
Joe Developer: "So, what is this PPMC thing?"
Website: "A mailing list where the project's core group learns what
it means to be part of the ASF. To help them do that, there's a group
of ASF people called the Incubator PMC. Also, there will often be
other interested ASF members to help out and answer questions."
Joe PPMC Member: "So how do I...?"
Website: "We don't have clean answers to most of those questions
(yet). Just post an e-mail about the question/issue/problem, and we'll
figure things out together."
Joe PPMC Member: "I don't have any more questions!"
Website: "Well, good! Go on then, out of the womb, go and
manage things on your own. By the way, would you be interested
in a position on the Incubator PMC to help out new projects?"



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

Re: [RESULT][VOTE] PPMCs for Incubating Projects

[Berin Lautenbach]

Cancel question about wiki - should have looked first.

Apologies - and a very Merry Christmas!

Cheers,
Berin
Berin Lautenbach wrote:

Nicola,

I only have one overall thought (and you're going to think it remarkable 
picky, especially at this late stage :>).  As an aside - is this on the 
wiki somewhere where we can do a bit of wordsmithing (if you don't 
object at such a late date :<.  Am also happy to play around once it is 
on the site if you would prefer.)

Onto the overall thought - do they have to be "Practice" PMCs?  To me it 
sounds very patronsing, although that might just be a culture thing.

On a more serious note however, to me PPMCs are more than practice - 
they are the real thing, it's just the Incubator PMC is double checking 
everything going on.  By calling them "practice", we are implicitly 
giving a message that what they are doing is not real.

Is there a better word?  "Provisional", "Preliminary" or some such?

Again - this is a very late stage.  Feel free to ignore, as I should 
have made this comment a long time ago.

Cheers,
Berin
Nicola Ken Barozzi wrote:

Apart from the general agreement on PPMCs, for this particular vote 
instance there has been a +1 from me, one from Noel, on with changes 
from Aaron and a positive comment from Leo.

Thus, and also given the rule we have tacitly agreed upon on the pmc 
list that the votes of this PMC are considered valid of there are not 
objections regardless the number of votes, I consider this vote passed.

Below is what I think is a sufficient summary of what PPMCs are. I'll 
be fixing the site with this info soon. If there are still things to 
change-fix, feel free to say so, they won't invalidate this vote but 
are just fixes that can be done as normal.

= PPMCs =

== Description ==

To make Incubating project learn to govern themselves and govern 
themselves at the same time, each project has a PPMC (a place where to 
practice having a PMC) that works similarly to a PMC but reports to 
the Incubator PMC instead of the board.


The is a construct

== Members of the PPMC ==

 * project developers-committers
 * landing PMC members that want to help (if there is a landing PPMC)
 * Incubator PMC members that want to help
The Mentors are the only ones /required/ to participate on the -dev 
list. The other Incubator members would have to "catch up" to the 
extent that PPMC discussion requires external context.

Incubator PMC members not engaged in active development or discussion 
on a project are still able to eventually intervene in quality of 
observers. They should refrain from voting on project decisions unless 
really necessary, thus acting as vetoers of last resort.

== Reporting the the main Incubator PMC ==

Development and discussions go on the dev lists, where the Mentors are 
the ones doing active oversight.

The status updates are posted to [EMAIL PROTECTED], prior 
ACK from any Incubator PMC member.

== FAQ ==

Joe Developer: "So, how does this 'incubation' thing work then?"
Website: "Well, we want to do our best to make new projects feel
welcome at the ASF, and we want the ASF to feel comfortable bringing
the new project under its hood. This requires a get-to-know-the-ropes
period, which we call incubation. We establish something dubbed a
PPMC, which is a mailing list where a project's core group learns how
to deal with all those 'serious' intricacies that come with being a part
of the ASF, like quarterly reports, voting in committers, STATUS
file management, voting procedures, etc etc.
Also, we'll take a good look at any IP/licensing/copyright/trademark
issues that may exist during the incubation process. As soon as it is
clear that a project has truely captured the ASF spirit and all legal
issues are sorted out, the project leaves incubation and lives on on
its own."
Joe Developer: "So, what is this PPMC thing?"
Website: "A mailing list where the project's core group learns what
it means to be part of the ASF. To help them do that, there's a group
of ASF people called the Incubator PMC. Also, there will often be
other interested ASF members to help out and answer questions."
Joe PPMC Member: "So how do I...?"
Website: "We don't have clean answers to most of those questions
(yet). Just post an e-mail about the question/issue/problem, and we'll
figure things out together."
Joe PPMC Member: "I don't have any more questions!"
Website: "Well, good! Go on then, out of the womb, go and
manage things on your own. By the way, would you be interested
in a position on the Incubator PMC to help out new projects?"



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




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

Re: [RESULT][VOTE] Re: request for incubation: axion database project

[Berin Lautenbach]

Noel J. Bergman wrote:
Rodney Waldhoff wrote:

The notion of automatically accepting projects already accepted by a
sponsor seems like a good one.  It's not very clear from the process
docs that this is the case.


As said before, the docs are in need of a major overhaul.  Hopefully,
somewhere in the axion or near axion-graduation timeframe.
Actually - this is in there!

http://incubator.apache.org/incubation/Incubation_Policy.html#Acceptance+of+Proposal+by+Sponsor%0D%0A

However I note that at the moment we have reserved the right for the 
Incubator PMC to vote if so desired.

Does everyone think we should remove that potential out of the policy?

Cheers,
Berin


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

Re: PPMCs and oversight

[Berin Lautenbach]

Nicola Ken Barozzi wrote:
The current mechanism assumes that designated Mentors are the ones that 
have decided to be there, and we may assume that is there are enough 
Mentors, they will be there or tell us that they cannot do it anymore.

If we don't have explicit Mentors... how does it work?

MHO is that we don't remove the Mentors as designated now, but that in 
the same time we don't prevent anyone from "mentoring" the project 
without having to necessarily be listed as Mentors. If PMC members want 
to be listed, they just list themselves on the project's index page, 
nothing asked.
My one concern is that at the moment we have a mentor who has been 
officially assigned to assist the project in question, who is a single 
contact for the new developers in the event of issues and who is the 
single person the Incubator PMC can go to to to ask where the project is 
and what is going on.  I.e. a single accountable person.

I have this fear that we are throwing the baby out with the bathwater. 
I have absolutely no problems with the idea that anyone who wants to can 
sit on the PPMC and assist in mentoring (not officially marked as mentor 
unless they want to be), but I believe there should be one officially 
assigned mentor who is responsible for reporting etc.

No different to the chair of a PMC.

Cheers,
Berin


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

Re: [RESULT][VOTE] Re: request for incubation: axion database project

[Berin Lautenbach]

Nicola Ken Barozzi wrote:

Berin Lautenbach wrote:
...
I note that at the moment we have reserved the right for the Incubator 
PMC to vote if so desired.

Does everyone think we should remove that potential out of the policy?


I think so now. It should not be of our business to challenge the 
decisions of other PMCs.

If an extreme need for it arises, we can deal with it as an exceptional 
case, without it being part of pur "normal" policy.

If we think there is a potential that this might happen, then maybe we 
should simply mark it as exceptional in the policy.

Something like "in exceptional cases the PMC will vote on the inclusion 
of a project, however normally acceptance is taken as granted".  Maybe 
something like the 72 hour Ack from the board for new board members?  If 
nobody in the PMC objects within 72 hours of the sponsoing PMC making 
mention, then it all goes ahead.

Otherwise you might get into arguments down the track that this isn't 
mentioned in the documentation so why are we doing it.

Cheers,
Berin


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

Re: PPMCs and oversight

[Berin Lautenbach]

Noel,

No - I agree :>.

My comments about a mentor is nothing to do with Status files or the 
like.  It's all about having one formal link between the current ASF and 
the particular project in incubation.

In fact that person doing all the status reports etc. I would see as 
counterproductive, for all the reasons you detail below.  But they 
should be the person who kicks these things off and helps the PPMC 
ensure they start occuring.

The "formal mentor" is not even necessarily a development person, just 
someone who is assigned to assist the project get underway, and who is 
seen by the INcubator PMC as the person who should be ensuring 
everything is happening the way it should.

That is *not* the PPMC.  The purpose of the PPMC is to get a group in 
place that will become the PMC on maturation.  The mentor is the person 
guiding the PPMC in its role at the start and playing less of a role as 
time goes on.  But (IMO) you need someone to formally bootstrap the PPMC 
and ensure everything is going properly.

CHeers,
Berin
Noel J. Bergman wrote:

Berin,

Just as the ASF Board does with each PMC, we should try to encourage each
PPMC to do the oversight required of it, with guidance from individuals, but
without micro-management by the PMC as a body.
My comment from "PPMCs, Mentors and Chairs" on the PMC list was that
although each PPMC can choose to do things as they find best, my own
preference would be for the production of any such report to be
collaborative, with every PPMC member feeling able to participate.
I'm not sure that there is a beneficial purpose to having a designated
person to deliver the report.  I've been pleased to see different
individuals taking on different responsibilities on the Geronimo PPMC, and
would be concerned that designating certain people for certain tasks could
be counter-productive to letting each PPMC find its own equilibrium.
	--- 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]

Help!

[Berin Lautenbach]

Nicola/Noel et al,

I started playing with the PPMC text, just to wordsmith a tiny bit and 
flesh out a few things, and realised I don't understand the entire 
intent :>.

I had been seeing the PPMC as the "PMC to be" - so to speak.  I think 
that is the case for the projects that will become TLPs, so lets deal 
with that one first.

In this case, will all developers be on a PPMC?  I wouldn't think so - I 
would have thought it would be like a normal TLP, where those who are 
guiding the project (hopefully nearly all committers - but not 
necessarily) will be on the PMC.  As an individual, you have to show a 
committment to guiding the project before you become part of the PMC.

In the case where the project is to become a sub-project of a landing 
project, what is the PPMC for?  In this case, the PMC of the sponsoring 
project should pretty much be the PPMC, as there is an expectation of 
the board that the PMC of a project is actively involved and oversiting 
all its code bases.  So why not just make the PMC the PPMC, as all these 
people should be actively involved in incubation in any case?  (I.e. add 
people from the incubating code base into the project PMC if necessary.)

Otherwise, we have this thing called the PPMC that is going to be 
discarded completely when the sub-project gets to its landing PMC - in 
this case I'm not sure what the value is?

There is no point in having a "practice" (still hate that word :>) PMC 
if there is no purpose in the practice.

(I think I have missed something somewhere, so many apologies. - Either 
way, if someone explains it to me, I'll update the document to make sure 
it's clear for others in future :>.)

Cheers,
Berin


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

Re: Help!

[Berin Lautenbach]

Noel J. Bergman wrote:

will all developers be on a PPMC?  I wouldn't think so - I would
have thought it would be like a normal TLP, where those who are
guiding the project (hopefully nearly all committers - but not
necessarily) will be on the PMC.


All active Committers should be on the PPMC, just as all active Committers
ought to be on the PMC.  As in the case of an established project, there may
a period between being granted commit karma and being granted a voting
right, but in the case of a PPMC, especially early on, I think that a lower
barrier is probably a good thing.  But we can leave that to the PPMC, IMO.
OK - This makes sense and is in line with what I expected.  I will 
change the wording slightly in the PPMC wiki doc to reflect.



In the case where the project is to become a sub-project of a landing
project, what is the PPMC for?


To provide a management structure for the project, which is under the
Incubator PMC, is expected to end up under another PMC, and has some set of
Committers.
I've been handling sub-project issues a lot with the XML project, and 
there is an absolute assumption by the board that the PMC has active 
oversite of all code-bases in its domain.  If that's the case, then part 
of incubation should actually be to ensure that the landing PMC is fully 
up to speed with the code-base before hand-over.

In which case, the PPMC should be landing PMC + mentor (which should 
probably be on PMC anyway!) + incubator PMC members that are interested.



the PMC of the sponsoring project should pretty much be the PPMC


No.  At the very least, it would consist of the Incubator PMC and the
landing PMC.  The landing PMC does not get control until after the project
leaves the Incubator.  The PPMC provides the structure by which both PMCs
participate, along with the project's other Committers.
Ahh - we might be violently agreeing.  However, in the case of a 
sub-project going under an existing landing PMC, then maybe one should 
expect that the landing PMC does have control, except in strictly 
defined cases where the Incubator PMC needs to double check.  (Release 
code, status reports etc.)

After all - the PMC is supposed to be already doing this for other 
sub-projects, so the only thing the Incubator PMC should be doing is 
double checking the new players are doing the right thing and that 
nothing is being released under the Apache name until everyone is happy 
the project is out of incubation.

Additionally - we have said in a couple of places that the PPMC should 
be making the decisions.  The INcubator PMC is simply in on the loop to 
double check that the ASF is being protected during the incubation period.


Otherwise, we have this thing called the PPMC that is going to be
discarded completely when the sub-project gets to its landing PMC
- in this case I'm not sure what the value is?


Hopefully the PPMC will be dissolved by merging it with the landing PMC.
Or by simply removing the Incubator PMC members



There is no point in having a "practice" (still hate that word :>)


We dropped the "practice" designation.
So what does the extra "P" stand for now?

Cheers,
Berin


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

Re: Help!

[Berin Lautenbach]

Noel J. Bergman wrote:

So what does the extra "P" stand for now?


Actually nothing.  But since everyone keeps asking, I consulted Mr. Roget.
Two choices could be "provisional" and "possible" -- as adjectives for the
project, not the committee.  Personally, I would not bother to expand the
acronym.
.  I only ask because I am reading the PPMC document, and it's 
always good to expand acronyms in explanatory dox.  I will go with 
provisional until someone tells me otherwise :>.

Cheers,
Berin


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

Re: PPMCs and oversight

[Berin Lautenbach]

Actually I see the mentor as being more than just requesting reports.  I 
see the mentor as the formal link between the incubating projects and 
the ASF.  A guide in the true sense of the word, and a person the ASF 
(generally in the form of the Incubator PMC) can hold accountable for 
the ongoing progress of incubation.

For example, watching XML-Beans, I believe Ted played an incredibly 
useful role at the start in just getting things up and running and in 
assisting the project to start up.  To me, that role is too important to 
leave as an informal thing.  If it doesn't exist and nobody does it (or 
everybody things someone else is doing it), incubation stands a good 
chance of failing.

Again - the mentor is the bootstrap.  He/She achieves success by 
becoming redundant :>.

But maybe this is my big company (always very desirous of 
accountability) background showing through :>.

Cheers,
Berin
Noel J. Bergman wrote:

Berin Lautenbach wrote:

When the Incubator is coming up for its own quarterly report, I think that
the Incubator Chair can send out a reminder to each PPMC list reminding
them.  The PMC, for its part, can and should make sure that there is
sufficient oversight, but I don't believe that we need to designate someone
as *the* Mentor, so much as make sure that there are always members
involved.  As for getting work done, the PPMC ought to take responsibility,
and the less it needs someone to ensure that tasks are accomplished, the
better.
Perhaps we will find out that we need something more formal, but the less we
need of that the better.
	--- 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: PPMCs and oversight

[Berin Lautenbach]

Aaron Bannert wrote:

Why must it be one person? The entire Incubator PMC is responsible, so
why should we limit this to one person?
Not saying there should be only one mentor (in fact I would argue 
against it).  But I do think it important to have *identified* mentors.

Having said that, I continue to maintain that having an identified 
single person as holding overall accountability for something (in this 
case the mentor role) is a good thing.  Makes things more likely to 
happen.  There can be other mentors as well, but there is one person for 
the Incubator PMC to go to.

(But I don't ever expect to win that last one :>)

I think it's important that there are at least a couple Incubator PMC
people subscribed to the PPMC mailing lists, but those people *are*
the "Mentors". If a PPMC has an issue they should send an email and
also cc: the [EMAIL PROTECTED] mailing list.
No - IMO these people are *not* the mentors (or at least this alone does 
not make them so).  As a PMC member, I subscribe to PPMC lists to make 
sure I understand what is going on, and so that when a question comes up 
that needs input/oversite from the Incubator PMC then I can adequately 
do my part.

A mentor is a far more active role than that.  The mentors are supposed 
to be actively assisting the new project (not just the PPMC!) in getting 
into the ASF.

By saying that anyone from the Incubator PMC on the PPMC list is a 
mentor for that project, we are loosing sight of what a mentor is 
supposed to be.

Of course, being an incubator PMC member in a PPMC list does not 
preclude one also being a mentor, it's just that more is necessary.

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

Re: PPMCs and oversight

[Berin Lautenbach]

Aaron Bannert wrote:

On Sun, Dec 28, 2003 at 03:43:56PM +1100, Berin Lautenbach wrote:
I'm confused by what you are saying. Do you believe there should
be one person in an authoritative position for each PPMC or not? I
am strongly against having "roles" within the ASF. Roles go against
the way volunteer organizations work. Volunteers at the ASF will
contribute when they can. It is difficult for most people to commit
to certain responsibilities when they must keep real life at a
higher priority (work, family, etc). By keeping things simple and
allowing people to contribute when they are best able to, we all
benefit.
One of the reasons I like the ASF is that it is a formal structure 
around volunteer work.  If you look at volunteer organisations, they 
don't just take people and let them do whatever they want.  They channel 
and put some formality in place to ensure the right things are being 
done in the right way in the right place.

That requires formalised roles.  They exist in volunteer organisations 
everywhere.

Similarly here.  It's not enough to just have enthusiastic volunteers. 
There needs to be some focus around those areas that the organisation 
(in this case the ASF) sees as important from a governance perspective.

I will absolutely agree that we want to keep them to a minimum.  But 
that minimum must exist for the ASF (as an organisation) to work.  PMC 
Chairs, board members etc.  Without that structure, the ASF would simply 
be another Sourceforge - which is not a bad thing, but it is very 
different to the ASF.

I also don't understand what kind of "accountability" you expect
someone to step up and accept? What magic feats do you see mentors
performing for which the Incubator PMC would not be better? I fail
to see any benefit to this sort of artificial bottleneck. Besides,
if there are serious issues to be taken care of (which I would hope
would be rare) would not a mentor be doing the Incubator PMC a disservice
by hiding those issues from the PMC?
Exactly my point!

As an Incubator PMC member who is not actually a mentor on any project, 
I don't personally give a tinker's cuss whether any of the projects 
(with one or two exceptions :>) succeed in the Incubator or not.

However, I *do* care that, as a member of the PMC, I am discharging my 
role in ensuring the ASF is being protected, and that projects entering 
the foundation do so in a manner that will not bring harm on the foundation.

To be comfortable, I want to know that there is an ASF member who is 
tracking what the incubating project is doing.  If any issues arise, I 
want to know about them soonest!  My best chance of doing that is by 
knowing that the ASF member has taken responsibility for protecting the ASF.

I think it's important that there are at least a couple Incubator PMC
people subscribed to the PPMC mailing lists, but those people *are*
the "Mentors". If a PPMC has an issue they should send an email and
also cc: the [EMAIL PROTECTED] mailing list.
No - IMO these people are *not* the mentors (or at least this alone does 
not make them so).  As a PMC member, I subscribe to PPMC lists to make 
sure I understand what is going on, and so that when a question comes up 
that needs input/oversite from the Incubator PMC then I can adequately 
do my part.


That sounds like mentoring to me. Or sheparding. Or incubating.
It's all the same. You are on the PMC because you are interested
in incubating new ASF projects, right?
Yes - but not in the sense that I am interested in seeing them 
successfully incubate (again with one or two exceptions :>).  I am 
interested in seeing that the role of the Incubator is being discharged 
as required by the board.

If you are involved in the Incubator project (not just on the PMC)
then you already have shown that you are interested in helping new
projects incubate. If you go so far as to actually join the PPMC
list then it's obvious that you are interested in that particular
community. In my mind once you get that far you are a "mentor".
No.  For example, I have joined the Geronimo PPMC.  That's not because I 
am particularly interested in the J2EE project (although it's 
interesting stuff!).  It's also not because I feel I can assist (my 
background is mainly C/C++ and security).  It is because there have been 
lots of concerns around licensing and use of non ASF code.  As an 
Incubator PMC member I feel I should be fully accross this issue, so I 
have joined the PPMC.

I make a distinction between teaching and doing. The way I see it,
veteran ASFers who are interested in incubating new ASF project
communities should join the Incubator PMC and any PPMCs that they
find interesting. By participating in those discussions, they can
teach these new projects how to behave like ASF projects.
Now that is what I see as a Mentor!

It seems to me that we have inadvertently invented the role of
Me

Re: PPMCs and oversight

[Berin Lautenbach]

Aaron Bannert wrote:

I should finally add that we have basically agreed also that the PPMC is 
made of all PMC members and all the committers+landing PMC members, but 
that only the mentors must always be subscribed to the ppmc and dev 
mailing lists.


Yuck, this is terminology overkill. We really need to slow down the
introduction of new words to our glossary, we're going to make the
lawyers jealous. :)
How about this:
The PPMC starts with every Incubator PMC person who wants on
the PPMC. New PPMC members are then voted in by the current
PPMC members.
It's a start.  But you also need the landing PMC members.

Am not so sure about committers.  Like you, I think I'd like to see them 
voted in by the PPMC.

Cheers,
Berin


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

Re: PPMCs and oversight

[Berin Lautenbach]

Nicola Ken Barozzi wrote:
IIUC this is what ATM we agree upon:

The role of Mentor is a self-selecting title (eg. anyone wishing to 
become a Mentor and has the title to be one as described in our policy 
just adds themselves to the projects/index webpage + the project status 
page and joins the PPMC and dev lists.
Yup.

This means that we can reasonably be sure that *at least* the Mentors 
that have listed themselves on the projects/index page are actually 
following the respective projects.

This of course does not remove the need to have at least one mentor 
identified in teh project proposal.
Yup.  And this is the person I would expect to take the lead on the 
mentoring side.

This should satisfy all needs, of accountability and of easiness to join.

I should finally add that we have basically agreed also that the PPMC is 
made of all PMC members and all the committers+landing PMC members, but 
that only the mentors must always be subscribed to the ppmc and dev 
mailing lists.
See other e-mail - am not sure about all committers.  (But also not 
convinced against :>)

Cheers,
Berin


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

Re: PPMCs and oversight

[Berin Lautenbach]

Noel J. Bergman wrote:

I disagree.  I believe that with the PPMC structure in place, we should hold
the PPMC accountable, just as every PMC is accountable.  We need to ensure
that the PPMC members are well aware of the responsibility of the PPMC, and
that it is accountable.  I think that instilling that sense of
accountability there from the beginning is important, and that installing a
designated taskmaster as I feel you describe it would be counter-productive.
No.  Absolutely not!  I am not after a taskmaster of any description, 
and I do not believe I have ever required it.

I am after a clearly identified individual who is accountable for 
ensuring things are being done that need to be done - not for making 
them happen.  That is not a taskmaster - that is an oversite task.

At the start, my guess is that it *will* be a(n unwilling) taskmaster 
for totally new PPMCs (i.e. those caring for projects totally new to the 
ASF).  But the aim of the mentor in this case should be to back off over 
time until they are doing nothing.

We do need to make sure that the PMC is aware of any issues, but I believe
that between Incubator PMC members being intimately involved on the PPMC,
and reports from the PPMC, I believe we have that covered.
Agreed.  However I believe there needs to be a formalisation that there 
is one Incubator PMC member who is ensuring the PPMC is meeting their 
requirements of accountability.  The role of the incubator is to 
actively oversite projects coming on board.  Unless we have someone we 
can point to who is doing that active oversite and reporting any issues, 
then I believe we cannot (as easily) show oversite.

For example I simply haven't got the bandwidth to be intimately involved 
in all incubating projects.  However I do believe that as an Incubator 
PMC member I have a responsibility to all of them.  I therefore want to 
have a level of comfort that there is someone who I can go to in order 
to gain confidence in the project's progress.

As a parallel, the board looks for PMCs for each TLP.  However there is 
a nominated individual (the chair) that the board goes to for all 
questions.  The expectation is that the PMC as a whole is driving the 
project, not the chair, but there needs to be someone that is 
responsible to the board.

At the end of the day, I think it will in 99% of cases be a matter of 
semantics, but I do believe putting it in place will make the 1% easier 
on everyone.  (And after all, it's that last 1% that has the capacity to 
cause the most problems.)

Cheers,
Berin


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

Re: PPMCs and oversight

[Berin Lautenbach]

Nicola Ken Barozzi wrote:

The role of the incubator is to actively oversite projects coming on 
board.  Unless we have someone we can point to who is doing that 
active oversite and reporting any issues, then I believe we cannot (as 
easily) show oversite.


Doesn't work this way. At work, I show that I have oversight if I know 
what is going on and things go smoothly. To know what is going on we 
have status reports (that I'll ask for very soon), and for the latter we 
need more Mentors. Pointing fingers is not our goal, making things 
actually be done instead is.
Not pointing fingers - identifying that there are people meeting a 
responsibility.

And I've found that status reports are never sufficient to show active 
oversite in a work situation.  If something goes pear shaped, and the 
first I know of it is in a report that comes every 3 months, things are 
not good.  I like to know there is someone handling a project/situation 
who will report back as soon as something comes up that I need to know 
about.

What we do need *identifiable* Mentors that we can reasonably assure are 
following the project. For me, having them (auto)listed on this page [1] 
is enough.
Yes - I think that is the compromise position (I'm not 100% comfortable, 
but then that's the definition of compromise :>).

Cheers,
Berin


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

Re: PPMCs and oversight

[Berin Lautenbach]

Leo Simons wrote:

IMHO, as long as a project still requires a "point man" (or
as long as the PMC still requires such a person in order to
be kept up to date of what is happening in the directory
project), the project is not ready for graduation.
Absolutely!  A good test of maturity.  If the mentor is doing absolutely 
nothing and things are going well, then there is no need for a mentor 
and quite possibly no need for the project to be in incubation anymore.

Cheers,
Berin


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

Re: PPMCs and oversight

[Berin Lautenbach]

Leo Simons wrote:

Absolutely!  A good test of maturity.  If the mentor is doing 
absolutely nothing and things are going well, then there is no need 
for a mentor and quite possibly no need for the project to be in 
incubation anymore. 


Exactly! 


So you are saying there should be a single liason for a project, and
at the same time an important goal for the project would be to stop
talking to/through this liason?
When did liason come into this?  I am confused as to what on earth 
oversite and assistance has to do with liason?  I am also confused as to 
why having an identified person would restrict others from being involved?

Cheers,
Berin


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

Re: PPMCs and oversight

[Berin Lautenbach]

Aaron Bannert wrote:

It's a start.  But you also need the landing PMC members.


What's a landing PMC member?
Where the code is to go into an existing project, then the PMC of 
pre-existing project is the landing PMC.  E.g. XML-Beans is set to enter 
the XML project once it leaves the icnubator, so the XML PMC is the 
landing PMC.

Cheers,
Berin


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

Re: PPMCs and oversight

[Berin Lautenbach]

Noel J. Bergman wrote:

Healthy ASF Projects are neither leaderless nor headless.  They are run by
multiple heads -- individuals participating as peers -- converging on a
consensus.  Sometimes things may take longer than one person acting on their
own, but it often means a better result, and it ensures that the project's
lifespan is based upon its community, not an individual's participation.  It
is when this process breaks down that the PMC Chair needs to exercise its
individual authority, ideally to help restore the proper collaborative
state.
(Note to Nicola - I am just discussing for the sake of discussing.  I 
can live with the current position :>)

I said in an e-mail some time back that I suspect we are are violently 
agreeing.  I still believe that :>.

Your above point exactly matches my desire.  I'm not looking for what I 
call "the accountable person" to drive and lead etc. in the normal 
course of events.  The more they have to, the further we are from 
leaving incubation.

However, the 80/20 rule applies.  In 80% of cases (I hope more :>), 
everything will work beautifully, the mentors will hardly ever get 
involved and all will be just peachy.  The PPMC will drive everything 
and having had an accountable person will make absolutely no difference 
whatsoever.

It's the other 20% (and in this case I hope far lower) I worry about. 
In that case, I want someone like an identified mentor who can raise 
issues back to the Incubator PMC and who can and will guide the project 
back to the "collaborative state" as you so eloquently put it :>.

And by having that person clearly identified *prior* to problems 
occuring, they can get in there and just do it.

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

Re: PPMCs and oversight

[Berin Lautenbach]

Noel J. Bergman wrote:

Now ... why not designate people beforehand to provide corrective action(s)?
Perhaps for the reasons that Sam is often quiet as a PMC Chair, or Greg is
very careful about which e-mail address he uses.  Because they have found
that it *does* make a difference.  Once you designate someone in a role, it
can be very hard for others to treat them as a peer.  And I would be
expecially sensitive to that in the Incubator, where we may have a good
number of new people who may already view PMC members differently from
themselves.
No - that simply states that we want people who take a formal role very 
seriously in those roles.

You could apply the argument above to say we don't want a chair of the 
PMC or a chair of the board.  That's not so.  It's simply that they are 
filled best (in the case of the ASF) when they are inhabitted by people 
who are very careful with the role, and who don't step in until it's 
absolutely necessary.  (Definition of Berin's perfect mentor?)

And I *want* people to view the mentor as a very serious role.  I 
personlly don't want people in the role who see it as a simple thing 
that is done easily, and "hey she'll be right"!.

But - in the interests of moving along - I'm happy to agree to disagree 
:>.  I think the requirement for mentors is documented, and whilst it's 
not as far as I would like, I believe it is sufficient.

Cheers,
Berin


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

Re: [VOTE] Granting committer status to log4net developers

[Berin Lautenbach]

Ceki Gülcü wrote:

What is it we are voting access for here?  Is it to the overall 
logging project repository?  To a CVS module for the log4net code that 
is to be created?


I am inclined to create a new CVS module for log4net and for each 
sub-project. If a log4-X committer wants to commit a patch to project 
log4-Y, they can ask to become a log4-Y committer.
+1.


Also - is log4net being directly imported or is it going through the 
incubator?  My understanding would be the latter given it's bringing 
new developers in, but my guess would be that it would be fairly 
simple if the license issues are simple?


As long as the legal questions are properly covered, I don't the think 
the ASF board will oppose the incubation process to take place here at LS.

My understanding is that it would need to go through the incubator as we 
are bringing new code and new developers into Apache.  However I have 
CCd to [EMAIL PROTECTED] to get a feeling from the people there as well.

Cheers,
Berin


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

Re: [VOTE] graduate MerlinDeveloper from incubation

[Berin Lautenbach]

Leo Simons wrote:

I propose we release MerlinDeveloper from incubation and allow avalon to 
import the code.

Please place your votes:

[x] +1 -- yes



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

Re: Request for graduation

[Berin Lautenbach]

> On Thu, 2004-01-22 at 01:15, Malte S. Stretz wrote:

>> Where do I find that module? At least via anoncvs I can't find it and
>> (I  think) I have only SVN and no CVS access.
>
> Crap.  Ok, just for the record, the SA guys have been ginea pigs with
> respect to SVN only accounts.  It looks like it's too early in the game
> for that, so I propose we create the matching unix accounts aswell.
> We'll repeat the experiment when we have more services in place and
> more projects in SVN (and at least the committers module).
>
> This will allow them to update the status file in Incubator, aswell as
> access the committer CVS module.

Eminently sensible whilst there are modules in CVS that need to be
accessed by all committers.  There are also things like access to web
sites for updates etc. that I would have thought unix accounts would be
useful for?
Cheers,
 Berin




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

Re: Project Documentation

[Berin Lautenbach]

Noel,

Moved to general (per your suggestion :>),

>> ROFL - A chance for my favourite hobby horse!  Where is the charter
>> for the Incubator?   I started one some time back
>> http://wiki.apache.org/incubator/IncubatorCharterDraft
>> But could never really get any traction or interest.
>
> A lot of discussion happened on various subjects without the web site
> getting updated.  I figure that people got a bit burnt out on some of
> the discussion, and "distracted" by important things.  And we did get
> some of the most important things done, such as establishing the PPMC
> concept, and seeing smoother operation of our projects.  The Geronimo
> community is happier, the SpamAssassin folks are happy, Directory has
> been moving along, some projects have graduated, etc.

I agree.  I have seen some incredibly positive things in the incubator
over the last six months.  Interestingly, we are not always following what
is documented in the policy and standards documents - maybe this is a time
to review those documents and reflect on whether what we are doing is
better than what we planned to do or vici versa.  If the former, then we
should update the documentation to reflect reality.
>
> Re-publishing the site is a bit of an obstacle, which is why I'd like
> to see us get Forrest installed on minotaur so that we can kick off
> rebuilds.  But with the assumption that we can easily rebuild and
> publish the site, would you mind coordinating what needs to be done
> updating our site docs?

Yup - it might take me a few days to get to it, but I will see what I can do.


On the subject of forrest on Minotaur - I'd *love* to see this happen.  I
use forrest for some web sites of my own, and have built some scripts to
do a CVS checkout hourly of a particular site's source files and then call
forrest if any source files have changed.  So I'm also happy to look at
that.  I have been wary in the past, because the preference from
infrastructure@ has (reasonably enough) been to have the built site in CVS
so that if minotaur crashes they can quickly get sites back online.
>
> I didn't post to general@ because I would not unilaterially move your
> comments to public view.  Feel free to move your reply to [EMAIL PROTECTED]

Done :>.


Cheers,
  Berin




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

Re: Project Documentation

[Berin Lautenbach]

Noel J. Bergman wrote:

My thought was something along the lines of:

  /home/incubator/
   incubator/ -- cvs co incubator
  incubator-site/ -- cvs co incubator-site
 forrest/ -- our friend tool, installed
That seem about right?  See ~noel/incubator for a start.  I did a cvspublic
checkout of incubator, but incubator-site was pulled from /home/cvs, so that
when we do the build, we can commit.  I don't have forrest installed, yet,
but I think you get the idea.
Do we want to go via the incubator-site CVS?  We can, but it means you 
can't use anonymous CVS for the co as you need to commit the changes 
back in post a run.  WHich means that to automate the check-in, you need 
to provide an authentication token (either an RSA id or password) 
directly on the file-system.  It would be protected by file permissions, 
but I always get wary.

I think that's the way forrest-bot runs, but just want to make sure 
that's the way we want to do it if we are building on minotaur, where 
it's easy enough to just directly copy the results of a forrest run to 
the incubator web directory.

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

Re: code donation to an existing project

[Berin Lautenbach]

David,

Just to back up Noel's comments below, if you put something to 
[EMAIL PROTECTED], we can all kick it around.  At the end of the day - if 
those in xml-commons think it's a good idea, then the chances are it 
probably is, and we can make it happen!

Cheers,
Berin
Noel J. Bergman wrote:

David,

If the XML PMC decides to accept the code donation, based upon interest
within the community, the Incubator can work with the XML PMC to help bring
the code on-board.  However, unless there is interest in having it, the rest
is kind of moot.
If there is interest, the procedure could be as simple as getting a Software
Grant and vetting the code for IP issues, in the case were you would pull it
into XML Commons as part of your community.
	--- 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: code donation to an existing project

[Berin Lautenbach]

David Crossley wrote:

By the way, the Incubator FAQ needs a statement on this topic.
Hmm.  Yes - I think you're right.  I'll do something about that!

Thanks!

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

Re: Upcoming Incubator PMC Chair Election

[Berin Lautenbach]

OK.  I'll start off by nominating Noel (although I think that was 
already done elsewhere?)

I'd also suggest we timebox this.  Can we allow a week for nominations?

Then maybe a week for votes within the PMC?

Cheers,
Berin
Noel J. Bergman wrote:

Candidates interested in the Incubator PMC Chair are invited to put their
names forward.  Also, if you there is someone whom you would like to
nominate, and who is intereted, please put their names forward.
It is suggested that a candidate be someone with a experience in the ASF;
most likely (but not required) an ASF Member; at least a year or two as a
committer, or six months as a committer on two or more projects; and
preferably experience serving on an ASF PMC.
As always, if you are interested in serving on the Incubator PMC, let us
know.  The Apache Incubator is an important project, helping to bring
enthusiastic new Projects and Communities into the ASF.
	--- 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]

New Incubee

[Berin Lautenbach]

Peoples,

The XML Project has voted to accept NativeJCE for incubation.

As per Incubator Policy [1], I am hereby requesting the Incubator 
project accept this project for incubation.  As per [1] :

- Vote is at [2]
- Proposal is at [3]
- Mentor will be myself
The plan at the moment is to name the new product "JuiCE".  A question 
to the incubator group - we have researched this name on the web, and 
could not find any other cryptographic software that had this name. 
There are of products on sourceforge - a blog tool [4] and a frontend to 
mpg123 [5] that are both named "juice", but I have to confess to not 
being enough of an expert on these issues to know if this is a problem 
or not.

Guideance appreciated.

Cheers,
Berin
[1] 
http://incubator.apache.org/incubation/Incubation_Policy.html#Acceptance+of+Proposal+by+Sponsor%0A
[2] 
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=1046
[3] 
http://nagoya.apache.org/wiki/apachewiki.cgi?XMLProjectPages/OpenSSLJCEProposal
[4] http://sourceforge.net/projects/juice/
[5] http://sourceforge.net/projects/juicy/

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

Re: New Incubee

[Berin Lautenbach]

The plan at the moment is to name the new product "JuiCE".  A question 
to the incubator group - we have researched this name on the web, and 
could not find any other cryptographic software that had this name. 
There are of products on sourceforge - a blog tool [4] and a frontend to 
mpg123 [5] that are both named "juice", but I have to confess to not 
being enough of an expert on these issues to know if this is a problem 
or not.
If anyone has any thoughts on this I'd be most grateful.  We don't want 
to create lists and cvs/svn repository with a name we have to change 
very quickly!

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

Re: Want to become a member of Apache J2EE Project

[Berin Lautenbach]

Have a look at

http://incubator.apache.org/projects/geronimo/index.html#How+do+I+get+Involved%3F

Cheers,
Berin
Poornima Gunasekar wrote:

Hi,
This is Poornima, Software Engineer. I wish to participate in the project 
"Apache-licensed implementation of the J2EE specification". Could you please
let me know what is the process to become an member of this project and
team?
Thanks
Poornima
PS:
This is with reference to the article in "theInquirer"
Apache Announces J2EE Project 

Open Letter from Greg Stein
By N. Alex Rupp : Tuesday 05
August 2003, 19:21


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

Report for JuiCE

[Berin Lautenbach]

Status report for JuiCE for the Incubator

JuiCE is just entering incubation, and is currently in the process of 
starting up.  We are currently waiting on CLAs from core developers to 
enable us to get started.

  * is the STATUS file up to date? (also post link)

Yes - http://incubator.apache.org/projects/juice.html

  * any legal, cross-project or personal issues
that still need to be addressed?
No.

  * what has been done for incubation since the last report?

JuiCE has only just entered the Incubator.  We are currently in the 
process of getting infrastructure up and running, accounts set up and 
code imported.

  * plans and expectations for the next period?

Getting code imported, web site setup and development started.



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

Re: [VOTE] Graduate Pluto

[Berin Lautenbach]

Guys,

I'm going to vote -1 here, until the status file is updated addressing 
some of the original concerns.

Andrew Oliver raised a specific point [1] that the Java PMC wanted the 
incubator to specifically consider community.

Also, have a look at some of the e-mail in :

http://nagoya.apache.org/eyebrowse/SearchList?listId=&listName=general%40incubator.apache.org&searchText=pluto&defaultField=subject&Search=Search

Guys - I'm quite sure that all the concerns *have* been addressed, and 
an updated status file will cover all of them.  At which point I'll 
gladly change this to a +1.

I also suspect that others in the PMC have more visibility than I, but 
we are being quite hard on other projects in incubation, and I believe 
we need to be consistent.

Cheers,
Berin
[1] 
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgId=792503

David Sean Taylor wrote:
The Portals PMC would like to graduate Pluto out of incubator into the  
Apache Portals project.
My vote is +1 to graduate Pluto
We believe we have met the requirements for exiting incubation as  
stated here:

http://incubator.apache.org/incubation/ 
Incubation_Policy.html#Exitting+the+Incubator

--
David Sean Taylor
[EMAIL PROTECTED]
Apache Portals
http://portals.apache.org
-
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] Graduate Pluto

[Berin Lautenbach]

Noel J. Bergman wrote:

As far as I know, those issues are mooted.  More to the point, perhaps,
Pluto has been adopted and integrated into the new Portals project, which is
asking for its release, and they don't appear to have any Community
concerns.  Do we have any questions about the TCK availability?
I suspect you are absolutely correct, and everything has been mooted or 
satisfactorily resolved.  Unfortunately, I have not been even remotely 
involved with Pluto, so I have to rely on STATUS to make my judgement.

As to Portals being comfortable on community - I'm of the opinion that 
it is part of the Incubator responsibility to double check.  We should 
be making our own judgement, not using another TLP to make a de-facto 
decision for us.

After all - it's the Incubator that is supposed to be tracking the 
history of incubation and ensuring concerns originally raised are 
addressed, not Portals.  If it all went pear shaped, I would expect the 
board to come to Incubator PMC - not Portals - to ask the serious 
questions.  I would also expect Portals to be asking us questions!

At the end of the day, I'm just reluctant support something where I am 
not sure of the answers.  Give me a status file that addresses the 
concerns raised at the start of incubation, and I'll change to +1 with 
fervor and alacrity :>.

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

Re: [VOTE][RESULT] Release of incubating-xmlbeans-1.0.2

[Berin Lautenbach]

Cliff Schmidt wrote:

In summary, the XMLBeans project needs to finish balancing its
committer diversity ratio and work out the details for a new 
TLP.  I am confident we can do both of these items in the next 
two months.

Any feedback/guidance about this plan would be appreciated.
I'd fully support both aspects of that.  I've been fairly comfortable 
(as a "kind of" impartial observer) with what I have seen in the 
XMLBeans lists, but the original concern out of the XML project was the 
balance of committers, so anything that works towards addressing that is 
goodness!

And I've been meaning to raise the TLP issue for a while, so thanks to 
Robert for pre-empting me :>.

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

Re: Pluto Incubation

[Berin Lautenbach]

Noel J. Bergman wrote:

I've published the revised Incubator site with the newly revised Pluts
STATUS file for everyone to review:
http://incubator.apache.org/projects/pluto.html
Does anyone have any outstanding questions/issues regarding Pluto's status?
I'm going to appear very thick here, for which I apologise in advance. 
 I'm not accross Pluto, and I was hoping the status file would make 
everything clear for me, but it hasn't :<.

How were the original concerns raised about NDAs and community 
addressed?  Ref [1]

This should probably be in STATUS, but personally I'm happy if someone 
just posts the answers here so that we have a formal record in the 
mailing list.  I'm not after great long details - just bullet points 
that clearly define how the issues were addressed.

Heck - if someone can give me the answers here, I'll even update the 
STATUS file myself!

Cheers,
Berin
http://nagoya.apache.org/wiki/apachewiki.cgi?TalkPlutoProposal

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

Re: [VOTE] Graduate Pluto

[Berin Lautenbach]

David,

Many thanks indeed.

I'm now a big +1 :>.

Cheers,
Berin
David Sean Taylor wrote:

On Apr 23, 2004, at 5:49 PM, Berin Lautenbach wrote:

Guys,

I'm going to vote -1 here, until the status file is updated 
addressing  some of the original concerns.

Andrew Oliver raised a specific point [1] that the Java PMC wanted 
the  incubator to specifically consider community.

Also, have a look at some of the e-mail in :

http://nagoya.apache.org/eyebrowse/SearchList? 
listId=&listName=general%40incubator.apache.org&searchText=pluto&defaul 
tField=subject&Search=Search

Guys - I'm quite sure that all the concerns *have* been addressed, 
and  an updated status file will cover all of them.  At which point 
I'll  gladly change this to a +1.

I also suspect that others in the PMC have more visibility than I, 
but  we are being quite hard on other projects in incubation, and I 
believe  we need to be consistent.

Cheers,
Berin
[1]  http://nagoya.apache.org/eyebrowse/ReadMsg? 
[EMAIL PROTECTED]&msgId=792503


Hi Berin,

Let me try to address the issues from the above link below:

Please note that my support is based on the following assumptions:

1. all spec/seed code will be released (this, in my opinion, 
must  be
done prior to consideration) If thats not till March, then the project
can't reasonably be considered until March. (We don't take on other
closed source projects)


All code is in Apache CVS. Absolutely nothing is closed. All in the  
open. Yup.

2. David Taylor and the other committee members will soon be
released from the Non-Disclosure agreements they are currently under  so
that they can participate freely. (You can't have a community based  
on a
closed spec where the members can't speak freely).


We can all speak freely and we won't get in that situation again.
With the public release of the Portlet Specification last year, there  
is nothing now that isn't already public.

3. I'm assuming that others including from the Jetspeed and
Cocoon-portal will go add themselves as committers...
http://nagoya.apache.org/wiki/apachewiki.cgi?PlutoProposal - I will  
send
an invitation out.


All Jetspeed and Cocoon committers had the opportunity to join Pluto.
Many Jetspeed committers did decide to join the Pluto team.
4. The project will keep compatibilty with the spec but we'll be
free to expand beyond it in much the same way Tomcat and other  projects
do. Xerces, for instance, doesn't solely implement just SAX and JAXP
with a parser under it. From a performance standpoint, SAX interfaces
would be nice, having them in the RI (extending the spec) would serve
this purpose.


The project has already started to expand quite healthily.
For example, David DeWolf, a Pluto committer, has started a Kuiper  branch.
Its a refactored experimental implementation of the portal based on COP
5. Future revisions of the Spec will happen in the open.

I give my word as an Apache committer that I will work hard, and  
already have believe me, towards making this situation (of a closed  
spec) never happen again.

Please note, I REALLY want to see this at Apache, so this is not a
fillibuster intended to kill the effort to be followed by a series of
Catch-22 arguments (here, but not there, which means it can't be  here).
But I don't feel the participants should be given a free pass into
Apache to create non community-based non-open projects just to get the
feather. If this is going to be an Apache project, it does need to 
be  an
Apache project. If there is motivation on everyone's part, we CAN
obviously fix these issues by addressing them head-on in an honest and
straightforward manner.

I DO want to particpate, and I DO want to see this happen, but lets do
the community thing. We can certainly resolve these issues if all
parties are motivated.
-AndrewCOliver


-
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: [PROPOSAL] Beehive

[Berin Lautenbach]

+1 - with some reservations/questions.
1.  I tried to find it, but I couldn't find a definitive answer to 
Noel's question RE mailing lists?  (I'd note that it is very easy to add 
more mailing lists and split things out at any point - hint hint :>)

2.  We seem to be adding a *lot* of initial committers. Have all of 
these people been actively involved in getting Beehive to its current 
state?  I'd be a bit uncomfortable giving all these people write access 
to repositories unless we have some comfort that they are actively 
involved in development to date.  Or are non-involved people already 
active Apache committers?

3.  I'd imagine we are going to have the same thing around BEA vs. 
non-BEA involvement as with XMLBeans?  (I.e. focus on building community 
outside the initial BEA startup.)

Having said the above - looks like a great idea! I also hugely 
appreciate the work that went into the proposal.  It makes things much 
easier to understand :>.

Cheers,
Berin
Cliff Schmidt wrote:
Incubator PMC folks,
I would like to propose a new Apache project named Beehive.
The proposal can be found at http://wiki.apache.org/incubator/BeehiveProposal.
Since the project is being proposed as a TLP with three subprojects,
I've requested that the Board consider this proposal at their next 
meeting.  However, it is my understanding that the proposal should 
first be voted on by the Incubator PMC.

Craig McClanahan has offered to be the Champion and Mentor
for this project (as defined in http://incubator.apache.org/incubation/Roles_and_Responsibilities.html).
Davanum Srinivas is also interested in the project, particularly
with the web services component.  If this proposal is approved
for incubation, I'd like to start a PPMC composed of these two 
Apache members, the other Beehive committers, and any Incubator 
PMC member who is interested in helping guide the project.

Please let me know if you see any issues with this proposal that
call into question whether it would be appropriate for incubation.
Thanks,
Cliff
-
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: TLPs, Incubation, and the Board (was RE: [PROPOSAL] Beehive)

[Berin Lautenbach]

Noel J. Bergman wrote:
I think there are some mis-understandings.  Our documentation seriously lags
reality (volunteers to help would be appreciated), but even so, AFAIK, you
*never* needed to go to the Board before proposing entry to the Incubator.
Directors might be interested, but the issue of where the podling will go is
not a prerequisite for Incubation.
That's my understanding as well.
From memory (and I just checked the current policy document, which 
seems to match) three entities are allowed to approve a project for 
incubation.

1.  The board
2.  The Incubator PMC
3.  Another PMC that will take it on post incubation.
The board was there for things like Geronimo.  But the Incubator can 
approve things that don't immediately have an identified home, such as 
Beehive.  (Probably TLP, but we might want to work it out as we go.)

Cheers,
Berin

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

Re: [VOTE] Graduate Geronimo from Incubator and recommend as top-level project

[Berin Lautenbach]

+1.  And very enthusiastic at that.
An absolutely heroic effort!
Cheers,
Berin
Geir Magnusson Jr wrote:
The Geronimo project has been in Incubation for almost 10 months.  In 
those 10 months, the Geronimo project has developed a community, 
developed a new codebase in an open and collaborative fashion, weathered 
problems both internal and external, formed a functioning group of 
committers to manage the day to day affairs of the project (the PPMC), 
demonstrated collaboration with other OSS groups in the enterprise 
software domain, and produced a milestone release of software.

Therefore, I believe the Geronimo project has satisfied the requirements 
of the Apache Incubation process, namely :

 o  does collaborative development according to the ASF's
philosophy and guidelines
 o  has a codebase that is properly licensed, has clear
provenance, and conforms to the ASF's legal requirements
for contributions
Furthermore, I believe that the Incubator PMC, on behalf of the Geronimo 
PPMC and the entire Geronimo community, should recommend to the Apache 
Board of Directors to make the Geronimo project a top-level Apache project.

If this pleases the chair of the Incubator PMC, I request that members 
of the Geronimo PPMC (which is the Incubator PMC and the Geronimo 
committers) please vote :

[ ] +1 - The Geronimo project has met the requirements
 for incubation and will be recommended to the
 board for TLP status
[ ] -1 - The Geronimo project as not met the requirements
 for incubation
This vote will run ~72 hours, closing at 23:59 EDT, Sunday May 23, 2004.
geir

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

Re: Request creation of new mailing lists

[Berin Lautenbach]

Roy T. Fielding wrote:
[EMAIL PROTECTED]
[EMAIL PROTECTED]

I have set up the archive on /www/incubator.apache.org/mail/
but someone else will have to enable eyebrowse.
Eyebrowse now set up as well.
Cheers,
Berin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Lenya PPMC List

[Berin Lautenbach]

Peoples,
I have just created a PPMC list for Lenya 
([EMAIL PROTECTED]).  Nobody is currently subscribed 
(other than myself), but I have taken the liberty of setting Stefano and 
Steven as moderators (at their Apache addresses).

Let me know if the moderators list is wrong or if anything else needs to 
be done on the list.

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

Overall status of incubating projects

[Berin Lautenbach]

Peoples,
The following lists provides my understanding (based on the "projects" 
page on incubator.apache.org) of when the last status update was. 
Projects with a ** have gone more than 3 months without any kind of 
update.  "No Report" means that the project *appears* (according to the 
status file) never to have issued a report to the Incubator PMC.  I'm 
not sure it's accurate, but I'm just reporting based on the STATUS page.

This started off from a comment from Noel, but I'd also be kinda 
interested in whether any of these projects can be graduated and/or shut 
down?

*AltRMI 30 Oct 2003 (No report)
*Axion  19 Dec 2003 (No report)
*Directory  20 Jan 2004
*FtpServer  30 Oct 2003 (No report)
GeronimoN/A - Graduated (probably needs to be documented)
JuiCE   20 April 2004
*Lenya  20 Jan 2004
*Log4net15 Jan 2004
Pluto   N/A - Graduated
*Depot  20 Dec 2003
SpamAssassin22 April 2004
WSRP4J  April 2004 (From CVS logs, date in file is 2004-10-)
XMLBeans20 April 2004
I thought Log4cxx was also under incubation?
Are there any others?
Cheers,
Berin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Lenya 1.2 incubation distribution

[Berin Lautenbach]

Noel J. Bergman wrote:
There is a request that we approve clearly marked incubation distribution of
Lenya to help further community development.  The request has the support
for Steven Noels and others in the Lenya community.  There has been
considerable discussion on the state of the community in conjunction with
this request.
 [ ] Yes, allow Lenya to put out a clearly marked incubation distribution
 [ ] No, I object to such a distribution, on the grounds that:
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Errors generating site

[Berin Lautenbach]

I *hate* (with a passion) the cwiki format.  There were two spaces at 
the start of an otherwise blank line in xmlbeans.cwiki.  Don't ask how 
long they took to find.

I've also fixed the log4??? stuff, rebuilt and committed.  It should 
come through to the site soon.

Cheers,
Berin
Noel J. Bergman wrote:
I tried to generate the site, and ran into the following:
X [0] projects/log4php   BROKEN: No pipeline matched request:
projects/site:projects/log4php
X [0] projects/xmlbeans.html BROKEN: Couldn't accept input softbreak ["\n"]
X [0] projects/log4cxx.html  BROKEN: Couldn't accept input hardbreak
["\n\n"]
X [0] projects/log4cxx   BROKEN: No pipeline matched request:
projects/site:projects/log4cxx
I tried one change in xmlbeans.cwiki, but it made no difference.  I don't
see anything from Cliff's most recent change:
http://cvs.apache.org/viewcvs.cgi/incubator/site/projects/xmlbeans.cwiki?r1=
1.9&r2=1.10&diff_format=h
that should account for the problem.
--- 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: [VOTE] Graduate XMLBeans from Incubator and recommend as top-level project

[Berin Lautenbach]

+1 :>.
Cheers,
Berin
Cliff Schmidt wrote:
The XMLBeans project has been actively developed in incubation for 
about 10 months.  During this time, the user and developer 
community has continued to grow stronger, both in number, 
diversity, and degree of cooperation.  In addition, the XMLBeans 
project has demonstrated an understanding and application of the 
legal and logistic measures necessary to protect and enhance the 
mission of the ASF.

Some examples of this progress can be seen in how XMLBeans has:
- worked with other members of the Apache community,
- brought on new committers, based on the merit of frequent 
contributions, 
- been responsive to the user community, 
- been careful with its handling of the Apache brand (and in fact,
helped to define an appropriate set of restrictions for incubating 
projects),
- collaboratively created two binary distributions,
- and implemented and made significant decisions through a PPMC.

Therefore, I believe the XMLBeans project has satisfied the 
requirements of the Apache Incubation process, namely :

  o  does collaborative development according to the ASF's
 philosophy and guidelines
  o  has a codebase that is properly licensed, has clear
 provenance, and conforms to the ASF's legal requirements
 for contributions
(See the status file for the detailed list:
http://cvs.apache.org/viewcvs.cgi/incubator/site/projects/xmlbeans.cwiki?rev=1.10&view=markup.)
Furthermore, I believe that the Incubator PMC, on behalf of the 
XMLBeans PPMC and the entire XMLBeans community, should recommend 
to the Apache Board of Directors to make the XMLBeans project a 
top-level Apache project.  

Note that the XMLBeans project was originally targeted as a 
subproject of the XML project.  However, based on the interests 
of the XML and the XMLBeans community (in support of the ASF's 
interest for proper delegation of project oversight from the 
Board to the PMCs), XMLBeans is now requesting TLP status.

I request that members of the XMLBeans PPMC (which includes the 
Incubator PMC, the XML PMC, and the XMLBeans PMC committers) 
please vote :

[ ] +1 - The XMLBeans project has met the requirements
  for incubation and will be recommended to the
  board for TLP status
[ ] -1 - The XMLBeans project as not met the requirements
  for incubation
This vote will run ~96 hours, closing at 23:59 GMT, Tuesday 
June 22, 2004 (extending to vote due to the weekend, but ending
before the upcoming Board meeting):
http://www.timeanddate.com/counters/customcounter.html?day=22&month=6&year=2004&hour=23&min=59

Cliff
-
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: Download location for Incubator distributions

[Berin Lautenbach]

Noel J. Bergman wrote:
As per Cliff's previous email, files will be moved on www.apache.org/dist
and the XMLBeans website will be updated.

Since XMLBeans appears to be about to leave the Incubator, this needn't
apply to it, but as we examine Incubator policies, I'm wondering if we
should make it a policy that all distributions will go under
http://cvs.apache.org/dist/incubator/, which is what we did with Geronimo,
and now with Lenya.
Comments?
Works for me.
As for XMLBeans, 1.03 is already under
http://cvs.apache.org/dist/incubator/, so why move it now?  Especially since
XMLBeans will have to move stuff again within the next week or so.
+1
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Graduate SpamAssassin from Incubator, recommend TLP

[Berin Lautenbach]

+1
Sander Striker wrote:
Hi,
I'd like to call for a vote to graduate SpamAssassin from the
Incubator.
SpamAssassin started working on incubation around August last year.
Since then a lot if not all of the Incubator requirements have been
addressed; the final one this week.  Patience and persistence has been
a prominent property of the community.
The codebase is under the AL v2.0.  License grants are on file, as well
as CLAs for all significant contributions.  Two trademarks are in the
process of being assigned to the ASF:
 * SPAMASSASSIN
http://assignments.uspto.gov/assignments/q?db=tm&sno=78148991
 * POWERED BY SPAMASSASSIN
http://assignments.uspto.gov/assignments/q?db=tm&sno=78213077)
The community is active and has seen committers added to the initial
committership during the incubation period.  The community has been
collaboratively working towards a 3.0 release.  Apache style voting
has been easily adopted by the community.
SpamAssassin resources are all on apache.org infrastructure, except
for BugZilla, which is mostly due to limited available time on part
of the Infrastructure team.  SpamAssassin has been one of the pioneers
when it comes to using Subversion at the ASF.  Mailinglists are in
active use under the @apache.org domain.
Did I mention the pleasant community? ;).
[ ] +1 - The SpamAssassin project has met the requirements
 for incubation and will be recommended to the
 board for TLP status
[ ] -1 - The SpamAssassin project as not met the requirements
 for incubation
I'd like to be able to present the Board with a resolution on
wednesday, which I realise is close by.
Sander
-
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] Accept MyFaces for Incubation

[Berin Lautenbach]

+1
Noel J. Bergman wrote:
See: http://wiki.apache.org/incubator/MyFacesProposal
[ ] Accept MyFaces into the Incubator
[ ] Reject MyFaces
Vote ends Midnight EDT (between Monday and Tuesday), Monday July 12, 2004.
--- 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]

July Report for JuiCE

[Berin Lautenbach]

Status report for JuiCE for the Incubator
JuiCE has stalled waiting on a set of changes to the CLA proposed by Uni 
of Memphis being approved by the ASF.  Without this approval, Walter 
Hoehn cannot get commit access to the repository.  As he is one of the 
key developers we need this sorted out before we can really ramp up.

  * is the STATUS file up to date? (also post link)
Yes - http://incubator.apache.org/projects/juice.html
  * any legal, cross-project or personal issues
that still need to be addressed?
No.
  * what has been done for incubation since the last report?
One account (for Noah Levitt) has been created, and the source code has 
been imported into SVN.

  * plans and expectations for the next period?
Hopefully sort out the CLA for Memphis Uni and get development going again.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Accept JCR for Incubation

[Berin Lautenbach]

+1
Roy T. Fielding wrote:
Here is the current text of the JCR proposal from
   http://wiki.apache.org/incubator/JcrProposal
Please cast your vote as +1 (yes), -1 (no), or something in between.
Vote ends 12pm (Noon) PDT -0700, Saturday, August 28, 2004.
Roy
1. Proposal for new project JCR
1.1. Rationale
   The Content Repository API for Java Technology (JCR) is being
   developed within the Java Community Process as JSR-170 [JSR170],
   with Day Software [Day] as specification lead. It recently passed
   public review and is incorporating the public comments. The
   reference implementation has been developed by Day under the
   proposals subdirectory of the Jakarta Slide [Slide] project's CVS
   [jcrri]. JCR currently uses several utilities within Java commons
   and is expected to be used (eventually) by Jakarta Slide, Cocoon,
   Lenya, and possibly as an interface to various DB projects.
 [JSR170] 
 [Day]
 [Slide]  
 [jcrri]   


   The purpose of this proposal is to move the JCR code out of the
   Slide proposals area and into a neutral podling where it can
   attract additional committers from other Apache projects and
   from the various JSR-170 expert group companies, learn the
   Apache way of doing things, and allow the mailing list subscribers
   to focus on this interface/implementation rather than all of
   the existing projects that might want to use it. We hope to
   improve collaboration on the code base by moving all of the
   active developers and authors to Apache, bring in as many of the
   Apache veterans as wish to get involved, and open it up to all
   of the 22 expert group companies. Development of the RI and TCK
   will occur in this project -- Day Software will export the
   official (binary) RI and TCK releases from public tag names
   within apache.org CVS, in accordance with JSPA 2.6 restrictions,
   allowing developers to test against the open source versions
   as well as the official versions.
   In the process, the reference implementation will become a useful
   package for other Apache projects wishing to incorporate the JCR
   interface. The code was originally proposed as the back-end for
   some future version of Slide, which may still happen at some point,
   and we anticipate future integrations with Lenya, Cocoon,
   XML Indexing, Axion, and Derby. We are also looking at integration
   with projects such as Beehive, Maven, and Portals.
   We are not certain of the destination PMC at the current time, though
   Slide (if it becomes a TLP), Lenya, Cocoon, DB, or some future
   framework/CMS TLP are all candidates. Since we believe this should be
   based on the people who show up to do the work, we would prefer to
   "re-start" within incubator and let the nascent Apache community
   decide once the choices become more clear. As such, we are requesting
   that the incubator PMC accept the podling with a vote, even though
   it was earlier accepted as a proposal by Slide committers.
  1.1.1. Criteria
1.1.1.1. Meritocracy
   We plan to do everything possible to encourage an environment that
   supports a meritocracy. The committer list for this proposal includes
   people who will specifically be responsible for doing the work
   necessary to foster a meritocracy.
1.1.1.2. Community
   JSR-170's expert group consists of all of the big companies that have
   traditionally supported Apache project work, and quite a few small
   ones as well. Our focus will be to get the individuals comfortable
   with the Apache development process and seek out new contributors.
1.1.1.3. Core Developers
   Currently Day employees, though this will change as soon as we get a
   chance to invite more people to join this effort. Stefano Mazzocchi  and
   Remy Maucherat have been representing Apache within the JSR-170  expert
   group.  The initial committers listed below include Apache veterans
   from many different projects.
1.1.1.4. Alignment
   The initial code base is targeted to run on any compliant Servlet
   or J2EE container. Ant is currently used as the build method.
   Some of the Jakarta Commons utilities are used internally.
  1.1.2. Warning Signs
1.1.2.1. Orphaned products
   This is an active project within Day Software and will be the basis
   of ongoing standards work, the RI and TCK, and the core of Day's
   own content management products.
1.1.2.2. Inexperience with open source
   Many of the committers have experience working on open source
   projects and several are veterans at Apache.
1.1.2.3. Homogenous developers
   The initial list of committers includes developers from six
   different countries, with more to come. They are experienced
   with working in a distributed environment.
1.1.2.4. Reliance on salaried developers
   JSR 170 is support

Re: Donation of JAXP 1.3 Sources to Apache

[Berin Lautenbach]

Neeraj Bajaj wrote:
Hello All,
I was wondering when can we start merging the JAXP 1.3 sources ? Merging 
the code in branch/review/testing/committing to main trunk
would take time so at least from my side i would like to see this work 
started as early as possible say from tomorrow.  What is the general 
procedure ? Is there any formality that needs to be completed first ? 
What is the opinion of
(Xml-commons/Xerces/Xalan) committers ?
I'm assuming that this is something that XML-Commons/Xerces/Xalan wish 
to do?

I've CCd [EMAIL PROTECTED] as well, as I'd like Noel's opinion, but my 
feeling is that *if* the Xerces/Xalan and/or XML-Commons community want 
this code to be imported (and it sounds like they do - but I'd like to 
see that formalised), then the community side is already there.

If that's the case, then I don't think we need to go through the full 
incubation process (Noel - thoughts appreciated!) - we only need a code 
grant from Sun (we can't take something into our repository until we are 
sure we have appropriate legal rights to do so) + someone needs to fill 
out the incubation docs to show that everything is AOK.  I'm happy to 
help out with the latter part.

Code grant details can be found at :
http://www.apache.org/licenses/#grants
As the sources would be put in a branch so it won't affect normal 
development but it would be good if we can restrict
large chunk of changes to the main trunk and fix only critical changes. 
It would help merging the changes back to main
trunk. What do others think ?

Thanks,
Neeraj
Neeraj Bajaj wrote:

Ramesh Mandava wrote:

- Both Elliotte's and Clay's questions below are important.  If someone
familiar with the code could comment on:  For either the main trunk, or
a temporary working branch for integration:
-- What JVM's will this code compile on?  Version/Vendors?
  J2SE 1.4.x,  J2SE 5.0 . We tried this on Sun JDKs but the same 
sources should run on  other JVMs as well.

-- What JVM's will this code run on?  Version/Vendors?
J2SE 1.3.x, J2SE 1.4.x,  J2SE 5.0. Again we qualified the sources on 
Sun JVM. But as there is no Sun JVM specific codem these  sources 
should work on other JVMs without modification ( we have to try it 
out though  :-) ). 

Right. This hasn't been tried but i don't see any reason why it 
shouldn't work on any other JVM as there isn't any Sun JVM specific code.

In other mail i have suggested that active Xerces/Xalan committers can 
try this before committin on main truck as the plan is to put the code
on branch first. I proposed JAXP 1.3 APIs to be committed on 
xml-commons main trunk but i am totally fine with creating a branch 
first to test
the compatibility with other JVM.

Neeraj

We need to *clearly* document which versions this stuff works on, and
should conditionally compile or something if it won't compile on at
least 1.3

Right now we face compilation problems in couple of file with J2SE 
1.3, but these should be worked around though. We can atleast have a 
switch to achieve the requirement  of compiling on J2SE 1.3.

(since we still have a lot of older JDK version users here).
My knee-jerk reaction is also to hope that it will compile & run on
both recent Sun and IBM JVMs at least before we put this on the main
trunk: we should really try to be JVM-vendor agnostic.


I agree.
Regards
-Ramesh
(anyone still
working on kaffe?  8-)

--- Clay Leeds <[EMAIL PROTECTED]> wrote:
 

On Oct 12, 2004, at 5:12 AM, Elliotte Harold wrote:
 

Are these APIs and implementation thereof independent of Java 1.5? 
i.e. can they be compiled and used in a Java 1.2/1.3/1.4


environment?  

If not, could they be backported to work in such environments?
-- Elliotte Rusty Harold  [EMAIL PROTECTED]
XML in a Nutshell 3rd Edition Just Published!
http://www.cafeconleche.org/books/xian3/
http://www.amazon.com/exec/obidos/ISBN%3D0596007647/cafeaulaitA/ 
ref%3Dnosim


Forgive me if this is covered under Mr. Harold's question, but:
Would this also be portable to IBM Java 1.30 (and any other 
non-Sun  implementation of Java...)?

Web Maestro Clay
p.s.  I'm not trying to look a gift-horse in the mouth--Thank you
Sun!  Love your logo!
--
Clay Leeds - <[EMAIL PROTECTED]>
Webmaster/Developer - Medata, Inc. - 
PGP Public Key: 
  


=
- Shane
http://apachecon.com/ November in Vegas, baby!" />
-
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 PROT

Re: Mentor and Project Guide (WAS: RE: [OT] How to prevent...)

[Berin Lautenbach]

It does look good.
Noel - make sure you do some heckling for me as well :>.
Cheers,
Berin
Noel J. Bergman wrote:
Cliff Schmidt wrote
If it's any use, you can download the slides at:
http://conferences.oreillynet.com/cs/os2004/view/e_sess/5439

I'll be giving a similar presentation next month at ApacheCon.

I'll be there to heckle.  ;-)
Actually, the presentation looks pretty good.  :-)
--- 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: [VOTE] Nutch

[Berin Lautenbach]

+1 from here!
Cheers,
Berin
Noel J. Bergman wrote:
Doug proposed this a week and change ago (bad timing to do such things
around major holidays :-)).  So far we have support from Dain, Nicola Ken,
Doug, Eric Hatcher, Henning, Roy and myself.
Roy, Nicola Ken, and myself provide the minimum 3 +1 from the PMC based upon
the current roster.
--- Noel

(0) rationale
Nutch is web search software. It builds on the Apache Lucene search library,
adding a crawler, web database (including full link graph), plugins for
various document formats, user interface, etc. It is currently used by sites
such as http://search.creativecommons.org/, http://library.cornell.edu/, and
the Internet Archive.
Nutch is a two-year-old open source project, currently hosted at Sourceforge
and backed by its own non-profit organization. The non-profit was founded in
order to assign copyright, so that we could retain the right to change the
license. We have now determined that the Apache license is the appropriate
license for Nutch and no longer require the overhead of an independent
non-profit organization. Nutch's board of directors and its developers have
both been polled and support a move to the Apache foundation.
We anticipate that Nutch will join the recently proposed search.apache.org
top-level project, with Lucene and its various ports.
(0.1) criteria
Meritocracy:
Nutch's developers are already comfortable operating as a meritocracy.
Nutch's current developer policies are a bit more informal than that of
Apache, but, then, there have never been any notable conflicts to resolve.
Community:
Nutch has an established and active developer community.
Core Developers:
Nutch has four active committers who are experienced open source developers.
Alignment:
Nutch currently users the following Apache projects: Ant, Lucene, Xerces,
POI, commons.
(0.2) warning signs
Orphaned products:
Nutch is not an orphan. It has the same corporate sponsors that it has
always had.
Inexperience with open source:
Nutch's committers are experienced with open source.
Homogenous developers:
Nutch's committers do not all share an employer or nation. All decisions are
made openly on public mailing lists.
Reliance on salaried developers:
Nutch has no salaried developers.
No ties to other Apache products:
Nutch has strong ties to Lucene.
A fascination with the Apache brand:
Nutch has a strong brand already. While the Apache brand will enhance that,
that is not a primary motivation for Nutch to join Apache.
(1) scope of the subprojects
All code is currently licensed under a variant of the Apache License 1.0.
The developers have approved a move to the Apache 2.0 license and a
re-assignment of copyright to the Apache Foundation. We have signed
Contributor License Agreements on file for all developers.
(3) identify the ASF resources to be created
(3.1) mailing list(s)
nutch-dev
nutch-commits
nutch-user
nutch-agent
(3.2) Subversion or CVS repositories
https://svn.apache.org/repos/asf/incubator/nutch
(3.3) Jira
Nutch (NUTCH)
(4) identify the initial set of committers
Doug Cutting (Lucene committer)
Michael Cafarella (current Nutch committer at Sourceforge)
Andrzej Bialecki (current Nutch committer at Sourceforge)
John Xing (current Nutch committer at Sourceforge)
Sami Siren (current Nutch committer at Sourceforge)
(5) identify apache sponsoring individual
Erik Hatcher, Champion and Mentor
Doug Cutting, Mentor
-
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: [PROPOSAL] Apache TSIK

[Berin Lautenbach]

First - I'm +1 on this (with the concomitant committment to help out - 
I'll even mentor if necessary, although my time is often limited at the 
moment).


Noel J. Bergman wrote:


This looks alright, but I have some questions.  First, why isn't the WS PMC
sponsoring this as WS-TSIK?


The XML Security team probably an equivalent level of overlap to the WS 
project.  The proposal discusses xml-sig/xml-enc and XKMS, all of which 
are worked on in xml-security.  But looking at the amount of stuff in 
there, I'd almost suggest this might be the catalyst for creating the 
broader XML security project - which I know I have talked about on and 
off for a while :>.


Cheers,
Berin



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

Re: [PROPOSAL] Apache TSIK

[Berin Lautenbach]

Granqvist, Hans wrote:

I realize that it may sound a bit vague, but I hope that I manage to 
convey that there is nothing intrinsic about TSIK that precludes, say,

the ASF xmlsec project to be reimplemented with a completely different set
of APIs -- I think Apache could use several available layers for different
uses.


As an aside - that's one of the things we have been looking at doing - 
wrapping JSR APIs around the current library without necessarily 
removing the original API that people currently use.


Cheers,
Berin

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

Re: [PROPOSAL] Apache TSIK

[Berin Lautenbach]

Noel J. Bergman wrote:


Dims raised the same issue to me, so there is a common thread there.  Would
this also help to resurrect JuiCE?  And, again, be aware of the proposed PGP
package for Jakarta Commons, targeting package signing.


Just having sorted out the *&^% CLA issue may help JuiCE along.  As Ben 
indicated - the OpenPGP package is somewhat of a different ballgame, if 
only because everything else we are talking about is XML based.  But 
hey, happy to throw anything in to the mix :>.




Are you also suggesting that we have some existing XML Security committers
who would be interested in joining?


Well, at least one :>.  One of the things I'm looking at at the moment 
is XKMS (albeit in the C++ space), and having another toolkit to work 
with in that space would be most interesting indeed.


Cheers,
Berin


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

Re: Fwd: [PROPOSAL] Apache TSIK

[Berin Lautenbach]

Sanjiva Weerawarana wrote:


Do I understand correctly that this is a basically complete package that
is being donated to Apache? Does it have its own SOAP stack ..
o.a.tsik.messaging? If not how does this stuff plug into say Axis?

So my concerns are:
- does it use Axis? If not what's the connection to anything we
currently have?
- it appears to have its own addressing impl too?
- same concerns for xml-security stuff - is this just a competitor (==>
split community in my mind)
- is there any roadmap with Axis2? Otherwise is it a permanent alternate
path? (o.a.tsik.domutil and AXIOM seem to have some overlap too?)
- If yes, I am concerned having a permanent split is not the most
healthy thing for the Apache developer community.


Is there anything intrinsically wrong with a different implementation of 
the same stuff in the ASF?


One of the things that *might* be interesting, would be to look at each 
component and see where we can merge things together to come up with an 
even better whole.


Cheers,
Berin


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

Re: a few steps before approving a project

[Berin Lautenbach]

I've been following this with a little bit of confusion.  It strikes me 
that there is a lot of reaction going on without really thinking through 
the implications.


So just to stir the pot

Cliff Schmidt wrote:


I'd like to suggest a few changes to the process of approving new
project proposals.  The purpose of these changes would be to allow the
ASF to consider big picture issues related to the acceptance of new
projects into the Incubator, which isn't as likely to happen with our
current set of rules where any of our 30+ PMCs can approve a new
project for incubation and where the Incubator PMC itself has a pretty
informal process for evaluating new proposals.

Here are some of the ideas I have in mind (note that some are
dependent on the implementation of others):

- change the Incubator PMC charter (not that we have a official
charter) to include approving of all new projects, so that once a
sponsor PMC (if not the Incubator PMC) approves a new project, the
Incubator PMC still has to give a final approval.


What does this add?  The incubator should not be the arbiter of what 
kinds of things the ASF wants to take on board - that's why we have 
project PMCs who can represent the wide and varied breadth of the ASF.


The purpose of the Incubator is to incubate and to make sure that code 
bases and communities are in a proper state before they enter the ASF 
whole.  Let them in!  If there are issues, then the process of 
incubation should bring those issues to light so we can decide what to do.


The only way I would ever be +1 on this kind of idea is if the allowable 
reasons for the Incubator PMC denying a project or proposal are very 
clearly defined and signed up to by all.  Otherwise we have one PMC 
second guessing another PMC.  Sure set the rules for accepting proposals 
or projects, but let the PMCs get on and do the work!




- ensure all proposals use the same standard template -- we've
recently gotten proposals that simply copied some other proposal they
saw -- we're not really making sure that any one set of standard
questions is answered.


OK - I can see this.  But again I'd be careful not to get too 
bureaucratic.  I'd put forward a standard template and encourage people 
to use it, but God help us if we start turning interesting and useful 
projects away simply because they didn't use the right template!




- add a question to the template asking whether the person(s)
proposing are aware of similar open source projects inside or outside
the ASF.  I'm not suggesting that a project wouldn't get approved if
there is some similar high profile open source project, but at least
we are explicitly asking the question and getting the information.


OK - This is just another bit of information we are asking for.  I 
personally think it's just adding work for proposals, but OK.




- consider having a formal liaison at a few key external open source
communities to give a friendly notice to whenever the Incubator PMC
knows there's a proposal that could be controversial.   This really
only works if we add the new proposal question mentioned above and
create a more centralized process of looping the Incubator PMC in
*before* a project is approved.


+1 to the first part, not sure I agree with the second.  I think we are 
forgetting that a project is *not* "approved" when it enters incubation. 
 It is simply approved to be incubated.  There is absolutely nothing 
wrong with things starting at that point rather than before.  Loop 
people in then - "we have just received a podling dealing with X and are 
letting you know".


Really we are in danger of creating an incubator that you need to get 
through before you get into the incubator.




- require that the Incubator PMC loops in the PRC on any project that
could have any chance of media attention (either because of the
overall significance of the project, the potential for controversy,
expected vendor press releases, or the opportunity to release a joint
statement with some other organization).


I think this is true of any PMC now isn't it?  And really, this should 
be the responsibility of the PPMC (or the owning PMC).  The Incubator 
PMC should just be stepping in when it isn't happening.


Otherwise you are asking the Incubator PMC to be involved in every 
single activity of every single podling, when really the aim of the 
Incubator is to make the podlings self sufficient and capable under the 
ASF umbrella and standards.




I really don't want to add more process than necessary, but as the
ASFs importance continues to grow, I think there a few issues that
should be addressed with each new project, and I'm hoping steps like
these could help that to happen.  Of course, an incubating project
isn't an officially endorsed ASF project, but we still call it "Apache
foo" and it's certainly perceived by the outside as being an action by
the ASF when it is accepted for incubation.


Another approach is to change peoples perception.  Another again i

Re: a few steps before approving a project

[Berin Lautenbach]

Justin Erenkrantz wrote:
--On September 1, 2005 8:41:11 PM +1000 Berin Lautenbach 
<[EMAIL PROTECTED]> wrote:



There are far more checks already.  To get a project approved you need a
full resolution signed by the board.  A better analogy would be voting 
on a
new PMC member.  No PMC requires *any* input from anyone else to take 
such a

vote.



No, it's not.  The board always reserves the right to reject a PMC 
member. Don't confuse the 100% success rate so far for a rubber stamp.  


I'm not - you are not reading me right.  For a vote on a PMC member, the 
board is not involved but the PMC member is not yet ratified by the 
board, and so is not yet a PMC member - *regardless of what the PMC 
might wish*.  If the board says no, then that's it.  Doesn't change the 
fact the PMC had a vote.  It just invalidates it.


Likewise incubation - you can incubate as much as you want, but without 
the signoff of the board, you will never get to TLP.


Cheers,
Berin

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

Re: a few steps before approving a project

[Berin Lautenbach]

Roy T. Fielding wrote:


I am generally opposed to any of the suggestions that we add
more constraints to incubation (aside from a general constraint
of no new projects, which I can understand for infrastructure
reasons alone).  What we need is more documentation, not more rules.


+1


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

Re: stdcxx snapshot

[Berin Lautenbach]

Justin Erenkrantz wrote:

I'm not really clear what the approval process is here on the part of 
the full Incubator PMC.  Bill, do you know?  Or, is it hidden on the 
website somewhere?  ;-)   -- justin


http://incubator.apache.org/incubation/Incubation_Policy.html#Releases%0D

Cheers,
Berin

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

Re: stdcxx snapshot

[Berin Lautenbach]

Justin Erenkrantz wrote:

--On September 3, 2005 10:30:49 AM +1000 Berin Lautenbach 
<[EMAIL PROTECTED]> wrote:



http://incubator.apache.org/incubation/Incubation_Policy.html#Releases%0D



I saw that, but it's not very helpful as it says: "Such approval SHALL 
be given only after the Incubator PMC has followed the process detailed 
in (Reference to Charter)".


I have no clue what that's supposed to mean.  -- justin


That just means there is a document that hasn't been written yet :>.  At 
the time the agreement around how to handle podling releases was done, 
everything that was required was written into this section of the policy.


If there is anything else, then this is probably where it should go.

Cheers,
Berin

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

Re: [VOTE] Werner as juice committer

[Berin Lautenbach]

Geez - for some reason I thought he already was!!!

+1

Cheers,
Berin


Davanum Srinivas wrote:

As part of reviving juice, can we please VOTE werner as a committer to
enable him to continue his offline work? [1]

Here's my +1.

thanks,
dims

[1] : http://www.nabble.com/Status-of-my-upgrades-and-so-on-t945224.html

--
Davanum Srinivas : http://wso2.com/blogs/

-
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: Ode proposal

[Berin Lautenbach]

Alan D. Cabrera wrote:

OT: I dislike the current trend of people using +1, -1, for simple 
conversations.  It confuses people and should be reserved for votes.


The use of +1/-1 for conversations (as apposed to votes) is very common 
through the ASF.  I've always rather liked it personally.  It's a very 
"ASF" thing.


Cheers,
Berin


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

Re: Incubator Roles revisited

[Berin Lautenbach]

Noel J. Bergman wrote:




As written, a Champion must be an ASF Member or Officer.  Why?  A Champion
actually has no specific rights.  Can anyone express a reason why the role
should be restricted to a Member or Officer?  One that comes to mind is as a
filter, but realistically, anyone can ask a PMC to sponsor a project.


I don't think it's really relevant any more.  The original idea was that 
we wanted someone who was trusted within the ASF (thus Member or 
Officer) to put forward the project within the organisation.  Given the 
increased oversite at the initiation stage, I think it's more than a 
little redundant now.





Following from the idea that a Mentor must be a PMC member, do we have a
need to require them to be an ASF Member, as per the current document, or
can we more simply drive the rule from the fact that a Mentor must be a PMC
member, which is effectively how we have been doing it?  Again, I get back
to saying that Mentors are PMC Members who are providing active oversight
and guidance.  Does anyone see any effective difference, since PMC members
have equal votes, and the only binding ones?  Other than apmember karma,
which means access to private information and the ability to contribute on
restricted infrastructure, what would an ASF Member have that isn't also
vested in someone whom we have otherwise chosen to vote onto the Incubator
PMC?


I always thought that using ASF Membership was more of a guide to say 
"we know this person understands what is required within the ASF well 
enough to be a sound mentor to this project".


So personally I'd be happy for non-members who have met your criteria 
above with one caveat - I'd prefer to have at least one member on each 
project to make sure there is someone in the podling that the membership 
as a whole have agreed is looking out for the wider interests of the ASF.


Cheers,
Berin



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