RE: my issues (was RE: [Pyblosxom-devel] Lucene and comments)

[Theodore W. L. <tw...@sa...>]

> -----Original Message-----
> From: pyb...@li...=20
> [mailto:pyb...@li...] On Behalf Of will
> Sent: Monday, February 10, 2003 7:24 AM
> To: pyb...@li...
> Subject: my issues (was RE: [Pyblosxom-devel] Lucene and comments)
>=20
Please call me Ted...
>=20
> Um, Theodore, did you read the thread from last week=20
> regarding the url handling stuff I was working on that Wari=20
> asked you to read?
>=20

I thought that I did, but on a second reading, I see that I didn't.  My
Apologies.

>=20
> I'm seriously concerned right now.  I think there are way too=20
> many cooks=20
> with their hands in the soup who aren't bothering to=20
> coordinate with the=20
> other cooks.  I go on vacation for a few days and come back to find a=20
> flurry of development (which is fine) which (unless you guys are=20
> communicating off the list--which sucks for coordination) seems to be=20
> totally uncoordinated.
>=20

I'm doing almost all of my communications here on the list.  Blake and I
have exchanged a few messages about logstats.py

>=20
> My basic problems with this project go like this:
>=20
> 1. there are no coding conventions--everyone's using their=20
> own style and=20
> the code base is a mess of several different styles which makes it=20
> difficult to figure out what's going on.

I wasn't aware that we had a coding style, I agree that it would be good =
to
have one.  I don't have enough experience with Python to outline what =
that
should be.  If you or one of the other guys wants to spell this out, I'm
happy to reformat my code to comply.

> 2. people aren't adequately documenting what they're doing. =20
> this is both=20
> specifications that should be written to the devel list so we=20
> can discuss=20
> things BEFORE they happen as well as inline documentation in the code.

I guess this is mostly me.  I wanted to get the lucene stuff checked in, =
and
Wari and Blake seemed to be okay with what I was proposing.  And given =
that
I didn't carefully read what you wrote, I thought what I checked in =
would be
okay.  Obviously not

> 3. there are some fundamental architecture changes that need=20
> to be done. =20
> my first blush impression by looking at the checkin diffs=20
> over the last week, we're duplicating functionality and=20
> calling it different names.

I agree with this.  So maybe the best thing for us to do is back out my
changes and I'll wait until you get done and then figure out how to
integrate my stuff.

>=20
> So what's the deal?  I definitely don't want to be involved=20
> if it's going=20
> to be this chaotic.  I'm totally not down with the "throw=20
> code together=20
> then discuss" method of doing things--I think it's an extremely poor=20
> development model which leads to a very large and unwieldy=20
> code-base with=20
> a lot of funkiness in edge-case scenarios.  It's not like=20
> we're inventing=20
> a totally new wheel here--many of the things we're discussing=20
> have been=20
> done over and over again in other projects.

It helps me to see what changes need to be made when I try to implement
functionality.  I guess my mistake was checking the code into CVS.  Next
time I'll post the diffs to the mailing list and we can talk about what
needs to happen.

> I'll be honest--if this is the way you guys want this to work, then I=20
> can't be involved and I'll bow out.

I think that would be a huge loss for pyblosxom -- you've contributed a =
lot
to what's here.  Let's work out how we want to work together and then =
try to
stick to it.  I promise to spend more time reading e-mails in the =
future.
In the meantime, if you want me to back out my changes, say the word and
I'll do it.

Ted

> /will
>=20
>=20
> On Sun, 9 Feb 2003, Theodore W. Leung wrote:
> >=20
> > Ok,
> >=20
> > I've committed changes that make lucene work in a plugin style way.
> >=20
> > I added a new kind of execute method to api.py, so that the=20
> executed=20
> > handlers can return a list (in the case of lucene, a list=20
> of files). =20
> > I then added two new callback chains, one for CGI and=20
> another for the=20
> > filelist.
> >=20
> > When I added the callback chain for the filelist, I created=20
> a default=20
> > plugin that contains the code for the standard blosxom file=20
> traversal.
> > I'm not sure that I like this approach because it puts the plugin
> > directory back as required.  Seems like it might be better to have
> > pyblosxom.py contain the code and somehow register it, but=20
> the plugin
> > discovery mechanism (as it stands) precludes that.
> >=20
> > Please let me know your thoughts on this.
> >=20
> > I totally don't mind comments that say "this sucks".  Part of the=20
> > reason I asked for feedback was that I didn't like it myself.
> >=20
> > I'll be looking at comments next, but I need to do a little Java=20
> > hacking the rest of today.
> >=20
> > Ted
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld =3D Something=20
> 2 See! http://www.vasoftware.com=20
> _______________________________________________
> Pyblosxom-devel mailing list Pyb...@li...
> https://lists.sourceforge.net/lists/listinfo/pyblosxom-devel
>=20