[dev] local git repository re: imp IMAP/MIME changes
Jan Schneider
jan at horde.org
Mon Nov 3 13:27:51 UTC 2008
Zitat von Michael Rubinsky <mrubinsk at horde.org>:
>
> Quoting Chuck Hagenbuch <chuck at horde.org>:
>
>> Quoting Jan Schneider <jan at horde.org>:
>>
>>> I still think this is the best strategy. Moving the libraries over
>>> one-by-one forces us to make sure that each package:
>>> - indeed has been reviewed, converted, refactored
>>> - works with as few dependencies as necessary
>>> - works separately from Horde applications (configuration etc)
>>> - has at least some basic unit tests
>>>
>>> At least that's what I hope this strategy gets us.
>>
>> Those are all good things. I worry about it being too high a
>> barrier. Here's another way of asking: what's keeping you,
>> personally, from converting a library right now?
Having too much to do with doing customer-paid work, and working on
the applications.
>> For me, I'm working on Horde_Date_Parser in git, but it has so much
>> cruft and the code I'm porting from in it right now that I'm doing
>> it in the hatchery. If that's not necessary with git, I'm open to
>> that argument also. I've also thought about moving over the
>> libraries that are already PHP 5 - Horde_Feed and such - but have
>> hesitated to split development between CVS and git too much.
>
> That's the worry I, personally, have. While I think all of us will
> struggle to some degree or another with transitioning to git, I
> worry about the number of things we change at once. Changing over to
> git is a big enough challenge, let alone having to deal with
> remembering what library is in git, or cvs, or if it's in git is it
> in the hatchery etc... While I think the list of goals that Jan has
> laid out is great - I see that list as goals for the library itself,
> not as a goal for moving from one RCS to another. I think it would
> ease the transition if we just made a clean break from CVS once we
> decided it was time. If that means waiting a bit until more
> libraries are in "better shape" or if that means we switch now and
> do the refactoring using git, well, I'm not sure.
Those ideas came from experience. There are a buch of libraries in
framework that I actually wanted to review/refactor when we changed to
the framework packages layout. They still haven't been touched.
I think we need some trigger or force to actually do something about
this and to create packages that are really usable as separate
libraries through pear distribution.
If that doesn't work, we have to go another way of course, but I still
think this is the best approach. Having some libraries in cvs and some
in git shouldn't be too hard, with adding some more magic to
horde-fw-symlink.php.
Jan.
--
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/
More information about the dev
mailing list