[bt-devel] Backend Proposal

[Greg Hellings]

On Sun, Jun 19, 2011 at 7:25 PM, Raoul Snyman
<raoul.snyman at saturnlaboratories.co.za> wrote:
> On Sun, 19 Jun 2011 14:54:47 -0700, Gary Holmlund wrote:
>> The work should be done so that there is never a commit that does not
>> compile and run.
>
> I disagree, on two accounts:
>
> 1. This is why we are using git, or at least supposedly. Instead, we're
> using it just like Subversion. What's the point in a distributed version
> control system if you don't use it in a distributed fashion?
>
> 2. If you can't commit broken code into your own branch, you can't ever
> make real progress. You end up being so afraid of committing broken code
> that tasks become insurmountable because of their size, and you never
> actually start any tasks.
>
> I propose a different workflow:
>
> 1. Everyone should have their own clone on Gitorious. This makes sure that
> we have codebases that are insulated from each other, but we can share code
> when and where necessary.
>
> 2. Once you have a Gitorious clone, you should have a local clone of that
> Gitorious clone. This is the repository you work in. Don't forget to keep
> your master up-to-date with the main repository master.

This step is one that I've never gotten to work with git/gitorious.
And it's the main reason I loathe using git over bzr.

>
> 3. Use branches. Commit often.
>
> 4. Once you are happy with the status of a branch, push your branch up to
> your personal Gitorious repository, and let others know that they can view
> it. This means that you can get peer feedback on your code and your ideas.
>
> 5. Pull branches from other people to collaborate on tasks.
>
> 6. Use the merge request feature of Gitorious so that you can get the
> above-mentioned feedback from one of the main (or core) developers, and so
> that they can make sure that broken code never enters BibleTime master.
>
> This may sound complicated at first, but it makes use of git's distributed
> nature, Gitorious' collaborative platform, and frees each developer up to
> mess around with the code as much as they like without messing up the main
> code.
>
> My 2c worth.

This is what I was getting at when I suggested we make sure that every
commit on bibletime:master compiles and runs, but that we keep
branches going which can be as broken as needed while we pull out a
component and get it working. Especially with the quantity of code
change we're talking about to do this type of refactoring, making sure
only commit always works will feel like an insurmountable obstacle and
will also lead to commits which are WAY bigger than they need to be. I
would say make sure every merge into master works as intended.

--Greg