Re: PostgreSQL Developer meeting minutes up - Mailing list pgsql-hackers

* Andrew Dunstan <andrew@dunslane.net> [090605 14:41]:

> The whole point is that we want something better *that suits our work  
> patterns*. Almost all the backpatching that gets done is by the  
> committers. So we have a bunch of concerns that are not relevant to that  
> vast majority of developers. In particular, it would be nice to be able  
> to make a bunch of changes on different branches and then commit it all  
> in one hit. If that's possible, then well and good. If it's not, that's  
> a pity.

My only concern is that I am seeing 2 requirements emerge:
1) Everything has to work as it currently does with CVS
2) We want better information about how patches relate for possible  future stuff

Unfortunately, those 2 requirements are conflicting...  If you (not
anyone personally, but the more general "PostgreSQL committer") want the
repository to properly track the "fixes" and show their relationship,
and extra through all the branches than you really do want the
"branch-to-fix" and merge the fix forward into all your STABLE/master
branches, like the "daggy" type thing mentioned elsewhere...  But
notice, that is *very* different from the current work patterns based on
the CVS model where everything is completely independent (save the
commit message), and it's a huge change to the way developers work.

If you want to stay with the current CVS style, then you aren't going to
get any closer than "commit messages matching" (or possibly a reference
to another commit as an extra line) that we currently have with CVS.

My suggestion is to keep it simple.  Just work independently, like you
currently do.  You don't want every committer to have to completely
learn the advanced features of a new tool just to use it...  You can use
it as you use the less feature-full tool as you learn all the
features...

But as people start to use the new tool, and start to use it's more
advanced features, then it's natural that their results will start to be
reflected the main repository.

But insisting that people currently comfortable and proficient in the
current work patterns *have* to learn completely new ones for a
"flag-day" type switch and start using them immediately is going to:* Piss them off* Create great ill-will against the
tool
And neither of those will be the fault of the tool itself, but of the
way a "new process" was forced in conjunction with a new tool...

I don't want to see the PG project trying to *force* a radical change in
the way the development/branches currently work at the same time as a
switch to git.  Replace the tool, and allow the current processes and
work-flows to gradually improve.  The process and work-flow improvements
will be an iterative and collaborative process, just like the actual
code improvements, where huge radical patches are generally frowned
upon.

I've used git for a long time, on many different projects.  I do know
how radically it *can* change the process, and how much more efficient
and "natural" the improved processes can be.  But the change is not an
overnight change.  And it's not going to happen unless the people
needing to change *see* it's benefits.  And that's going to take time
and experience with the new tool...

Anyways, I said previously that I was over with this thread, but now I
mean it ;-) If someone want specific git information or help, I'm
available.

a.

-- 
Aidan Van Dyk                                             Create like a god,
aidan@highrise.ca                                       command like a king,
http://www.highrise.ca/                                   work like a slave.