[Pyblosxom-devel] next steps

[will <wi...@bl...>]

Wow--I didn't mean to cause such a raucus or make anyone feel inadequate 
or anything.  I'm just concerned about the state of things and whether the 
development process you guys want to do matches something I can deal with.  
I have a couple other projects I work on and I can't spend a huge amount 
of time trying to figure out what happened day to day.  So I just don't 
have the time for projects that want to involve more of a chaotic 
development process.

So that's where I'm coming from.

Having said that, I'd like to clarify some things.  When I said that I'm
not down with "code first discuss later" I meant more along the lines of
"code first, commit to CVS, discuss later".  It's that middle step that I
find really difficult to work with.  I'm definitely into people doing the
analysis and research and trying out various ideas in code as we go
through figuring out exactly what we're doing.  If you feel the need to 
send diffs to the list, that's fine.  I think in most cases it's not 
something we need.  Bug fixes should be committed--just new development 
and changes to the core architecture that need to be ironed out before 
being committed because it affects everyone in different ways.

This doesn't need to apply to everything.  I think if someone was going to 
whip together a plugin for ... well, let's use my calendar plugin as an 
example.  It's a plugin and is additional functionality.  If someone 
wanted to whip together something like that which doesn't affect anyone 
adversely and then check it in, that's fine.  It's when we're all 
adjusting pieces of the core architecture and changing the way things 
operate and the default behavior that I really would want to measure twice 
and cut first, so to speak.

I definitely don't think we need a full specification process like Sun has 
with Java, either.  I just want a clear understand of what people are 
doing before they do it because then each of us can figure out how it 
affects us and what additional things could be involved.  We're not in a 
rush--we don't have a deadline to meet--so we can take our time and think 
things through as we go along.  We'll end up redoing things over and over 
again and the codebase will end up much easier to manage.

I'm not saying anything wildly exciting or new here.  I just figured it 
needs to be said by someone so we all know we're on the same page.

The coding conventions thing is irritating and coupled with rare
commenting makes it difficult to figure out what's going on.  I have a
standard that I use with Lyntin and now I'm using it with Stringbean as
well.  It's adapted from Guido's style guide with some changes to make
generating out of line API documentation more comprehensive.  I'd suggest
that as a good first draft.  It involves indenting by two spaces, but we
can go with whatever indentation method you guys want to use--I don't
really care either way.  I care more about inconsistent case usage in
variable names, vs class names, vs function names.

I forget what the other thing I whined about was.  Hmmm....  Probably 
wasn't wildly important.

I have to run, otherwise I'd do more work tonight.  I think what Ted (I 
wrote a post-it note reminding me that Ted likes to be called Ted and that 
Blake is subscribed to both lists and doesn't need repeats) did is fine 
for now.  I'll look more carefully at it and compare it to the other 
things we were discussing last week and augment what he's already written.  
I'll probably do that tomorrow or Wednesday.  Definitely don't worry about 
backing out the changes.

Even though I got all concerned, it's exciting to see such a flurry of
development happening on such a diverse set of missing functionality.  
There's some cool stuff being worked on now.  I might have time to log in 
tonight, but to be honest, I'm pretty tired and somewhat jet-lagged right 
now.

Rock on!
/will

-- 
whatever it is, you can find it at http://www.bluesock.org/~willg/
except Will--you can only see him in real life.