[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-release-team
Subject:    Re: [Kde-pim] kdepim runtime
From:       Ingo =?iso-8859-15?q?Kl=F6cker?= <kloecker () kde ! org>
Date:       2009-06-17 21:48:27
Message-ID: 200906172348.42377 () thufir ! ingo-kloecker ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Wednesday 17 June 2009, Thomas McGuire wrote:
> On Wednesday 17 June 2009 09:00:36 Volker Krause wrote:
> > On Wednesday 17 June 2009 02:16:38 Allen Winter wrote:
> > > On Tuesday 16 June 2009 10:48:09 am Allen Winter wrote:
> > > > On Thursday 07 May 2009 5:47:03 pm Tom Albers wrote:
> > > > > Hi DIrk, *
> > > > >
> > > > > As discussed today, we would like to have a kdepim-runtime
> > > > > tarball, we would like to have it contain the content of
> > > > > /trunk/KDE/kdepim/akonadi. It should be able to compile stand
> > > > > alone and only contains the stuff that is a runtime
> > > > > dependency for akonadi application.
> >
> > I suggest to just rename akonadi to runtime then, we don't need the
> > extra level of directories there. If possible packaging-wise I
> > would also suggest to omit the apps directory and leave that stuff
> > on top-level, otherwise branch-maintenance will be a nightmare.
> > Keep in mind that we have half a dozen active branches with merge
> > tracking to trunk! At least wait until trunk is open again, then we
> > can merge the work branches (soc, akonadi ports) first, leaving
> > only the 4.x and enterprise branches.
>
> Excellent point about the merging stuff. I actually strongly oppose
> to rename _anything_, unless someone fixes svnmerge.py to take
> renames into account. Merges for stuff that has moved is more
> time-consuming than normal merges, and alone the KOrganizer
> reorganization into "views" subdirectories is annoying enough. I
> don't want that to happen for all of kdepim.
>
> So please don't rename anything, with the possible exception of
> akonadi -> runtime (which will be annoying for merging the Akonadi
> porting branches, probably)

To me (as a semi-outsider) the best option seems to be to leave 
everything as it is for now and revisit the split of kdepim into 
runtime and apps when all apps have been ported to Akonadi (or when the 
amount of parallel branches has dropped again after GSOC is finished).

If kdepim/akonadi is independent of the rest in kdepim then it can still 
be packaged in a kdepim-runtime tarball even if it is not moved to 
kdepim/runtime/akonadi or kdepim/runtime or whatever.

Just my 2 cents.

Regards,
Ingo

["signature.asc" (application/pgp-signature)]

_______________________________________________
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team


[prev in list] [next in list] [prev in thread] [next in thread]