Re: Maintenance state (was Pyblosxom Documentation)

On Sat, 2003-12-20 at 04:45, Jesse Lawrence wrote:
> It's a shame to hear that you're unable to keep up the
> great work with Pyblosxom, Wari.  Although I'm rather
> new to the Pyblosxom scene, I have noticed that there
> are a few others who seem to be likely candidates to
> take over the project.  Will seems to be right up
> there, but I don't want to presume too much.

Hehe. You are thinking what I am thinking, but Will has a few projects
up his sleeve, adding one more as lead developer might kill his time
available for his excellent Lyntin and Stringbean projects. Not to
mention his life outside the internet.

Another pyblosxom user who has been in the background but doing some
funny exploratory stuff is IWS, I don't even know his name, and can't
really read his website. You can look up his pyblosxom page @
http://iws.dyndns.org/blog/net/pyblosxom

This guy's got a problem to solve (that is running pyblosxom thru
mod_python, and using MySQL as a cache), he might just be motivated to
maintain pyblosxom until he got his problem solved. I will talk about
this below.

> I have a concern about placing Pyblosxom in a
> maintenance state before it reaches version 1.0.  It
> seems to me that Pyblosxom is very stable.  It has an
> excellent code base, and it seems to be really
> grabbing the attention of webloggers.  For developers
> and people familiar with the open source/free software
> scene, using a pre 1.0 piece of software isn't that
> big of a deal.  We know that it's just versioning, and
> that there is a lot of great software which is pre
> 1.0.  

Well, IMO, PyBlosxom is not complete until it can be a 'make' for
weblogs. Right now it's just a 'cat'.

There are a few things that needs to be done. Right now, I feel that
pyblosxom is like blosxom 0.8 sans plugins. blosxom 1.0 introduced
static rendering (the 'make' part) other than the standard CGI stuff
(the 'cat' part). Of course, blosxom plugins came later than pyblosxom,
hence blosxom 2.x.

So what is needed is really, a command line processor, synonymous to the
pyblosxom.cgi program that output to files instead of stdout, not only
that it output to files, but goes thru the regime of building archives
of category, and date. I don't think that it's hard to do, just need to
find the time for it. So for 1.0, there should be no change in the
pyblosxom library at all, just one more python program to do all the
work while utilising the pyblosxom library.

The second is the stability part. This, for me is 2.x stuff, so it's in
the back burner. Pyblosxom is not stable when runnning as a long
process, that is, when running as a webware servlet, or as mod_python
program. This is due to a few factors:

  * CGI program was in mind when designing pyblosxom
  * Global variables everywhere especially in tools.py
  * File locking needs fixing, when one instance of pyblosxom is
touching something, the other should just wait.
  * Contention issues, globals in one state, when another instance wants
another state, etc.

For this, a rewrite might be needed, in order to achieve such a robust
piece of code, while having the ability to run as a CGI process as well.

This really needs someone who has done such things, and aware of such
issues, which I neither have the skill, and knowledge to handle the
task. It would be nice to learn from someone more wiser than me for
something interesting as this.

> I assume that it is a goal of everyones to get
> programmer types and end users alike to use Pyblosxom
> (let me know if that's not the case).  I feel that
> many end users are turned off by pre 1.0 software,
> believing that maybe it's buggy, or incomplete in some
> way.

If you look at pyblosxom, it really requires one to have some skill in
computers before being able to operate such machinary. I believe 99% of
the bloggers out there would only be comfortable using tools such as
Movable Type or WordPress as their weblog tool of choice. Those willing
to work with pyblosxom or blosxom are comfortable using editors and
creating text files. And possibly can program a few lines or two just to
solve his real need.

So I'm not at all worried about pyblosxom users. They are the kind who
knows how to take care of themselves, without stepping on their foot.
There are some who migrated to syntaco (webware based blogging tool with
emphasis on xpath like queries) or even MovableType, or b2, due to some
features lacking in pyblosxom, like static rendering, or multiple
categories. More power to you people. I'm not at all sad by these moves,
though I am happier to see people who migrated from blosxom to
pyblosxom.

> So the question is, is Pyblosxom complete?  I've seen
> throughout the lists and on the wiki that there seems
> to be quite a few ideas floating around out there,
> regarding feature additions and improving certain
> aspects of the codebase.

Well, the answer would be yes, and no. Pyblosxom is more or less
complete, if a CGI tool is what you need, it's a stable piece of code.
And no, as somethings can or needs to be done on it.

Talking about 'stable', the pyblosxom site keeps on core dumping, and
the dumps tend to take up all the space available on my site. I've got a
cron job solving that issue. These core dumps are not due to pyblosxom,
but the buggy python that is installed on the site. Administrators have
no clue what I'm talking about. X(

> I guess what I'm saying is that it would be a shame to
> put Pyblosxom into maintenance mode now, when it's
> picking up so much steam.  Wari, you seem to have
> provided excellent leadership on this project, and
> hopefully you might find the time to continue doing so
> in the future.  Hopefully someone can step in and keep
> the ball rolling.  

If I find a bit of free time I might put in the static rendering stuff
and declare it to be 1.0, though it's not in the near future. I'd like
to see if anyone is willing to step up the plate and be the number one,
I would still be around just in case the project does not go astray,
following the words of wisdom from Will, as he has been more experienced
in maintaining projects than me.

> I'm a python coder too, though my
> skills aren't up to par with Wari and Will, and I
> would love to help out however I can.  

I code up pyblosxom just to learn python, I don't think I have better
skills than anyone here. To me, it's the ability to keep up the
enthusiasm and learning from mistakes as I have learned thru pyblosxom.
Will has been an excellent guide and contributor to pyblosxom. I have
learnt much from him, and I do hope that he has learnt from me too. :)

> I'm starting to
> get familiar with the code base, and will continue to
> study it until I feel like I can start contributing in
> useful ways.

I don't think the code is difficult to read, maybe the plugins part
needs a bit of hand holding, but the rest is just pure straight python.

> Also, I'm going to keep working on the documentation,
> towards the end of adopting new users.

Thanks Jesse. Do note the target audience of pyblosxom, I believe that
most potential users cannot grok the benefits of pyblosxom, and may not
be able to even install and use it. Pyblosxom users IMO are advanced
users, who do not need instructions on how to use notepad.exe and are
brave enough to install pyblosxom. Even then, only 1% who have tried
will look for other 'easier' tools to work with.




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click