RE: [Pyblosxom-devel] Re: my issues

[Blake W. <bl...@ph...>]

> > I'm seriously concerned right now.  I think there are
> > way too many cooks with their hands in the soup who
> > aren't bothering to coordinate with the other cooks.
> I guess what we can do for now is to at least define some 
> form of roles and what each of us can do to contribute to
> pyblosxom.  I for one am trying to make things as modular
> as possible, Ted and Blake are doing comments, and as for
> you, in charge of api functionality.

That sounds about right, although if I have a quick bug-fix,
and the original maintainer of a file doesn't get back to me
in a day or two, I might just check it in myself.  (i.e.
mt2blosxom.py)

Having said that, I'm not going to do a whole lot on comments
until the api and modularity settle down a little.  There's
the back-end stuff which I've been working on, but there's
also front-end stuff which won't be started for a while.

> > I go on vacation for a few days and come back to find a
> > flurry of development (which is fine) which (unless you
> > guys are communicating off the list--which sucks for
> > coordination) seems to be totally uncoordinated.

The development I've been doing has been fairly uncoordinated,
but it's also been available from my website, and explicitly
not been checked in, and there's not a lot of coordination that
needs to be done with the storage part.  I've been developing
the API, and writing an implementation of it.  If the API
changes because of things people need, I'll change the
implementation to fit it.  If someone wants to use the API,
they should let me know (as I've said), and we can talk a
little more about how to do what they want to do.

> > My basic problems with this project go like this:
> > 1. there are no coding conventions--everyone's using their
> >    own style and the code base is a mess of several
> >    different styles which makes it difficult to figure out
> >    what's going on.
> We could solve this by following some coding guidelines, I 
> guess the one you have for lyntin would be a good base to
> start.

My preference is for a coding style that doesn't use tabs, and
uses four-space indents, but I'm flexable.  If I'm modifying
a currently existing file, I follow the style of that file, but
that's a no-brainer.

> > 2. people aren't adequately documenting what they're doing.
> >    this is both specifications that should be written to
> >    the devel list so we can discuss things BEFORE they
> >    happen as well as inline documentation in the code.
> I hope I've given enough information as to what I'm doing so 
> that no one gets lost.

Same here, with the caveat that an example is sometimes the
best way to explain things.  If there's anything about the
storageApi, or the xmlFile implementation you don't understand
and need or want to, please email me off-list, and I'll answer,
and use the answers to create documentation both to put in the
class as comments, and to post to the list, and even to put in
the wiki.

> > 3. there are some fundamental architecture changes that
> >    need to be done.

This is why I'm not working on the front-end.  But I think that
the back-end stuff I am working on is architecture-independant.
Well, mostly architecture-independant, anyways.  Anywhere it
isn't is a bug in the spec.  ;)

> > So what's the deal?  I definitely don't want to be involved
> > if it's going to be this chaotic.  
> I guess you could give us a chance? pyblosxom-devel with all
> the cooks in it are quite young, basically, it's just two
> months old (does it feel like a long time or what?). Heck
> even most of the code contribution is not mine.

I think that the main bit of chaos is the rearchitecting of
the code, and that that will settle down in the fairly near
future.  It's complicated by the other stuff we're doing
(comments, lucene search), but by and large, I think the sets
of items are rather distinct.

> > I'm totally not down with the "throw code together then
> > discuss" method of doing things--I think it's an extremely
> > poor development model which leads to a very large and
> > unwieldy code-base with a lot of funkiness in edge-case
> > scenarios.

Even if the code isn't checked in?  Myself, I prefer to have
code that I can look at and poke while I'm discussion a
proposal, even if (especially if) that code isn't what's
going to be put into CVS.  That was why I asked if I should
check the api in, and that was also why I decided to not do
that, and to let people look at it another way.

> > It's not like we're inventing a totally new wheel here--
> > many of the things we're discussing have been done over
> > and over again in other projects.

Yes, and at least for the stuff I've been doing, I've
been looking at the other projects, and seeing how what
I'm writing compares to them.

> What we need is to give out specs, or throw in working
> diffs before checking it (at least for major changes),
> bug fixes can be checked in as they are found.

That's been the way I've been trying to do stuff.
Have I been doing okay, or have I been slipping?

> > I'll be honest--if this is the way you guys want this
> > to work, then I can't be involved and I'll bow out.
> Don't leave just yet, ok?

I second that.  We need the voice of reason to say stuff
like this, and make us look at what's going on.

Well, that was long.

Later,
Blake.