You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@commons.apache.org by Peter Donald <pe...@apache.org> on 2002/10/25 04:30:12 UTC
APR-Serf
Hi,
Can someone give us non-APR peeps a basic rundown of serf. It seems to be a
ring in and has all the qualities of Commons candidate from what people say.
However it does not have a separate website that I could see and nor does it
have anything besides developer documentation in CVS (that I could see
anyways).
So someone wanna give a spiel on it? Do we plan for it to be our road test?
--
Cheers,
Peter Donald
*------------------------------------------------------*
| An expert is someone who knows everything about the |
| topic except for its place in the world. |
*------------------------------------------------------*
Re: APR-Serf
Posted by Aaron Bannert <aa...@clove.org>.
On Fri, Oct 25, 2002 at 05:20:10PM +1000, Peter Donald wrote:
> One thing that jumps into my mind. Are we going to set a minimum bar of entry
> for commons projects? Or at least a minimum bar for release of said projects?
Want to add this excellent point to STATUS?
-aaron
Re: APR-Serf
Posted by Steve Downey <st...@netfolio.com>.
On Friday 25 October 2002 06:15 am, Aaron Bannert wrote:
> On Fri, Oct 25, 2002 at 12:32:17AM -0700, Justin Erenkrantz wrote:
> > I also don't think that the PMC should set guidelines on a release
> > (other than 3 binding +1s) or on coding style or on build systems.
> > Leave that up to the committers.
>
> +1 I agree (on these points)
>
> > The PMCs job should be to stay the
> > heck out of the way of the committers.
>
> I agree with this, once the PMC has defined a clear mission.
>
> > If the committers need help,
> > they can ask the PMC for guidance, but let's not have a PMC that
> > dictates from upon high.
>
> Dictate is a strong word. I haven't experienced any ASF PMC which
> has dictated from upon high. What kinds of things are you worried
> about, specifically?
>
I think it's fear of the unknown. The Jarkarta PMC is very small, and mostly
concerned with issues like jarkata top level project creation and oversight
of the actions of the committers. The committers make all day to day
decisions with little to no reference to the PMC.
In fact, an appeal to the PMC is generally regarded as a failure of the
community. Consensus could not be reached, and progress at a standstill.
Although, I believe this is in theory, not practice. Software developers are
not good at inventing process, we worry far to much about corner cases and
exceptional conditions. Necessary in code, not so much when dealing with
people.
Re: APR-Serf
Posted by "Michael A. Smith" <ma...@apache.org>.
Peter Donald wrote:
> One thing I would love to see is some documentation about the process. For
> example I would love to see some docs such as the following collated and used
> as reference. They could just be "guidelines" and people could be free to
> ignore them. Of course not all of them are relevent for all languages while
> some are. Anyways here are some examples;
>
> Releasing:
> --http://cvs.apache.org/viewcvs.cgi/jakarta-ant/ReleaseInstructions?rev=1.9.2.1&content-type=text/vnd.viewcvs-markup
> --http://jakarta.apache.org/turbine/maven/development/release-process.html
Jakarta commons has a step-by-step process for releasing:
http://jakarta.apache.org/commons/releases.html
> Branching CVS (and presumably Subversion):
> --http://jakarta.apache.org/turbine/maven/development/branches.html
>
> Versioning (C specific but with slight mods could be java aswell):
> --http://apr.apache.org/versioning.html
Jakarta commons has a java specific versioning document:
http://jakarta.apache.org/commons/versioning.html
> Deprecation Rules (java specific?):
> --http://jakarta.apache.org/turbine/maven/development/deprecation.html
>
> etc.
[the rest snipped]
regards,
michael
--
Michael A. Smith
mas@apache.org
Re: APR-Serf
Posted by Peter Donald <pe...@apache.org>.
On Fri, 25 Oct 2002 17:32, Justin Erenkrantz wrote:
> --On Friday, October 25, 2002 5:20 PM +1000 Peter Donald
>
> <pe...@apache.org> wrote:
> > Sounds kool.
> >
> > One thing that jumps into my mind. Are we going to set a minimum
> > bar of entry for commons projects? Or at least a minimum bar for
> > release of said projects?
>
> For now, you have to convince the PMC. In serf's case, we have a
> very stacked deck, so it's not quite fair. =) And, my personal
> position is that the barrier would be pretty low.
okay.
> I also don't think that the PMC should set guidelines on a release
> (other than 3 binding +1s)
> or on coding style or on build systems.
who cares on these things. The point I was trying to make is about the
artefacts that effect external users and the process. For example. many of
the things jakarta has been criticised for by users (and rightly so imho) is
things like;
* lack of documentation
* no uptodate website
* lack of documentation
* multiplicity of versioning schemes
* lack of documentation
* no unit testing
* lack of documentation
* ignoring backwards compatability
* lack of documentation
One thing I would love to see is some documentation about the process. For
example I would love to see some docs such as the following collated and used
as reference. They could just be "guidelines" and people could be free to
ignore them. Of course not all of them are relevent for all languages while
some are. Anyways here are some examples;
Releasing:
--http://cvs.apache.org/viewcvs.cgi/jakarta-ant/ReleaseInstructions?rev=1.9.2.1&content-type=text/vnd.viewcvs-markup
--http://jakarta.apache.org/turbine/maven/development/release-process.html
Branching CVS (and presumably Subversion):
--http://jakarta.apache.org/turbine/maven/development/branches.html
Versioning (C specific but with slight mods could be java aswell):
--http://apr.apache.org/versioning.html
Deprecation Rules (java specific?):
--http://jakarta.apache.org/turbine/maven/development/deprecation.html
etc.
It would also be nice to have a minimum standard for producing documentation
when releases are made. (Unit tests would be nice but consesus would be
impossible...)
So don't think of it as what style your code is in or whether to use GNUMake,
Ant or someother tool. Think of it more as process. It need not be inforced
but it could be recomended.
I know some people will have their own religion regarding different parts of
process but if we could document a base standard then that would be great. I
am happy to do the collating and if anyone else has any specific guidelines
then they should feel free to rewrite one of the above or whatever.
So is that a useful thing for us to do? And if so does anyone have any other
process docs they would like to add? If it ends up being successful we can
always push it back to www.apache.org but until then it could be just what we
recomend to components.
Like or no?
> (One
> reason I'm against using Ant commons-wide - it sucks for C code which
> is about all I care about.) -- justin
yes - using Ant for C is about as much fun as sticking hot pokers in your eye
(and thats coming from an ant committer ;])
--
Cheers,
Peter Donald
-----------------------------------------------------------------------
| I thought there was a knob on the TV to turn up the intelligence. |
| There's a knob called "brightness", but it doesn't work. |
-----------------------------------------------------------------------
RE: Role of PMCs was Re: APR-Serf
Posted by Sander Striker <st...@apache.org>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> Sent: 25 October 2002 19:55
> Justin Erenkrantz wrote:
>
> > --On Friday, October 25, 2002 12:58 PM +0200 Stephen McConnell
> > <mc...@apache.org> wrote:
> >
> >> PMC's have some things to dictate - license policy - voting policy
> >> - security policy - duspute resolution mechanisms. The PMC could
> >> choose to use the Jakata policies with would be a good starting
> >> point.
> >
> >
> > The one thing I can be absolutely sure of is that this PMC will not be
> > involved in disputes about code *ever*. (No, I don't speak for the
> > entire PMC.) There will be no 'veto override' and 'veto of last
> > resort' or any other such nonsense. If dueling vetos exist, I
> > couldn't care less what the PMC says - it's the job of the committers
> > (and the relevant community) to duke it out.
+1
> I understand where your comming from and in 99.9% of the cases I think
> your right. However, following classic Jakarta rules provides for
> deadlocks withing which a hell of a lot of strees can be placed on a
> community. Rules provide structure and a framework that enable rolution
> of issues without resorting personal duke-it-out (and the associated
> stress) ... I guess I see rules much more like the lines on a soccer
> field - you know where your can go - you know what expected, whats' not
> expected - makes for civilized communities :-)
No, the people in the community make it civilized, not the rules.
> > Whenever two committers get in a fight, they shouldn't be running to
> > 'Mommy PMC' to solve their problems. Namely because both of them will
> > probably be on the PMC anyway. So, it's not going to be that productive.
>
> That's the negative way to look at a PMC - but its a majority view -
It is? Can that be attributed to the fact that the Jakarta PMC is a small
elected group? Or is there another reason?
> maybe it should be renamed to PECker "Project Avangilization Club" - and
> the members are there to make you sucessfull. Yes I know a dozen people
> and going to say no-way - but hey - everyone is allowed an opinion !
Sander
Re: Role of PMCs was Re: APR-Serf
Posted by Stephen McConnell <mc...@apache.org>.
Justin Erenkrantz wrote:
> --On Friday, October 25, 2002 12:58 PM +0200 Stephen McConnell
> <mc...@apache.org> wrote:
>
>> PMC's have some things to dictate - license policy - voting policy
>> - security policy - duspute resolution mechanisms. The PMC could
>> choose to use the Jakata policies with would be a good starting
>> point.
>
>
> The one thing I can be absolutely sure of is that this PMC will not be
> involved in disputes about code *ever*. (No, I don't speak for the
> entire PMC.) There will be no 'veto override' and 'veto of last
> resort' or any other such nonsense. If dueling vetos exist, I
> couldn't care less what the PMC says - it's the job of the committers
> (and the relevant community) to duke it out.
I understand where your comming from and in 99.9% of the cases I think
your right. However, following classic Jakarta rules provides for
deadlocks withing which a hell of a lot of strees can be placed on a
community. Rules provide structure and a framework that enable rolution
of issues without resorting personal duke-it-out (and the associated
stress) ... I guess I see rules much more like the lines on a soccer
field - you know where your can go - you know what expected, whats' not
expected - makes for civilized communities :-)
>
> Whenever two committers get in a fight, they shouldn't be running to
> 'Mommy PMC' to solve their problems. Namely because both of them will
> probably be on the PMC anyway. So, it's not going to be that productive.
That's the negative way to look at a PMC - but its a majority view -
maybe it should be renamed to PECker "Project Avangilization Club" - and
the members are there to make you sucessfull. Yes I know a dozen people
and going to say no-way - but hey - everyone is allowed an opinion !
Cheers, Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
Role of PMCs was Re: APR-Serf
Posted by Justin Erenkrantz <je...@apache.org>.
--On Friday, October 25, 2002 12:58 PM +0200 Stephen McConnell
<mc...@apache.org> wrote:
> PMC's have some things to dictate - license policy - voting policy
> - security policy - duspute resolution mechanisms. The PMC could
> choose to use the Jakata policies with would be a good starting
> point.
The one thing I can be absolutely sure of is that this PMC will not
be involved in disputes about code *ever*. (No, I don't speak for
the entire PMC.) There will be no 'veto override' and 'veto of last
resort' or any other such nonsense. If dueling vetos exist, I
couldn't care less what the PMC says - it's the job of the committers
(and the relevant community) to duke it out.
Whenever two committers get in a fight, they shouldn't be running to
'Mommy PMC' to solve their problems. Namely because both of them
will probably be on the PMC anyway. So, it's not going to be that
productive.
> But you may want to look further into the implications of
> "release". The PMC is accountable to the board. The board shoud
> be imformed about a release (it increases Apache legal exposure).
> This means that the PMC should be notifying the board of impending
> releases. The community here should be driving the PMC - make sure
> you have a process in place that makes those guys on the PMC work
> for you!!!
No, I don't think the board needs to be notified when a release
occurs. The PMC should be large enough that whomever does the
release is on the PMC. That's good enough for me.
I would imagine that the PMC would take a reactive role in the event
of problems with a release. (Mainly due to inappropriate licensing.)
If the code is of poor quality, that, IMHO, really isn't the problem
of the PMC. Well, it might cause the PMC to look at the community
and considering folding it, but that's about it. -- justin
RE: APR-Serf
Posted by Sander Striker <st...@apache.org>.
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> Sent: 25 October 2002 12:59
> Aaron Bannert wrote:
>
> >On Fri, Oct 25, 2002 at 12:32:17AM -0700, Justin Erenkrantz wrote:
> >
> >
> >>The PMCs job should be to stay the
> >>heck out of the way of the committers.
> >>
> >>
> >
>> I agree with this, once the PMC has defined a clear mission.
>
> The more you clarify scope and stucture - the more accountability you
> assign to yourselves. With clear accountability the community can be
> more responsible - with demonstrated responsibility the PMC should in
> principal stay out of the way of the committers (at least if the PMC
> follwoing the model of the Jakarta process).
>
>>> If the committers need help,
>>> they can ask the PMC for guidance, but let's not have a PMC that
>>> dictates from upon high.
>>
>> Dictate is a strong word. I haven't experienced any ASF PMC which
>> has dictated from upon high. What kinds of things are you worried
>> about, specifically?
Me neither.
> PMC's have some things to dictate -
> license policy -
This is something dictated by being in the ASF, not a choice of
a PMC.
> voting policy - security policy -
I'm kind of hoping those won't have to be dictated (but come
natural).
> duspute resolution mechanisms. The PMC could choose
> to use the Jakarta policies with would be a good starting point.
It should choose to use policies that fit in the ASF, be it from
Jakarta, HTTPD, APR or otherwise.
My $0.02,
Sander
Re: APR-Serf
Posted by Stephen McConnell <mc...@apache.org>.
Aaron Bannert wrote:
>On Fri, Oct 25, 2002 at 12:32:17AM -0700, Justin Erenkrantz wrote:
>
>
>>The PMCs job should be to stay the
>>heck out of the way of the committers.
>>
>>
>
>I agree with this, once the PMC has defined a clear mission.
>
>
The more you clarify scope and stucture - the more accountability you
assign to yourselves. With clear accountability the community can be
more responsible - with demonstrated responsibility the PMC should in
principal stay out of the way of the committers (at least if the PMC
follwoing the model of the Jakarta process).
>
>
>>If the committers need help,
>>they can ask the PMC for guidance, but let's not have a PMC that
>>dictates from upon high.
>>
>>
>
>Dictate is a strong word. I haven't experienced any ASF PMC which
>has dictated from upon high. What kinds of things are you worried
>about, specifically?
>
>
PMC's have some things to dictate - license policy - voting policy -
security policy - duspute resolution mechanisms. The PMC could choose
to use the Jakata policies with would be a good starting point.
>
>
>>Note that as a committer I have very rigid requirements for what a
>>release is, what coding style, and what build system to use. But, I
>>don't believe the PMC should dictate to *me* what tools I use.
>>
Agreed.
But you may want to look further into the implications of "release".
The PMC is accountable to the board. The board shoud be imformed about
a release (it increases Apache legal exposure). This means that the PMC
should be notifying the board of impending releases. The community here
should be driving the PMC - make sure you have a process in place that
makes those guys on the PMC work for you!!!
Cheers, Steve.
>> (One
>>reason I'm against using Ant commons-wide - it sucks for C code which
>>is about all I care about.) -- justin
>>
>>
>
>+1 :)
>
>-aaron
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@commons.apache.org
>For additional commands, e-mail: general-help@commons.apache.org
>
>
>
>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
Re: APR-Serf
Posted by Aaron Bannert <aa...@clove.org>.
On Fri, Oct 25, 2002 at 12:32:17AM -0700, Justin Erenkrantz wrote:
> I also don't think that the PMC should set guidelines on a release
> (other than 3 binding +1s) or on coding style or on build systems.
> Leave that up to the committers.
+1 I agree (on these points)
> The PMCs job should be to stay the
> heck out of the way of the committers.
I agree with this, once the PMC has defined a clear mission.
> If the committers need help,
> they can ask the PMC for guidance, but let's not have a PMC that
> dictates from upon high.
Dictate is a strong word. I haven't experienced any ASF PMC which
has dictated from upon high. What kinds of things are you worried
about, specifically?
> Note that as a committer I have very rigid requirements for what a
> release is, what coding style, and what build system to use. But, I
> don't believe the PMC should dictate to *me* what tools I use. (One
> reason I'm against using Ant commons-wide - it sucks for C code which
> is about all I care about.) -- justin
+1 :)
-aaron
Subject lines, SHOULD'VE BEEN: Policies, WAS: RE: APR-Serf
Posted by Sander Striker <st...@apache.org>.
I'm sorry, but what has this got to do with APR-Serf?
I know, I've been guilty of not changing subjects too,
but when cross-posting, at least let the subject reflect
what it is about.
Thanks,
Sander
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: 25 October 2002 16:35
> To: general@commons.apache.org; general@incubator.apache.org
> Subject: Re: APR-Serf
>
>
>
> /CCing incubator/
>
> Henri Yandell wrote:
> >
> > On Fri, 25 Oct 2002, Justin Erenkrantz wrote:
> >
> >
> >>I also don't think that the PMC should set guidelines on a release
> >>(other than 3 binding +1s) or on coding style or on build systems.
> >>Leave that up to the committers. The PMCs job should be to stay the
> >>heck out of the way of the committers. If the committers need help,
> >>they can ask the PMC for guidance, but let's not have a PMC that
> >>dictates from upon high.
> >
> > I'm assuming other things would exist. A project must have a
> > PROPOSAL.html. A project must maintain a STATUS.html. A release must have
> > a release manager.
>
> In Forrest, we have decided to keep the information about the project in
> xml files.
>
> There are two files: module.xml and status.xml.
> Examples from Forrest CVS:
> http://cvs.apache.org/viewcvs.cgi/xml-forrest/module.xml?rev=HEAD&content-type=text/vnd.viewcvs-markup
> http://cvs.apache.org/viewcvs.cgi/xml-forrest/status.xml?rev=1.20&content-type=text/vnd.viewcvs-markup
>
> Since they have stylesheets, opening them in the browser shows:
> http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/module.xml?rev=HEAD&content-type=text/xml
> http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/status.xml?rev=HEAD&content-type=text/xml
>
> Which is quite cool IMHO.
>
> Module.xml is a descriptor of the CVS module and the project it
> contains, with goals, license, credits, project-related info and
> dependencies with other projects.
>
> In status.xml there are the committers, the todo and the changes.
>
> Forrest already makes info based on status, and we'll get module.xml
> done too soon:
>
> http://xml.apache.org/forrest/changes.html
> http://xml.apache.org/forrest/todo.html
>
> What do you think, could this be an option?
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Re: APR-Serf
Posted by Steve Downey <st...@netfolio.com>.
On Friday 25 October 2002 10:47 am, Henri Yandell wrote:
> On Fri, 25 Oct 2002, Nicola Ken Barozzi wrote:
> > /CCing incubator/
> >
> > Henri Yandell wrote:
> > > On Fri, 25 Oct 2002, Justin Erenkrantz wrote:
> > >>I also don't think that the PMC should set guidelines on a release
> > >>(other than 3 binding +1s) or on coding style or on build systems.
> > >>Leave that up to the committers. The PMCs job should be to stay the
> > >>heck out of the way of the committers. If the committers need help,
> > >>they can ask the PMC for guidance, but let's not have a PMC that
> > >>dictates from upon high.
> > >
> > > I'm assuming other things would exist. A project must have a
> > > PROPOSAL.html. A project must maintain a STATUS.html. A release must
> > > have a release manager.
> >
> > In Forrest, we have decided to keep the information about the project in
> > xml files.
> >
> > Module.xml is a descriptor of the CVS module and the project it
> > contains, with goals, license, credits, project-related info and
> > dependencies with other projects.
> >
> > In status.xml there are the committers, the todo and the changes.
> >
> > Forrest already makes info based on status, and we'll get module.xml
> > done too soon:
> >
> > http://xml.apache.org/forrest/changes.html
> > http://xml.apache.org/forrest/todo.html
> >
> > What do you think, could this be an option?
>
> I'm not that bothered, so I'll immediately be a hypocrit and suggest +ves
> and -ves.
>
> XML is a better storage mechanism but a worse presentation mechanism
> [using w3m to view an xml file probably isn't as exciting as a html. but
> it's a minor thing outweight by the advantage of a structured file].
>
> XML is usually a finite domain, whereas HTML is infinite. By that I mean
> that if we used XML to record this information then it would as I said be
> more structured, but would also be limited. If someone wanted to add some
> more information, then they have to request new tags? Or would it be
> free-flow xml? In a HTML one the information is unbounded but
> unstructured.
>
> I guess it just depends on whether the existing proposal/status files out
> there are deemed to be enough evolving to define a standard. Which brings
> on the arguments over whether maven's project.xml, forrest's module.xml
> etc should be the standard :)
>
> Really my initial mail was that the information in PROPOSAL.html and
> STATUS.html should exist in each project, and that A-C as a project
> probably wants to standardise how to store this information. Using the
> same system as J-C is not mandatory.
>
>
STATUS.html is very limited in scope. Standardising that as an xml document
shouldn't be _that_ difficult. Current committers, to do lists, planned
releases, current release, etc.
PROPOSAL.html is a lot less structured. Or would be if everyone in
Jakarta-Commons wasn't creatively lazy, and didn't copy from the last
succesful PROPOSAL.html. The important thing about PROPOSAL is that it is
what defines and limits the scope of a component. It's what was voted on to
accept the component.
Re: APR-Serf
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 25 Oct 2002, Nicola Ken Barozzi wrote:
>
> /CCing incubator/
>
> Henri Yandell wrote:
> >
> > On Fri, 25 Oct 2002, Justin Erenkrantz wrote:
> >
> >
> >>I also don't think that the PMC should set guidelines on a release
> >>(other than 3 binding +1s) or on coding style or on build systems.
> >>Leave that up to the committers. The PMCs job should be to stay the
> >>heck out of the way of the committers. If the committers need help,
> >>they can ask the PMC for guidance, but let's not have a PMC that
> >>dictates from upon high.
> >
> > I'm assuming other things would exist. A project must have a
> > PROPOSAL.html. A project must maintain a STATUS.html. A release must have
> > a release manager.
>
> In Forrest, we have decided to keep the information about the project in
> xml files.
>
> Module.xml is a descriptor of the CVS module and the project it
> contains, with goals, license, credits, project-related info and
> dependencies with other projects.
>
> In status.xml there are the committers, the todo and the changes.
>
> Forrest already makes info based on status, and we'll get module.xml
> done too soon:
>
> http://xml.apache.org/forrest/changes.html
> http://xml.apache.org/forrest/todo.html
>
> What do you think, could this be an option?
>
I'm not that bothered, so I'll immediately be a hypocrit and suggest +ves
and -ves.
XML is a better storage mechanism but a worse presentation mechanism
[using w3m to view an xml file probably isn't as exciting as a html. but
it's a minor thing outweight by the advantage of a structured file].
XML is usually a finite domain, whereas HTML is infinite. By that I mean
that if we used XML to record this information then it would as I said be
more structured, but would also be limited. If someone wanted to add some
more information, then they have to request new tags? Or would it be
free-flow xml? In a HTML one the information is unbounded but
unstructured.
I guess it just depends on whether the existing proposal/status files out
there are deemed to be enough evolving to define a standard. Which brings
on the arguments over whether maven's project.xml, forrest's module.xml
etc should be the standard :)
Really my initial mail was that the information in PROPOSAL.html and
STATUS.html should exist in each project, and that A-C as a project
probably wants to standardise how to store this information. Using the
same system as J-C is not mandatory.
Re: APR-Serf
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 25 Oct 2002, Nicola Ken Barozzi wrote:
>
> /CCing incubator/
>
> Henri Yandell wrote:
> >
> > On Fri, 25 Oct 2002, Justin Erenkrantz wrote:
> >
> >
> >>I also don't think that the PMC should set guidelines on a release
> >>(other than 3 binding +1s) or on coding style or on build systems.
> >>Leave that up to the committers. The PMCs job should be to stay the
> >>heck out of the way of the committers. If the committers need help,
> >>they can ask the PMC for guidance, but let's not have a PMC that
> >>dictates from upon high.
> >
> > I'm assuming other things would exist. A project must have a
> > PROPOSAL.html. A project must maintain a STATUS.html. A release must have
> > a release manager.
>
> In Forrest, we have decided to keep the information about the project in
> xml files.
>
> Module.xml is a descriptor of the CVS module and the project it
> contains, with goals, license, credits, project-related info and
> dependencies with other projects.
>
> In status.xml there are the committers, the todo and the changes.
>
> Forrest already makes info based on status, and we'll get module.xml
> done too soon:
>
> http://xml.apache.org/forrest/changes.html
> http://xml.apache.org/forrest/todo.html
>
> What do you think, could this be an option?
>
I'm not that bothered, so I'll immediately be a hypocrit and suggest +ves
and -ves.
XML is a better storage mechanism but a worse presentation mechanism
[using w3m to view an xml file probably isn't as exciting as a html. but
it's a minor thing outweight by the advantage of a structured file].
XML is usually a finite domain, whereas HTML is infinite. By that I mean
that if we used XML to record this information then it would as I said be
more structured, but would also be limited. If someone wanted to add some
more information, then they have to request new tags? Or would it be
free-flow xml? In a HTML one the information is unbounded but
unstructured.
I guess it just depends on whether the existing proposal/status files out
there are deemed to be enough evolving to define a standard. Which brings
on the arguments over whether maven's project.xml, forrest's module.xml
etc should be the standard :)
Really my initial mail was that the information in PROPOSAL.html and
STATUS.html should exist in each project, and that A-C as a project
probably wants to standardise how to store this information. Using the
same system as J-C is not mandatory.
Subject lines, SHOULD'VE BEEN: Policies, WAS: RE: APR-Serf
Posted by Sander Striker <st...@apache.org>.
I'm sorry, but what has this got to do with APR-Serf?
I know, I've been guilty of not changing subjects too,
but when cross-posting, at least let the subject reflect
what it is about.
Thanks,
Sander
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: 25 October 2002 16:35
> To: general@commons.apache.org; general@incubator.apache.org
> Subject: Re: APR-Serf
>
>
>
> /CCing incubator/
>
> Henri Yandell wrote:
> >
> > On Fri, 25 Oct 2002, Justin Erenkrantz wrote:
> >
> >
> >>I also don't think that the PMC should set guidelines on a release
> >>(other than 3 binding +1s) or on coding style or on build systems.
> >>Leave that up to the committers. The PMCs job should be to stay the
> >>heck out of the way of the committers. If the committers need help,
> >>they can ask the PMC for guidance, but let's not have a PMC that
> >>dictates from upon high.
> >
> > I'm assuming other things would exist. A project must have a
> > PROPOSAL.html. A project must maintain a STATUS.html. A release must have
> > a release manager.
>
> In Forrest, we have decided to keep the information about the project in
> xml files.
>
> There are two files: module.xml and status.xml.
> Examples from Forrest CVS:
> http://cvs.apache.org/viewcvs.cgi/xml-forrest/module.xml?rev=HEAD&content-type=text/vnd.viewcvs-markup
> http://cvs.apache.org/viewcvs.cgi/xml-forrest/status.xml?rev=1.20&content-type=text/vnd.viewcvs-markup
>
> Since they have stylesheets, opening them in the browser shows:
> http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/module.xml?rev=HEAD&content-type=text/xml
> http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/status.xml?rev=HEAD&content-type=text/xml
>
> Which is quite cool IMHO.
>
> Module.xml is a descriptor of the CVS module and the project it
> contains, with goals, license, credits, project-related info and
> dependencies with other projects.
>
> In status.xml there are the committers, the todo and the changes.
>
> Forrest already makes info based on status, and we'll get module.xml
> done too soon:
>
> http://xml.apache.org/forrest/changes.html
> http://xml.apache.org/forrest/todo.html
>
> What do you think, could this be an option?
>
> --
> Nicola Ken Barozzi nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
Re: APR-Serf
Posted by Nicola Ken Barozzi <ni...@apache.org>.
/CCing incubator/
Henri Yandell wrote:
>
> On Fri, 25 Oct 2002, Justin Erenkrantz wrote:
>
>
>>I also don't think that the PMC should set guidelines on a release
>>(other than 3 binding +1s) or on coding style or on build systems.
>>Leave that up to the committers. The PMCs job should be to stay the
>>heck out of the way of the committers. If the committers need help,
>>they can ask the PMC for guidance, but let's not have a PMC that
>>dictates from upon high.
>
> I'm assuming other things would exist. A project must have a
> PROPOSAL.html. A project must maintain a STATUS.html. A release must have
> a release manager.
In Forrest, we have decided to keep the information about the project in
xml files.
There are two files: module.xml and status.xml.
Examples from Forrest CVS:
http://cvs.apache.org/viewcvs.cgi/xml-forrest/module.xml?rev=HEAD&content-type=text/vnd.viewcvs-markup
http://cvs.apache.org/viewcvs.cgi/xml-forrest/status.xml?rev=1.20&content-type=text/vnd.viewcvs-markup
Since they have stylesheets, opening them in the browser shows:
http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/module.xml?rev=HEAD&content-type=text/xml
http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/status.xml?rev=HEAD&content-type=text/xml
Which is quite cool IMHO.
Module.xml is a descriptor of the CVS module and the project it
contains, with goals, license, credits, project-related info and
dependencies with other projects.
In status.xml there are the committers, the todo and the changes.
Forrest already makes info based on status, and we'll get module.xml
done too soon:
http://xml.apache.org/forrest/changes.html
http://xml.apache.org/forrest/todo.html
What do you think, could this be an option?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: APR-Serf
Posted by Nicola Ken Barozzi <ni...@apache.org>.
/CCing incubator/
Henri Yandell wrote:
>
> On Fri, 25 Oct 2002, Justin Erenkrantz wrote:
>
>
>>I also don't think that the PMC should set guidelines on a release
>>(other than 3 binding +1s) or on coding style or on build systems.
>>Leave that up to the committers. The PMCs job should be to stay the
>>heck out of the way of the committers. If the committers need help,
>>they can ask the PMC for guidance, but let's not have a PMC that
>>dictates from upon high.
>
> I'm assuming other things would exist. A project must have a
> PROPOSAL.html. A project must maintain a STATUS.html. A release must have
> a release manager.
In Forrest, we have decided to keep the information about the project in
xml files.
There are two files: module.xml and status.xml.
Examples from Forrest CVS:
http://cvs.apache.org/viewcvs.cgi/xml-forrest/module.xml?rev=HEAD&content-type=text/vnd.viewcvs-markup
http://cvs.apache.org/viewcvs.cgi/xml-forrest/status.xml?rev=1.20&content-type=text/vnd.viewcvs-markup
Since they have stylesheets, opening them in the browser shows:
http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/module.xml?rev=HEAD&content-type=text/xml
http://cvs.apache.org/viewcvs.cgi/*checkout*/xml-forrest/status.xml?rev=HEAD&content-type=text/xml
Which is quite cool IMHO.
Module.xml is a descriptor of the CVS module and the project it
contains, with goals, license, credits, project-related info and
dependencies with other projects.
In status.xml there are the committers, the todo and the changes.
Forrest already makes info based on status, and we'll get module.xml
done too soon:
http://xml.apache.org/forrest/changes.html
http://xml.apache.org/forrest/todo.html
What do you think, could this be an option?
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Requirements was Re: APR-Serf
Posted by Justin Erenkrantz <je...@apache.org>.
--On Friday, October 25, 2002 9:25 AM -0400 Henri Yandell
<ba...@generationjava.com> wrote:
> I'm assuming other things would exist. A project must have a
> PROPOSAL.html. A project must maintain a STATUS.html. A release
> must have a release manager.
>
> That's all that springs to mind, would hope it's documented at J-C
> somewhere :)
No, I don't see those as a requirement. As a good practice, perhaps.
But, not as something that the PMC would enforce. The PMC might want
to see a rough proposal before we begin, but I'm not even certain of
that.
And, no a release doesn't *have* to have a release manager. -- justin
Re: APR-Serf
Posted by Henri Yandell <ba...@generationjava.com>.
On Fri, 25 Oct 2002, Justin Erenkrantz wrote:
> I also don't think that the PMC should set guidelines on a release
> (other than 3 binding +1s) or on coding style or on build systems.
> Leave that up to the committers. The PMCs job should be to stay the
> heck out of the way of the committers. If the committers need help,
> they can ask the PMC for guidance, but let's not have a PMC that
> dictates from upon high.
I'm assuming other things would exist. A project must have a
PROPOSAL.html. A project must maintain a STATUS.html. A release must have
a release manager.
That's all that springs to mind, would hope it's documented at J-C
somewhere :)
>
> Note that as a committer I have very rigid requirements for what a
> release is, what coding style, and what build system to use. But, I
> don't believe the PMC should dictate to *me* what tools I use. (One
> reason I'm against using Ant commons-wide - it sucks for C code which
> is about all I care about.) -- justin
Sounds good. You'd have far more effort trying to convince the
maven/centipede/ant fans to settle on one tool. So the tool aspect is
something J-C wouldn't be able to demand, so seems unlikely that A-C would
be able to.
Hen
Re: APR-Serf
Posted by Justin Erenkrantz <je...@apache.org>.
--On Friday, October 25, 2002 5:20 PM +1000 Peter Donald
<pe...@apache.org> wrote:
> Sounds kool.
>
> One thing that jumps into my mind. Are we going to set a minimum
> bar of entry for commons projects? Or at least a minimum bar for
> release of said projects?
For now, you have to convince the PMC. In serf's case, we have a
very stacked deck, so it's not quite fair. =) And, my personal
position is that the barrier would be pretty low. Perhaps we could
go to the length of the Jakarta guidelines as suggestions, but I'm
not sure how often we're going to get code handed to us in Commons.
I also don't think that the PMC should set guidelines on a release
(other than 3 binding +1s) or on coding style or on build systems.
Leave that up to the committers. The PMCs job should be to stay the
heck out of the way of the committers. If the committers need help,
they can ask the PMC for guidance, but let's not have a PMC that
dictates from upon high.
Note that as a committer I have very rigid requirements for what a
release is, what coding style, and what build system to use. But, I
don't believe the PMC should dictate to *me* what tools I use. (One
reason I'm against using Ant commons-wide - it sucks for C code which
is about all I care about.) -- justin
Re: APR-Serf
Posted by Peter Donald <pe...@apache.org>.
Sounds kool.
One thing that jumps into my mind. Are we going to set a minimum bar of entry
for commons projects? Or at least a minimum bar for release of said projects?
The kinda things I am thinking about is something like;
* Must have a website that gives basic overview and detailed usage
instructions
* Must have unit tests that cover at least x% of codebase
* Must have at least a two week freeze prior to release (or be releases be
branched or whatever)
etc.
These could be rules or guidelines or whatever.
The result is that the commons components jump in their terms of quality. They
become much more highly respected. The negative being that it is a bunch more
work and may deter people from developing stuff here.
Thoughts?
On Fri, 25 Oct 2002 15:21, Justin Erenkrantz wrote:
> Serf serves two purposes - getting a solid BSD-licensed HTTP client
> library out there (something I think we're in a good position to
> deliver) as well as testing some filtering ideas originating from
> httpd-2.0 that may eventually trickle back in to httpd itself.
>
> The people who have written code or given suggestions to serf (so
> far) are pretty much a subset of the crowd that wrote that silly HTTP
> server (usual suspects of me, Aaron, Greg, Sander, Ian, and Cliff).
> Most of the conversation though has been dominated to a large degree
> by Aaron, Greg, and myself. Even though we don't have a lot of time
> to code on it, we do believe that we need such a solution. (Perhaps
> we can make some progress at the Hackathon? Oooh!)
>
> As I hinted out earlier, we would like to take some of the data
> abstraction techniques we learned in the development of httpd-2.0
> (filters and buckets) and do a better job of it. Some of the filter
> paradigm in httpd-2.0 doesn't strike us as 'quite right,' so we sort
> of want a playground to test new ideas.
>
> Flood, an HTTP tester over in the HTTP Server Project, and Subversion
> are potential candidates for use of Serf. So, even if no one outside
> of our little group likes it, we will probably use it somewhere
> ourselves.
>
> And, there is *some* code already in apr-serf's repository. -- justin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@commons.apache.org
> For additional commands, e-mail: general-help@commons.apache.org
--
Cheers,
Peter Donald
"Artists can color the sky red because they know it's blue. Those of us who
aren't artists must color things the way they really are or people might
think we're stupid." -- Jules Feiffer
Re: APR-Serf
Posted by Justin Erenkrantz <je...@apache.org>.
--On Friday, October 25, 2002 12:30 PM +1000 Peter Donald
<pe...@apache.org> wrote:
> Hi,
>
> Can someone give us non-APR peeps a basic rundown of serf. It seems
> to be a ring in and has all the qualities of Commons candidate
> from what people say. However it does not have a separate website
> that I could see and nor does it have anything besides developer
> documentation in CVS (that I could see anyways).
>
> So someone wanna give a spiel on it? Do we plan for it to be our
> road test?
Serf serves two purposes - getting a solid BSD-licensed HTTP client
library out there (something I think we're in a good position to
deliver) as well as testing some filtering ideas originating from
httpd-2.0 that may eventually trickle back in to httpd itself.
The people who have written code or given suggestions to serf (so
far) are pretty much a subset of the crowd that wrote that silly HTTP
server (usual suspects of me, Aaron, Greg, Sander, Ian, and Cliff).
Most of the conversation though has been dominated to a large degree
by Aaron, Greg, and myself. Even though we don't have a lot of time
to code on it, we do believe that we need such a solution. (Perhaps
we can make some progress at the Hackathon? Oooh!)
As I hinted out earlier, we would like to take some of the data
abstraction techniques we learned in the development of httpd-2.0
(filters and buckets) and do a better job of it. Some of the filter
paradigm in httpd-2.0 doesn't strike us as 'quite right,' so we sort
of want a playground to test new ideas.
Flood, an HTTP tester over in the HTTP Server Project, and Subversion
are potential candidates for use of Serf. So, even if no one outside
of our little group likes it, we will probably use it somewhere
ourselves.
And, there is *some* code already in apr-serf's repository. -- justin