Thanks for your encouraging reply Robert.
I've scattered by replies through yours below.
Thanks again,
Stuart
Robert Burrell Donkin wrote:
(this email is just personal opinions with my mentor hat removed)
On Mon, Sep 14, 2009 at 12:06 PM, Steve Poole <spoole...@googlemail.com> wrote:
I'd vote for not doing it Stuart, your on the hook as you're down as the
tutor. Perhaps we can go for the next ApacheCon?
perhaps but i'd recommend thinking hard before turning this one down...
ApacheCon is a great experience, and offers a great chance to learn
and network. this one is the 10th birthday bash and is going to be
very special indeed. if the tutorial offers a way to attend that you
wouldn't otherwise have then you may well later regret turning the
offer down.
My concern is that what we have is immature and has never been used in
anger. While what we
are doing may be interesting, it isn't something to be used in
production. Therefore I don't believe
that it would be fair to the paying attendees to do the tutorial just yet.
On Fri, Sep 11, 2009 at 3:17 PM, Stuart Monteith <stuk...@stoo.me.uk> wrote:
+1
I also think it's too early. There is no sign on the mailing list of people
trying out what we have already - I'd like more insight from community
members
before taking it to a tutorial.
perhaps it might be worthwhile talking to an old hand who regularly
does tutorials at ApacheCon. want me to try to set something up?
We'd like to do a tutorial at some point, so that may still be useful.
Steve Poole wrote:
On Thu, Sep 10, 2009 at 5:39 PM, Stuart Monteith <stuk...@stoo.me.uk>
wrote:
Hi,
It turns out that of our submissions to ApacheConUS 2009, one was
accepted. Oddly enough, it was a tutorial rather than a presentation.
Here are the details:
http://us.apachecon.com/c/acus2009/speakers/282
Before such a thing occurs there should be a release of some sort of our
project's code.
I was wondering what people (esp. mentors) thought about that. The code
itself would be like an alpha release. This would hopefully encourage
discussion and early adoption, and possible participation.
release often, release early :-)
i don't know the code but IMHO it's worthwhile thinking about whether
'alpha' is really the best description
for example, IMHO
* kato-1.0-alpha implies that 1.0 is pretty much done but the code
hasn't had the real life testing required to be sure that the quality
is there. once an alpha is shipped, i would expect the code to be
stable, with just bug fixes until a 1.0
* kato-0.1 implies that kato is short of features and is not mature as
an API but that the code quality is reasonable as far as it goes
* kato-M1 implies that kato is immature and under very active
development but that this milestone offers an island of stability
That last option is the most promising, I'll follow up with what I think
we should do.
The steps I think would should take towards a release would include:
o Writing documentation
documentation is essential when developing a user base. IMHO if aiming
for a 0.1 or an M1, minimal documentation would be ok.
Agreed. Documentation is like some things. Even what it's bad, it's been
that having none at all.
o Improving the website - it's difficult to ascertain what we are
offering. The binaries would be linkable from here.
got to have something to offer first ;-)
IMHO users tend to want a binary to play. so, i'd probably wait until
kato has some sort of binary available before improving the website.
Ok.
o Establishing on this mailing list our current state.
There is a release process drafted here:
http://incubator.apache.org/guides/releasemanagement.html , but I'm not
sure how achievable all of that is at this stage of the project.
it's usually easier to cut a release whilst a project is young and
simple: the longer it's left, the more work it usually turns out to
be.
Sure, I can see how it'll take a few goes even to get it right, and once
we've got a stable process the delta between
releases should be smaller.
I'll be very interested in what everyone's thoughts are.
One question I have is what is the expectation on tutorials at
ApacheCon? I'm sure we can create the necessary material but I worry
about offering a tutorial for something as early in its life as Kato.
a tutorial is long, hands-on small-group training session paid for by
those attending
judging from the pitch
(http://us.apachecon.com/c/acus2009/sessions/397) i would expect an
expert session heavy on JSR326 and practical experiences with kato as
the tool being used for the problem solving. for a tutorial practical
as described, kato doesn't need to be finished just useful as a
practical problem solving tool.
- robert
That sounds close to what I had in mind. I think we are somewhat lacking in
practical experiences and problem solving - I'd like for more experience with
what we have. Unfortunately the potential for adversely affecting JVMs is
somewhat high.
--
Stuart Monteith
http://blog.stoo.me.uk/
