[arch-dev-public] arch-dev-public, or am i just too dumb?

[Aaron Griffin]

On Fri, Jan 23, 2009 at 10:41 AM, Jan Mette <jan.mette at berlin.de> wrote:
>
> Hi there,
>
> i have just tried it 4 times to respond to this thread:
>
> http://www.archlinux.org/pipermail/arch-dev-public/2009-January/010005.html
>
> Although i have registered today, i get only a "not open for public" message
> that tells me i should respond to your mail address, so maybe i have no
> sufficient rights to post something on this list...
>
> It would be very nice if you can forward my mail to the list.
>
> I am just a "mailing list procrastinator" and have almost no experience with
> this stuff, sorry for bothering you and my dumbness :)

Hey Jan,
Typically what people do is reply to the message and change to address
to arch-general to transfer the thread there. I've sent this on to the
dev list anyway.

Cheers,
Aaron

> ---------------------------------------------------------------------------------------------------------------------
>
>> Hey guys,
>>
>> providing splitted KDE packages is one of most wanted feature request sine
>> there was KDE in Arch. And people have good reasons demanding it. Let's
>> have a look at the problem:
>>
>> The KDE project does not provide source packages for every single
>> application but they put them in some kind of categories. E.g. there are
>> kdenetwork, kdemultimedia, kdegraphics etc.. So if you want an VNC client
>> you have to install kdenetwork and you'll get an instant messanger,
>> download manager, nvc server, samba client and others including their
>> dependencies for free.
>>
>> ...
>>
>> After 4.2 will hit [extra] I'd like to work on this. This will also be a
>> good test case for the makepkg implementation.
>>
>> ...
>>
>> My idea of splitting is to create one package for each app like kopete and
>> not split by data, lib, docs etc.. Those packages will be members of a
>> group; so pacamn -S kdenetwork still results in the same apps being
>> installed.
>>
>> And last but not least: You might wonder why we not just include kdemod. I
>> had a little talk with funkyou about this. KDEmod/Chakra has different
>> goals and philosophy and is not really compatible with the Arch way. So
>> they'd like to keep doing their own thing.
>>
>> Greetings,
>>
>> Pierre
>>
>
> Hi there,
>
> At first: sorry for not responding to the original thread. I have just
> registered on this ML, and i cannot reply to it...
>
> As you may know i am the so-called "lead developer" of KDEmod, although i dont
> like those titles at all and all other people in our team seem to be much more
> capable than myself - so this is just that you can recognize me ;)
>
> I have already talked to Pierre about the whole split stuff and want to add my
> view about it, and also set the record straight on some points he mentioned.
>
> At first, the goals and philosophy of the KDE packages in extra and KDEmod are
> not very different, both are (now) aiming for split KDE modules. I also told
> Pierre that we can remove all of our backports from KDEmod (currently there is
> just one small backported patch in our KDE 4.2 packages) and keep it clean. We
> planned that anyway for the 4.2 version, as it is now completed enough to live
> without those backports.
>
> From my point of view, there isnt a real difference in terms of goals and
> philosophy... And when KDEmod is not compatible to the Arch way, what about
> split KDE packages in extra? Are these conform to the Arch way then? If thats
> the case, i would like to know why... As i see it, splitting up KDE in Arch
> doesn't really conform to the Arch way anymore, at least as i understand
> "...without unnecessary additions, modifications, or complications..." and
> "...an elegant, minimalist approach..."
>
> Oh, and i never said that we would like to continue doing our own thing, just
> to say that... We are absolutely open to make KDEmod more conform to Arch, and
> thats exactly what i told Pierre. We have also just started to port KDEmod to
> the new makepkg with split support, which we plan to use with the release of
> 4.2.1... All in all, KDEmod is also a good testcase for the split support in
> makepkg, and so far there have been no problems with it, good work :)
>
> There is some more stuff i would like to add here, basically my view about the
> whole "split KDE packages in Archs extra repo" idea:
>
> 1. If you split up KDE in Arch, you will basically reinvent the wheel,
> including all mistakes we did during the past ~2 years, which will also affect
> the users of course. It will be the same learning effect that we had, repeated
> by someone else - and splitting up KDE is not as trivial as it may seem. You
> cannot do just one package per app for example. While this may work for
> kdenetwork, most other KDE modules have shared components that need something
> like a "-common" package, so this needs quite a lot of planning and testing.
> To outline the needed efforts: With KDE 4.2 we just have reached a point where
> we can say "ok, its really solid now", and that took a lot of time and efforts
> (since KDE3, to be exact).
>
> 2. Choice is better than two competing projects. Currently, Arch has the
> absolutely best selection of KDE packages available. We have KDE in extra,
> KDEmod, KDEmod KDE 3 packages and of course Tanis repo and Markc's daily SVN
> repo. The result of that is that users have a real choice... And from my
> experience there are also a lot of users who dont like split KDE packages, but
> just want the "plain default".
>
> 3. Our aim with KDEmod is to deliver a "high-class selection" of KDE packages,
> which are both suitable for users and developers. There are quite some KDE
> devs who are using our packages, because we are providing packaged debugging
> symbols for example, and because we are not "tied to any rules" we are also
> able to do weekly updates from the stable KDE branch and such stuff, which
> makes bug-hunting a lot easier.
>
> 4. We are 8 people and several contributors (who test and give feedback) who
> work on the KDEmod packages. This is a lot more manpower than it is available
> for Archs KDE packages - and i can guarentee that doing split packages with
> only 1-2 people is a lot of work, especially when it comes to testing
> packages and packaging a new major release.
>
> 5. If KDE in extra will be split, there will be two competing package sets and
> a lot of doubled efforts. This will maybe result in some confusion for the
> users, and in the end no one really gains something from it. It will also be
> more work for us, because we have to adapt our stuff to the changed KDE
> packages in extra.
>
> Now, please dont misunderstand me here, but from my point of view the current
> plans are not very well-grounded and need some more communication, as they
> will lead to doubled efforts, confusion of users and of course a lot more
> complexity for packagers (like us).  (oops, i am repeating myself, sorry...)
>
> The two solutions i see are:
>
> 1. If people want split packages in Arch, we would be absolutely happy to make
> KDEmod (more) conform to Arch and then put it into [extra]. Of course we would
> also help maintaining it, if you guys accept people as devs who were not very
> active "the official way" before :) Oh, and if that would be the case, we
> would also need to discuss about makepkg support for -debug packages (i have
> already ported the debug patch to the new makepkg with split support), as
> these are quite a standard among distros and would attract a lot more people
> who like to use Arch + KDE, but miss some important features.
>
> 2. We can just continue doing what we did before, let users decide what they
> want to use and keep the choice. That would mean "standard" non-split KDE
> packages in [extra] and of course KDEmod as an alternative, with some more
> features and more agile developers who are not bound to any rules applying to
> Arch. Also, the argument that there are just too much dependencies for KDE in
> [extra] seem a bit like a personal thing of Pierre to me (no offence
> intended). I mean, the KDE 4.2 packages in extra are missing 6 dependencies so
> far, and these are really small and easy to add, and that doesnt justify
> splitting up KDE from my point of view.
>
> I am quite unsure about which way to prefer, so i would like to read some
> opinions about that from you guys... However, i am slightly tending to option
> 2 = leave it like it is and let the users have their choice - of course with
> some more collaborating between us and you guys...
>
> Greetings
>
> Jan (aka funkyou)
>