Re: Re: pybloxsom (fwd)

On Thu, 31 Mar 2005, Bill Mill wrote:
>
> I think that we can handle tagging and branching, and that it's 
> important enough to do. Really, if we can get that down, then a lot of 
> our problems go away.

What problems are you speaking to specifically?


>>   2. It is causing a lot of checkin email that I'm not really
>>      following.  I use the checkin email to keep track of things and
>>      as a poor-man's peer review queue.
>
> I don't know. There've only been 25 messages in the last 2 weeks, and 
> that doesn't seem excessive. Isn't it pretty simple to weed out the ones 
> that are no-brainers? I ask because I really don't know.

Hrm.  You're not really getting what I'm getting at.  We just increased 
our numbers by one.  Say we add another few people in the next month and 
everyone gets branch-happy.  I think that the 25 messages in 2 weeks will 
become a lot more.  If that's the only way we're doing peer review and 
we're expecting people to branch and then merge, I think it's going to get 
very difficult to do peer review with the existing method.

So, to clarify, I'm not talking about a problem we have right now in 
regards to checkin messages.  I'm talking about the ramifications that 
changing the way we do things will have.


>>   3. It seems people are communicating less and prototyping more.  I'd
>>      really like to discuss things before they start getting checked
>>      in and moved around.  Additionally, we have a small code-base and
>>      communicating with eachother will help a lot when people are
>>      making changes to the same pieces of code.
>
> If we have tagging and branching, as we should, then we should be able 
> to keep CVS bleeding-edge, it seems to me. This is *by far* the optimal 
> solution. Imagine that Doug's prototype branch gets too far off the main 
> one to be merged back in easily? I've run into that myself, and it 
> causes bad wastes of time, and developer frustration.

The first two sentences of this paragraph are hyperbole and only state 
your opinion--which is fine, except I think there's a clear lack of data 
here.  The next two sentences puzzle me because I'm not sure why that's 
suddenly not an issue by doing the branching in the same repository as our 
code.  Don't we incur the same issues?  I think this has less to do with 
where someone is working on their code and more to do with whether they're 
keeping up with what other people are doing.  That won't get solved by 
moving where they're doing prototyping on code that hasn't been discussed 
or specified yet from their local machine to CVS.


>> Here's why I keep talking about me.  I have no idea how dedicated you 
>> guys are to this project.  We've had developers come, do some stuff, 
>> and then disappear off the face of the earth.  That's fine and is 
>> expected--peoples' lives change and this is an open source project. 
>> However, the remaining people can't be left with a bunch of stuff they 
>> don't know how to deal with.  Additionally, I don't plan to work on 
>> this project for the rest of my life either.  I want to leave the 
>> project in a state where it has a lot of momentum and new people can 
>> come in, familiarize themselves with things, and help out.
>
> Understood, and your commitment to this project has been demonstrated.

Just to clarify, I'm not saying anything here for ego-purposes.  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.

In the back of my head, I'm trying to push the project in enough of the 
right places so that it has enough momentum and infrastructure to get over 
me leaving without a problem.  Unlike Lyntin (the last project I stepped 
down from) which seems to have stopped when I left.


> However, I just don't think that making big prototype branches that only 
> a single developer has access to is a good solution.  I've not committed 
> a whole ton of stuff for just this reason.

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?

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 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.


> As I start to use source control for real (I've got my own subversion 
> server for pyblosxom now, and I'm using it at work), I see that the only 
> way the system works is with small, atomic commits happening frequently.

Yes, but prototyping something is the process where you have a stated 
mission that you want to accomplish and you're poking around the codebase 
trying to figure out what pieces are involved and need changing. 
Prototyping is not the process of writing the code according to the 
specification that everyone has signed off on.

So, in that regard, I agree with you that version control works better for 
small atomic commits.  However, I think that most prototyping should be 
done outside of the main repository.

If we were refactoring the whole system, or some similarly large-scale 
thing that involved multiple people working on it, I think that's a good 
reason to put it in CVS.

If it's one person working on a small-to-medium task, I'd rather they did 
it on their own.

That's what I think should happen.  We haven't come to any resolution on 
that yet.


> I don't feel like tagging and branching requires a huge mastery of CVS - 
> but I've never done it either. I think that the benefits outweigh the 
> negatives, especially as we start to add developers.

Can we qualifty the pros and cons somewhere?


> I'd prefer that our CVS HEAD branch stayed bleeding-edge, with him 
> committing as soon as he does something. I think I've explained why in 
> too many words already :)

I'm a bit confused.  I think what you're saying is that Doug, Steven, and 
other people all working on separate projects that might cross over one 
another should all work in CVS HEAD on stuff that may or may not end up as 
a part of the codebase because bleeding-edge is good.

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?

Am I the only one concerned about the issues here?  Am I communicating my 
concerns 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.

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.


I'd like this discussion to end up in some kind of formal process for how 
we do development on PyBlosxom in regards to CVS and we have a few folks 
who are familiar with what we're doing enough to fix things if they get 
hairy.  I'd like to take that process and put it on the web-site as a 
series of practices people agree to adhere to.  Until then, I'm a big fan 
of keeping it simple because simple is more developer-friendly than the 
alternatives.

Anyone else have thoughts on this?

/will


-------------------------------------------------------
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