Re: Re: pybloxsom (fwd)

Will,

Before I get started, I don't think that your and my viewpoint are as
far different as you seem to think they are. (update: after finishing,
I apologize in advance for the length.)

Let me try to expand on what I think the problem is. When I started
developing the caching stuff, I took a snapshot of the CVS, and
started hacking away on it. However, my version wasn't under any type
of source control, and I eventually had changed nearly every file in
pyblosxom. None of it was committed to CVS, and I was left with
scattered notes on what had changed and why, as well as undocumented
changes.

So, my question is, what should I have done? Should I be responsible
for maintaining my own source control system? Should I try to spend
hours poring over diff files to try and post a huge change to the
mailing list, which almost certainly nobody will read thoroughly
enough to know about it?

Saying that the developers should be responsible for their own source
control on experimental prototypes is, at the least, logically
consistent. However, it seems like a mistake to me. It's a turn-off to
potential developers, always a problem in an open-source environment.
It discourages any significant changes to the trunk code, ever, which
leads to cruft and a fear of refactoring.

Regarding communication, I agree with you that people should be
emailing before they start to do anything. However, for my prototype
cache, I think the best solution would have been for us to start a
branch (after deciding to do so via email), let me hack away on it
(where everyone can see what I'm doing) and see what develops. If it's
a dead end, then so be it, and it gets deleted when we decide that
it's done. If it's good, then the changes are all out in a common
server, in a common format, where everyone can see them - or even
check out the experimental branch.

This is not to say that I should not have been emailing, and should
have just started whaling away on the main source code - this is
clearly a bad thing, and I was suggesting no such thing. However, if
we want significant improvements, we need to improve our development
environment.

Imagine if, instead of wading through huge patches by Steven when he
did his wsgi and twisted stuff, I could have just checked out his
experimental branch? I feel like it would have been much nicer, plus I
could have watched his progress on it. Furthermore, if he had done it
then left before its completion, we would have had the ability to
decide what changes were worth keeping and what changes we wanted to
throw out.

I feel like you're looking at it from a more practical POV than I am.
Yes, this would be a lot more work for the administrator (i.e. you)
and we would need to increase our cvs-fu as a group. I feel that the
advantages of complicating our cvs setup outweigh the disadvantages of
keeping it the way it is - but you may disagree. I think that both are
reasonable positions, with valid arguments in their favor.

Only a couple comments directly on your email:

> >
> > Understood, and your commitment to this project has been demonstrated.
> 
> Just to clarify, I'm not saying anything here for ego-purposes.

Man, did this come out wrong. It sounds insulting, like I was trying
to take you down, but I was trying to pay you a compliment. My
apologies.

> The issue
> involves me as well.  I have no interest in working on this project
> forever and I'm very quickly approaching the point where my abilities and
> knowledge aren't really helpful.  I think in the next few months, possibly
> after the next version release, I'm going to step down as a maintainer.

That would be a sad day for me. I think you've done an excellent job
managing things while I've been working on the project, and you've
overseen some serious improvements to pyblosxom. Of course, it's your
choice.

> 
> This statement is irritating.  Have you told anyone what you're sitting
> on?  Has it been discussed with other pyblosxom developers to the point
> where we're all +1 with the changes to be checked in?
> 

Like I said before, my code ended up in such a mess, in about 5
pyblosxom directories on my hard drive, that even I don't know what I
did anymore. This is why I don't like asking programmers to handle
their own source control - some of them are as sloppy and lazy as I
am.

Basically, I knew what I had done after I did it, and you asked me to
hold off on it until after 1.2 came along. By the time 1.2 came along,
I had no more idea what I had done. It will take me some serious
code-reading time to go in and figure that out now.

> As far as I know, you're sitting on changes involving index caching
> because I said that I thought it was a better idea to refactor the storage
> api to better handle index caching.  As I racall, one of the problems with
> your caching is that it's global and not local to the PyBlosxom request so
> it would have problems with mod_python and other frameworks.  Please
> correct me if I'm wrong.
> 

I don't understand how mod_python, or any non-blosxom python
framework, work on any deep level. However, I don't believe that my
code would be incompatible with any of them.

> I don't want people checking in things they haven't discussed with other
> people.  This project should be built by a team of developers, not a
> free-for-all.  The free-for-all gets too difficult to coordinate.
> Communication first, then coding.
> 

Here's where you think we disagree, but I couldn't agree any more. I
just don't want us to fall *too* far on the conservative side - this
is supposed to be a fun, open-source project, not IBM Blosxom v6.7.
 
> If that's what you're saying, my questions are these.  What's the process
> that we should institute so that we're all on the same page in terms of
> use of our repository?  Should we even have a process?  Should we allow
> people to check in things when they want to?  Is there a requirement for
> testing, specification, or communication with other development members
> before checking things into CVS HEAD?  Should we force everyone to have
> their own branch for the things they're working on?  Do we require some
> kind of specification before people start their own branch or should
> everyone just have their own branch?
> 

I think there should be an administrator. If I have a medium-to-large
experimental idea, I think that I should propose it to the
administrator for discussion by the group. If it's decided that it's a
good idea to try, then the administrator should give that person a
branch of the code to play with, where everybody can follow along, or
multiple people can collaborate on it.

This *is* different from what I said in my previous email. I
reconsidered based on your arguments.

> Am I the only one concerned about the issues here?  Am I communicating my
> concerns poorly?

I don't think so, I think that I communicated mine poorly.

> 
> Just to clarify, I've worked with a bunch of different version control
> systems before and do understand versioning, branching, tagging and
> various other things that you can do with version control systems.  I've
> also been following to some degree arch, subversion, bazaar-ng and a few
> other version control projects.  CVS has a few issues that make it kind of
> a pain in the ass to use.  Blah blah blah.  My point being that CVS is not
> the easiest system to work with and makes some things a pain in the ass.
> 

If CVS isn't up to the task of how I imagine it working (which I hope
I clarified above) then just tell me, and I'll shut up. I reiterate
yet again that my bias is *way* on the programmer side, and I'm cvs
and source control stupid. I just want us to be able to write code
that takes risks in a place where people can collaborate and see what
each other are doing.

> Continuing, if we have no development processes written down, then we are
> increasingly developer-unfriendly because we make it harder for new people
> to figure out how to send us diffs and such.  If we have bleeding edge and
> a dozen branches, it's that much more to document.
> 

You're right, that's a negative. It seems to be a reasonable thing to
take on to me, but I'm not an administrator who has to deal with it. I
don't think we should let branches proliferate - more than 2 or 3
seems to many to me - but I think we should allow them.

Peace
Bill Mill
bill.mill at gmail.com


-------------------------------------------------------
This SF.net email is sponsored by Demarc:
A global provider of Threat Management Solutions.
Download our HomeAdmin security software for free today!
http://www.demarc.com/Info/Sentarus/hamr30