On Sun, Oct 16, 2005 at 11:34:24AM +0100, Neil Williams wrote: <snip> > > > > You're right, this is HUGE. There's enough pain in the codebase > > itself, but much of the pain is in code management. We *have* to fix > > this somehow. > > Let's take an example or two and see if I can draw Josh's arguments in line > with mine and yours. > > Example 1: > Currently, the business file backend is broken. /tmp/gnucash.trace confirms > this. I have a fix that completely solves the problem. I cannot commit. Why? > > Even though my patch does not affect ANY of the files that have been patched > since I last committed, I have to test TWO separate builds. I have to build a > pristine copy from CVS prior to putting my changes into that. I also have to > build my working copy that now needs to be updated with the latest changes > from CVS. This process has currently taken FOUR DAYS due to employment > commitments. > > If I could simply commit the change, everyone would benefit. > > Example 2: > I have a situation similar to yours with patches outside the tree (actually > it's a complete tree outside the tree). This tree works with external QOF and > I want to be able to commit these changes too. > > Unfortunately, that will require maybe FOUR complete builds going back to > make > distclean in each case - just because of the negative feedback. > > This is wasting my time, it is delaying others and it is all out of fear. > > Fear is not fun. As a volunteer, fear undermines my motivation to make > changes > - ANY changes - it erodes the time I have available for working on the code. >
> However, the most difficult aspect is that it HIDES my changes from everyone > else. Nobody else knows what I am about to change or how it relates to their > changes. Of all the bad things you listed, all the fear and pain, *this* one has the worst effect on GC's development. You'd think there was some law preventing us from sharing code. I cannot overstate how inefficient it is to develop in isolation. It's worse than having to build on three platforms before every commit. > So I have to spend MORE time writing complex emails to the list that > try to explain new code that is not itself available for others to inspect. > > A picture is worth a thousand words? A commit is worth 20kb of email > description! > > 5 seconds compared to several hours. > > This is ALL because the current version control system relies on the final > arbiter being a single directory on a single machine: cvs.gnucash.org. Unfortunately, you're right. > > I need to be able to make smaller commits that change fewer files in one go, > that require less time building pointless trees and which are available for > *inspection* by others WITHOUT necessarily having to be IN their build. > > That is a decentralised model - there is no single arbiter, no single source. > It's almost like a branch per developer. > > Each branch is folded into the others *when it is ready* but not before. Yet > it remains available for others to inspect and use if they want it. This is key. > > *We should not have to have patches outside the tree!* > > *Breaking the build cannot be allowed to remain a capital offence!* > > We need to ditch the idea that there is a sacrosanct single build. The > release > is built from those branches that work together. Hiding code in local builds > is enforced by the negative feedback and implicit mantras - I thought free > software was about sharing code, not hiding it in fear. > > I believe that the current development mantras in gnucash are wrong, not > because the *ideals* are wrong but because the implementation forces > constraints on those ideals that make the whole process overtly negative. > > "Breaking the build" is only a problem because we have a single build > directory on a single server. > > Our bigger problem is that this weakness in our implementation is actively > discouraging development, wasting immense amounts of developer time and - > fatally - putting developers in fear of change. I think you're right. :( > > Why am I prevented from merely fixing the problem? > > Why this emphasis on wasting time building trees over and over and over and > over again? > > > Any enviroment > > that makes you dread and delay committing is pretty much the exact > > polar opposite of the goal set forth in the article. I have to say, I > > think *this* is the root symptom. If we can fix this, everything else > > will folow. > > Code needs to be shared - including broken, in-progress, code. Making changes > in gnucash can be a LONG process and an involved, complex task. During that > process, it is essential that others can SEE how those changes are > progressing. I couldn't agree more. > > Currently I only have two options to do that: > > 1. Commit and be damned, or > > 2. Waste vast amounts of eeryone's time trying to explain code in emails to > the list when it would be far simpler for everyone if they could just look at > the code! > > So, generally, I commit and be damned. > > That is actually preferable to spending even more time on a development > thread > that made a bad assumption at the start. > > I choose to write free software because it CAN be peer-reviewed. Our problem > is that our peer review process is crippled, overtly negative, paranoid and > prohibits change. > > I am also aware that my own arguments here are working against a change to > SVN > and a move to something like GNUarch - despite my previous experience with > it. I've been looking at distributed SCMs recently and there seems to be several options, with Arch not being particularly outstanding in terms of popularity, features, maturity, friendliness, etc. -chris _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
