Menu
▾
▴
pyblosxom-devel
|
From: Wari W. <wa...@ce...> - 2003-02-10 11:24:55
|
* Theodore W. Leung <tw...@sa...> [030210 08:07]: > I've committed changes that make lucene work in a plugin style way. > > I added a new kind of execute method to api.py, so that the executed > handlers can return a list (in the case of lucene, a list of files). I then > added two new callback chains, one for CGI and another for the filelist. Hi sir, I wanted the lucene indexing to recognize other files using entryparsers if possible, you game for it, it would somehow mean that index.sh would be index.py, pushing data to the lucene java program. I don't think it's an easy task though, but hey, who knows? I don't want this to be an immediate thing yet, but when you can throw in all sorts of file in a blosxom directory, you wont want to be limited by a .txt only implementation. -- Regards: Wari Wahab Senior R&D Engineer Celestix Networks http://www.celestix.com/ |
|
From: will <wi...@bl...> - 2003-02-10 15:23:48
|
Um, Theodore, did you read the thread from last week regarding the url handling stuff I was working on that Wari asked you to read? 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 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. 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. 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. 3. there are some fundamental architecture changes that need to be done. my first blush impression by looking at the checkin diffs over the last week, we're duplicating functionality and calling it different names. So what's the deal? I definitely don't want to be involved if it's going to be this chaotic. 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. 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. 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. /will On Sun, 9 Feb 2003, Theodore W. Leung wrote: > > Ok, > > I've committed changes that make lucene work in a plugin style way. > > I added a new kind of execute method to api.py, so that the executed > handlers can return a list (in the case of lucene, a list of files). I > then added two new callback chains, one for CGI and another for the > filelist. > > When I added the callback chain for the filelist, I created a default > plugin that contains the code for the standard blosxom file 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 the plugin > discovery mechanism (as it stands) precludes that. > > Please let me know your thoughts on this. > > I totally don't mind comments that say "this sucks". Part of the reason > I asked for feedback was that I didn't like it myself. > > I'll be looking at comments next, but I need to do a little Java hacking > the rest of today. > > Ted |
|
From: <su...@ho...> - 2003-02-10 16:06:03
|
On Mon, Feb 10, 2003 at 09:23:48AM -0600, will wrote: > Um, Theodore, did you read the thread from last week regarding the url > handling stuff I was working on that Wari asked you to read? Ah yes, issues that bugs me still. > 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 is trying to make things as modular as possible, Ted and Blake are doing comments, and as for you, in charge of api functionality. > 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. As far as I know, I did not communicate off the list, as far as possible. > 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. > 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. > 3. there are some fundamental architecture changes that need to be > done. my first blush impression by looking at the checkin diffs > over the last week, we're duplicating functionality and calling it > different names. Can you point out which of these fires needs to be put out? Yeah, being new to python development doesn't help, but at least I do try my best to point out what will break big picture. > 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'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. 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. 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. > 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? |
|
From: Blake W. <bl...@ph...> - 2003-02-10 16:48:23
|
> > 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. |
|
From: Theodore W. L. <tw...@sa...> - 2003-02-10 22:08:00
|
> -----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 |
Thanks for helping keep SourceForge clean.
X