http://blog.gmane.org/gmane.comp.web.pyblosxom.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.web.pyblosxom.devel/2388 <pre>Attached is a patch that enables pagination in static-rendering mode, pagination being the rendering of index pages which are longer than num_entries by writing them out to multiple pages, combined with the production of navigation strings which the user can include in the templates for those pages. Since: -- doing this as a plugin seemed somewhere between painful and impossible, and -- I think this really should be core functionality anyway, I went ahead and implemented the whole thing in the core. It should work for dynamic rendering, too (or whatever one calls the opposite of static rendering), but I haven't tested that mode. It is meant to supersede the present "paginate" plugin, but the latter should still work (again, untested). It uses all the same config variables, except for "paginate_count_from", which I thought was far too much in the bikeshedding direction to be worth saving. The variable "paginate_linkstyle" accepts, besides the old settings (0 or 1), the more descriptive settings "1 of 4" (same as style 1) or "1234" (same as style 0). For static rendering, instead of the page number being sent in the HTML query, as in http://example.com/blog/index.html?page=2 it has to be part of the filename, as in http://example.com/blog/index_page2.html which is now this change does it. I haven't yet fixed up the documentation to reflect the changes. (As for why I think this should be core functionality, I can't imagine anyone not wanting it, at least for normal weblog use.) </pre> Norman Yarvin 2012-03-16T09:03:34 http://comments.gmane.org/gmane.comp.web.pyblosxom.devel/2386 <pre> I worked through the remaining bugs sitting in the 1.5 milestone today. Now there are no more bugs sitting in the 1.5 milestone. If there's anything outstanding that I haven't finished up, let me know in the next two days. Barring any issues, I'm going to ship 1.5 next week. After 1.5 goes out, I'm going to spend some time moving interesting bugs to the issue tracker on github and then take a hiatus from Pyblosxom development for a while. I will continue to work through patches submitted by other people whether they code or docs or fixes to the website. /will ------------------------------------------------------------------------------ Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure </pre> Will Kahn-Greene 2011-12-17T15:17:37 http://comments.gmane.org/gmane.comp.web.pyblosxom.devel/2374 <pre> I updated the roundup package on bluesock (the server that hosts the Pyblosxom bug tracker) and inadvertently stomped on the fix I made to roundup. Then I started getting lots of error emails from roundup because it's "helpful". Took me about 30 minutes to figure out how I fixed it the last time and re-fix it. Irritating. That got me thinking. A while back, when we talked about switching to git and picking a host, I remember a lot of people said they already had github accounts. I picked gitorious because at the time is was close enough feature-wise and it was Free Software. I picked roundup because it seemed like a decent choice. At this point, I want to revisit those decisions. I'm thinking of moving things around in this way: 1. Move from gitorious to github. In doing this, we gain post-commit hooks some of which are wildly useful, an issue tracker, inline comments for pull requests, probably an order of magnitude more people who already have github accounts and who are used to drive-by-fixes, and probably some other github features I haven't yet discovered. 2. Move the Pyblosxom manual to ReadTheDocs. We're already using Sphinx. If we switch to github, then it's a post-commit hook to update it everytime something gets checked in. This would be really nice. 3. Ditch roundup and use the github issue tracker. After that we can see where things are at. Any thoughts on this? Is anyone against it? If not, I'm going to do this before releasing 1.5 since I want to update the urls everywhere. Hopefully before the end of this year. /will ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d </pre> Will Kahn-Greene 2011-11-24T00:20:23 http://comments.gmane.org/gmane.comp.web.pyblosxom.devel/2368 <pre> I just merged the 34-plugins branch into master. It seems fine. I could use more help testing it, though. I've made a lot of structural changes and updated the code for a lot of the plugins. If you have 10 minutes today or tomorrow, helping me test would help a lot. /will ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 </pre> Will Kahn-Greene 2011-11-05T14:31:14 http://comments.gmane.org/gmane.comp.web.pyblosxom.devel/2367 <pre>I nixed the pyblosxom-checkins list (we haven't used it in years) and the pyblosxom-announce list. In retrospect, I should have said something on each list before nixing it, but it's too late for that now. That leaves us with two lists: pyblosxom-users and pyblosxom-devel. I think that's good for now. /will ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 </pre> will kahn-greene 2011-11-04T13:46:56 http://comments.gmane.org/gmane.comp.web.pyblosxom.devel/2366 <pre> Hi all! I did a bunch of pyblosxom docs work over the last few days while I had no power through judicious use of battery life on my laptop. I'm feeling pretty good about doing a 1.5 final release soon. However, I really need some help with some things: 1. I did a massive overhaul of plugins and documentation in the 34-plugins branch that needs testing and a second set of eyes. Anyone who is interested in helping on this, just grab the 34-plugins branch and start testing and reading through the docs. 2. I need someone to do whatever it is you do with Freenode stuff to get the #pyblosxom channel registered so that we can get ops on it and change the topic and all that jazz. We only need one person to do this, so if someone is interested, let me know. 3. I need someone to triage bugs in the bug tracker. There are a bunch of bugs, some have been targeted at various milestones, but I don't really have a good sense of where things are at, what really needs to be in 1.5, what can be deferred and what's already done or isn't applicable any more. If someone is interested in helping on this, go for it. If you feel uncertain about making decisions, feel free to ping me on IRC with questions. It's helpful to even just look at the issues you've created and bump them with current status. Anyone who does anything, please reply to the list and let us know what you accomplished so that we can thank you and sing your praises! That's it for now! It's not glamorous work, but I really need the help moving through these things, otherwise Pyblosxom will continue at a glacial pace. I really want to get 1.5 out the door--it's a _HUGE_ improvement over 1.4 and it'll make everyone's lives so much easier. /will ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 </pre> Will Kahn-Greene 2011-11-03T00:20:49 http://comments.gmane.org/gmane.comp.web.pyblosxom.devel/2363 <pre> A while back, I (pretty sure it was me) moved things around and put PyBlosxom into the package Pyblosxom (upper-case P lower-case b). That's different than the project name which is PyBlosxom. In the Pyblosxom package is a pyblosxom module. In the pyblosxom module is a PyBlosxom class. Yes, seriously. The only good thing I can say is that at least there isn't a pYbLOSXOM in there, too. Anyhow, this is already a source of confusion, but the circumstances don't come up with enough frequency that I've decided to fix it. Until now.... The pain of the current situation increases now that I'm moving core plugins into the Pyblosxom package (yes--one more round of the hokey pokey with the location of the plugins). Because of this change, it's very likely that the confusion will cause problems for users since new users will be typing 'Pyblosxom.plugins.ladeedah' over and over again in the load_plugins list in their config.py files. Further, after I make this change to plugins, the pain of changing the package name goes up astronomically. So the time to fix it is now! I see two options: 1. Change the name of the project from PyBlosxom to Pyblosxom. Camel case is so 90s anyhow. This makes the package the same as the project name. Then we change the name of the PyBlosxom class to Pyblosxom and we're all set. This last bit shouldn't be much pain--only the internals really use the PyBlosxom class. 2. Change the name of the package from Pyblosxom to pyblosxom or PyBlosxom. This is a ton of pain because it means all plugins have to change. Because I'm pain-averse these days, I'm inclined to go with option 1 and change the name of the project to Pyblosxom. Does anyone object to a name change? Does anyone have a better solution or something related that we should mull over? /will ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct </pre> Will Kahn-Greene 2011-10-19T01:16:58 http://comments.gmane.org/gmane.comp.web.pyblosxom.devel/2358 <pre>Hi! I'm new to pyblosxom and I would like some clarification as to how mtimes work. As best as I understand, entries with an mtime later than today should not be displayed, whereas mtimes older than today should be displayed by the blog in decreasing order of date. Is this a correct understanding? If not, how can I help to make this happen, and in the meantime, what is the best way for me to write entries well in advance of their publish date? </pre> Mark David Dumlao 2011-08-28T15:15:27 http://comments.gmane.org/gmane.comp.web.pyblosxom.devel/2357 <pre>Release! ======== I just release PyBlosxom 1.5rc3. For changes, take a look at the What's new chapter: http://pyblosxom.bluesock.org/1.5/whatsnew.html Amongst other things, it continues to reduce the difficulties in configuring and debugging PyBlosxom and plugins. I encourage everyone to upgrade. Going forward ============= There are still problems that I'd like to sort out for 1.5, but this is another big step towards getting there. If you're interested in helping out, see the Milestone 1.5 link on the left side if the issue tracker at http://pyblosxom.bluesock.org/bugs/ . If you find issues, please write up issues there or send something to the pyblosxom-devel mailing list. Details on the website at http://pyblosxom.bluesock.org/ . /will ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev </pre> will kahn-greene 2011-06-19T13:55:45 http://comments.gmane.org/gmane.comp.web.pyblosxom.devel/2354 <pre>Hi! I've been really busy the last few months and haven't gotten anything I've wanted to do on PyBlosxom done. Things have cleared up a bit and I finally have some breathing space, but... probably not for long since I'm on another aggressive software release schedule. For June, I want to focus on the following three things: 1. work on pyblosxom 1.5 and finish it up 2. work on cleaning up the PyBlosxom and project documentation 3. clear out my queue of things people are waiting on me to do I won't be able to get all of these things accomplished, but these are the things I am focusing on. Today, I spent some time with gitorious and wrapped my head around merge requests (finally). It makes a lot more sense now. One thing that's really important for a merge request is that we switch the way we're doing contributions to make sure contributions are done in bugfix branches. I've overhauled the development docs accordingly: http://pyblosxom.bluesock.org/static/development.html They assume you have a working knowledge of git currently. I plan to add links on how to learn git, but really don't want to host our own git tutorial. With that in mind, does the changes in the documentation make sense? Are they still hard to follow? What specific changes would you make? There are some things I want to clean up in the PyBlosxom core, but first I think I need to step back a bit, go through the issues in the 1.5 roadmap, and make sure there are issues for all the things I think need to be in PyBlosxom 1.5. Part of the issue here is that I've been away so long, that I don't really remember what I was doing. There have been people popping up on #pyblosxom with questions. As people ask questions, I need help identifying the root of the issues and addressing those issues in either the documentation or the code. Probably the best thing to do is copy and past the IRC conversation into an issue with a sentence or two identifying the issue and possible solutions. I think that's where things are at. If you're waiting on me for something, let me know. I've got 2000 emails in my inbox and I'm tossing around declaring email bankruptcy because I can't work through them all. /will ------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev </pre> will kahn-greene 2011-06-13T02:24:21 http://comments.gmane.org/gmane.comp.web.pyblosxom.devel/2345 <pre>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. </pre> Neil Santos 2011-04-05T13:37:20 http://comments.gmane.org/gmane.comp.web.pyblosxom.devel/2342 <pre>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 ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf </pre> will kahn-greene 2011-04-02T16:02:20 http://comments.gmane.org/gmane.comp.web.pyblosxom.devel/2340 <pre>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. </pre> Neil Santos 2011-04-02T06:04:34 http://comments.gmane.org/gmane.comp.web.pyblosxom.devel/2337 <pre>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. ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf </pre> seanh 2011-04-01T13:48:13 http://comments.gmane.org/gmane.comp.web.pyblosxom.devel/2336 <pre>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. ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf </pre> seanh 2011-04-01T13:38:45 http://comments.gmane.org/gmane.comp.web.pyblosxom.devel/2335 <pre>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, </pre> Toby Smithe 2011-03-30T22:01:54 http://comments.gmane.org/gmane.comp.web.pyblosxom.devel/2329 <pre>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 ------------------------------------------------------------------------------ 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 </pre> will kahn-greene 2011-03-19T02:42:15 http://comments.gmane.org/gmane.comp.web.pyblosxom.devel/2323 <pre>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 ------------------------------------------------------------------------------ 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 </pre> will kahn-greene 2011-03-18T01:40:30 http://comments.gmane.org/gmane.comp.web.pyblosxom.devel/2319 <pre>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. Anyhow, I really apologize for not keeping up with things. Keep up the awesome work! /will ------------------------------------------------------------------------------ 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 </pre> will kahn-greene 2011-03-13T04:04:55 http://comments.gmane.org/gmane.comp.web.pyblosxom.devel/2318 <pre>Hi! Sean and I talked about sprints on IRC yesterday and decided that instead of doing a single minor sprint, we'd do a 7-day sprint! Thus, I hereby welcome you all to Sprint Week for PyBlosxom 1.5! The Sprint Week will start on Thursday, March 10th and end a week later on Thursday, March 17th. The goal of the sprint is to finish everything off so we can do a PyBlosxom 1.5 release. This will make us all much happier. I encourage you all to participate, even if it's doing one thing on the list. If you need any help, send an email to the pyblosxom-devel list. 9 times out of 10, you'll need help because I didn't document something appropriately. Here's a non-exhaustive list of things that I'd like us to work on over the sprint week: 1. There are a list of issues marked with the 1.5 milestone. Working on these definitely gets us closer to a 1.5 release. Working on flavour packs, updating the plugin registry, and updating the documentation don't require and coding skills. 2. Also in the 1.5 milestone are a bunch of issues that were ported over from SourceForge bug tracker. You can recognize these because they all have ID: xxxxx at the end of the issue title. These need to be triaged. It's possible that some of these aren't issues anymore. 3. Going through the bug tracker for bugs that should be in the 1.5 milestone, but aren't. 4. Getting the most recent PyBlosxom from git and running the unit tests. If you bump into failures, write up an issue for each one. If you're able to fix the failures, sending patches is fantastic! 5. Fixing any other issues you have with PyBlosxom or the plugins or even writing new plugins. 6. Writing up issues for problems with the web-site, infrastructure, or other things. This doesn't require coding skills. I'm at PyCon 2011 from Thursday through Wednesday during much of this sprint. I'll be checking email and I'll be on IRC when I can be. I'll also plan to spend some quality time with PyBlosxom towards the end of the conference. I encourage you to participate. If there's anything that makes participating difficult, let me know and I'll work on reducing barriers to entry and blocks as much as I can. I'd love to get this release out the door, but I can't do it alone (unless we all want to wait another 6 months). Let the sprint begin! /will ------------------------------------------------------------------------------ What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d </pre> will kahn-greene 2011-03-08T20:18:32 http://comments.gmane.org/gmane.comp.web.pyblosxom.devel/2315 <pre>I'm going to PyCon 2011 in Atlanta which I think is in two weeks. If anyone else is going, I'd love to do a sprint on any of the following things: 1. unit tests 2. documentation 3. fixing up the web-site 4. plugins 5. flavour packs 6. anything else that other people are interested in working on 7. anything that helps us get pyblosxom 1.5 out We could do the sprint in such a way that we're coordinating the sprint on irc so then people who are there and people who aren't there can all participate. If there are people interested, I'd like to assemble a small list of things that we'd like to work on so we're more likely to get things accomplished. Anyone interested? If so, what would you like to work on? /will ------------------------------------------------------------------------------ Free Software Download: Index, Search &amp; Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev </pre> will kahn-greene 2011-02-24T16:12:36 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.web.pyblosxom.devel