[Kde-scm-interest] Meeting minutes

[Chani]

> 
> > - the sizes of the Git object dbs are larger
> 
> i think you posted some numbers before, but would you mind refreshing
> our memory?
> irrespective of the actual numbers i'd venture the guess that on
> average, individual developers would still save disk space, as they
> wouldn't have to download stuff they have no interest in. that applies
> to app developers in particular.

I expect this to be true; how many developers actually check out and compile a 
large percentage of trunk, instead of just using trunk for the stuff they work 
on and stable everything-else (or distro-packaged trunk)?

> 
> > - the module doesn't match the tarball
> >
> > Let me emphasise the last point: you MUST check out today kdelibs,
> > kdepimlibs, kdeutil, kdesdk, etc. You cannot checkout from SVN anything
> > under that and expect it to work.
> >
> > So if we do split, then we need one of two things:
> > a) split the tarballs too; or
> > b) use some kind of script that restores the build structure and
> > maintains it (like repo or git-submodule)
> >
> > Splitting the tarballs would be suicide. Instead of nice 19 tarballs for
> > the main KDE modules, we'd end up with 322 (crude find run). Even if my
> > count is exaggerated, we'd have over 200. Not to mention that the
> > dependency checking that CMake is doing now for us would have to be done
> > by the packagers, in order to build KDE in the proper order.
> 
> what you are presenting as a reason not to do the split is in fact
> probably the most requested feature for / most reported bug against the
> kde distribution process. i don't think we'll ever get a better
> opportunity (well, motivation) to fix it.
> apart from that, the dependency problem isn't new, it will just become
> bigger (to the point of not being manageable without tools).
> it doesn't have to be left to packagers, anyway. in fact, it musn't, as
> otherwise kde devs would be unable to work with it. but that's no biggie
> - when things are split up, the modules must have individual cmake
> checks for their deps anyway. and this is *good*, as it clarifies the
> relationships. and has the nice side effect, that a nightly script could
> auto-collect the dependencies and enter them into the meta-module database.

interesting...
given that packagers have to split up kde applications anyways, could it be 
*good* to offer individual tarballs? if so, wouldn't now be the least painful 
time to make such a change? what if kdegames was a gitorious project with 39 
repos (assuming one extra for shared stuff)?

or would it be easier to just go to git and then convince people to split 
things up later? .. that doesn't sound likely unless the big repos are really 
annoying. but how hard would it be to split up a git repo vs. rearranging 
things in svn before the conversion?

> 
> > For KDE, I'd recommend you always merge up (i.e., p4i). That would
> > solve the conflict issues.
> 
> yes, it would solve that issue, indeed.
> at the cost of being more work (well, ok, who cares) and producing a
> rather terrible merge history.
> if the modules were split up, the merging policy could be determined by
> the respective module maintainers for optimal results.

what's p4i? what does "merge up" mean? :)


-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com