Re: finishing up PyBlosxom 1.5

I've checked it out from sourceforge and played around with it. Really
good work! I love that I was able to do just:

    pyblosxom-cmd create ./blog
    cd blog
    paster serve blog.ini

and then I was looking at a new blog running in a local paste webserver.
And this was all very clear from the documentation, which seems to have
improved a lot.

I'm also a big fan of the new truncate_* config variables.

And I really like the pyblosxom-cmd and that it looks like (from the
docs) plugins can integrate with it. There's a whole bunch of 'utility'
plugins in the plugin registry that are really standalone command-line
scripts and not plugins at all, they could now be integrated into
pyblosxom-cmd.

I agree with moving off SourceForge, it's really not a very good site. I
like git so I'd probably be happy with gitorious or github. However bzr
is a distributed VCS with about the same feature-set of git, and
launchpad.net (a bzr source code hosting site) offers features that may
be very useful to Pyblosxom and may be missing from github and
gitorious. I'm thinking of its support for bug tracking, code reviews,
translations, mailing lists, question & answer tracking and FAQs,
specification tracking, maybe even the automated Ubuntu package
building. It's all stuff I've never wanted for my own little scripts
(which are on github) but that might be useful for a bigger project with
a community, like Pyblosxom.  It's these community project features that
launchpad seems to excel at. As far as I know both github and gitorious
(and I think bitbucket) offer only minimal features of this kind, e.g.
they will give your project a wiki but not much else, but the advantage
they have over launchpad is simplicity and directness.

Does Pyblosxom still use the contributed plugins package? I thought that
had been dropped some time ago in favour of plugins being self-hosted by
the plugin authors, and merely linked to from the plugin registry on the
pyblosxom site?

I'm afraid I can't contribute as I'm writing my thesis, but at this
point (i.e. for 1.6) I think that sorting out the plugins (as Will
suggested) should be top priority. Plugins are very important for
Pyblosxom, you can only barely get a functional weblog out of Pyblosxom
without using any plugins, and yet with the current setup plugin rot is
a real problem. Perl blosxom uses the same plugin registry approach as
Pyblosxom does, with plugins self-hosted by their authors instead of
centrally hosted by the blosxom project. A few months ago I checked out
Perl blosxom again, and I found that so many of the download links to
plugins were broken that I couldn't even piece together a blog with some
very basic features. The same thing is already happening to Pyblosxom, a
lot of the download links in the plugin registry are broken or else link
to hopelessly out of date versions.

As I see it there are two serious problems we need to fix:

1. Plugin rot. Because plugins are hosted by their authors they
   eventually go offline, leaving broken links in the plugin registry,
   and these plugins are no longer available to new Pyblosxom users.
   
   Plugins may also be unmaintained and not work with the current
   version of Python or Pyblosxom.

2. Registry bottleneck. If you want to get a plugin added to the plugin
   registry or update a link you have to request the change from the
   small number of people who have the necessary access, and they
   (understandably) may not respond very quickly or at all.

The current system for Pyblosxom plugins is the worst of both worlds.
Plugins are hosted by their authors, and hence not kept together in a
central location that can be relied upon. And yet the plugin registry
(which is how users find plugins) is still centrally hosted, so
distributing the hosting of the plugins themsevles to the plugin authors
has created the plugin rot problem without solving the bottleneck
problem.

How do other projects handle plugins? One system I have seen, in Gnome
Do for example, is to have a set of "officialily supported plugins" plus
a set of "community plugins". The official plugins are a core set of
plugins that are maintained and centrally hosted as part of the
Pyblosxom project, maybe right there in the main svn branch or in a
separate repo like contrib for 1.3 used to be, and the official plugins
for a given version of Pyblosxom should work with that version of
Pyblosxom (if not, you have found a bug in the Pyblosxom project).

The community plugins are maintained by the plugin authors and not as an
official part of the project, so the Pyblosxom project itself makes no
guarantee that they will work.  I'm not sure if these should be hosted
centrally by the Pyblosxom project, just linked to from the Pyblosxom
site, or what. I want to avoid the registry bottleneck, but also avoid
the self-hosting rot. Maybe we could have a plugins wiki, forum or
mailing list, that plugins authors could post to when they have created
a new plugin or updated one? And then users could search this for a
plugin they want.

That Will wants to move the project off sourceforge may be important. Of
the potential new hosts for the project, what possibilities does each
provide for hosting "community supported" plugins?

Anyway, plugins certainly seem to me to be Pyblosxom's biggest issue,
the Pyblosxom code looks in pretty good shape, the plugin code looks
almost like that of blosxom: the ruins of a dead project.

On Sun, Jan 03, 2010 at 06:36:26PM -0500, will wrote:
> I spent today working on PyBlosxom 1.5.  Seriously.
> 
> I finished up the things in my todo list, I went through the bugs in the 
> bug tracker on SourceForge, and I spent time testing the command line 
> utility and going through the documentation.
> 
> Everything in svn trunk should be "good".  I pushed a lot of changes 
> today and I'm running the latest from trunk on my blog now.  I'm pretty 
> happy with where it is now.  The command line plugin interface is really 
> awesome and will make plugins more powerful.
> 
> Over the next week, I'm going to let the changes I've pushed bake in 
> svn.  I'll try to spend some time looking at plugins in contrib and 
> testing the popular ones.
> 
> After that, I want to get off of SourceForge.  I'd also like to switch 
> from svn to git or some other dvcs.  Having me as the bottleneck sucks 
> for everyone.  Gitorious looks interesting.  I'm also tempted to host it 
> on my own server.  I welcome thoughts on this (though we've talked about 
> this a few times over the last few years).
> 
> After that, I'll work on bug fixes and such and might start doing work 
> towards a PyBlosxom 1.6, though I'm not sure what that would entail, 
> yet.  I also want to work on the plugin situation because it sucks and 
> could be a lot better.
> 
> If you have some time and want to test out what's in svn, that'd be 
> really helpful.  Send issues, concerns, patches, and bugs to this list.
> 
> /will
> 
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev 
> _______________________________________________
> Pyblosxom-devel mailing list
> Pyblosxom-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel


------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev