On Sun, Dec 04, 2016 at 08:59:24PM +0100, Hartmut Goebel wrote:
> Hi,
> 
> the number of packages increased to 338(!).
> 
> The first list of 170 contained "only" the applications listed at
> http://kde.org/applications. In addition there are ca. 90 packages in
> download.kde.org/stable/applications and another ca. 90 in
> download.kde.org/stable/ which are not listed at
> http://kde.org/applications. Among these are important things like
> plasma (which AFAIK is the desktop).
> 
> Given this huge number of package, we should agree on
> a) into which .scm we want to split then
> b) a proceeding.
> c) volunteers
> 
> a) into which .scm we want to split then
> 
> The packages in my list have categories like Development, Education,
> Office, Plasma, System, mostly following the categories in
> http://kde.org/applications (plus one or two I created).
> 
> Guix already has kde.scm, containing a few "unsorted" packages, not even
> listed are kde.org/applications. So using a file "kde-application.scm"
> would not give a major benefit compared to using "kde.scm" IMHO. (The
> framework is in kde-framework.scm already).
> 
> Another idea (which I'd prefer) is to put the packages into files
> following the categories above, e.g. "kde-development.scm",
> "kde-edu.scm", etc. It's up to the packager to select where to put the
> "unlisted" stuff.

I have no preferences

> 
> b) proceeding
> 
> I first had the idea to avoid flooding guix-commit with 340 messages by
> pushing *one* commit to "wip-kde-applications". Whoever is working on a
> package would copy-and-pastes the relevant part from this branch into
> his/her working-copy. But when rethinking this, this is to complicated
> and may distract people from working on packages.
> 
> So I'd follow iyzsong's suggestion and prepare 340 commits for
> wip-kde-applications, where others can cherry-pick from and amending
> with "git commit --amend --reset-author" (or using git gui). The commits
> I prepare would already contain an appropriate draft message.
> 
> Additionally I'd putt a lot of information into each package, e.g.
> typical URLs where to look for updates, etc.

This sounds like a good idea

> 
> c) Volunteers
> > Regarding synopses and descriptions, please make sure those that are
> > imported are generally in line with what we do (most likely they are).
> >
> > Congrats on the mass import!  :-)
> 
> Thanks for the congrats, but I'm only preparing the stuff. I'm not going
> to import all these packages :-)
> 
> Does anybody have contact to KDE, KDE developers or Debian maintainers
> we can ask for supporting our efforts? Esp. for the desktop services it
> would be great if somebody already knowing the software could assist.
> May we (Ludo?) could ask the KDE e.V. for assistance?

Back in March KDE started an outreach program to help distributions in
their KDE packaging efforts.
https://dot.kde.org/2016/03/03/announcing-kde-communitys-distribution-outreach-program

> 
> How does this sound? Comments are welcome!
> 
> -- 
> Regards
> Hartmut Goebel
> 
> | Hartmut Goebel          | h.goebel@crazy-compilers.com               |
> | www.crazy-compilers.com | compilers which you thought are impossible |
> 
> 

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted