[dev] Horde 5?

Michael J Rubinsky mrubinsk at horde.org
Mon Feb 27 14:28:53 UTC 2012


Quoting Jan Schneider <jan at horde.org>:

> Zitat von Gunnar Wrobel <wrobel at horde.org>:
>
>> Zitat von Ralf Lang <lang at b1-systems.de>:
>>
>>>>> I think we began changing the Wiki page to "Horde 4.1 not planned"
>>>>> before it went into maint.
>>>>
>>>> I would love to start breaking BC and removing deprecated stuff, since
>>>> it seemed like half of the work/fixes I did this evening was figuring
>>>> out how to keep compatibility rather than fixing the problem.
>>>>
>>>> But I also think before we start work on Horde 5 we should probably
>>>> decide on how (or if) to setup the git repo differently than what we
>>>> currently have. Meaning: separate git repos for each
>>>> application/framework going forward?
>>>
>>> Don't know if we shouldn't postpone this repo reorg to release time.
>>
>> If somehow possible I would say we should definitely postpone this.
>>
>> Michael, do you see serious issues ahead in case we don't  
>> reorganize the repo before the next release?
>>
>> Not that I wouldn't like to break up the repo. I said so before and  
>> if we are actually considering this I'm really happy. I'll  
>> definitely invest my part in ensuring that we have the tools ready  
>> to allow working based on a splitted repository. Might mean I will  
>> take a closer look at "composer" which could help.
>>
>> But I don't think we will be able to allow that to delay the  
>> release. The recent hack was already a blow to our planning and I  
>> already see difficulties in sticking to the time line we originally  
>> had in mind. We can maybe extend by a week or two but thats about  
>> it. Restructuring the repo and the tools we use for the release  
>> management is something I don't see given the time we currently  
>> still have available.
>>
>> Cheers,
>>
>> Gunnar
>>
>>>
>>> I'd need some time to figure out/script how to setup a  
>>> devel/integration test installation, how unit tests will work etc.
>>>
>>> If we keep April as release date, I'd rather spend that time  
>>> learning more about the Horde Ajax Framework and Horde_Controller  
>>> - and on fixing these Rdo bugs which may or may not incorporate BC  
>>> breaking changes if needed (I'd rather avoid them).
>
> I agree. With our limited resources, we shouldn't tackle too many  
> things at once.
>
> OTOH I do understand Michael's suggestion that doing the split not  
> long before a major release is probably the best time. At this point  
> the last major version more or less gets into security fixes mode,  
> so there won't be many merges between the two major versions  
> anymore. Having to fix merges after the release with split  
> repositories in develop and a monolithic in master is going to be a  
> major PITA.
>
> It may boil down to doing the split now, or wait until short before  
> the Horde 6 release, which might have the same resource and time  
> constraints like we have now.
>
> I'm a bit torn, I guess I'm not annoyed enough with the monolithic  
> repository yet to go with the pain of splitting them up. But if we  
> agree that we don't want to wait until the Horde 6 release, I'd vote  
> for doing the split before the release of Horde 5. I won't be able  
> to devote much time if any into that task though.

I guess I just don't see the urgency in splitting things. Personally,  
I'd prefer NOT to split the repo. I just don't see what improvements  
that would get us, while it is more likely to cause confusion/issues  
simply due to the increased complexity. Issues with merging would  
still exist with commits that touch the same file(s) within the same  
repo...and those conflicts can be kept to a minimum by committing  
changes that go into both branches into master first. I see it as only  
giving us additional work that we don't really have time for,  
regardless of when we do it - but especially when up against a release  
deadline.

If we do end up having to split things, I'd prefer to keep the  
framework intact and only split the applications. Though I still don't  
see the benefit.
-- 
mike

The Horde Project (www.horde.org)
mrubinsk at horde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6096 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.horde.org/archives/dev/attachments/20120227/3d6aaa4f/attachment.bin>


More information about the dev mailing list