'Re: Randa: GIT migration plan for KDE Multimedia'

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

List:       kde-multimedia
Subject:    Re: Randa: GIT migration plan for KDE Multimedia
From:       Christian Esken <esken () kde ! org>
Date:       2011-06-18 11:22:19
Message-ID: 201106181322.19206.esken () kde ! org
[Download RAW message or body]

Am Freitag, 3. Juni 2011, 21:06:17 schrieb ian.monroe@gmail.com:
> On Fri, Jun 3, 2011 at 14:01, Harald Sitter <sitter@kde.org> wrote:
> > On Fri, Jun 3, 2011 at 8:40 PM, ian.monroe@gmail.com
> > <ian.monroe@gmail.com> wrote:
> >> On Fri, Jun 3, 2011 at 13:35, Harald Sitter <sitter@kde.org> wrote:
> >>> On Fri, Jun 3, 2011 at 7:18 PM, ian.monroe@gmail.com
> >>> <ian.monroe@gmail.com> wrote:
> >>>> On Fri, Jun 3, 2011 at 11:02, Harald Sitter <sitter@kde.org> wrote:
> >>>>> On Fri, Jun 3, 2011 at 5:59 PM, ian.monroe@gmail.com

[...]

> >>>>> So we
> >>>>> might as well split proper. It does not make much difference whether
> >>>>> we expand to 5 or 13 repos really.
> >>>>
> >>>> Well people complain a lot, see the latest thread on release-team. I
> >>>> think making the dep tree very simple is a good thing and not hard to
> >>>> do.

I have now read the "git migration, next steps" thread. After that the 
situation doesn't seem to be so easy. What I see is that Distributors have 
valid arguments against a split.

I'll try to summarize the thread as neutral/balanced as possible:

If I understand correctly, one of the issues would be if the change is
sudden and not announced ahead long enough. From 
http://mail.kde.org/pipermail/release-team/2011-June/004875.html:
> Rex Dieter/Fedora: "Seems to me, git repo splits were done only
> for convenience of 
> developers (and rightly so), but without any forethought to the 
> implications that had on source distribution and packagers.  The
> latter  ought to be well-planned and discussed ahead-of-time,
> not rushed in as  an afterthought."
http://mail.kde.org/pipermail/release-team/2011-June/004867.html
> "Split tarballs *after* migrations are final and where it can be
> carefully planned and executed would be more welcome, say for kde-4.8."

This issue can easily be avoided, by announcing early enough.

> >>> It was pointed out by fedora and kubuntu packagers that it makes much
> >>> sense to have kdemm split.

Are you sure about Fedora?
From http://mail.kde.org/pipermail/release-team/2011-June/004869.html:
> Kevin Kofler/Fedora: "In fact, the main Red Hat KDE packager (Than Ngo)
> has also expressed his unhappiness about the split tarballs in the
> Fedora KDE SIG discussions."

And in http://mail.kde.org/pipermail/release-team/2011-June/004884.html:
> Kevin Kofler/Fedora: "Our policy so far has been to only split
> where there is a concrete need for it."

And in http://mail.kde.org/pipermail/release-team/2011-June/004877.html:
> Kevin Kofler/Fedora:
> "more burden", "less flexibility"
> "it is only possible to build multiple binary subpackages from 
> one source package and not the other way round"
> "Doing split binary packages in turn has other problems, e.g.
> huge update  metadata when we push a new version"

Other statements:

http://mail.kde.org/pipermail/release-team/2011-June/004868.html:
> Jeremy Whiting/Slackware: "I fired up this discussion on my blog
> and the SLackware 
> forum a few hours ago... Slackware will have to consider dropping KDE 
> if we are confronted with source fragmentation. We are a small team 
> and can not accept the added burden of maintaining a fragmented KDE 
> based desktop environment."

Summary of concerns in http://mail.kde.org/pipermail/release-team/2011-
June/004874.html:
> Raphael Kubo da Costa/kde-packager:
>  * Adding new packages (SRPMs or whatever) is slow in some distros;
>  * Fear that new tarballs will be released without proper instructions
>    or not following any criteria, so that creating packages and
>    following the dependencies gets harder.

There are also some arguments for splitting:
> Jeremy Whiting/SUN-Port: "I'm porting KDE to Solaris. We often
> face difficulties compiling either due to compiler (Sun Studio)
> or OS differences. The split will actually make it easier to make
> most of KDE available in time [...]

There is a proposed compromise solution, but this makes more work for the kde-
release team. http://mail.kde.org/pipermail/release-team/2011-June/004868.html
> Eric Hameleers/Slackware: I would feel very relieved if the
> old monolithic tarballs would stay as a download option.
> Even if the release team maintains a series of scripts
> that makes a controlled checkout of monolithic tarballs 
> possible for packagers, that would be an acceptible solution.

I am not sure any longer whether splitting is worth the trouble. I am getting 
the impression that it could also effectively lead to an even more fragmented 
kde-multimedia.

   Greetings,
        Christian
_______________________________________________
kde-multimedia mailing list
kde-multimedia@kde.org
https://mail.kde.org/mailman/listinfo/kde-multimedia
[prev in list] [next in list] [prev in thread] [next in thread] 