[Kepler-Project] Kepler snapshot 20070809-2121

[Andre Carregal]

On 8/10/07, hisham.hm at gmail.com <hisham.hm at gmail.com> wrote:
> Why LuaDoc? AFAIK even though it is part of the "Kepler project", it
> is not part of the Kepler package, so it shouldn't be holding back the
> critical path IMHO.

And it is not. It is just a matter of LuaDoc being ready for a long
time and the fact that I'm involved in both projects (aka bottleneck).

> > I suggest we use the time until LuaDoc, Copas and Xavante are released
> > to decide what to do with SAPI. Whatever gets to CVS during that time
> > will be part of the CGILua release.
>
> I disagree. If the current HEAD is ready to go (and indeed it is a
> proven codebase that is already being used in production), then let's
> not mess with it, if we want the release to happen sooner rather than
> later. If it is decided to change SAPI at this point, then we're back
> to square one, posting snapshots and waiting for people to test them
> and report bugs.

A good point indeed. And we can always correct details on the go.

> Remember that at this point it's not the matter of "being careful when
> releasing an API to the world". The API is already out there (in the
> form of snapshots), we're just giving it a proper version number. Even
> if it is decided to change it later, this is beneficial, so that one
> can talk unambiguously about CGILua 5.1 versus CGILua 5.1.1.

No questions here.

> > I would change a bit the order:
> >
> > - (LuaDoc)
> > - Copas
> > - Xavante (as a module, so without XavanteTray)
> > - LuaSQL (full on Unix, whatever we got on Windows)
> > - CGILua (with whatever SAPI improvements we managed to get)
> > - Kepler 1.1
>
> My focus is on the code that's in the snapshots today. From the
> reports we're getting on the list, I'd say it is already good enough
> to be called Kepler 1.1. The Xavante and CGILua improvements you have
> in mind are, well, improvements, so they are new development (which
> due to everyone's lack of time, has no timeframe to happen, and if it
> happens, will prompt us to restart the testing cycle).

I was talking about the improvements, but some corrections. But I got
your point. :o)

> If the code itself is ready to be frozen, we can mark tags for the
> remaining packages in CVS now, even if the Windows packages take a
> while to turn up, in order to get the Unix packages done, then.

I agree in freezing the code base, but then let's turn to the
documentation, since it is outdated for Xavante and Kepler itself.

> So that we get a clearer picture of what this call-for-volunteers
> entails, what exactly needs to be done? :)

Documentation would be the priority here, but a "Kepler release"
involves quite a lot of details:
http://kepler-tmp.dreamhosters.com/en/Checklist

André