[Kde-pim] Git migration rules

[Thomas McGuire]

Hi,

> > Now to some special enterprise issues:
> > There is branches/kdepim/enterprise/kde-l10n/ and
> > branches/kdepim/enterprise4/l10n-kde4/. I don't think they should be
> > included in the kdepim repo. Can they be added to a seperate repo
> > instead, for example kdepim-enterprise-translations (with two branches)?
> 
> Can't they stay in svn with the rest of the KDE translations?

They are translations to the enterprise branches, which means they won't work 
with the official KDE branches. Furthermore, the only translation in there is 
German, and it includes some custom hacked-together scripts to process 
translations. I don't know how the translation team would feel about having 
this in their repo. I don't have a preference here.
I'd actually like to get rid of the custom scripts, since nobody knows how 
they work, and use the official KDE infrastructure for this. If this is 
somehow possible, that would be great. I need to talk to Albert about this.

> > Then branches/kdepim/enterprise4 contains a bunch of forks of kdelibs and
> > kdebase. I have no idea what to do with them, but we can't loose them.
> > Maybe add as branches to the main kdelibs and kdebase repos?
> 
> What we can do is have enterprise clones of kdelibs, kdepimlibs, kdepim and
> kdebase(-runtime ?), separate to the official KDE clones of each. We can
> have all of the branches we want in the enterprise clones and make
> enterprise releases from those clones. All of the other branch work I
> described separately would also be pushed to the enterprise clone instead
> of the official KDE clone so as not to get in other peoples way.

Ok, good idea as well. With remote branches, this should have no downsides.

> > Next point: enterprise and enterprise4 contain a "packaging" subdir,
> > which I think shouldn't be included in the kdepim repo either. Can we
> > have a seperate repo kdepim-packaging or kdepim-enterprise-packaging for
> > that, with two branches? Just like kdepim-enterprise-translations.
> 
> This could also be a candidate for including in the enterprise clone.

Possibly. Depends on how we split the repos. The "packaging" subdir contains 
rules for all modules, e.g. kdepim and kdepimlibs. If we have a seperate 
enterprise repository that includes both kdepim and kdepimlibs, we can add the 
packaging as-is. Otherwise, when we have a kdepim and kdepimlibs enterprise 
repo, we need to split up the packaging module. No idea how easy this is.

> > That should cover the enterprise branches, I think.
> > 
> > The "runtime" subdir of kdepim should be added to a seperate repo,
> > kdepim- runtime.
> 
> That sounds very inconvenient. Is it worth it? Remember that move-with-
> history doesn't work between different repos (it does work across different
> clones of the same repo of course).

Hmm, move with history doesn't work between repos? So what if we want to move 
stuff from kdepim to kdepimlibs? Or from playground to kde-review? From kde-
review to whereever? All those have the same problem.
I think that kdepim-runtime should be a seperate repo is pretty much decided, 
we also have seperate tarballs for kdepim-runtime right now.

Also, another topic I forgot: The komo (Kontact Mobile) branch at 
/branches/work/komo/. Volker, how should Git migration be handled for that?

Regards,
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20100311/1ab2d1ee/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/