[Kolab-devel] Question about horde patches
Gunnar Wrobel
wrobel at pardus.de
Tue Dec 4 07:22:34 CET 2007
Richard Bos <ml at radoeka.nl> writes:
> Op Monday 03 December 2007 19:10:21 schreef Gunnar Wrobel:
>> > Why do those 2 modules provide exactly the same patches?
>>
>> Counterquestion: Do you know what fbview is or does? :) A Kolab server
>> offers a standard horde installation and "fbview" which is basically a
>> reduced kronolith installation. So we do in fact have two seperate
>> Horde installations on a Kolab server if the user chooses to install
>> both Horde and fbview. Consequently the patches used in the packages
>> are the same.
>
> Ah, now I understand why there are 2 modules! To be sure, when I install
> kronolith with the FB patches, the FB is integrated in the kronolith (sub)
> menu?
Hm, kronolith is not really kronolith anymore when it's fbview. Sounds
a little bit strange but fbview only offers the functionality
delivered by the attendees.php script within kronolith. So once you
enter fbview you are greeted with a page that let's you enter
user names in order to see when they are free and when they are busy.
>
>> > Now all the patches have been agregrated into 1 patch directory:
>> > server/patches/horde. This is quite nice as those patches have the horde
>> > version in their name, so it is easy to determine on which horde they can
>> > be applied. But those patches are the same as the once above, but
>> > because of their different they are not easy to map to the once above....
>>
>> I disagree. A sed statement to make the two comparable should be
>> trivial. At least as long as I get the filenames right.
>
> I agree with you, that 'sed' can easily rename the files, but it is not that
> trivial that (my) a human eye can easily connect the different files....
>
> .......................
>
>> > To conclude this email; what to do next ;) ? Should things be cleaned
>> > up, or not? I find the current situation confusing.
>>
>> This is bad and of course not intended I will definitely try to
>> improve the situation.
>>
>> > The pach directory might be nice, but is it really needed?
>>
>> I believe it is needed and it serves a completely different function
>> than the package directories.
>>
>> We currently collect all upstream patches required for the Kolab
>> server within "server/patches". We do that for Cyrus Imap, c-client
>> and php as well as for horde. I see this as an external reference
>> point that should provide the first location to look into if you are
>> interested in building the Kolab server on something other than
>> OpenPKG.
>>
>> For Cyrus Imap, c-client and php it is absolutely required to have the
>> patches in Kolab CVS because we don't manage the corresponding
>> packages within Kolab CVS but in OpenPKG CVS.
>>
>> If we wouldn't collect the patches there people like you (for SuSE)
>> and me (for Gentoo) would thus have to download the OpenPKG source
>> packages and try to discern what the patches are actually required
>> for.
>
> I appreciate the patches to be there very (very, very) much!
>
>> I still remeber doing that initially when I build the Kolab2/Gentoo
>> version and it was difficult work since I was unable to discern the
>> meaning of each patch. And for some I didn't know if it was a Kolab
>> relevant patch or if it was only required for OpenPKG to work.
>>
>> That is also the reason why I added the README files with the patches.
>>
>> For Horde the situation is the same. As a packager of a native Kolab
>> version your first point of reference should still be the
>> "server/patches" directory.
>>
>> I probably shouldn't have mixed the fbview specific patches with the
>> horde ones. I fixed this now and created a separate "fbview"
>> folder. But most patches actually match patches from the "horde"
>> directory. Maybe we should also split the current "server/horde"
>> directory into "server/horde" and "server/fbview" at some point.
>>
>> > In case the readme's in that directory are
>> > placed next to the patches in the cvs horde module, it would remain
>> > clear. A single README in the server/patches/horde directory could
>> > explain how to obtain the patches (find server/horde -name "*patch") and
>> > eplain that there are README's for each patch.
>>
>> I will try to add more explicit instructions at a later point.
>>
>> > And what about the directory horde/horde-kronolith and
>> > horde/fbview-kronolith? Can either one be removed?
>>
>> See above.
>>
>> So I guess the main problem originates from the distinction between
>> horde and fbview. I'll try to make the distinction clearer. But I also
>> suggest that you install the OpenPKG server just to see what you get
>> when you call http://mykolab.example.com/horde
>> vs. http://mykolab.example.com/fbview.
>
> I know this (since a long time), but with the introduction of horde I assumed
> that fbview would not exist as seperate thing. Now I understand that there
> is a fully horde integrated fbview (or at least integrated in the menu) and a
> standalone fbview.
I originally thought one could merge the specific fbview patches into
kronolith and remove the fbview package but it really handles a very
specific and distinct use case as compared to what you can do with
kronolith.
Since I now apply most fbview patches also in Kronolith, you actually
get all fbview features also in kronolith but you have to click about
four times until you actually end up in the attendees.php view. If you
want to get a quick overview about when your co-workers or resources
like rooms are available, fbview is much quicker to deliver the
required information.
And there are of course plans to further extend the fbview
functionality.
> My concern (problem) is that the same patch, is located at several places in
> cvs. You know where they are, but will others know?
You are right this is problematic and I'll clean this up.
> I mean, if I would commit a patch to cvs I would do it in
> server/patches/horde or in horde/<application>, but not in both....
If you have a patch for Horde I think it is best to submit it to the
Kolab bug tracker if it is Kolab specific or to the Horde bug tracker
if it is Horde specific. If in doubt, choose the Kolab bug tracker.
Since I can commit in Horde upstream I'd try to get your patch
integrated there.
> It is even more difficult than this, some patches need to committed
> to 3 (perhaps more) locations..... To me this looks very difficult
> to maintain (for others)..... (personnally I would like to see only
> 1 source file, all other files are generated from that (but not
> committed to cvs).
You are of course right and I admit that I forgot that RPM is well
capable of dealing with remote patches. So I don't actually need to
replicate the patches within the horde/* directories. I will remove
them and link directly to Kolab cvs the way we also do it within
OpenPKG cvs.
So the "server/patches" directory will remain the only source
location.
Currently the patches maintained within that directory originate from
http://hg.pardus.de. I'm using mercurial for that since this tool has
fantastic patch management capabilities and I'd go nuts without it :)
In any case that is the reason why it is better if you submit patches
for upstream code like horde in the bug tracker. I can then try to get
it in upstream and maintain it within mercurial.
Of course it would be better if the patch management would be done
within the realm of *.kolab.org. As far as I know Thomas is still
pushing for mercurial use for the Kolab project.
The general problem that I see is that we have different "source"
types within the Kolab server cvs:
- Source code (perl-kolab, php-kolab, kolabconf, kolabd,
kolab-filter, kolab-freebusy, kolab-webadmin)
- Configuration (server/kolabd/kolabd/templates)
- Patches for upstream packages (server/patches)
- Packaging (*.spec files and associated stuff)
Because of the OpenPKG decision there has been a history of mixing
these distinct types within Kolab cvs. I also attribute the fact that
we don't distribute source packages to this. From a packagers
viewpoint it's a simple nightmare ;)
I'd be very much in favor of splitting this better because that would
make understanding the Kolab server easier.
Cheers,
Gunnar
--
______ http://kdab.com _______________ http://kolab-konsortium.com _
p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium
____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de Dr. Gunnar Wrobel
Tel. : +49 40 432 72335 Bundesstrasse 29
Fax : +49 40 432 70855 D-20146 Hamburg
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Mail at ease - Rent a kolab groupware server at p at rdus <<
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
More information about the devel
mailing list