pyblosxom-devel — Development Mailing List for pyblosxom

[Pyblosxom-devel] Circular dependency mess

[Neil S. <pyb...@ne...>]

Been looking at liberally sprinkling logging support to a bunch of
modules.  Now, wanting to start out nice and easy, I decided to start
with plugin_utils.py.

Except tools.py import plugin_utils.py, and trying to use the logging
facilities in the latter causes Python to call me names and question my
lineage.  And I don't like it when programming languages do that to
me. :P

I've this notion of further breaking down various modules, to try and
get pyblosxom to the point that it's at least possible to include
logging in the various modules without circular dependencies causing me
to tear my hair out in sizable chunks.

I'm not sure how attached anyone is to the current structure, so I'm
announcing my intention of doing so beforehand (to give way to
objections and such).

This is, of course, a non-trivial change, hence this message.  I feel
that this ought to be done before 1.5 is pushed out (with proper
deprecation messages and such where appropriate, of course), though I
wouldn't be suprised if this stretches far into 1.6, as I haven't really
taken a very close look at how big a job it is.

I can probably post an update here if anyone's curious.

If there are no objections, I'll proceed to chopping up pyblosxom
modules.  To start with, I want to move logging-related functions into
its own module, as well as other, more minor, attendant changes: i.e.,
deprecated_function() will need to relocated, or at least, I'd have to
figure out how not to invoke Python's wrath at yet another breach of
circular dependency conduct.

Let me know what you guys think.
-- 
Neil Santos
Disgruntled Paradigms :: Code Monkey  //  Doing software The Right Way(TM)

[HTTP] neil.diosa.ph :: [XMPP] ne...@xm... :: [Y!M] neil_santos18

"Throwing a book of rules at a terrible programmer just creates a terrible
 programmer with a bruise on their head where the book bounced off."
                                                              -- Jeff Atwood

v4sw7LMYRhw5ln7pr5Fck4ma3u7OSLw2Gm3l7OArchi6e0t5Tb8/en7g6aI!sr9p-2/-4 hackerkey.com

Re: [Pyblosxom-devel] error handling, logging, debugging and trouble-shooting

[will kahn-g. <wi...@bl...>]

On 04/02/2011 12:13 PM, Dieter Plaetinck wrote:
> On Sat, 02 Apr 2011 12:02:20 -0400
> will kahn-greene <wi...@bl...> wrote:
> 
>> verification
>> ------------
>>
>> We added some configuration verification stuff to PyBlosxom which you
>> can run on the command line.  This enables PyBlosxom to tell you what's
>> horribly wrong with your config.py file and also ask plugins to do the
>> same.  The problem here is two-fold:
>>
>> 1. since it's run from the command line and not the web-server, this
>> can't point out any permissions issues
> 
> this can be solved by telling users "when you do a verification on commandline, be sure to run it as the same user your web process runs as"; if they have any problem with this, I would classify it as PEBKAC

That only works if you have access to the account the server runs under,
so I think we should do more.


>> 2. Change logging so that it:
>>
>> 2.1. always logs to stderr
> Why would you do this?
> stderr is for errors and warnings. regular output should go stdout.
> I don't like it when software violates this.  If you have a restriction like "cannot use stdout because that's for page content in CGI, or something like that" , still only use stderr for errors/warnings, if you want to log regular things but you can't use stdout, use a logfile.

Sorry about that--I wasn't very clear here.  This email is about
trouble-shooting, so I'm just talking about logging that is
error/warning based.

/will

Re: [Pyblosxom-devel] error handling, logging, debugging and trouble-shooting

[Dieter P. <di...@pl...>]

On Sat, 02 Apr 2011 12:02:20 -0400
will kahn-greene <wi...@bl...> wrote:

> verification
> ------------
> 
> We added some configuration verification stuff to PyBlosxom which you
> can run on the command line.  This enables PyBlosxom to tell you what's
> horribly wrong with your config.py file and also ask plugins to do the
> same.  The problem here is two-fold:
> 
> 1. since it's run from the command line and not the web-server, this
> can't point out any permissions issues

this can be solved by telling users "when you do a verification on commandline, be sure to run it as the same user your web process runs as"; if they have any problem with this, I would classify it as PEBKAC


> 2. Change logging so that it:
> 
> 2.1. always logs to stderr
Why would you do this?
stderr is for errors and warnings. regular output should go stdout.
I don't like it when software violates this.  If you have a restriction like "cannot use stdout because that's for page content in CGI, or something like that" , still only use stderr for errors/warnings, if you want to log regular things but you can't use stdout, use a logfile.

> I bring this up now because I'm increasingly of the mind that problems
> with troubleshooting are awful enough that we should alleviate some of
> them for 1.5.  Amongst other things, it helps us solve a bunch of other
> problems more easily. 

Agreed bigtime: as a newcomer who jumped into 1.5 right away, I can tell you figuring out issues was (and still is) a big pain. The good news is, we can only improve ;)

Dieter

[Pyblosxom-devel] error handling, logging, debugging and trouble-shooting

[will kahn-g. <wi...@bl...>]

The Summary
===========

There have been several people hopping on IRC that have problems with
PyBlosxom that are difficult to debug since all they see is a really
helpful error message kind of like this one:

   A server error occurred


Some of us know that that's probably an HTTP 500 error page from the
web-server.  Other than that, we know nothing about what happened, what
the circumstances were, or anything else that would be useful to solve
the problem.


The problem
===========

cgitb
-----

First step I suggest when helping people trouble-shoot is to enable
cgitb.  There's a line in pyblosxom.cgi that you can uncomment that
enables this.  Enabling cgitb causes cgitb to bind to the
sys.excepthook.  When an unhandled exception occurs, then cgitb does its
thing and shows some useful information.  Several problems with this:

1. since it's in pyblosxom.cgi, it's useless for people who don't run
PyBlosxom as a CGI script

2. the information is useful for developers and useless to everyone else

3. there's no helpful information about what to do if you encounter a
problem or even where the problem might lie (core?  plugins? ...)

4. you only get the context at the point where PyBlosxom died--that may
or may not be the origin of the actual problem


logging
-------

Moving along, PyBlosxom also has some logging infrastructure.  Neil has
been kind enough to go look at this in detail because, as many have
pointed out, it doesn't actually seem to log anything.  There's a bunch
of logging infrastructure code in Pyblosxom/tools.py, but neither
PyBlosxom nor the plugins actually do any logging.  So problems with this:

1. nothing seems to do any actual logging

2. the logging code doesn't look threadsafe because it's using a global
cache


verification
------------

We added some configuration verification stuff to PyBlosxom which you
can run on the command line.  This enables PyBlosxom to tell you what's
horribly wrong with your config.py file and also ask plugins to do the
same.  The problem here is two-fold:

1. since it's run from the command line and not the web-server, this
can't point out any permissions issues

2. most plugins don't implement verify_installation


Solutions?
==========

So, I think we can all read that and come to the same conclusion: the
situation sucks.  Amongst other things, it makes it really difficult to
write an effective troubleshooting chapter for the PyBlosxom User Manual.

I'm tossing around the following things:

1. Write our own exception hook that we can bind at the relevant entry
points.  By doing this, we can be clever about the running context, we
make the output PyBlosxom-specific, and we can direct people to the
forums where we can help them.

2. Change logging so that it:

2.1. always logs to stderr
2.2. optionally logs to a log file
2.3. has less "clever" infrastructure overhead
2.4. keeps track of the last x logged items to display in the except hook

3. Somehow rework the verify_installation stuff to be easier.  At a
minimum, it should verify that required configuration parameters exist
and this should be easy to add for a plugin developer.


I bring this up now because I'm increasingly of the mind that problems
with troubleshooting are awful enough that we should alleviate some of
them for 1.5.  Amongst other things, it helps us solve a bunch of other
problems more easily.  Also, I think solution 1 is easy to implement (an
hour or two) and 2 might be, too.

Any thoughts on these?  Do these solutions seem like a good idea?

/will

Re: [Pyblosxom-devel] pyblosxom logging

[Dieter P. <di...@pl...>]

On Sat, 2 Apr 2011 14:04:34 +0800
Neil Santos <nei...@us...> wrote:

> I'm a big fan of Python's logging module).

you can do some cool things with it, but it's way too complicated imho.
surprisingly so for a python module.

Dieter

[Pyblosxom-devel] pyblosxom logging

[Neil S. <nei...@us...>]

As I mentioned in IRC, as it is, there's nothing really wrong in
pyblosxom's logging--that is, the foundation's pretty much
rock-solid (if you can't tell, I'm a big fan of Python's logging
module).

Most of the problem, as it relates to the bug jordi has been
encountering, lies with plugins.  I've noticed that most plugins
don't do any logging at all: in fact, most don't do any
error-handling *at all*.  Having written a few plugins myself,
I'm also guilty of this.

At the moment, I can't decide between diving into the existing
comments plugin and liberally adding support for logging, and
just getting off of my lazy bum and write my own comments plugin,
one which will easier to understand (for me, anyway).

I've still a few days left to lounge around, before I forced by
circumstances to *really* look for a job.  I'll see what I come
up with.

In any case, if anyone should decide to tackle the existing
comments plugin, you ought to add "properly supporting logging"
to your to-do list.

Welp, it's *really* early (for me, anyway); I should probably get
something to eat first.

Later, guys.  Stay frosty.
-- 
Neil Santos
Disgruntled Paradigms :: Code Monkey  //  Doing software The Right Way(TM)

[HTTP] neil.diosa.ph :: [XMPP] ne...@xm... :: [Y!M] neil_santos18

"Throwing a book of rules at a terrible programmer just creates a terrible
 programmer with a bruise on their head where the book bounced off."
                                                              -- Jeff Atwood

v4sw7LMYRhw5ln7pr5Fck4ma3u7OSLw2Gm3l7OArchi6e0t5Tb8/en7g6aI!sr9p-2/-4 hackerkey.com

Re: [Pyblosxom-devel] Thoughts on static rendering

[will kahn-g. <wi...@bl...>]

On 04/01/2011 09:48 AM, seanh wrote:
> Currently the static rendering docs tell you to write a script that
> deletes old files from static_dir after rendering incrementally, and
> that copies files not rendered by pyblosxom into static_dir. I wonder if
> it might be worth creating a feature request issue to improve static
> rendering. How simple would it be to make pyblosxom handle this
> automatically?
> 
> Add an option config.py setting py["static_files"] that should point to
> a directory containing files not rendered by pyblosxom (images, CSS...)
> that should be copied into static_dir after static rendering.

I think this is interesting and it should be a small change.  So I'm +1
on doing this.  It's worth adding an issue to the tracker and working on
a patch.


> When running `pyblosxom-cmd staticrender` pyblosxom could:
> 
> 1. Recursively delete the contents of static_dir.
> 2. Render blog files into static dir.
> 3. Recursively copy the contents of static_files into static_dir.
> 
> When running `pyblosxom-cmd staticrender --incremental` it would skip
> step 1 and do steps 2 and 3 incrementally. For step 3, recursively walk
> static_files and compare each file to its counterpart in static_dir. If
> the counterpart is older or does not exist, then copy the file over.
> As long as you have only added and modified files then you can just
> render incrementally, if you've deleted files or moved files you'd need
> to render the whole thing again.
> 
> It might be possible to simplify it even more ... If pyblosxom could
> automatically detect when it needs to render the whole thing and just do
> it.

I'm kind of -0 on doing this.  It adds more work and to core maintenance
to save a line or two in a script for a user.

/will

Re: [Pyblosxom-devel] Thoughts on pyblosxom-cmd

[will kahn-g. <wi...@bl...>]

On 04/01/2011 09:38 AM, seanh wrote:
> 1. Is there a reason why the command is pyblosxom-cmd and not just
> pyblosxom?

Yes.  It was originally pyblcmd or something short like that, but I
decided it's better to make it unambiguous.  If people use it a lot,
they can always alias it.


> 2. Can `paster serve blog.ini` be integrated into pyblosxom-cmd?
> Something like `pyblosxom-cmd serve`.
> 
> If it can't work because paster is not installed it should print out a
> helpful message saying paster is not installed, try `sudo pip install
> PasteDeploy` (or whatever is should be).
> 
> And the command would not to be run inside a pyblosxom blog dir with a
> blog.ini and config.py (or perhaps a subdirectory thereof), otherwise it
> would print out a helpful message explaining so.
> 
> Optional command-line option to specify the blog directory to use
> instead of the current working directory.

There's a commandline callback.  I'd love to implement this as a plugin
to get the details right.  If it's good, I'd be game for adding it to
the core code (not as a plugin--but actually as core code).

It might not have to use paster, either.  It might work fine with stdlib
stuff.  This might be a compelling reason to up the python version
requirement again.

/will

[Pyblosxom-devel] Thoughts on static rendering

[seanh <sn...@gm...>]

Currently the static rendering docs tell you to write a script that
deletes old files from static_dir after rendering incrementally, and
that copies files not rendered by pyblosxom into static_dir. I wonder if
it might be worth creating a feature request issue to improve static
rendering. How simple would it be to make pyblosxom handle this
automatically?

Add an option config.py setting py["static_files"] that should point to
a directory containing files not rendered by pyblosxom (images, CSS...)
that should be copied into static_dir after static rendering.

When running `pyblosxom-cmd staticrender` pyblosxom could:

1. Recursively delete the contents of static_dir.
2. Render blog files into static dir.
3. Recursively copy the contents of static_files into static_dir.

When running `pyblosxom-cmd staticrender --incremental` it would skip
step 1 and do steps 2 and 3 incrementally. For step 3, recursively walk
static_files and compare each file to its counterpart in static_dir. If
the counterpart is older or does not exist, then copy the file over.
As long as you have only added and modified files then you can just
render incrementally, if you've deleted files or moved files you'd need
to render the whole thing again.

It might be possible to simplify it even more ... If pyblosxom could
automatically detect when it needs to render the whole thing and just do
it.

If we did this we should rename the config.py variables as static_files
and static_dir are not very clear. I suggest something like
static_outdir and static_filesdir.

[Pyblosxom-devel] Thoughts on pyblosxom-cmd

[seanh <sn...@gm...>]

1. Is there a reason why the command is pyblosxom-cmd and not just
pyblosxom?

2. Can `paster serve blog.ini` be integrated into pyblosxom-cmd?
Something like `pyblosxom-cmd serve`.

If it can't work because paster is not installed it should print out a
helpful message saying paster is not installed, try `sudo pip install
PasteDeploy` (or whatever is should be).

And the command would not to be run inside a pyblosxom blog dir with a
blog.ini and config.py (or perhaps a subdirectory thereof), otherwise it
would print out a helpful message explaining so.

Optional command-line option to specify the blog directory to use
instead of the current working directory.

[Pyblosxom-devel] xmlrpc_pingback and the data dict in 1.5

[Toby S. <tob...@gm...>]

Hi all,

I'm trying to get a site up under pyblosxom 1.5, and it seems
xmlrpc_pingback from git chokes in the fileFor method on calling at
least blosxom_file_list_handler, because the data dict that fileFor
gets from the Request object doesn't contain fileds like "bl_type" or
"root_datadir" which blosxom_file_list_handler expect. I'm not really
sufficiently au fait with the processing stream to know how to get the
root_datadir back into the dict, and though I can quite easily patch
xmlrpc_pingback.py to guess bl_type, doing so with root_datadir seems
more tricky if I want to keep it portable.

Is anyone else successfully using xmlrpc_pingback?

Cheers,

-- 
Toby Smithe

Re: [Pyblosxom-devel] new site pushed

[seanh <sn...@gm...>]

On Fri, Mar 18, 2011 at 10:42:15PM -0400, will kahn-greene wrote:
> 1. we need to finish up changes to the documentation, then compile that
> and push it to the site -- Sean has done a ton of stuff and I haven't
> caught up with looking through those changes, yet.

There is still much more that could be done to improve the
documentation, but I think I'll give it a rest for now and wait for you
to catch up with my commits. I'm not sure how far along you are with
accepting/rejecting/modifying them.

> 2. we need to finish up updating the plugin registry
> 
> 3. we need to finish up updating the flavour registry

Is the plan to move both of these to the coming pyblosxom wiki? If so I
think it might be good to setup the wiki first then we can update the
registries as we move them over to the wiki. I noticed the gitorious has
built-in wikis, but I haven't tried it out to see if it might be
suitable.

The main thing that I think the new website needs is for the news posts
to be on the front page. Currently there is nothing on the front page
for people who are re-visiting the site rather than visiting it for the
first time, and there's nothing to immediately tell people what's new.
Having the full contents of the posts on the front page would be too
long, but maybe it could have just the titles of the three most recent
posts, or titles and previews/summaries, linked to the full posts. This
might fit into the sidebar. There's a good example of this on the
banshee site: http://banshee.fm/

Re: [Pyblosxom-devel] new site pushed

[Dieter P. <di...@pl...>]

On Sat, 19 Mar 2011 16:56:08 -0400
will kahn-greene <wi...@bl...> wrote:

> I'm also not sure that the "readable without scrolling" rule is
> compelling.  What's the motivation for that rule?

my reasoning was: if you add links to that information in the menu, you should remove it from the home page, otherwise there would be some redundancy - which in my case always causes confusion, which is a bad thing.  Example: when the frontpage has a section "IRC" but the menu also has a link "irc" I will wonder if they point to different information, and if so, which one is the most useful/up-to-date; i will have a click glance at the irc info, then click the link and see what happens.
all this mental overhead can be avoided by removing all redundancy. (and it makes the page a tiny bit simpler as well)

However, I think your goal of having all critical on the homepage is nice too. so just ignore me, first of all, I don't know what I'm talking about, and even if i was this can debated endlessly with very little possible benefit, your way is fine.

> I would definitely be interested in project pages you find compelling as
> well as what requirements you (or anyone else reading this email) think
> a project front page should have.

I like http://uzbl.org/ , nearly all the content there is generated from the documentation within the project, and I find it easy to navigate.
but that doesn't mean you should do it like that. I don't know much about UX.

Dieter

Re: [Pyblosxom-devel] new site pushed

[will kahn-g. <wi...@bl...>]

On 03/19/2011 06:19 AM, Dieter Plaetinck wrote:
> On Fri, 18 Mar 2011 22:42:15 -0400
> will kahn-greene <wi...@bl...> wrote:
> 
> the links "report bug" / "request feature" point to the same. why not just one link "bugtracker"
> or maybe "bugs / tickets" but I think 'bugtracker' is clear to everyone that it also includes feature requests and/or misc tickets.

That makes a lot of sense.  Fixed!


>> 1. the features list on the front page -- are there other things we
>> should mention?  things we shouldn't mention?
> 
> * the last line basically repeats the 2nd point. imho remove it entirely.

You're right!  Fixed!


> * "works with blog standards" -> maybe mention this is done through templates so that people don't think the core has bloat for that built-in.

I'm going to be a bit hard here, but bear with me.  I think the "bloat"
word is overused and really means "the software has code for things I
don't use" which is true of all software for all people.  If people
think that of a file-based blogging system and it's a turn off, then
they're not the sort of people I want to deal with anyhow.  I'm pretty
ok with them not using PyBlosxom.  So there's that.

I think it's important that PyBlosxom works with blog standards, so I
think that should be in the list.  However, it really should include
feeds as well as some of the other standard blog things like pingbacks,
trackbacks and things like that.  PyBlosxom has plugins for those, but I
have no idea if they work anymore and even if they did, they should
probably get re-written to use 1.5 awesome-happy-goodness.  So while
this is in the list, I think we're actually kind of failing on this front.

I think I want to leave it for now, but recognize that this line is
debatable.

I'd also be interested in whether there are other blog standards that we
should be supporting.  What is PyBlosxom missing to interoperate better
with other blog systems?


>> 2. the quick start section on the front page -- it's slightly more
>> complicated than these steps, so I wasn't sure whether to include them
>> or not, but I really like the idea of having a quick start
> 
> instead of [ edit config.py ]
> you could put $ $EDITOR config.py

I thought about this for a while and I think I prefer the "[ edit
config.py ]" since it's a general instruction even though it doesn't fit
in with the other things which are shell commands.

I'm not sure it's true that all people have an $EDITOR environment
variable.  So I think changing it to "$EDITOR config.py" possibly makes
it applicable to fewer people.


>> 3. the "how to send us a patch" section on the development page -- do
>> those instructions look adequate?  how would you improve them?
> 
> * has a typo commet -> commit

Oops!  Fixed!


> * an alternative for patches is pushing commits to gitorious (or any other public git repository) and issuing a pull request (in the latter case, a pull request is basically a mail saying "please pull from that repo/branch")
> looks ok otherwise.

I really dislike the gitorious merge request thing.  I know you didn't
mention that, but I'll just put it out there.  It's entirely possible
I'd like it more if I could figure out how the damn thing works without
picking up all patches everywhere.

Pull requests are interesting, too, but they require that someone's
clone is in a public place that I can pull from.  I think just talking
about git format-patch is a lower common denominator, so I think I just
want to go with that.


>> 4. the navigation items in the sidebar -- is it saner than it was
>> before?  are there better names for some of the sections that we should use?
> 
> * you can put me on the pyblosxom users page. my blog is @
> http://dieter.plaetinck.be/

Added!


> * the section "documentation" with 2 subitems, one of them being "documentation" is a bit weird.
> maybe append the two links to the upmost list (i.e. add them below the link to bugtracker)

Done!


> * users and registries could get their own title. like "Community". then, under
>   community you could put also a link "Get in touch" which contains the mailing
>   list and irc info. that might be a better place then the home page for it.
>   imho the home page should be short and focused. (readable without scrolling) so if you can get the
>   irc/mailing list info away from there.. maybe also remove the "Bugs/Features" section. after all there are links to that from the main menu.

I put them in a Community section and added links for the two mailing
lists and IRC.  I have them link to the respective sections on the front
page.

One of the things I really want to do is bring together all the critical
bits of information someone needs to know.  So from the front page,
someone ought to be able to:

1. evaluate pyblosxom in regards to whether they should use it
2. find information about mailing lists and irc
3. download the software
4. get the source code
5. report bugs/features
6. contribute patches

Those are the critical actions that encompass the human side of the
project.  I want to experiment with putting all these things on the
front page rather than separate them out into a few different places.

I'm also not sure that the "readable without scrolling" rule is
compelling.  What's the motivation for that rule?

I would definitely be interested in project pages you find compelling as
well as what requirements you (or anyone else reading this email) think
a project front page should have.

/will

Re: [Pyblosxom-devel] new site pushed

[Dieter P. <di...@pl...>]

On Fri, 18 Mar 2011 22:42:15 -0400
will kahn-greene <wi...@bl...> wrote:

> I reworked a ton of content on the web-site, removed a bunch of stuff,
> added some new things, and reorganized everything.
> 
> http://pyblosxom.bluesock.org/
> 
> There are some outstanding things that need to be done:
> 
> 1. we need to finish up changes to the documentation, then compile that
> and push it to the site -- Sean has done a ton of stuff and I haven't
> caught up with looking through those changes, yet.
> 
> 2. we need to finish up updating the plugin registry
> 
> 3. we need to finish up updating the flavour registry
> 
> 
> After that, I think the web-site is good enough to do a 1.5 release.
> After 1.5 we should talk about other things we can do to improve the
> site.  Improving the look-and-feel is probably a good thing to work on.
> 
> 
> I'd love to hear people's thoughts and whether there are other critical
> things we should improve now. 

the links "report bug" / "request feature" point to the same. why not just one link "bugtracker"
or maybe "bugs / tickets" but I think 'bugtracker' is clear to everyone that it also includes feature requests and/or misc tickets.


> 
> 1. the features list on the front page -- are there other things we
> should mention?  things we shouldn't mention?

* the last line basically repeats the 2nd point. imho remove it entirely.
* "works with blog standards" -> maybe mention this is done through templates so that people don't think the core has bloat for that built-in.
* otherwise I think this bullet list is very accurate and clear.

> 2. the quick start section on the front page -- it's slightly more
> complicated than these steps, so I wasn't sure whether to include them
> or not, but I really like the idea of having a quick start

instead of [ edit config.py ]
you could put $ $EDITOR config.py


> 3. the "how to send us a patch" section on the development page -- do
> those instructions look adequate?  how would you improve them?

* has a typo commet -> commit

* an alternative for patches is pushing commits to gitorious (or any other public git repository) and issuing a pull request (in the latter case, a pull request is basically a mail saying "please pull from that repo/branch")
looks ok otherwise.

> 4. the navigation items in the sidebar -- is it saner than it was
> before?  are there better names for some of the sections that we should use?

* you can put me on the pyblosxom users page. my blog is @
http://dieter.plaetinck.be/
* the section "documentation" with 2 subitems, one of them being "documentation" is a bit weird.
maybe append the two links to the upmost list (i.e. add them below the link to bugtracker)
* users and registries could get their own title. like "Community". then, under
  community you could put also a link "Get in touch" which contains the mailing
  list and irc info. that might be a better place then the home page for it.
  imho the home page should be short and focused. (readable without scrolling) so if you can get the
  irc/mailing list info away from there.. maybe also remove the "Bugs/Features" section. after all there are links to that from the main menu.

Dieter

Re: [Pyblosxom-devel] sprint week recap -- it's over, but we still need your help!

[will kahn-g. <wi...@bl...>]

Awesome!  Thank you so much!

I'll take a look at these in the next day or two.


On 03/18/2011 08:33 PM, Mikko Varri wrote:
> On Thu, Mar 17, 2011 at 09:40:30PM -0400, will kahn-greene wrote:
>>
>> Things I still need help with:
>>
>> 2. Running the unit tests.
>>
> 
> Hi Will,
> 
> 
> I ran the unit tests on Slackware64 13.37rc2 and noticed that two
> tests were failing.  Both turned out to be time zone dependent, so I
> fixed the tests instead of the code under test.  You can see the
> change in my pyblosxom clone[1], change 8edfe5b[2].
> 
> There's a couple of other changes, too, but they are not fixing any
> functionality.  Change 37c5602[3] is about a bit of documentation, and
> c09e5e8[4] moves the 'w3cdate' definition out of the setlocale scope.
> 
> [1] http://gitorious.org/~vmj/pyblosxom/vmjs-pyblosxom/commits/master
> 
> [2] http://gitorious.org/~vmj/pyblosxom/vmjs-pyblosxom/commit/8edfe5bba57796db24f54baea4bc3d3194400789
> 
> [3] http://gitorious.org/~vmj/pyblosxom/vmjs-pyblosxom/commit/37c5602747d8e37e5713e4bad41a1494c2aeceb9
> 
> [4] http://gitorious.org/~vmj/pyblosxom/vmjs-pyblosxom/commit/c09e5e83688a679aea687f73e702e49132a1debb
> 
> 
> -vmj
> 
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Pyblosxom-devel mailing list
> Pyb...@li...
> https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel
> 

[Pyblosxom-devel] new site pushed

[will kahn-g. <wi...@bl...>]

I reworked a ton of content on the web-site, removed a bunch of stuff,
added some new things, and reorganized everything.

http://pyblosxom.bluesock.org/

There are some outstanding things that need to be done:

1. we need to finish up changes to the documentation, then compile that
and push it to the site -- Sean has done a ton of stuff and I haven't
caught up with looking through those changes, yet.

2. we need to finish up updating the plugin registry

3. we need to finish up updating the flavour registry


After that, I think the web-site is good enough to do a 1.5 release.
After 1.5 we should talk about other things we can do to improve the
site.  Improving the look-and-feel is probably a good thing to work on.


I'd love to hear people's thoughts and whether there are other critical
things we should improve now.  Particularly on the following things:

1. the features list on the front page -- are there other things we
should mention?  things we shouldn't mention?

2. the quick start section on the front page -- it's slightly more
complicated than these steps, so I wasn't sure whether to include them
or not, but I really like the idea of having a quick start

3. the "how to send us a patch" section on the development page -- do
those instructions look adequate?  how would you improve them?

4. the navigation items in the sidebar -- is it saner than it was
before?  are there better names for some of the sections that we should use?


I've pushed all the changes to the pyblosxom-web repository.  Many
thanks to Sean and Dieter for their thoughts and feedback so far.

/will

Re: [Pyblosxom-devel] sprint week recap -- it's over, but we still need your help!

[Mikko V. <vm...@li...>]

On Thu, Mar 17, 2011 at 09:40:30PM -0400, will kahn-greene wrote:
> 
> Things I still need help with:
> 
> 2. Running the unit tests.
> 

Hi Will,


I ran the unit tests on Slackware64 13.37rc2 and noticed that two
tests were failing.  Both turned out to be time zone dependent, so I
fixed the tests instead of the code under test.  You can see the
change in my pyblosxom clone[1], change 8edfe5b[2].

There's a couple of other changes, too, but they are not fixing any
functionality.  Change 37c5602[3] is about a bit of documentation, and
c09e5e8[4] moves the 'w3cdate' definition out of the setlocale scope.

[1] http://gitorious.org/~vmj/pyblosxom/vmjs-pyblosxom/commits/master

[2] http://gitorious.org/~vmj/pyblosxom/vmjs-pyblosxom/commit/8edfe5bba57796db24f54baea4bc3d3194400789

[3] http://gitorious.org/~vmj/pyblosxom/vmjs-pyblosxom/commit/37c5602747d8e37e5713e4bad41a1494c2aeceb9

[4] http://gitorious.org/~vmj/pyblosxom/vmjs-pyblosxom/commit/c09e5e83688a679aea687f73e702e49132a1debb


-vmj

Re: [Pyblosxom-devel] sprint week recap -- it's over, but we still need your help!

[will kahn-g. <wi...@bl...>]

Yes!  We've actually been using `reST`_ and `Sphinx`_ for a while, but
occasionally there are typos like the below that need to be fixed.

I occasionally even use it in email!

.. reST: http://docutils.sourceforge.net/rst.html
.. Sphinx: http://sphinx.pocoo.org/


On 03/18/2011 09:34 AM, Dieter Plaetinck wrote:
> On Fri, 18 Mar 2011 19:31:57 +0800
> Neil Santos <nei...@us...> wrote:
> 
>> On Fri, Mar 18, 2011 at 09:40, will kahn-greene <wi...@bl...> wrote:
>>
>>> Things I still need help with:
>>>
>>> 1. Testing PyBlosxom 1.5 in git works on your blog.
>>
>> I can confirm that 1.5-git works on my blog (I plan on running it
>> solely using bleeding edge code--provided it checks out on my local
>> dev setup first, of course).
> 
> i also updated my dev and production setup to the latest git code. seems to works fine.
> 
> i was kinda surprised to see the newly introduced usage of '::', i.e. changes like:
> 
> -Here's an example of what to put in config.py:
> +Here's an example of what to put in config.py::
> 
> Is this because we use RST as described on
> http://www.python.org/dev/peps/pep-0316/ ?
> 
> Dieter

Re: [Pyblosxom-devel] sprint week recap -- it's over, but we still need your help!

[Dieter P. <di...@pl...>]

On Fri, 18 Mar 2011 19:31:57 +0800
Neil Santos <nei...@us...> wrote:

> On Fri, Mar 18, 2011 at 09:40, will kahn-greene <wi...@bl...> wrote:
> 
> > Things I still need help with:
> >
> > 1. Testing PyBlosxom 1.5 in git works on your blog.
> 
> I can confirm that 1.5-git works on my blog (I plan on running it
> solely using bleeding edge code--provided it checks out on my local
> dev setup first, of course).

i also updated my dev and production setup to the latest git code. seems to works fine.

i was kinda surprised to see the newly introduced usage of '::', i.e. changes like:

-Here's an example of what to put in config.py:
+Here's an example of what to put in config.py::

Is this because we use RST as described on
http://www.python.org/dev/peps/pep-0316/ ?

Dieter

Re: [Pyblosxom-devel] sprint week recap -- it's over, but we still need your help!

[Neil S. <nei...@us...>]

On Fri, Mar 18, 2011 at 09:40, will kahn-greene <wi...@bl...> wrote:

> Things I still need help with:
>
> 3. Going through the bugs in the 1.5 milestone and triaging the ones I
> pulled from SourceForge.  You can recognize them because they have "ID:"
> in the title.  This is mostly a testing and triaging exercise.

In the interests of getting my feet wet, here's a minor fix for issue
29 on the tracker:

http://dollhouse.diosa.ph/cgit/cgit.cgi/pyblosxom/commit/?id=48d8d0080b652a38aaff2998fed00e131c255dbb

Sorry, couldn't figure out how to add a new note to the bug report. :P
-- 
Neil Santos
Disgruntled Paradigms :: Code Monkey  //  Doing software The Right Way(TM)

[Web] neil.diosa.ph :: [MSN] nei...@ho... :: [Y!M] neil_santos18
v4sw7LMYRhw5ln7pr5Fck4ma3u7OSLw5Gm3g/l7SL/i6e0t4Vb8en7g5aI!sr9p-2/-4
hackerkey.com

Re: [Pyblosxom-devel] sprint week recap -- it's over, but we still need your help!

[Neil S. <nei...@us...>]

On Fri, Mar 18, 2011 at 09:40, will kahn-greene <wi...@bl...> wrote:

> Things I still need help with:
>
> 1. Testing PyBlosxom 1.5 in git works on your blog.

I can confirm that 1.5-git works on my blog (I plan on running it
solely using bleeding edge code--provided it checks out on my local
dev setup first, of course).
-- 
Neil Santos
Disgruntled Paradigms :: Code Monkey  //  Doing software The Right Way(TM)

[Web] neil.diosa.ph :: [MSN] nei...@ho... :: [Y!M] neil_santos18
v4sw7LMYRhw5ln7pr5Fck4ma3u7OSLw5Gm3g/l7SL/i6e0t4Vb8en7g5aI!sr9p-2/-4
hackerkey.com

[Pyblosxom-devel] sprint week recap -- it's over, but we still need your help!

[will kahn-g. <wi...@bl...>]

I had a really busy day and didn't get as much done as I wanted.

I think the sprint week went really well.  Looks like we spent a lot of
time on the web-site and on documentation with some time on a few other
things.

I also helped someone upgrade from a 1.4.something to a 1.5-git blog and
that went swimmingly.

The 1.5 milestone has grown, but I'm feeling pretty good about it
nonetheless.

I'm currently working on factoring Dieter's and Sean's thoughts on the
web-site into a web-site overhaul.  I think doing a chunk of this before
a 1.5 release is important since it's the best way to find plugins and
documentation.  Having a sucky web-site sucks.

A couple of days ago, I said I'd throw together an outline for the new
site, send it to the list, and then we could banter it about.  I'm
thinking instead I'm going to throw a new site together that's "good
enough" and fixes the egregious issues the current one has.  Then I'll
move on to other things blocking the 1.5 release.  After 1.5 is out, we
can go back and properly work through the web-site as a group.

Things I still need help with:

1. Testing PyBlosxom 1.5 in git works on your blog.

2. Running the unit tests.

3. Going through the bugs in the 1.5 milestone and triaging the ones I
pulled from SourceForge.  You can recognize them because they have "ID:"
in the title.  This is mostly a testing and triaging exercise.


While the sprint week is over, we still haven't released 1.5.  Any help
towards that laudable goal is immensely appreciated!

/will

Re: [Pyblosxom-devel] pyblosxom 1.5 sprint week: status (saturday)

[seanh <sn...@gm...>]

> Weird.  I really thought there was a contact page on the web-site in the
> sidebar, but it's not there.

There is a 'mailing lists' link in the sidebar, it links to a page
titled 'Contact Us' with links to the lists and bug tracker. The link
should be renamed to "Contact Us" perhaps with "Mailing lists,
IRC channel, issue tracker" as subtitle or tooltip.

But the website _should not_ have its own contact page! Since there is
already a contact page in the docs, and there is an online copy of the
docs on the website, the 'Contact Us' link on the website front page
should just link directly to the Contact Us page in the online copy of
the documentation. Don't duplicate information. Things will be much
easier to navigate if there is just one place to go to for each piece of
info, and if there are multiple copies then they will get out of sync
and then people will not know which is right.

Duplication of content between the website and the documentation has
been bothering me. I think the solution is to move information into the
docs and to put links on the website front page to particular pages in
the docs. That way the info is both on the website and in the pyblosxom
download, yet there is only one copy of it to maintain and for users to
read.

Another example of this is the "What is PyBlosxom?" page of the website
and the "About PyBlosxom" page in the docs. They contain two different
but overlapping answers to the same question. Delete the web page, and
link to the section in the docs instead.

I think the website could become merely a blog (the "news" page)
without any static pages of its own. It should have links in the sidebar
to certain pages in the online copy of the docs (contact, about
pyblosxom), to the issue tracker, and when it exists to the wiki and
certain pages of the wiki (the list of pyblosxom users and the flavour
and plugin registries should be moved to the wiki).

I'm not sure that the references/specs and colophon pages are worth
keeping. Perhaps they should be moved to the wiki also.

The development howto page belongs in the documentation.

Keep the git repositories link of course, but move it under the Download
heading in the sidebar alongside the tar.gz link(s).

At the top of the sidebar there should be a link titled 'PyBlosxom' or
'Home' or something that links back to the front page of the site.
Replace the 'Contents' title.

> 
> There's a bit in the PyBlosxom documentation:
> 
> http://pyblosxom.bluesock.org/1.5/about_pyblosxom.html#project-details-contact-information-and-where-to-go-for-help
> 
> I'll grab your paragraph plus those bits and throw together a contact page.
> 
> What else is missing?
> 
> Also, on a related note, what other projects have good web-sites that we
> could emulate?
> 
> 
> On 03/13/2011 04:11 AM, Sebastian Spaeth wrote:
> > On Sat, 12 Mar 2011 23:04:55 -0500, will kahn-greene <wi...@bl...> wrote:
> >> I'm really psyched to see things happening in the issue tracker.  I've
> >> been doing A/V work and haven't had time to do PyBlosxom work.  However,
> >> I met another PyBlosxom user here and he's interested in doing 1.5 work
> >> on Monday.  Thus, I'm planning to do a bunch of PyBlosxom work then.
> >>
> >> One of the things I'm going to tackle on Monday is the web-site.  It
> >> sucks.  It should be way better.  At a bare minimum, it shouldn't be so
> >> horribly wrong about everything.
> > 
> > One thing I was searching for lately, is the IRC channel of
> > pyblosxom. This might be good info eg on the Mailling list
> > page. Something like:
> > 
> > If you prefer more direct communication, there are often some people
> > hanging out on the IRC channel #pyb...@ch.... However,
> > sometimes no one is listening or reading the channel for hours, so if
> > you come over to say hello, be patient.
> > 
> > would already help. Thanks :)
> > Sebastian
> 
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> Pyblosxom-devel mailing list
> Pyb...@li...
> https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel

Re: [Pyblosxom-devel] pyblosxom 1.5 sprint week: status (saturday)

[will kahn-g. <wi...@bl...>]

Weird.  I really thought there was a contact page on the web-site in the
sidebar, but it's not there.

There's a bit in the PyBlosxom documentation:

http://pyblosxom.bluesock.org/1.5/about_pyblosxom.html#project-details-contact-information-and-where-to-go-for-help

I'll grab your paragraph plus those bits and throw together a contact page.

What else is missing?

Also, on a related note, what other projects have good web-sites that we
could emulate?


On 03/13/2011 04:11 AM, Sebastian Spaeth wrote:
> On Sat, 12 Mar 2011 23:04:55 -0500, will kahn-greene <wi...@bl...> wrote:
>> I'm really psyched to see things happening in the issue tracker.  I've
>> been doing A/V work and haven't had time to do PyBlosxom work.  However,
>> I met another PyBlosxom user here and he's interested in doing 1.5 work
>> on Monday.  Thus, I'm planning to do a bunch of PyBlosxom work then.
>>
>> One of the things I'm going to tackle on Monday is the web-site.  It
>> sucks.  It should be way better.  At a bare minimum, it shouldn't be so
>> horribly wrong about everything.
> 
> One thing I was searching for lately, is the IRC channel of
> pyblosxom. This might be good info eg on the Mailling list
> page. Something like:
> 
> If you prefer more direct communication, there are often some people
> hanging out on the IRC channel #pyb...@ch.... However,
> sometimes no one is listening or reading the channel for hours, so if
> you come over to say hello, be patient.
> 
> would already help. Thanks :)
> Sebastian