Re: Pyblosxom 1.1 Was:Patch for simple walk caching

On Mon, 6 Dec 2004, Bill Mill wrote:
>
> Thanks for the clarification; I haven't looked at any of those plugins, 
> so I didn't know that they were duplicating the directory walk.
>
> On an entirely unrelated note, are there any blocking issues for 
> releasing pyblosxom 1.1?  Do we have a date to shoot for?

I was going to do it months ago, but then was going to do it weeks ago, 
but then was going to do it days ago, but then figured I'd wait until 
SourceForge finished updating all their web-servers.

There were two good reasons for this wait:

1) They've updated the web-server so now pyblosxom works on their system. 
We can now merge PyBlosxom main site with the PlanetPyBlosxom sites into 
one big site that has all the documentation, all the details on 
development, and all the news updates.

2) I had a hunch that after updating all their web-servers, they'd have 
some "growing pains" kind of issues and figured it's better to wait a week 
or so.

3) There really isn't much in PyBlosxom 1.1.  There are a few fixes, but 
everything is pretty minor.  The major change between 1.0 and 1.1 is that 
I'm ditching the contrib directory.  My new plan is this:

    1. release PyBlosxom as one tar ball
    2. release plugins, flavours, and such as a separate entity

This makes a whole lot of stuff much easier to deal with and allows us to 
split up the release schedules because we find a lot more problems with 
the contributed plugins because no one really tests them before release 
than we do with the core.

So...  that's my thinking at the moment.

But to be honest, the big thing we're waiting on is me.  I've just totally 
lacked the motivation and free time to go through my inbox, read through 
all the pyblosxom emails, get organized and then push the release out and 
do all the things that are related to that.  It's probably a couple of 
days of work.

I'll try to get started on it now so that I can do a release this weekend.

Things that I could use some help with:

1) making sure the INSTALL and README guides are up-to-date and accurate
2) making sure that the code works well--we should note changes the user
    will have to do when they upgrade
3) go through the contributed plugins and make sure:
    a) they're updated and work with the current core
    b) they have updated documentation at the top
    c) they're ready to be put in the registry--meaning they should
       meet the requirements for plugins in the registry

I think that's about it.

/will


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now. 
http://productguide.itmanagersjournal.com/