Forgotten patch: qofid.diff

Chris Shoemaker c.shoemaker at cox.net
Sun Oct 30 18:31:40 EST 2005


On Sat, Oct 29, 2005 at 04:28:47PM -0400, Josh Sled wrote:
> 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.

I guess we have the same goal in a broader sense.  I just meant the
narrow sense of wanting to do two different things to the same code,
e.g. bug-fix current register, and completely overhaul register. 

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

That depends on how you want to use it, of course.  If everybody tends
to work in the same branch, then no, it's probably not a compelling
feature.  OTOH, if you prefer to branch for any non-trivial code
endeavor, then yes, it's useful.

> Chris, I really don't care to spend any more time on these threads.  

Me neither.  I recognize there is a diminishing return value here.

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

Re: "unspecified".  I've been light on specification not because there
are not concrete realizations of what I'm talking about but because I
wanted to separate issue of requirements and implementation.

> 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 think I've been unclear here.  SCM tools are both a _product_
of their development culture and _influence_ their development
culture.  Problems in both are manifest in the other.

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

I don't think you'd find a consensus unless you limited the vote to
certain people.  I agree with Christian's recommendations: collapse G2
_soon_, move forward with SVN, re-eval next year.

-chris


More information about the gnucash-patches mailing list