[dev] The layout of the git repositories

[Michael M Slusarz]

Quoting Chuck Hagenbuch <chuck at horde.org>:

> Quoting Gunnar Wrobel <p at rdus.de>:
>> When using distributed developer branches you'd assign maintainers for
>> each of the available modules. These maintainers are responsible for
>> releases of the modules they manage and usually pull from the people
>> they trust. This will not work if all modules exist within one
>> repository as you would need to care for things beside the modules you
>> maintain.
>
> That's not how Horde has been organized, historically. We have a
> number of core developers who all help maintain the codebase. The
> model you describe would be a stretch for us, and create more work for
> those core developers (in needing to pull into many different
> modules). A lot of what went into the current structure is not
> creating extra work for the developers by making us commit
> individually to every application, when that's not how we've worked in
> the past. We have 50+ applications if you count everything in CVS and
> git; that's an awful lot of repositories to maintain.

I'll echo what Chuck said here.  Other projects seem to be based  
around the idea that only mature, bug-free code should be committed to  
the final codebase.  Horde is much more of a "throw some development  
code in and see what happens."  The results might be hideous.  But  
more often than not, the results work out better because the feedback  
gained from other devs/people running HEAD fix, improve, and send the  
code into directions not originally conceived.

A better way to put this is that HEAD is much more experimental than  
many other projects.  This is why our release process takes longer -  
when we fork a release for HEAD, we go through a fairly long release  
process as compared to a project that can fork from HEAD and be ready  
to release within a week.  Both approaches have their pros/cons.

And, quite frankly, my development time is somewhat limited so I don't  
want to be spending all my time pulling patches from various repos.   
I'd rather just pull once and hack away.  I trust the other devs, and  
if there is a mistake/error in the code, it's generally pretty  
straightforward to fix and I can continue on my work.

>> The current setup gives me the impression as if we were coming from
>> CVS - which we did ;) - and wanted to keep the logic behind CVS. But
>> of course distributed revision control is pretty far away from CVS and
>> uses some radically different concepts. And it feels strange if we try
>> to use git for something it was definitely not meant to be used for.
>
> You're right that we're not using the specific linux kernel model of
> development. I wonder, though, if there is a specific area where you
> think git won't work for what we are trying to do with it, though? Our
> current layout is not set in stone, and if there are problems with it
> we'll try to adjust.

Git is a great tool, especially the more I use it.  But this is the  
single biggest hang-up I have with the git community in general;  
namely, that the distributed model (i.e. linux kernel model) is the  
*ONLY* acceptable method of developing. (Read some discussions about  
git rebase sometime.  There are some people who equate using rebase  
with killing a dog).  I heartily disagree.  There was/is a reason why  
the CVS/SVN model has been popular, notwithstanding some  
technical/engineering limitations.

michael

-- 
___________________________________
Michael Slusarz [slusarz at horde.org]