> Zitat von Gunnar Wrobel <wrobel@...>:
>> Zitat von Ralf Lang <lang@...>:
>>>>> 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.
>>> 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
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.