You are viewing a plain text version of this content. The canonical link for it is here.
Posted to axkit-dev@xml.apache.org by Kip Hampton <kh...@totalcinema.com> on 2004/04/06 18:13:36 UTC
Wake-Up Call
Howdy Folks,
This message is a long time coming and, since no one seems to want to
step up to address the issue I guess I'll be the one to drag in into the
light...
Specifically, I'm concerned about apparent lack of recent interest in
AxKit among what have historically been its core developers and the
general "so what" attitude that is being presented to its users.
I'm aware that every project has its ebb and flow, and that sometimes
the requirements of Real Life don't always make it possible to
contribute the time and attention that we'd like; but the inertia seems
to go deeper than that, in this case.
Speaking personally for a moment, the timing for this couldn't possibly
be worse. On the one hand, I'm very excited to be at the end of the
publishing process for the O'Reilly AxKit book, but, in emerging from
that 2-year ordeal (with a book that I believe the AxKit community can
be proud of) I find that the once-vibrant group that inspired me to
write the thing in the first place have, for all practical purposes,
abandoned ship.
I don't see any value in pointing fingers or ascribing blame-- we've all
done what we could as time permitted and need required (and we should be
*proud* of what we've done!)-- but its time, I think, to draw a line
between AxKit's past and its future.
Letting the AxKit project fall by the wayside is simply not an option.
In addition to our regular users, we have other OSS community projects
and commercial companies whose development plans require a vital and
energetic AxKit.
So, where do we go from here?
For those who may not be aware, the Apache XML Project Management
Committee is being reorganized and AxKit has the opportunity to become
what is known as a "top-level project" (much like mod_perl or Cocoon is
now). The most significant change for us, is that we can set the
guidelines and processes by which AxKit gets developed in a way that
most intimately reflects our goals and ideas as a smaller community.
That is, *we* get to define the rules and conventions that we believe
will lead to best possible AxKit for everyone.
I suggest that we take the opportunity that (potentially) becoming a
top-level project provides to take stock, put aside old baggage, and
move AxKit forward with renewed vigor. To that end, I've put together a
first draft proposal for the guidelines and mission that are required
for AxKit as an Apache top-level project. That document can be found
here [1].
It is important to note that this document is not intended to be the
final word. In fact, the official charter and guidelines for AxKit as a
TLP must be decided by its new Project Management Committee and approved
by the ASF Board. I post it here (with some trepidation) only as a means
open discussion about where we might be going and a concrete means to
get there.
The time for shoe-gazing, shoulder-shrugging, and praying for "round
tuits" is now over. Be realistic. If AxKit is not part of your future
then so be it; things change and no one will judge you for being honest.
But if you are practically committed to AxKit and its evolution (and are
willing and able to devote the time to back that up) then please, help
us re-kindle the fire and move on.
Okay, I've said my piece-- now its time to hear from others. Thanks for
bearing with such a long-winded screed...
Cheers,
-kip
[1] http://totalcinema.com/axkit/axkitguidelines.xml
Re: Wake-Up Call
Posted by Wendell <en...@fldna.net>.
On Tue, Apr 06, 2004 at 09:13:36AM -0700, Kip Hampton wrote:
+1 (lurker)
AxKit is important to me too. I also enjoy working with it and am
happy to help and contribute to the "rebirth".
Thanks, and I'm looking forward to the book.
Wendell
Re: Wake-Up Call
Posted by Tom Schindl <to...@gmx.at>.
I'm also a non-commiter but +1 from me too.
Michael A Nachbaur wrote:
> Yeah, agreed on all points. +1 to the draft from this non-commiter as
> well.
>
>
Re: Wake-Up Call
Posted by Michael A Nachbaur <mi...@nachbaur.com>.
Yeah, agreed on all points. +1 to the draft from this non-commiter as well.
Re: Wake-Up Call
Posted by Michael Kröll <mi...@uibk.ac.at>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Kip Hampton wrote:
| Speaking personally for a moment, the timing for this couldn't
| possibly be worse. On the one hand, I'm very excited to be at the end
| of the
| publishing process for the O'Reilly AxKit book, but, in emerging from
| that 2-year ordeal (with a book that I believe the AxKit community can
| be proud of) I find that the once-vibrant group that inspired me to
| write the thing in the first place have, for all practical purposes,
| abandoned ship.
First and foremost - Thank you Kip for bringing us the AxKit book and
for placing this wake up call! I do not think the timing for this
couldn't be worse. It would have been far worse if this current state of
uncertainty about AxKit's future, which I know I am not the only one
percieving it, would have continued being undealt with. So, now, before
the book is released and before the decision about AxKit being a TLP or
not, is surely better than after it.
| Letting the AxKit project fall by the wayside is simply not an option.
| In addition to our regular users, we have other OSS community projects
| and commercial companies whose development plans require a vital and
| energetic AxKit.
True. There will not be a Callisto CMS or XIMS CMS without AxKit, just
to name two OS projects.
| I suggest that we take the opportunity that (potentially) becoming a
| top-level project provides to take stock, put aside old baggage, and
| move AxKit forward with renewed vigor. To that end, I've put together a
| first draft proposal for the guidelines and mission that are required
| for AxKit as an Apache top-level project. That document can be found
| here [1].
IMHO AxKit urgently needs such guidelines and a mission statement,
Apache TLP or not. Reading through it, I do not find arguments for
substantial corrections. Especially, I like the "Pumpking" approach
which promises shorter AxKit development cycles and better ressource
partitioning amongst committers.
So, +1 from me non-committer for this draft. Now, let's wait for binding
votes.
- --michael
- --
IT Services University of Innsbruck
063A F25E B064 A98F A479 1690 78CD D023 5E2A 6688
http://zis.uibk.ac.at/.m/uibk.ac.at_pgp_pubkey.asc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
iD8DBQFAdAV+eM3QI14qZogRAo4cAKDKgY0LJGXtNnE38UZWivfZR+3JWgCg+TkT
tlownqybsg96je0YNpJRk7k=
=0ymx
-----END PGP SIGNATURE-----
Re: Wake-Up Call
Posted by Kip Hampton <kh...@totalcinema.com>.
Mike Chamberlain wrote:
> I like the idea of having a Pumpkin, I think the problem we've been
> having recently is no one has been wanting to take charge, and at
> other times too many people want to run the show / have conflicting
> ideas and there isn't anyone who is willing to act as a chairman to
> get a decision made. - As can been seen from the hiatus on the dev
> work I was doing on the pipeline / apache2.
Yes, exactly. And the power stays balanced because the committers as a
group selected the pumpkin in the first place by approving their
proposed release plan. Actually, there are lots of potential benefits,
IMO-- we have a clear plan to follow, there's a shepherd to push or
reign-in as needed, and we can give users a clear(er) idea about what
changes to expect and when to expect them.
>
> I'd also like to see more use of the -dev list to discuss ideas. IRC
> is all well and good, but it doesn't leave any records for anyone
> else to see or comment on.
I agree. IRC has its place, but once an idea goes past the "watercooler
talk" stage, we should really drag it out into the light, where the
archives can capture the discussion. Note too that the the use of a
STATUS file should help in this regard, as well.
Cheers,
-kip
Re: Wake-Up Call
Posted by Tom Schindl <to...@gmx.at>.
Thanks Mike,
I'll take a look this afternoon. The most important thing for me is
Apache2 since all our mp-stuff is running now on mp2.
Maybe I could spend sometime to get it run on Apache2 or at least
identify what has to changed todo so.
Tom
Mike Chamberlain wrote:
> On 19 Apr 2004, at 09:29, Mike Chamberlain wrote:
>
>> Yeap,
>>
>> First off.
>>
>> ***** THIS IS NOT AN OFFICIAL RELEASE. ******
>> Do not expect this to work the way the current or future axkit's will
>> work.
>> Do not take this code as in indication of what any final product will
>> look like.
>> etc etc.
>> *********************************************
>>
>
> I should expand on that a little.
>
> What that means is no one on the -dev team has voted on these changes. They
> are my personal view on some stuff. And thus it's use at your own risk etc.
>
> Mike.
>
>
Re: Wake-Up Call
Posted by Mike Chamberlain <mi...@btinternet.com>.
On 19 Apr 2004, at 09:29, Mike Chamberlain wrote:
> Yeap,
>
> First off.
>
> ***** THIS IS NOT AN OFFICIAL RELEASE. ******
> Do not expect this to work the way the current or future axkit's will
> work.
> Do not take this code as in indication of what any final product will
> look like.
> etc etc.
> *********************************************
>
I should expand on that a little.
What that means is no one on the -dev team has voted on these changes.
They
are my personal view on some stuff. And thus it's use at your own risk
etc.
Mike.
Re: Changing the Pipeline Model
Posted by Mike Chamberlain <mi...@btinternet.com>.
>
> - There's no easy way to change the pipeline mid-stream with a pull
> model
>
There is code in there now to allow append to the front (from current
position),
and append to the end. The problem comes if you want to add stuff in
the middle :)
But there is ways to do that if you know in advance where in the middle
you want
to add stuff. :)
> I don't exactly know the right answer to this, so if you have input
> into this send it now. I think what really has to happen is we have to
> download this new code and play with it, and see what we think of it
> from an individual point of view, and then come back here (and not
> IRC) and discuss it openly.
>
> Matt.
>
That'd be cool.
Mike.
Re: Changing the Pipeline Model
Posted by Tom Schindl <to...@gmx.at>.
Matt Sergeant wrote:
>> (A push pipeline, each stage is run independantly, the output pushed
>> to the next handler).
>>
>> A pull pipeline looks just like a function call stack, starting at the
>> outside... which means each stage ask the stage before it for the
>> representation it wants before getting it, which allows for lots of
>> self optimisation.
>>
>> send( get_binary ( get_text ( get_dom( get_dom( get_dom( ) ) ) ) ) )
>>
>> (in the code this is the $self->upstream()->get_dom() stuff).
>>
>> The (dis)advantage is that the pipeline gets created first, before things
>> like the cache get created, which allow for the cache to interact with
>> the
>> pipline (and thus XSP). The disdvantage is is that it's a little
>> slower than
>> the current axkit due to this overhead.
>>
>> It however also means that we can make the cache just another pipeline
>> module.
>> So incremental caching is available if you want it out of the box.
>>
>> AxKit.pm is a lot smaller.
>>
>> Chained XSP works.
>>
>> Chained sax handlers work the way you would expect them to, they're
>> just a style
>> using the Apache::AxKit::Pipeline::SAX processor
>>
>> Error stylesheets have been fixed, there is an Error Provider now
>> which you need
>> to set up as you server 500 handler.
>
>
> Before I chime in on Kip's "Wake-Up" thread, which I will try and do
> tomorrow, I want to address this issue, and start off a new thread on
> it, so the WakeUp call doesn't get bogged down in discussing this side
> issue.
>
> We need to come to a decision on this - whether to fundamentally change
> our pipeline model in AxKit-2.0.
>
> As I see it the arguments for/against are something like this:
>
> For:
> - The pull model cleans up some code
> - The pull model already supports some things we've wanted for a while:
> e.g. Chained XSP and more flexible cache
I'm working on chained XSP by using my new XML::LibXSLT::Enhanced(a new
module of mine) which allows you to add perl functions inside your XSL.
As a proof of concept I reimplemented your ESQL-Taglib. With this
approach you can easily chain XSP because it's nothing more than an
XSL(T)-Pipeline.
At the moment the following things are supported:
* defining your own variables (to overcome: you only set a variable once
in xsl)
* logging via log4perl (that's really fantastic to debug XSLs)
* esql (not competely ready yet)
It also comes with a commandline interface named xslt-proc-enhanced
which allows you to register TagLib's out side of the AxKit-Context and
test your xsls like one is used to with xslt-proc.
The module is not ready for release on CPAN still if somebody is
interessted in it I can publish the code. At the moment one can also use
http://search.cpan.org/~tomson/Apache-AxKit-Language-LibXSLTEnhanced-0.02/
this was my first try on adding something like TagLib's to XML::LibXSLT.
Please note when writing TagLib's using this module they will not be
compatible with XML::LibXSLT::Enhanced-TagLibs.
> - The pull model means some cleaner code
>
> Against:
> - It's a big change. This means a change for developers and users alike
> to get used to.
> - (Meta For argument) - 2.0 is as good a time as any for big changes
> - Some of the things the pull model does should be possible with a bit
> more work using the push model, without breaking anything else.
> - There's no easy way to change the pipeline mid-stream with a pull model
>
> I don't exactly know the right answer to this, so if you have input into
> this send it now. I think what really has to happen is we have to
> download this new code and play with it, and see what we think of it
> from an individual point of view, and then come back here (and not IRC)
> and discuss it openly.
>
> Matt.
>
>
Re: Changing the Pipeline Model
Posted by Mike Chamberlain <mi...@btinternet.com>.
--- Matt Sergeant <ma...@sergeant.org> wrote: > On 22
Apr 2004, at 21:18, Mike Chamberlain wrote:
>
> > Well the config reader would obviously have to
> support the option in
> > the same way it supports
> > other Ax* directives...
>
> What I meant was, would a different pipeline model
> require a completely
> different looking config file, and thus be tied to a
> configreader.
>
Ah, I see what you mean.
OK, at the moment I've only required the one extra
directive, but then I've not tried to do anything
clever with it.
I'm guessing there is no easy way which would allow
modules to define their own configuration options, and
some how extend the config reader when they're used.
That would be really cool, but require quite a bit of
thought into that api.
Mike.
Re: Changing the Pipeline Model
Posted by Matt Sergeant <ma...@sergeant.org>.
On 22 Apr 2004, at 21:18, Mike Chamberlain wrote:
> Well the config reader would obviously have to support the option in
> the same way it supports
> other Ax* directives...
What I meant was, would a different pipeline model require a completely
different looking config file, and thus be tied to a configreader.
Matt.
Re: Changing the Pipeline Model
Posted by Mike Chamberlain <mi...@btinternet.com>.
On 22 Apr 2004, at 21:04, Matt Sergeant wrote:
> On 22 Apr 2004, at 17:08, Kip Hampton wrote:
>
>> Matt Sergeant wrote:
>>
>>> We need to come to a decision on this - whether to fundamentally
>>> change our pipeline model in AxKit-2.0.
>>
>> I think the only sane answer to "do we do implement a pull or a push
>> model for the core pipelines?" is "Yes!". What I mean is: why don't
>> we make the pipeline just YA swappable component rather than
>> hard-coding one model or the other?
>>
>> Thoughta?
>
> My thoughta is this might be needless complexity (?). Though I really
> do need to sit down with the code and play some. Would making the
> pipeline swappable make it incompatible with the ConfigReader (or
> rather, make it tied to the ConfigReader)?
>
>
Well the config reader would obviously have to support the option in
the same way it supports
other Ax* directives... But I don't think it adds needless complexity.
Theoretically it should
make axkit more powerful, by allowing people to more interesting stuff
than just a straight pipeline.
After all, almost everything else is plugable, including the config
reader, so why not the pipeline?
Mike.
Re: Changing the Pipeline Model
Posted by Matt Sergeant <ma...@sergeant.org>.
On 22 Apr 2004, at 17:08, Kip Hampton wrote:
> Matt Sergeant wrote:
>
>> We need to come to a decision on this - whether to fundamentally
>> change our pipeline model in AxKit-2.0.
>
> I think the only sane answer to "do we do implement a pull or a push
> model for the core pipelines?" is "Yes!". What I mean is: why don't we
> make the pipeline just YA swappable component rather than hard-coding
> one model or the other?
>
> Thoughta?
My thoughta is this might be needless complexity (?). Though I really
do need to sit down with the code and play some. Would making the
pipeline swappable make it incompatible with the ConfigReader (or
rather, make it tied to the ConfigReader)?
Matt.
Re: Changing the Pipeline Model
Posted by Mike Chamberlain <mi...@btinternet.com>.
--- Kip Hampton <kh...@totalcinema.com> wrote: >
Matt Sergeant wrote:
>
> > We need to come to a decision on this - whether to
> fundamentally change
> > our pipeline model in AxKit-2.0.
>
> I think the only sane answer to "do we do implement
> a pull or a push
> model for the core pipelines?" is "Yes!". What I
> mean is: why don't we
> make the pipeline just YA swappable component rather
> than hard-coding
> one model or the other?
>
> Thoughta?
>
I've actually done some work towards that goal on the
pipeline branch, but not yet commited it. Shouldn't be
too much more to do on it.
Ideally then the way the pipeline works (and the
features available) would be swappable.
So definite +1 from me with regards making the
pipeline controller just another configurable part.
Mike.
Re: Changing the Pipeline Model
Posted by Kip Hampton <kh...@totalcinema.com>.
Matt Sergeant wrote:
> We need to come to a decision on this - whether to fundamentally change
> our pipeline model in AxKit-2.0.
I think the only sane answer to "do we do implement a pull or a push
model for the core pipelines?" is "Yes!". What I mean is: why don't we
make the pipeline just YA swappable component rather than hard-coding
one model or the other?
Thoughta?
-kip
Changing the Pipeline Model
Posted by Matt Sergeant <ma...@sergeant.org>.
> (A push pipeline, each stage is run independantly, the output pushed
> to the next handler).
>
> A pull pipeline looks just like a function call stack, starting at the
> outside... which means each stage ask the stage before it for the
> representation it wants before getting it, which allows for lots of
> self optimisation.
>
> send( get_binary ( get_text ( get_dom( get_dom( get_dom( ) ) ) ) ) )
>
> (in the code this is the $self->upstream()->get_dom() stuff).
>
> The (dis)advantage is that the pipeline gets created first, before
> things
> like the cache get created, which allow for the cache to interact with
> the
> pipline (and thus XSP). The disdvantage is is that it's a little
> slower than
> the current axkit due to this overhead.
>
> It however also means that we can make the cache just another pipeline
> module.
> So incremental caching is available if you want it out of the box.
>
> AxKit.pm is a lot smaller.
>
> Chained XSP works.
>
> Chained sax handlers work the way you would expect them to, they're
> just a style
> using the Apache::AxKit::Pipeline::SAX processor
>
> Error stylesheets have been fixed, there is an Error Provider now
> which you need
> to set up as you server 500 handler.
Before I chime in on Kip's "Wake-Up" thread, which I will try and do
tomorrow, I want to address this issue, and start off a new thread on
it, so the WakeUp call doesn't get bogged down in discussing this side
issue.
We need to come to a decision on this - whether to fundamentally change
our pipeline model in AxKit-2.0.
As I see it the arguments for/against are something like this:
For:
- The pull model cleans up some code
- The pull model already supports some things we've wanted for a
while: e.g. Chained XSP and more flexible cache
- The pull model means some cleaner code
Against:
- It's a big change. This means a change for developers and users
alike to get used to.
- (Meta For argument) - 2.0 is as good a time as any for big changes
- Some of the things the pull model does should be possible with a bit
more work using the push model, without breaking anything else.
- There's no easy way to change the pipeline mid-stream with a pull
model
I don't exactly know the right answer to this, so if you have input
into this send it now. I think what really has to happen is we have to
download this new code and play with it, and see what we think of it
from an individual point of view, and then come back here (and not IRC)
and discuss it openly.
Matt.
Re: Wake-Up Call
Posted by Mike Chamberlain <mi...@btinternet.com>.
Yeap,
First off.
***** THIS IS NOT AN OFFICIAL RELEASE. ******
Do not expect this to work the way the current or future axkit's will
work.
Do not take this code as in indication of what any final product will
look like.
etc etc.
*********************************************
Having said that, any feed back would be gratefully received.
you need to check out the axkit-pipeline-2 branch from the axkit cvs
tree.
cvs checkout -r axkit-pipeline-2 xml-axkit
This currently is a build for apache1. It's a rewrite of the way the
pipeline
system works. Fundamentally, it's a change from a push pipeline to a
pull
pipeline.
(A push pipeline, each stage is run independantly, the output pushed
to the next handler).
A pull pipeline looks just like a function call stack, starting at the
outside... which means each stage ask the stage before it for the
representation it wants before getting it, which allows for lots of
self optimisation.
send( get_binary ( get_text ( get_dom( get_dom( get_dom( ) ) ) ) ) )
(in the code this is the $self->upstream()->get_dom() stuff).
The (dis)advantage is that the pipeline gets created first, before
things
like the cache get created, which allow for the cache to interact with
the
pipline (and thus XSP). The disdvantage is is that it's a little slower
than
the current axkit due to this overhead.
It however also means that we can make the cache just another pipeline
module.
So incremental caching is available if you want it out of the box.
AxKit.pm is a lot smaller.
Chained XSP works.
Chained sax handlers work the way you would expect them to, they're
just a style
using the Apache::AxKit::Pipeline::SAX processor
Error stylesheets have been fixed, there is an Error Provider now which
you need
to set up as you server 500 handler.
The original plan was I that i write this, then we look at porting this
to apache2
(having cleaned it all up). However there was 'some discussion' on this
point and
on what the apache2 version should look like, which has lead to a bit
of a hiatus.
It's not heavily documented, so you'll need to mail me questions and
stuff. The main
thing is most pipeline stuff is now under
Apache::AxKit::Pipeline::*
and they should be used instead of the Language::* modules, but there
is a backwards
compat layer for stuff I've not looked at yet.
There is still some work on my machine to commit around allowing
different Pipeline
controllers to be used, so you could in theory write one which works
exactly the
way the current axkit works but with the loss in functionality.
Mike.
On 19 Apr 2004, at 07:07, Tom Schindl wrote:
> Hi Mike,
>
> is it somehwo possible to take a look at what you've done on
> pipeline/apache2 stuff?
>
> Thx
>
> Tom
>
> Mike Chamberlain wrote:
>>>
>>>
>>> [1] http://totalcinema.com/axkit/axkitguidelines.xml
>>>
>>>
>> +1 from me.
>> I like the idea of having a Pumpkin, I think the problem we've been
>> having recently is
>> no one has been wanting to take charge, and at other times too many
>> people want to
>> run the show / have conflicting ideas and there isn't anyone who is
>> willing to act
>> as a chairman to get a decision made. - As can been seen from the
>> hiatus on the dev
>> work I was doing on the pipeline / apache2.
>> I'd also like to see more use of the -dev list to discuss ideas. IRC
>> is all well and
>> good, but it doesn't leave any records for anyone else to see or
>> comment on.
>> Mike.
>
Re: Wake-Up Call
Posted by Tom Schindl <to...@gmx.at>.
Hi Mike,
is it somehwo possible to take a look at what you've done on
pipeline/apache2 stuff?
Thx
Tom
Mike Chamberlain wrote:
>>
>>
>> [1] http://totalcinema.com/axkit/axkitguidelines.xml
>>
>>
>
> +1 from me.
>
> I like the idea of having a Pumpkin, I think the problem we've been
> having recently is
> no one has been wanting to take charge, and at other times too many
> people want to
> run the show / have conflicting ideas and there isn't anyone who is
> willing to act
> as a chairman to get a decision made. - As can been seen from the hiatus
> on the dev
> work I was doing on the pipeline / apache2.
>
> I'd also like to see more use of the -dev list to discuss ideas. IRC is
> all well and
> good, but it doesn't leave any records for anyone else to see or comment
> on.
>
>
> Mike.
>
>
>
>
>
>
>
>
Re: Wake-Up Call
Posted by Mike Chamberlain <mi...@btinternet.com>.
>
>
> [1] http://totalcinema.com/axkit/axkitguidelines.xml
>
>
+1 from me.
I like the idea of having a Pumpkin, I think the problem we've been
having recently is
no one has been wanting to take charge, and at other times too many
people want to
run the show / have conflicting ideas and there isn't anyone who is
willing to act
as a chairman to get a decision made. - As can been seen from the
hiatus on the dev
work I was doing on the pipeline / apache2.
I'd also like to see more use of the -dev list to discuss ideas. IRC is
all well and
good, but it doesn't leave any records for anyone else to see or
comment on.
Mike.
Re: Wake-Up Call
Posted by Michael A Nachbaur <mi...@nachbaur.com>.
Kip Hampton wrote:
> Specifically, I'm concerned about apparent lack of recent interest in
> AxKit among what have historically been its core developers and the
> general "so what" attitude that is being presented to its users.
I for one have noticed this, and have been very concerned about it. I'm
very interested in the direction of AxKit, seeing how I earn my bread &
butter with it, and this recent turn AxKit has taken is giving me
pause. I don't know what I can do to help spur activity...my recent
hope was, given patches and contributions, more work can be made in that
direction. My XSP taglibs, and more recently my patches to AxKit-CVS,
have been my own attempts at putting in my own contribution to the
momentum of AxKit.
I'm not sure how effective the taglibs have been, since I don't have a
handle on how many people, other than me, use them. I know however that
the patches haven't gone anywhere. Its now been exactly 6 weeks since I
submitted a patch -devel, and I still have to hand-patch my own copy
when I install an AxKit instance, despite it's being accepted. Now, for
me this is disheartening. I put in fast effort to do a good job, submit
good documentation, and nothing has come of it. Coming from a person
who's invested as much time and effort into AxKit as I have over the
years, this is a pretty hard knock. How would this be percieved to an
outsider, who doesn't have this investment? They'd just shrug, mutter a
few profanities, and move on, leaving AxKit by the way-side.
> I'm aware that every project has its ebb and flow, and that sometimes
> the requirements of Real Life don't always make it possible to
> contribute the time and attention that we'd like; but the inertia
> seems to go deeper than that, in this case.
Especially since, AFAICT, the guidelines set forth in the XML-PMC are
supposed to mitigate this to some extent, to spread the decision-making
load across multiple team members, as it were.
> Letting the AxKit project fall by the wayside is simply not an option.
> In addition to our regular users, we have other OSS community projects
> and commercial companies whose development plans require a vital and
> energetic AxKit.
I, for one, rely on AxKit at work, as I've alluded to above. I can't
afford (literally and figuratively) to have AxKit loose it's vibrant
sense of growth and cutting-edge development that attracted me to it in
the first place. I have a significant code-base built up at work that's
written using AxKit, and a number of sites and applications (Callisto
for one) that rely on it. I frankly depend on AxKit for my financial
success.
I want AxKit as a software project, and as a community, to flourish.
This is in part due to my occupational dependancy on it, but also
because I truely *believe* in it. I've tried Cocoon, and I judged it to
be inferior. I've tried PHP, Mason, and all those other paridigms, and
judge them also to be inferior. We have something here that is truely
exciting...we may forget it from time to time, having become used to
it. But, it is better than the alternatives. I just don't want to see
us ride on the laurels of past success. There are still many
developments that need to be made, and for that we need IMHO an active
and vibrant developer community.
> For those who may not be aware, the Apache XML Project Management
> Committee is being reorganized and AxKit has the opportunity to become
> what is known as a "top-level project" (much like mod_perl or Cocoon
> is now). The most significant change for us, is that we can set the
> guidelines and processes by which AxKit gets developed in a way that
> most intimately reflects our goals and ideas as a smaller community.
> That is, *we* get to define the rules and conventions that we believe
> will lead to best possible AxKit for everyone.
>
> I suggest that we take the opportunity that (potentially) becoming a
> top-level project provides to take stock, put aside old baggage, and
> move AxKit forward with renewed vigor. To that end, I've put together
> a first draft proposal for the guidelines and mission that are
> required for AxKit as an Apache top-level project. That document can
> be found here [1].
This looks good to me, though since I'm not a "Core" developer or
anything, I don't think I really have a say in the matter, do I? This
does seem much more in line with the way Apache projects work. I think
the extra exposure form bing a top-level project, as well as the
independance from the XML PMC could really help AxKit. After all, most
of the XML PMC is Java-based tools, and AxKit doesn't really seem to fit
into a comfortable niche.
> The time for shoe-gazing, shoulder-shrugging, and praying for "round
> tuits" is now over. Be realistic. If AxKit is not part of your future
> then so be it; things change and no one will judge you for being
> honest. But if you are practically committed to AxKit and its
> evolution (and are willing and able to devote the time to back that
> up) then please, help us re-kindle the fire and move on.
Hear hear. AxKit is definitely part of my future, and my success - or
lack of it - depends on AxKit's being a vibrant and actively developed
community. I very much like being a part of the developer community,
even if I don't have CVS access. I'm happy to be able to provide what I
can where I can. If additional support is needed, then I'm willing to
devote the time necessary to that end.
--man
Re: Wake-Up Call
Posted by Michael A Nachbaur <mi...@nachbaur.com>.
On April 20, 2004 08:04 am, Kip Hampton wrote:
> 1) What happens if the current Pumpking can't or won't fulfil their duties?
I think this is an instance where it's discussed & voted upon in -devel.
Maybe have it so if the Pumpking drops off the face of the earth, gets hit by
a bus, a meteorite, a job or so on, a majority vote could assign an interim
Pumpking to take over the RP in their absense. Or the Pumpking could
identify a substitute 'till they get back, or if they realize they don't have
the management skills necessary to finish the release.
> 2) Is charging a Pumpking with ownership of a full set of subversion
> releases *still* too much? Should we do new RPs for each microversion
> instead? Maybe a "keep releasing until all items on the RP are
> completed, regardless of version numbers" approach would work better?
I think the RPs should indicate features that are to be added, and discussion
can be used to determine if the changes are sufficient to necessitate a bump
in the major version number. Instead of being "Version" driven, I think we
should be "Feature" driven.
That being said, if a person wants to suggest an RP for a full major version,
then they should be welcome to do so.
> In any case, it looks like we have a general consensus w.r.t. to that
> project guidelines doc and we should probably push forward with the TLP
> proposal (if you have thoughts to the contrary, speak up now).
I'm still +1.
Re: Wake-Up Call
Posted by Chris Prather <ch...@prather.org>.
On Tuesday 20 April 2004 19:38, Kip Hampton wrote:
> Matt Sergeant wrote:
> >> Chris reports progress to the AxKit PMC at the (newly instituted)
> >> bi-weekly dev meetings.
> >>
> >> When the items on Chris' RP are knocked down and released, the process
> >> starts over.
> >
> > This seems like the Pumpking is also going to be the main developer on
> > the release.
>
> Not necessarily, and there's nothing in or about the RM's mandate that
> makes it so. I only presented it from that angle because I couldn't
> imagine submitting a release plan that I wasn't also prepared to
> implement in full myself if that's what it took to see it though to the
> end.
Even if the chosen Pumpking wasn't coditng the whole release alone, he would
be responsible for making sure that the patches were submitted, reviewed, and
checked in against the dev branch for that release. So even with a more
cheerleader style Pumpking reign the language use is still applicable.
> In any case, the Pumpking is answerable to the PMC and is expected show
> forward progress at the bi-weekly dev. meetings so there's already a
> poker's poker in place.
Well and the entire reason someone volunteers is because they have an itched
that needs to be scratched. I can't imagine someone taking on that position
without alot of motivation to get a release out.
Also note that sometimes Pumpkings can come in simply to keep progress moving,
by taking a smaller list of low hanging fruit patches and bundling them
together to cause a release. This keeps project momentum in times when larger
changes don't have a champion with enough time to govern them through the
process.
> That said, if it truly looks like the RM will be forced to do too much,
> then, realistically, no one will volunteer (and that would be a bad
> thing). Did you have other ideas about spreading the responsibility around?
I can't see how in the great group of users that AxKit has that nobody will
lack the desire to volunteer. If a Pumpking drops off the face of the earth,
and nobody else wants to take over their Release plan, wouldn't it be fairly
simple to say "Well Chris is dead and he didn't finish his plan we'll leave
them as TODOs anybody want to take over? No? Damn. Well what about a new
release plan incorporating the stuff Chris finished? Good, go for it Timmy".
-Chris
Re: Wake-Up Call
Posted by Kip Hampton <kh...@totalcinema.com>.
Matt Sergeant wrote:
>> Chris reports progress to the AxKit PMC at the (newly instituted)
>> bi-weekly dev meetings.
>>
>> When the items on Chris' RP are knocked down and released, the process
>> starts over.
>
>
> This seems like the Pumpking is also going to be the main developer on
> the release.
Not necessarily, and there's nothing in or about the RM's mandate that
makes it so. I only presented it from that angle because I couldn't
imagine submitting a release plan that I wasn't also prepared to
implement in full myself if that's what it took to see it though to the
end.
In any case, the Pumpking is answerable to the PMC and is expected show
forward progress at the bi-weekly dev. meetings so there's already a
poker's poker in place.
That said, if it truly looks like the RM will be forced to do too much,
then, realistically, no one will volunteer (and that would be a bad
thing). Did you have other ideas about spreading the responsibility around?
-kip
Re: Wake-Up Call
Posted by Matt Sergeant <ma...@sergeant.org>.
On 20 Apr 2004, at 16:04, Kip Hampton wrote:
> Chris Commiter really want to see FeatureX happen, so s/he picks it,
> and a few other items from the STATUS and makes a Release Plan.
>
> Chris' RP is selected or rejected by a vote. If selected, Chris
> becomes Pumpking for the next set of subversion releases. Those
> releases contain *only* the items from the RP + fixes for any bugs
> that pop up during his/her tenure.
>
> Chris reports progress to the AxKit PMC at the (newly instituted)
> bi-weekly dev meetings.
>
> When the items on Chris' RP are knocked down and released, the process
> starts over.
This seems like the Pumpking is also going to be the main developer on
the release. I don't think that's the right model - someone separate
should be prodding and chasing that person.
Matt.
Re: Wake-Up Call
Posted by Kip Hampton <kh...@totalcinema.com>.
Matt Sergeant wrote:
> On 6 Apr 2004, at 17:13, Kip Hampton wrote:
>> [1] http://totalcinema.com/axkit/axkitguidelines.xml
>
>
> I think this document hits the mark, and I'm +1 on moving forward with
> becoming a TLP and adopting this new development approach. I've gone
> over this document twice now and have nothing to add to it at this point.
>
> Of course we'll need a pumpking. I'm not saying I won't do it, but given
> my recent activity (rather - lack of) on AxKit I doubt many people would
> ask me to take up the role. But if it turns out to be a hot potato I'd
> be happy to pick it up as it's easier to arrange meetings and shout at
> people than it is to pick up the codebase again.
Some important things to note about the Pumpking is that he/she is
selected 1) only for a given minor version (1.7 through 1.7.n) and 2)
based on the approval of their proposed release plan.
Here's how I see that working (ideally):
Wishlist/feature items get added to the STATUS file, voting happens
as-needed.
Chris Commiter really want to see FeatureX happen, so s/he picks it, and
a few other items from the STATUS and makes a Release Plan.
Chris' RP is selected or rejected by a vote. If selected, Chris becomes
Pumpking for the next set of subversion releases. Those releases contain
*only* the items from the RP + fixes for any bugs that pop up during
his/her tenure.
Chris reports progress to the AxKit PMC at the (newly instituted)
bi-weekly dev meetings.
When the items on Chris' RP are knocked down and released, the process
starts over.
The benefits I'd hope to see from this are:
* Democratic fairness. Since RPs are accepted by vote (based on STATUS
file items that will also have been voted in) everybody gets their itch
scratched sooner or later.
* Faster release cycles. If a developer's pet features aren't in the
current RP, they still have a reason to help implement the current
items, so that the next RP goings that *does* have their pet features
will come up sooner.
* Better communication. Everyone on the dev team knows where we are at,
and users get to know what to expect from the next release (and roughly
when to expect it).
* No single committer get saddled with the Pumpking duties. Committers
are more likely to step up and take on a leadership role if they know
that there is a there is a clear end in sight and they don't have to
worry about biting off more than they can chew in terms of time/energy
comitment.
A Couple of questions still stick out in my mind (none of which are
probably showstoppers, but we should talk about them):
1) What happens if the current Pumpking can't or won't fulfil their duties?
2) Is charging a Pumpking with ownership of a full set of subversion
releases *still* too much? Should we do new RPs for each microversion
instead? Maybe a "keep releasing until all items on the RP are
completed, regardless of version numbers" approach would work better?
In any case, it looks like we have a general consensus w.r.t. to that
project guidelines doc and we should probably push forward with the TLP
proposal (if you have thoughts to the contrary, speak up now).
Cheers,
-kip
Re: Wake-Up Call
Posted by Jörg Walter <jw...@garni.ch>.
On Monday, 19. April 2004 23:09, Matt Sergeant wrote:
> >
> > [1] http://totalcinema.com/axkit/axkitguidelines.xml
>
> I think this document hits the mark, and I'm +1 on moving forward with
> becoming a TLP and adopting this new development approach. I've gone
> over this document twice now and have nothing to add to it at this
> point.
As you may have noticed, I am back, quite recognizable from the fact I was
away for ~3 months. I am still digging through heaps of emails, MLs and
stuff, but this looks very sensible to me. Just my 2 cents. Count me back in
- soon earning money with the help of AxKit! Yay!
--
CU
Joerg
PGP Public Key at http://ich.bin.kein.hoschi.de/~trouble/public_key.asc
PGP Key fingerprint = D34F 57C4 99D8 8F16 E16E 7779 CDDC 41A4 4C48 6F94
Re: Wake-Up Call
Posted by Matt Sergeant <ma...@sergeant.org>.
On 6 Apr 2004, at 17:13, Kip Hampton wrote:
> I suggest that we take the opportunity that (potentially) becoming a
> top-level project provides to take stock, put aside old baggage, and
> move AxKit forward with renewed vigor. To that end, I've put together
> a first draft proposal for the guidelines and mission that are
> required for AxKit as an Apache top-level project. That document can
> be found here [1].
>
> It is important to note that this document is not intended to be the
> final word. In fact, the official charter and guidelines for AxKit as
> a TLP must be decided by its new Project Management Committee and
> approved by the ASF Board. I post it here (with some trepidation) only
> as a means open discussion about where we might be going and a
> concrete means to get there.
>
> The time for shoe-gazing, shoulder-shrugging, and praying for "round
> tuits" is now over. Be realistic. If AxKit is not part of your future
> then so be it; things change and no one will judge you for being
> honest. But if you are practically committed to AxKit and its
> evolution (and are willing and able to devote the time to back that
> up) then please, help us re-kindle the fire and move on.
>
> Okay, I've said my piece-- now its time to hear from others. Thanks
> for bearing with such a long-winded screed...
>
> Cheers,
> -kip
>
> [1] http://totalcinema.com/axkit/axkitguidelines.xml
I think this document hits the mark, and I'm +1 on moving forward with
becoming a TLP and adopting this new development approach. I've gone
over this document twice now and have nothing to add to it at this
point.
Of course we'll need a pumpking. I'm not saying I won't do it, but
given my recent activity (rather - lack of) on AxKit I doubt many
people would ask me to take up the role. But if it turns out to be a
hot potato I'd be happy to pick it up as it's easier to arrange
meetings and shout at people than it is to pick up the codebase again.
Matt.