[Debian-sf-devel] [RFC] Plans for the near future (was: Estimated 2.6 stable date?)

[Roland Mas]

Eric D Nielsen (2002-05-17 12:53:19 -0400) :

> Is it possible to estimate the release date of a stable 2.6?  For a
> while I thought it was getting quite close.

Yes indeed, that's exactly why I started breaking it again, since it
was starting to get less fun :-)  Seriously though, it's hard to say.

> Now that the splitting effort is underway I suspect that the stable
> 2.6 is further away.  I've no doubt that splitting the package will
> lead to a more stable "stable."

  Yep.  It should also help isolate problems, and facilitate the way
to multi-host installations.  And third-party theme packages.  And...
No end of good stuff.

  The way I see it is this: I'm currently splitting the package.  To
be frank, the current state of my local checkout of the CVS repository
is "utterly broken, don't even think of installing it, it won't
install anyway".  That's why you probably won't see many CVS commits
from me in the next few days.  On the other hand, the current package
(as of what's in CVS) seems to install fairly dependably, and be
mostly working.  The problem is we don't know exactly what this
"mostly" covers.  Therefore, we need more testing, more reporting of
problems, and more fixing of those problems.  Therefore, we need more
visibility.

  Proposed plan (this is a request for comments):

0. I'm currently trying to "design" how the packages will behave after
   the split (my previous attempts were coded rather than designed,
   and the result didn't work.  When the design is done, I'll probably
   post it and ask for comments.

1. I get to the point of making the sourceforge-* installable in some
   cases (preferably most cases, but maybe not);

2. We upload to experimental with a big "This doesn't work.  If it
   does, please tell us." warning.  We announce it here, on the
   Savannah webpage, on the debian-devel mailing list, everywhere.

3. We collect lots and lots of bug reports.  We fix them.  When no
   more appear for a reasonable amount of time, we upload to unstable.

  During all this period, we fix any grave bugs in the 2.5 series, if
only as a recreation from the nightmare that is the split.  I think it
will be necessary to upload a 2.5-30 sometime anyway, but I definitely
expect 2.5 to be frozen.  No patches providing new features against
2.5 please, only bugfixes.

  With any luck, this should get us to the point where we can upload a
2.6 package to unstable before summer.  That would be cool, since two
rather large tasks wait for us then.

  First, "new upstream release".  VA stated they would make a new
(2.7) release of Sourceforge.  Depending on what is new or improved as
compared to the 2.6 codebase we currently have, we may or may not want
to adopt 2.7.  We will have to study it a bit however.

  Second, porting to PHP 4.2.  There's a big difference between the
4.1 and 4.2 series of PHP.  In 4.1, you can use the value of the CGI
parameter "foo" by simply calling $foo.  In 4.2, you have to use
either $_GET['foo'] or $_POST['foo'].  The same applies to environment
variables.  While this generally improves code readability,
traceability and maintenance, it will be a large conversion to do.
One can configure PHP 4.2 to still work like 4.1 in this regard, but
it's not the default and it's not a viable long-term solution.

  There.  I'd like to say thanks to Soon-Son Kwon for the website
redesign, and also for his work in internationalisation.  Thanks also
to all you out there for your patience in waiting for the splitting to
happen.

Roland.
-- 
Roland Mas

All tribal myths are true, for a given value of 'true'.
  -- in The Last Continent (Terry Pratchett)