[Kde-pim] Git migration rules

[Ingo Klöcker]

On Thursday 11 March 2010, Torgny Nyblom wrote:
> On Thursday 11 March 2010 12.10.58 Thomas McGuire wrote:
> > Hi,
> 
> > On Tuesday 09 March 2010 19:17:31 Torgny Nyblom wrote:
> [...]
> 
> > > Yes but... Then we need to be certain about what branches we
> > > should keep since all others (not merged with history) will be
> > > lost.
> > > 
> > > So if someone can give me a list of these branches and we are
> > > 100% sure about them, yes.
> > 
> > Ok, these branches need to exist in the repo, they are still
> > active: - trunk
> > - the X.Y branches (well not sure if we need them all, but at least
> > the 4.Y
> > 
> >   ones, for the occasional securtiy fix)
> > 
> > - akonadi-ports (Akregator is there)
> > - enterprise (KDE3-based, still active development)
> > - enterprise4 (still Kleopatra-related development)
> 
> Added rules for these.

I think we should keep all KDE/X.Y branches. It's nice still to be able 
to build the KDE 2.0 version of KMail. In fact, a few years ago I did 
this in order to make a screenshot for a presentation. :-)


> > Branches that are fully merged, which we don't need as a branch in
> > the repo: - branches/kdepim/soc
> > - branches/work/kdab-post-4.0
> > - branches/kdepim/proko2
> > - branches/work/kdepim-3.5.5+
> > - branches/kdepim/kmail-soc
> > - branches/kdepim/scalix
> > - make-it-cool branch
> > - osnabrück branch
> > - branches/work/~vkrause
> > 
> > No idea about the other branches here.
> > 
> > I also found a bunch of branches in /branches/kdepim/, all of them
> > (except the ones mentioned above) don't need a branch in the repo,
> > including them in the history should be enough.
> 
> No other branches then the ones mentioned in the previous section is
> in the rule files, branches may be added when the migration tool
> finds the merge (not sure about this).
> 
> [snip translations as they stay in svn]
> 
> > 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?
> 
> That would be my choice, since they are branches to those modules.
> 
> > 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.
> 
> Sure.
> 
> > That should cover the enterprise branches, I think.
> > 
> > The "runtime" subdir of kdepim should be added to a seperate repo,
> > kdepim- runtime.
> 
> Is this final, or is the one repo for kdepim and kdepimlibs still on
> the table?

I don't like having a separate repo for kdepim-runtime. One can easily 
put the contents of one Git repo into two different tarballs just like 
we do it now with the kdepim module in SVN.

W.r.t. kdepim and kdepimlibs, I'd put them into different repos.


> > Torgny, you and Ingo are communicating with each other to
> > coordinate, I assume? Also, is there a wiki page with all
> > information or is everything in this thread?
> 
> Not so far, last I heard Ingo had troubles with syncing the
> repository. But I'm sure this will change soon :)

Yeah. I'm finally synching the repo...


Regards,
Ingo
-------------- 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/01a861b3/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/