[Seaside-dev] about going alpha

[Julian Fitzell]

On Sat, Oct 4, 2008 at 2:41 PM, Philippe Marschall
<philippe.marschall at gmail.com> wrote:
> Hi
>
> It's about a year since we released Seaside 2.8 and we still don't
> have much to such in terms of Seaside 2.9. I would really like to have
> an alpha out so that people have something they can provide feedback
> on. My fear is that people want to put every conceivable refactoring
> and clean up in Seaside 2.9. If we continue like this we'll never have
> a release. This must stop. Especially if it introduces non fixed
> blockers like the WACache refactoring.

I agree. That's why I went through and marked issues with Milestones.
I'm not saying everything I marked for alpha is correct... that was
just my best guess. I think we need to focus on those issues and get
an alpha out as soon as possible. Again, that's why I went through and
added the milestones because I had time to work on issues but was
having trouble focusing on which issues actually needed to be worked
on. I was, of course, hoping others would chime in with opinions on
which issues I had missed or which were not important.

The WACache refactoring was in response to issues that were filed in
the bug tracker and I wanted to get it in before alpha because it
involved changing the dispatcher class hierarchy. It's not much work
to fix the remaining issues with it (I think) but I need some comment
on how best to implement them.

> Lets quickly get trough the list of open issues marked for alpha:
>
> Issue 48
> IMHO not a must have for an alpha. Messing around with cookies should
> be pretty rare in Seaside. I can implement the suggested fix but I
> need someone to review it. I especially need input on comment 4.

Agreed it is not essential to have in alpha. I included it because it
had been marked as critical. I think we need to have some
brainstorming around the right way to fix this so that it doesn't look
like a hack. I'm pretty sure there is a clean way that "fits". Perhaps
we can discuss this at a sprint (once we have all the alpha issues
fixed, of course :) ).

> Issue 100
> IMHO not a must have for an alpha or even 2.9.
>
> Issue 104
> IMHO not a must have for an alpha or even 2.9.

Both are not strictly necessary but Lukas feels that people will begin
active development pretty quickly when an alpha comes out and it would
be better not to have methods there that will disappear. In
particular, I think completing Issue 100 is an important part of
making the request context refactoring make sense to people. If we
still have old crud lying around on the session that should be
somewhere else, I think that will do us a disservice. I'm happy to
look at this issue, I just haven't got around to it because other
things on the list seemed more important (it *is* flagged as Medium
and I sort by priority).

Issue 104 is half resolved anyway and I've started looking at the
other half in a branch. It's marked as Low and if it's the only left
on the lest for Alpha at the end, I wouldn't hold back a release
because of it.

> Issue 124
> Julian, do it. Although it IMHO does not have to happen absolutely for an alpha.

I will do it, don't worry. You set it to Critical; if you don't think
it is, change the priority. :)

> Issue 132
> Absolutely critical. Relates to Issue 124.

Lukas is working on it, no?

> Issue 163
> What is left here?

No idea. :)

> Issue 165
> Do it now or later.

Again, that's why it's on the list. If it's going to be done, it would
be *better* if it was done before Alpha since it will affect the class
hierarchy of key user classes. It also doesn't strictly have to happen
at all nor in alpha. It's on the list so I remember to do it if I have
time. I wouldn't stop an alpha release necessarily if it was the only
thing left.

> Issue 168
> As described in comment and mails. If nobody has any opinion on this
> I'll just do as I please. This means prefixing the categories with
> Seaside- and naming the versions 2.8.999.alpha1.

I don't have a strong opinion. I hate the 2.8.999 thing but I dislike
Lex's suggestions even more. Lukas may also have a point about
Universes but I'm not sure. Probably we can let users decided what
they want to use.

> Issue 174 - 178
> You guys did it, you fix and test it.

Obviously. Again, that's why it's on the list: so it can be fixed. If
I file the issue then other people can contribute when they have time
(I've been traveling the last week so haven't had any). WACache
addresses several issues including configurability of session and
continuation caching and portability. It also removes duplicated coded
and simplifies the request handling class hierarchy. It's a good
change, it just isn't quite finished yet.

Anybody could do 175 and 176 easily... it's just a matter of doing it.
If you have any opinions on 177, that would make me more likely to
start working on it.

> Issue 190
> Low prio and must have for alpha don't go together.

I disagree. The help text for Priority-Low says "Might slip to later
milestone". I still think it should be done by Alpha because it's easy
and it affects package loading and there's no reason *not* to do it
for Alpha. It's marked Low precisely because it could slip if needed.
The Milestone says what milestone the issue is targeted for, it
doesn't imply it "must" be done.

I would like to see us just hack away at the issues that are listed
for the Alpha milestone (which is why I think it's important that
issues are listed with no owner whenever possible so that anybody can
tackle them). We should be focusing on getting that list down and
doing an Alpha in the next 6-8 weeks, in my opinion. I think we need
to be focused but I don't think there's need for panic.

(further discussion on specific issues really should happen in the
issue comments, I think)

Julian