Forgotten patch: qofid.diff

[Josh Sled]

On Fri, 2005-10-28 at 21:00 -0400, Chris Shoemaker wrote:
> of the foundational issue: our development process.  Our process just
> doesn't support the case where:
>    1. not everybody wants to work on the same thing,
>    2. they can't produce almost perfect code the first time out, and
>    3. they want to collaborate.

Branches can support all three of these goals.

Though, I continue to not understand why it's not reasonable for
everyone to be working primarily towards the same goal/thing.


On Fri, 2005-10-28 at 22:21 -0400, Chris Shoemaker wrote:
> Then you've gotten the wrong impression.  As a matter of fact, if I
> had everything /my/ way (a scary thought, I know, you can open your
> eyes now) the standard would be far *higher* that it is now.  I would
> name you the release manager for g2 and *only* you would decide what
> goes into *your* tree (but it's all visible of course).  And it's
> ready when you say it's ready and release it.  Then, there have to be
> mechanisms in place to cultivate the "cloud" of code changes to swirl
> around us, including you, and mechanisms to make it easy to for
> everyone, including you, to grab arbitrary selections of those
> changes.  You get the idea.  Anyway, I hope that clears that up.

I don't think we need, and personally I don't want, a system that
requires any individual to take arbitrary selections of the "cloud" of
changesets.  I'm quite fine developing software from a single
changeset-based repository.


On Sat, 2005-10-29 at 00:04 -0400, Chris Shoemaker wrote:
> well might have a HUGE MESS.  OTOH, if have all 500 commits and 250^2
> degrees of freedom in merge order, you're much more likely to be able
> to merge with NO conflicts.  And any conflicts you do have will be the
> conflicts of *individual* commits.

250^2 degress of freedom in merge order?  Ignoring the fact that that's
not practically true or useful given the semantic dependencies of the
commits, do we really practically need this capability?  I'm finding
your argument tending toward the absurd ... with respect to GnuCash
especially.

> Incidentally, I really think you and I have philosophical differences
> here.  I don't WANT the authority to dictate what code is in the
> software you use.  I want ONLY YOU to have that authority.  OTOH, I
> *do* want the ability to make MY code available to whoever wants it
> (and will agree to the license), and to work with others efficiently.
> Those are my goals.

Well, you're free to take as much time and effort as you like to
assemble for yourself what code is in the software you use.  I think I
can speak for most of the developers (and users) when I say that the
rest of us are trying to produce 1 piece of software... 1 codebase.
It's not a question of coersion or curtailing individual liberties...
it's just practical development simplicity.  Doing this might take
extended branches from time to time, but I don't think we need or want
this flexability you desire, and its associated cost.


Chris, I really don't care to spend any more time on these threads.  You
assert that the development process is broken, and most of the rest of
us assert the opposite.  You really want some unspecified distributed
SCM/"convergence tools", and most of the rest of us are fine just moving
to SVN.   You claim the problem's in the tools, then you claim it's not
just about the tools... around and around we go.

I don't quite know how to resolve this.  I guess we could make proposals
and vote Apache-style, but I already see a concensus.  What do you want?

...jsled
-- 
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`