Re: Gamepad KCM

[Jeremy Whiting]

On Sun, Jul 30, 2023 at 1:30 AM David Edmundson 
wrote:

> b) merge it into the gamepad-kcm repo itself
>
> I would suggest doing this. It'll be easiest for future gamepad-kcm
> devs to find than any other repo, and means it'll be obvious if it
> ever becomes obsoleted.
>

Ok, I've copied it into gamepad-kcm and added the needed .reuse changes for
it. Also updated the README.md file for it.

Hopefully with those, anyone should see how to add new gamepad types.


> David
>

Gamepad KCM

[Jeremy Whiting]

Hello,

For the past while Josh and I have spent some time working on a new gamepad
kcm. It currently lives here [1] but we'd like to move it to plasma after a
review period. It also uses an inkscape plugin to export parts of an svg
file to svg images and a qml file for a given gamepad type. The inkscape
plugin lives here [2]. I think it would make sense to either move that into
plasma/ also or either a) into some other tools prefix (do we have one? I
haven't looked in ages) or b) merge it into the gamepad-kcm repo itself. I
think any of those options makes sense to me. Once it has an official
landing place I'll add to the gamepad-kcm readme file how it works, how to
use it, where to get it, etc.

I found xwaylandvideobridge had an issue with a checklist, (not sure if
there's a way to add templates like that to gamepad-kcm, tried by adding
.gitlab-ci.yml and .kde-ci.yml, but no templates appeared, so copy/pasted
and edited) to create
https://invent.kde.org/redstrate/gamepad-kcm/-/issues/1 for tracking
progress/what's still needed I guess.

BR,
Jeremy

1: https://invent.kde.org/redstrate/gamepad-kcm
2: https://invent.kde.org/redstrate/inkscape-gamepad-extension

Re: KDE Applications 16.12 release schedule proposal

[Jeremy Whiting]

+1 from me too. Sorry, been a bit busy lately :( You are awesome Albert.

On Mon, Oct 24, 2016 at 4:31 AM, Aleix Pol  wrote:
> On Sun, Oct 23, 2016 at 12:41 PM, Albert Astals Cid  wrote:
>> As usual noone seems to care enough to comment/+1/-1 so we'll just go with 
>> it.
>>
>> Albert
>>
>> El divendres, 7 d’octubre de 2016, a les 1:11:23 CEST, Albert Astals Cid va
>> escriure:
>>> https://community.kde.org/Schedules/Applications/16.12_Release_Schedule
>>>
>>> Since the proposal is to freeze on 10 Nov, we need to agree/disagree on this
>>> pretty fast.
>>>
>>> So I'm giving you until October 21 to propose suggestions/improvements.
>>>
>>> Cheers,
>>>   Albert
>
> +1 :)
>
> Thanks!
> Aleix

Re: kde-baseapps

[Jeremy Whiting]

It's too late for Applications/16.08 yeah. Is this a port from Qt4 to Qt5?

At any rate after Applications/16.08 has been branched master is open
for changes (maybe that has already happened) so only need to update
dependencies and let i18n-doc mailing list know that master branch is
now qt5/kf5 based and it will be in the next release
Applications/16.12 I guess.

BR,
Jeremy

On Sat, Aug 6, 2016 at 3:07 AM, David Faure  wrote:
> I have ported and bugfixed keditbookmarks in kde-baseapps master.
>
> It's a runtime dependency of konsole, konversation, and other apps using
> KBookmarks.
>
> Is it too late to include kde-baseapps master into Applications/16.08 ?
>
> If so, what is the procedure for making it part of the next release ?
>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>

Re: Fwd: Could I make a tag for k3b kf5 branch?

[Jeremy Whiting]

Usually the person doing a release (you in this case, thanks for
stepping up, we appreciate it) will create the tags. Usually tags are
created from master branch though. I suggest first merging the kf5
branch to master (if it's ready) then announcing the merge on the
i18n-doc mailing list so translations can be moved. Then create a tag
from master branch and release from the tag. There may be a releaseme
script for k3b that you can use in the releaseme git repository. I see
one in there, not sure if it has been updated or even needs to be
updated it may work as is.

thanks,
Jeremy

On Thu, Jul 14, 2016 at 7:49 PM, Leslie Zhai  wrote:
> Hi KDE release team,
>
> I want to maintain K3b KF5 branch if there is NO maintainer any more ;-)
>
> As the CMakeLists.txt file in K3b KF5 branch, the tag version might be
> v2.9.90, can I tag for it? or done by the release manager?
>
>
> 在 2016年07月15日 09:44, Leslie Zhai 写道:
>>
>>
>> -- Forwarded message --
>> From: *Albert Astals Cid* >
>> Date: 2016-07-15 5:20 GMT+08:00
>> Subject: Re: Could I make a tag for k3b kf5 branch?
>> To: Leslie Zhai >
>>
>>
>> El dijous, 14 de juliol de 2016, a les 9:12:42 CEST, Leslie Zhai va
>> escriure:
>> > Hi Michael,
>> >
>> > There is NO maintainer for k3b KF5 branch perhaps, I can maintain k3b
>> > KF5
>> > branch!
>>
>> You should subscribe to the release-team mailing list and send the email
>> there, not to me.
>>
>> I'm not Michael.
>>
>> Cheers,
>>   Albert
>>
>> >
>> > 2016-07-14 5:54 GMT+08:00 Albert Astals Cid > > >:
>> > > --  Missatge reenviat  --
>> > >
>> > > Assumpte: Re: Could I make a tag for k3b kf5 branch?
>> > > Data: dilluns, 11 de juliol de 2016, 18:18:14 CEST
>> > > De: Michael Pyne >
>> > > A: KDE release coordination > > > >
>> > >
>> > > On Mon, July 11, 2016 09:14:50 Leslie Zhai wrote:
>> > > > Hi,
>> > > >
>> > > > K3b kf5 branch might be out of date, and my collegue found a issue
>> > > > https://git.reviewboard.kde.org/r/128376/bugs/365089/
>> > > > I fixed it and David reviewed and ship it, and I want to know could
>> > > > I
>> > >
>> > > make
>> > >
>> > > > a tag, for example v2.9.90 as its CMakeLists.txt
>> > > > https://github.com/KDE/k3b/blob/kf5/CMakeLists.txt#L9 suggested, for
>> > > > k3b
>> > > > kf5 branch? or could you give me some advice about the release
>> > > > version,
>> > > > thanks a lot!
>> > >
>> > > Tagging is normally done by whoever is the release manager for the
>> > > software.
>> > >
>> > > I don't think K3B is released as part of KDE Applications (or Plasma,
>> > > or
>> > > KDE
>> > > Frameworks 5). Is there a maintainer for K3B? If so I'd say ask him or
>> > > her. If
>> > > not... did you want to take over maintenance of K3B? :)
>> > >
>> > > Regards,
>> > >
>> > >  - Michael Pyne
>> > >
>> > > ___
>> > > release-team mailing list
>> > > release-team@kde.org 
>> > > https://mail.kde.org/mailman/listinfo/release-team
>> > >
>> > > -
>>
>>
>>
>>
>>
>> --
>> Regards,
>> Leslie Zhai - a KDE developer
>> https://git.reviewboard.kde.org/users/lesliezhai/
>
>
> --
> Regards,
> Leslie Zhai - a KDE developer
> https://git.reviewboard.kde.org/users/lesliezhai/
>
>
>
> ___
> release-team mailing list
> release-team@kde.org
> https://mail.kde.org/mailman/listinfo/release-team
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Applications release process FAQ

[Jeremy Whiting]

I like it. Nice work.

On Mon, Mar 21, 2016 at 5:47 PM, Sandro Andrade  wrote:
> Hi,
>
> As I went through the release process of Minuet, I had to poke Albert
> with some questions. It's not that we have many new applications
> showing up often, but maybe a FAQ could be useful for future releases
> of new and existing applications.
>
> I added some Q in:
> https://community.kde.org/Applications/Release_Process_FAQ
>
> If you find it useful I may help keeping it up to date and collecting
> new questions which arise in the future.
>
> Thoughts?
>
> Cheers,
> --
> Sandro
> ___
> release-team mailing list
> release-team@kde.org
> https://mail.kde.org/mailman/listinfo/release-team
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: libkdeedu

[Jeremy Whiting]

Works for me.

On Sat, Mar 19, 2016 at 11:12 AM, Albert Astals Cid <aa...@kde.org> wrote:
> El dissabte, 19 de març de 2016, a les 10:57:28 CET, Jeremy Whiting va
> escriure:
>> I don't think we need to release libkdeedu anymore. It contains
>> qt4/kdelibs based libraries that were used by applications that hadn't
>> been ported yet. libkeduvocdocument was moved to libkeduvocdocument
>> repo when it was ported to Qt5/KF5. All applications that use
>> libkeduvocdocument have been ported. I suggest we either don't release
>> it with 16.04 or remove it from the set of what we release for the one
>> after that. I prefer the first, but am ok with the second option if
>> there's a reason someone wants to release it one more time.
>
> Given how close KDE Applications 16.04 is, i'd say remove it for KDE
> Applications 16.08, just to *really* make sure we're not breaking something so
> late.
>
> Cheers,
>   Albert
>
>>
>> thanks,
>> Jeremy
>> ___
>> release-team mailing list
>> release-team@kde.org
>> https://mail.kde.org/mailman/listinfo/release-team
>
>
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

libkdeedu

[Jeremy Whiting]

I don't think we need to release libkdeedu anymore. It contains
qt4/kdelibs based libraries that were used by applications that hadn't
been ported yet. libkeduvocdocument was moved to libkeduvocdocument
repo when it was ported to Qt5/KF5. All applications that use
libkeduvocdocument have been ported. I suggest we either don't release
it with 16.04 or remove it from the set of what we release for the one
after that. I prefer the first, but am ok with the second option if
there's a reason someone wants to release it one more time.

thanks,
Jeremy
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE Applications 16.04 tentative schedule

[Jeremy Whiting]

Looks good to me.

On Thu, Jan 14, 2016 at 1:35 PM, Albert Astals Cid  wrote:
> https://techbase.kde.org/Schedules/Applications/16.04_Release_Schedule
>
> Discuss!
>
> Cheers,
>   Albert
> ___
> release-team mailing list
> release-team@kde.org
> https://mail.kde.org/mailman/listinfo/release-team
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Minor typo in Applications 15.12 announcement

[Jeremy Whiting]

Fixed, thanks for pointing it out.

On Mon, Dec 14, 2015 at 11:57 PM, Yuri Chornoivan  wrote:
> Hi,
>
> announce-applications-15.12.0.php:29:
>
>  Addition");?>
>
> should be "Spectacular".
>
> Thanks for fixing this typo.
>
> Best regards,
> Yuri
> ___
> release-team mailing list
> release-team@kde.org
> https://mail.kde.org/mailman/listinfo/release-team
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: www/sites/www

[Jeremy Whiting]

Looks good to me. Nice work.

On Fri, Nov 20, 2015 at 2:40 PM, Albert Astals Cid  wrote:
> El Friday 20 November 2015, a les 21:13:38, Albert Astals Cid va escriure:
>> SVN commit 1444789 by aacid:
>>
>> KDE Applications 15.12 Beta
>>
>> CCMAIL: release-team@kde.org
>
> Some release notes
> https://community.kde.org/Applications/15.12_Release_Notes
>
> Please fix if anything is wrong.
>
> Cheers,
>   Albert
> ___
> release-team mailing list
> release-team@kde.org
> https://mail.kde.org/mailman/listinfo/release-team
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: New release of Krusader

[Jeremy Whiting]

Extragear tarballs are usually created by scripts in the releaseme got
repo. A quick look there I see the old script for crusader on the kdelibs4
branch. May need to bring it to master branch and give it a try.
On Oct 8, 2015 11:16 AM, "Ovidiu-Florin BOGDAN" 
wrote:

> Hello,
>
>
>
> It has been some time since the last release of Krusader (~2 and a half
> years).
>
>
>
> A lot of fixing has been done since then, and it has been ported to KF5.
> Could we have a release of it?
>
> How would we go about doing this?
>
>
>
> Regards,
> --
>
> Ovidiu-Florin Bogdan
>
> GeekAliens.com 
>
> Kubuntu Romania Representative 
>
> Kubuntu Council Member 
>
> ___
> release-team mailing list
> release-team@kde.org
> https://mail.kde.org/mailman/listinfo/release-team
>
>
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Review Request 125565: KMail: Fix scrolling up/down on the message viewer

[Jeremy Whiting]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/125565/#review86523
---


Explanation makes sense to me. I think a pim person needs to give the ship it 
though.

- Jeremy Whiting


On Oct. 8, 2015, 6:39 p.m., Albert Astals Cid wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/125565/
> ---
> 
> (Updated Oct. 8, 2015, 6:39 p.m.)
> 
> 
> Review request for KDEPIM and Release Team.
> 
> 
> Repository: kdepim
> 
> 
> Description
> ---
> 
> The new style connection for signals does not support default arguments so 
> 
> connect(mScrollUpAction, ::triggered,
> q, ::slotScrollUp);
> 
> Connects the version of triggered(bool) with slotScrollUp meaning that 
> slotScrollUp always gets a 0 since the action is never checked.
> 
> This breaks the API but the widget is only used internally so i think it's 
> something we can live on.
> 
> Release-team can we sneak this onto 15.0.8.2 since it's relatively critical?
> 
> kdepim guys is there a bug number for this?
> 
> 
> Diffs
> -
> 
>   messageviewer/viewer/viewer.h 150c24b 
>   messageviewer/viewer/viewer.cpp ea4fa75 
> 
> Diff: https://git.reviewboard.kde.org/r/125565/diff/
> 
> 
> Testing
> ---
> 
> WORKS
> 
> 
> Thanks,
> 
> Albert Astals Cid
> 
>

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: How do we release dependent libraries for digiKam-5.0.0-beta1?

[Jeremy Whiting]

One other thing to note. All 5 of those libraries that are released
with KDE Applications are kdelibs4/qt4 based on their master branches
currently. To release them with KDE Applications 15.12 they need the
frameworks branches merged to master branch.

On Wed, Sep 23, 2015 at 4:48 PM, Jeremy Whiting <jpwhit...@kde.org> wrote:
> From a release team perspective I don't think we can/should move
> libraries that are currently part of KDE Applications already to
> extragear. We usually release applications with their dependencies
> (except frameworks) at the same time. Releasing libkexiv2 from
> extragear while okular in Applications uses it seems backwards to me.
> Are all 5 of the libraries that are released with KDE Applications
> used by applications that are also released with KDE Applications?
>
> BR,
> Jeremy
>
> On Wed, Sep 23, 2015 at 4:28 PM, Alexander Potashev
> <aspotas...@gmail.com> wrote:
>> Hi everyone,
>> (Luigi pushed me a lot so I finally start this discussion ;))
>>
>> digiKam-5.0.0-beta1 is planned for October 18th, so we need to release
>> its dependencies (KF5-based versions of libraries) at least as
>> alpha/beta versions before that date:
>> 1. libkipi (currently in KDE Applications)
>> 2. libkface (currently in KDE Applications)
>> 3. libkexiv2 (currently in KDE Applications)
>> 4. libkdcraw (currently in KDE Applications)
>> 5. libksane (currently in KDE Applications)
>> 6. libkvkontakte (currently in extragear-libs)
>> 7. libmediawiki (currently in extragear-libs)
>>
>> As listed above, many of these dependent libraries are currently part
>> of KDE Applications, for example in KDE Applications 15.08.x we have
>> kdelibs4-based editions of all 5 relevant libraries from the above
>> list.
>>
>> I see two ways of releasing the 7 libraries mentioned above:
>>  Plan 1: Keep the first 5 ones in KDE Applications and make an alpha
>> release of KDE Applications 15.12.x before October 18th. libkvkontakte
>> and libmediawiki should also be released before that date, but they
>> are not tied to KDE Applications release schedule. (Btw, is it OK if
>> digikam-beta depends on kde-apps-alpha?)
>>  Plan 2: Move all these 7 libraries (their KF5-based versions) into
>> extragear-libs and release them.
>>
>> Please tell us if any of these plans works better for you than the
>> other, and why. Everyone are welcome to share their thoughts -
>> packagers, KDE Apps release team, developers, etc.
>>
>> --
>> Alexander Potashev
>> ___
>> release-team mailing list
>> release-team@kde.org
>> https://mail.kde.org/mailman/listinfo/release-team
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: 15.12 release schedule

[Jeremy Whiting]

Ok, this seems to have no objections. I guess we should make it
official and add it to the ical file?

BR,
Jeremy


On Wed, Aug 26, 2015 at 7:29 AM, Jeremy Whiting <jpwhit...@kde.org> wrote:
> Hey release team.
>
> I've created a proposed Applications 15.12 schedule here:
> https://techbase.kde.org/Schedules/Applications/15.12_Release_Schedule
> . Take a look and let me know if it looks ok. It avoids christmas, new
> years, etc. But let me know if it's hitting any other holidays I don't
> have on my radar.
>
> thanks,
> Jeremy
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: kservice v5.14.1 release

[Jeremy Whiting]

David,

Thanks for all the fixing.

On Wed, Sep 16, 2015 at 3:36 PM, David Faure  wrote:
> On Wednesday 16 September 2015 22:57:31 David Faure wrote:
>> kservice v5.14.1
>> cb25732e88f43cea8ae6d852d165d1dac2844f74
>> 44fa7c3bd52470459cdc924b19393d6c39741c2749e87676126cb7071da9b203  
>> sources/kservice-5.14.1.tar.xz
>
> Wait - please ignore that one. Another regression was reported, fix coming up.
>
> Man this stuff is fragile (but I'm working on making it less so...)
>
> --
> David Faure, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
> ___
> release-team mailing list
> release-team@kde.org
> https://mail.kde.org/mailman/listinfo/release-team
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Superkaramba

[Jeremy Whiting]

Ok requested it be moved to unmaintained. I'll remove it from the scripts
for 15.12 once it has moved.

Thanks,
Jeremy
On Aug 30, 2015 8:36 AM, "Raphael Kubo da Costa" <rak...@freebsd.org> wrote:

> Jeremy Whiting <jpwhit...@kde.org> writes:
>
> > Hey all,
> >
> > I think we should kill superkaramba (move it to unmaintained) like I
> > recently did with ktux and amor for the following reasons:
> >
> > 1. It's old mainly targeted KDE 3.x
> > 2. It's unmaintained.
> > 3. Plasma can do most/all of what it could do.
> > 4. It's not been ported to Qt5/kf5.
> >
> > Any objections?
>
> Nope, works for me with my kdeutils hat.
>
> ___
> release-team mailing list
> release-team@kde.org
> https://mail.kde.org/mailman/listinfo/release-team
>
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: release notes link

[Jeremy Whiting]

Fixed. Maybe adding the link should be added to the todo list for
frameworks releases?

On Mon, Aug 31, 2015 at 10:15 AM,   wrote:
> Hi there :)
>
> The link to the release notes of 5.13 is missing here:
> https://techbase.kde.org/Schedules/Frameworks
>
> I suggest this each month since May, is it maybe possible to automate that
> one ?
>
> Thanks a lot
> ___
> release-team mailing list
> release-team@kde.org
> https://mail.kde.org/mailman/listinfo/release-team
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Superkaramba

[Jeremy Whiting]

Hey all,

I think we should kill superkaramba (move it to unmaintained) like I
recently did with ktux and amor for the following reasons:

1. It's old mainly targeted KDE 3.x
2. It's unmaintained.
3. Plasma can do most/all of what it could do.
4. It's not been ported to Qt5/kf5.

Any objections?

thanks,
Jeremy
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: [kde-community] KGpg

[Jeremy Whiting]

Which aspects of KGpg are nicer to use? Could those same changes come
to Kleopatra possibly? or is this another Parley vs KWordquiz and we
should do our best to keep both around?

On Sun, Aug 30, 2015 at 8:54 AM, Sune Vuorela nos...@vuorela.dk wrote:
 On 2015-08-30, Jeremy Whiting jpwhit...@kde.org wrote:
 Hey all,

 I may have found another candidate for unmaintained. KGpg is a ui for
 gnupg. I've never used it, but have used kleopatra. Anyway, here's my
 reasoning. Please fix any false assumptions I may have made if you
 know kgpg or kleopatra better than I:

 1. KGpg does gnupg. Kleopatra also does, but is maintained.
 2. KGpg has not been ported to Qt5/kf5, Kleopatra has.
 3. KGpg isn't part of kdepim nor is it maintained by the PIM team, Kleopatra 
 is.

 Is there anything that KGpg does that Kleopatra doesn't/can't do? Or
 is there any reason to port KGpg to Qt5/kf5 and keep releasing it?

 I personally prefer the kgpg ui to the kleopatra ui for gpg key
 management.

 /Sune

 ___
 kde-community mailing list
 kde-commun...@kde.org
 https://mail.kde.org/mailman/listinfo/kde-community
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KGpg

[Jeremy Whiting]

Correction, KGpg is maintained, Rolf made commits as late as last
month. My mistake. I gave KGpg a try here and it does seem to work
well. Rolf, could you use a hand porting it to Qt5/KF5 ?

On Sun, Aug 30, 2015 at 8:48 AM, Jeremy Whiting jpwhit...@kde.org wrote:
 Hey all,

 I may have found another candidate for unmaintained. KGpg is a ui for
 gnupg. I've never used it, but have used kleopatra. Anyway, here's my
 reasoning. Please fix any false assumptions I may have made if you
 know kgpg or kleopatra better than I:

 1. KGpg does gnupg. Kleopatra also does, but is maintained.
 2. KGpg has not been ported to Qt5/kf5, Kleopatra has.
 3. KGpg isn't part of kdepim nor is it maintained by the PIM team, Kleopatra 
 is.

 Is there anything that KGpg does that Kleopatra doesn't/can't do? Or
 is there any reason to port KGpg to Qt5/kf5 and keep releasing it?

 thanks,
 Jeremy
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

15.12 release schedule

[Jeremy Whiting]

Hey release team.

I've created a proposed Applications 15.12 schedule here:
https://techbase.kde.org/Schedules/Applications/15.12_Release_Schedule
. Take a look and let me know if it looks ok. It avoids christmas, new
years, etc. But let me know if it's hitting any other holidays I don't
have on my radar.

thanks,
Jeremy
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: This is not working [for me]

[Jeremy Whiting]

On Thu, Jul 30, 2015 at 5:18 PM, Albert Astals Cid aa...@kde.org wrote:
 El Dijous, 30 de juliol de 2015, a les 12:54:01, Jeremy Whiting va escriure:
 Albert,

 I've given this problem a bit of thought since you pasted your
 frustration to me the day 15.08 beta release started (and since the
 original e-mail here). I think fundamentally the problem is that
 there's nobody responsible for each module anymore. We have a list of
 Module Coordinators here:
 https://techbase.kde.org/Projects/Release_Team that is mostly obsolete
 and we don't really have a mechanism in place for replacing people
 there who have left. I'm not suggesting we adopt a top-down heirarchy
 for KDE Applications, but it would be good to have someone specific
 for each module to poke when things aren't ready at release time (or
 any other time tbh). A few names on that list are quite good and
 current, while others have left quite a while ago. For example I don't
 think Gunnar is the one to poke if something in kdeaccessibility is
 broken for some reason. I've e-mailed him a bit about KMail and after
 sending 3 mails over 6 months I got one reply back. We need people on
 that list that are around, available and can fix things in their
 respective areas or can poke someone they know who can. When kdepim
 didn't build or wasn't ready (not all git repos were even in the right
 place in projects, etc.) did you try poking Allen? Would he know who
 to poke if he was asked (I really don't know, not anything against
 Allen, but the pim effort lately seems to have been all Laurent and
 Daniel)? If we have people who are present and aware of their module's
 current contents for each module we then have a release Team rather
 than a release-Albert :) Anyway I suggest the following:

 1) Define what module coordinators responsibility is and what is
 expected of them.

 I'd say this is on the webpage more or less, no? Anything you think may need
 adding/removing?

Yes, that makes sense what's there already. I admit I haven't read
that page all the way through in quite some time :/ it does cover all
the things I was thinking of.


 2) Ask the people on the module coordinator list if they want to be
 coordinators still (and explain what is expected of module
 coordinators).

 I just did that today.

Ok, great.


 3) Create a mechanism for replacing module coordinators that leave or
 fail to perform their responsibilities.

 The last one I'm not so sure about how to handle. I can think of
 having a volunteering situation, and if nobody volunteers we could
 consider retiring the module altogether or putting it on life
 support/LTS. (maybe kdemultimedia is headed there? dunno). Once we
 have a definition of what's required and such it shouldn't be hard to
 define rules for when someone should be phased out. Something like if
 the coordinator is unreachable for X days or weeks on urgent issues
 they get retired from the spot and replaced by someone that can handle
 the responsibilities?

 For the email i sent today I said that if I don't get and answer in two months
 I'll assume it's a no.

 Thanks for giving it a thought, it seems we reached at least a similar
 conclusion is that the list needed updating :)

Yeah, I think having defunct/missing module coordinators has been a
big problem in the past. Hopefully it will get better as we are able
to get more of a team.

BR,
Jeremy


 Cheers,
   Albert


 BR,
 Jeremy

 On Thu, Jul 30, 2015 at 5:07 AM, Albert Astals Cid aa...@kde.org wrote:
  El Diumenge, 1 de març de 2015, a les 23:00:40, Albert Astals Cid va
 
  escriure:
  I don't know how to fix it, I am not even sure what's wrong, but this was
 
  supposed to be a release team, and to me it seems that it's me being the
  bad
 
  guy and everyone else just pushing in for their own agenda.
 
 
 
  Of course this may be my own perception of the thing, but it's affecting
  my
 
  mood and willigness to work on stuff so I decided it made sense to bring
  it
 
  up.
 
 
 
  Some days this week i really wanted to step down for 15.04 but at the end
  i
 
  convinced myself it's too close and I don't want to leave anyone with no
 
  floor to stand on.
 
 
 
  But we need to make this work better for my sanity for 15.08 otherwise
  I'm
 
  out.
 
  Sadly this did not work out for KDE Applications 15.08 and we had the
  same/similar issues like the ones we had with KDE Applications 15.04 and
  my
  mood/motivation/happyness went to hell again.
 
 
 
  This can't continue much.
 
 
 
  Release Team members of each module, please make sure you keep your module
  apps and developers informed about freezes and try to make my life easier.
 
 
 
  Cheers,
 
  Albert
 
  Does anyone have any magic solution?
 
 
 
  Cheers,
 
  Albert
 
 
 
  ___
 
  release-team mailing list
 
  release-team@kde.org
 
  https://mail.kde.org/mailman/listinfo/release-team
 
  ___
  release-team mailing

Re: This is not working [for me]

[Jeremy Whiting]

Albert,

I've given this problem a bit of thought since you pasted your
frustration to me the day 15.08 beta release started (and since the
original e-mail here). I think fundamentally the problem is that
there's nobody responsible for each module anymore. We have a list of
Module Coordinators here:
https://techbase.kde.org/Projects/Release_Team that is mostly obsolete
and we don't really have a mechanism in place for replacing people
there who have left. I'm not suggesting we adopt a top-down heirarchy
for KDE Applications, but it would be good to have someone specific
for each module to poke when things aren't ready at release time (or
any other time tbh). A few names on that list are quite good and
current, while others have left quite a while ago. For example I don't
think Gunnar is the one to poke if something in kdeaccessibility is
broken for some reason. I've e-mailed him a bit about KMail and after
sending 3 mails over 6 months I got one reply back. We need people on
that list that are around, available and can fix things in their
respective areas or can poke someone they know who can. When kdepim
didn't build or wasn't ready (not all git repos were even in the right
place in projects, etc.) did you try poking Allen? Would he know who
to poke if he was asked (I really don't know, not anything against
Allen, but the pim effort lately seems to have been all Laurent and
Daniel)? If we have people who are present and aware of their module's
current contents for each module we then have a release Team rather
than a release-Albert :) Anyway I suggest the following:

1) Define what module coordinators responsibility is and what is
expected of them.
2) Ask the people on the module coordinator list if they want to be
coordinators still (and explain what is expected of module
coordinators).
3) Create a mechanism for replacing module coordinators that leave or
fail to perform their responsibilities.

The last one I'm not so sure about how to handle. I can think of
having a volunteering situation, and if nobody volunteers we could
consider retiring the module altogether or putting it on life
support/LTS. (maybe kdemultimedia is headed there? dunno). Once we
have a definition of what's required and such it shouldn't be hard to
define rules for when someone should be phased out. Something like if
the coordinator is unreachable for X days or weeks on urgent issues
they get retired from the spot and replaced by someone that can handle
the responsibilities?

BR,
Jeremy


On Thu, Jul 30, 2015 at 5:07 AM, Albert Astals Cid aa...@kde.org wrote:
 El Diumenge, 1 de març de 2015, a les 23:00:40, Albert Astals Cid va
 escriure:

 I don't know how to fix it, I am not even sure what's wrong, but this was

 supposed to be a release team, and to me it seems that it's me being the
 bad

 guy and everyone else just pushing in for their own agenda.



 Of course this may be my own perception of the thing, but it's affecting
 my

 mood and willigness to work on stuff so I decided it made sense to bring
 it

 up.



 Some days this week i really wanted to step down for 15.04 but at the end
 i

 convinced myself it's too close and I don't want to leave anyone with no

 floor to stand on.



 But we need to make this work better for my sanity for 15.08 otherwise I'm

 out.



 Sadly this did not work out for KDE Applications 15.08 and we had the
 same/similar issues like the ones we had with KDE Applications 15.04 and my
 mood/motivation/happyness went to hell again.



 This can't continue much.



 Release Team members of each module, please make sure you keep your module
 apps and developers informed about freezes and try to make my life easier.



 Cheers,

 Albert





 Does anyone have any magic solution?



 Cheers,

 Albert



 ___

 release-team mailing list

 release-team@kde.org

 https://mail.kde.org/mailman/listinfo/release-team




 ___
 release-team mailing list
 release-team@kde.org
 https://mail.kde.org/mailman/listinfo/release-team

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: [Kde-pim] What's up with kdepim*?

[Jeremy Whiting]

Framework is more than a synonym for library. Frameworks are those
libraries that we release monthly with a defined API that won't
change. Library is some bit of code that other applications can use.

On Mon, Jul 20, 2015 at 7:21 AM, Aleix Pol aleix...@kde.org wrote:
 On Mon, Jul 20, 2015 at 3:19 PM, laurent Montel mon...@kde.org wrote:
 Le Monday 20 July 2015, 06:45:31 Jeremy Whiting a écrit :
 TLDR we can't release applications that depend on an unreleased framework...

 ?
 So we can release an application which depends on lib which is not released ?

 Framework is a synonym for library. It doesn't make a difference, I'd
 say. Releasing with unreleased dependencies means that distributors
 can't ship what we release, therefore it's a bogus release.

 Aleix
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: [Kde-pim] What's up with kdepim*?

[Jeremy Whiting]

Laurent,

The problem isn't that pim wants to be released again, the problem is
pim people (maybe you, I can't recall) asked for it to not get
released from master until further notice. Then no notice was given.
Notice 3 days after dependency freeze isn't a good idea, causes more
rush and stress on our release team. At any rate if pim depends on
parts of akonadi which are in frameworks that haven't been released,
then we can't release pim until after the first frameworks release
that has what's depended on (or we could put the missing dependency in
the applications release, but that's a bad idea as when would it then
get moved to frameworks release cyle?)

BR,
Jeremy


On Mon, Jul 20, 2015 at 7:21 AM, Aleix Pol aleix...@kde.org wrote:
 On Mon, Jul 20, 2015 at 3:19 PM, laurent Montel mon...@kde.org wrote:
 Le Monday 20 July 2015, 06:45:31 Jeremy Whiting a écrit :
 TLDR we can't release applications that depend on an unreleased framework...

 ?
 So we can release an application which depends on lib which is not released ?

 Framework is a synonym for library. It doesn't make a difference, I'd
 say. Releasing with unreleased dependencies means that distributors
 can't ship what we release, therefore it's a bogus release.

 Aleix
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: [Kde-pim] What's up with kdepim*?

[Jeremy Whiting]

TLDR we can't release applications that depend on an unreleased framework...

On Mon, Jul 20, 2015 at 6:40 AM, Albert Astals Cid aa...@kde.org wrote:
 El Dilluns, 20 de juliol de 2015, a les 13:18:41, laurent Montel va escriure:
 Le Monday 20 July 2015, 10:38:39 laurent Montel a écrit :
  Le Monday 20 July 2015, 09:46:05 laurent Montel a écrit :
akonadi-search is part of playground, we don't release playground
repositories as part of KDE Applications.
  
   Why it was moved in playground
   So what is the solution for it ?
 
  Akonadi-search is not a new lib.
  There is not new feature
  It was just a split from base based on baloo when it was split.
 
  So review was already done.
 
  Is it possible to add an exception for it for moving quickly in correct
  place ?

 Another solution that we discussed with Dan this morning, is if we can't
 have an exception we can release akonadisearch as we release akonadi so
 there is not problem after that.

 Yes, that is still a problem, means we're releasing something like a circular
 dependency.

 KDE Applications (which includes kdepim) depends on akonadi
 KDE Applications (which includes kdepim) depends on akonadi-search
 akonadi-search depends on KDE Applications (which includes kdepim)

 Salut,
   Albert


 Regards.

  Regards
 
Cheers,
   
  Albert

 ___
 release-team mailing list
 release-team@kde.org
 https://mail.kde.org/mailman/listinfo/release-team
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Applications 15.04.3 tarballs are up for packagers

[Jeremy Whiting]

I'm doing everything in the wrong order this time somehow, sorry.

Anyway, marble from this release doesn't build with Qt 5.5 so Anke
Boersma d...@kaosx.us provided a fix that is in a new tarball that
I'm uploading now. The hash and revision are the following:

marble Applications/15.04
11c7e96e96c11ae24a485ce34f95925365acc4f4
5aa065a8271df5f2ef594d8a8cc2985223b1f009a06f1ad569e17ee4b2724bba
sources/marble-15.04.3.tar.xz

I'll chown the folder to let all grab the sources after this upload is
done. The release has been announced on www.kde.org and the other
mailing lists.

BR,
Jeremy

On Fri, Jun 26, 2015 at 9:42 AM, Jeremy Whiting jpwhit...@kde.org wrote:
 Hello packagers,

 Applications 15.04.3 tarballs are up under stable/applications/15.04.3
 I'll try building them all this evening here, so they are untested as
 such. Let me know if you hit any issues with them also and I'll do
 likewise when I test them here.

 BR,
 Jeremy
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Missing tag for Applications 15.04.2 ?

[Jeremy Whiting]

Doh, I forgot to push the tags. I'll fix that now.

On Mon, Jun 15, 2015 at 3:05 PM, jb j...@kdenlive.org wrote:
 Hi,

 I just noticed - after a user request - that there seem to be no tag for the
 KDE 15.04.2 Applications release. Did I miss something or are the applications
 maintainers supposed to create the tags ?

 Thanks for your work and regards,

 For the Kdenlive team,
 Jean-Baptiste Mardelle
 ___
 release-team mailing list
 release-team@kde.org
 https://mail.kde.org/mailman/listinfo/release-team
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

KDE Applications 15.04.2 tarballs are up for packagers

[Jeremy Whiting]

Hello packagers,

Applications 15.04.2 tarballs are up under stable/applications/15.04.2
I'll try building them all this evening here, so they are untested as
such. Let me know if you hit any issues with them also and I'll do
likewise when I test them here.

BR,
Jeremy


REVISIONS_AND_HASHES
Description: Binary data
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE Applications 15.04.2 tarballs are up for packagers

[Jeremy Whiting]

Fixed. Sorry if anyone was downloading. I've moved the files under
their proper src folder now.

BR,
Jeremy

On Fri, May 29, 2015 at 3:16 PM, Jeremy Whiting jpwhit...@kde.org wrote:
 Oops, my mistake. I'll fix that now.

 On Fri, May 29, 2015 at 3:01 PM, Antonio Rojas aro...@archlinux.org wrote:
 Jeremy Whiting wrote:

 Hello packagers,

 Applications 15.04.2 tarballs are up under stable/applications/15.04.2
 I'll try building them all this evening here, so they are untested as
 such. Let me know if you hit any issues with them also and I'll do
 likewise when I test them here.


 The sources are not in a src/ subdir anymore. Is this a permanent change or
 just a mistake in this release? In the latter case, could you please add a
 src - . symlink so as not to break packaging scripts?

 ___
 release-team mailing list
 release-team@kde.org
 https://mail.kde.org/mailman/listinfo/release-team
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

KDE Applications 15.04.1 tarballs are up for packagers

[Jeremy Whiting]

They are in stable/applications.

Release is next Tues May 12 if all goes well.

BR,
Jeremy


REVISIONS_AND_HASHES
Description: Binary data
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE Applications 14.12.2 ready for packagers

[Jeremy Whiting]

That page is about the Applications/14.12 releases, they wont change from
Qt4/kdelibs4 to Qt5/kf5 during the point releases no.

Many more applications will be changing to kf5/Qt5 for the
Applications/15.04 release though, yes.

On Mon, Feb 2, 2015 at 8:47 AM, Eric Hameleers al...@slackware.com wrote:

 On Mon, 2 Feb 2015, Harald Sitter wrote:

  On Mon, Feb 2, 2015 at 4:13 PM, Eric Hameleers al...@slackware.com
 wrote:

 On Fri, 30 Jan 2015, Albert Astals Cid wrote:

  Usual location, I'm at FOSDEM this weekend so it may happen that if you
 guys find some issue (hopefully not) it'll have to wait until monday
 for me
 to act on it.

 Cheers,
  Albert



 Hi Albert

 Where can I find the list of applications that have been ported to
 Qt5/Frameworks versus the ones that still reply on KDE 4 libs?


 this [1] should offer a complete list of kf5 apps in the 14.12 apps
 bundle, everything else is kdelibs4 based

 [1] https://community.kde.org/Frameworks/Application-
 release-status-December-2014

 HS


 That page was last modified in November 2014.

 This means, there will not be a change in KF5 ports for alll the
 Applications 14.12.x releases?
 And likewise, there will be an unchanging list of KF5 ports for the
 upcoming Applications 15.04.x ?

 Cheers, Eric

 --
 Eric Hameleers al...@slackware.com
 Home: http://alien.slackbook.org/blog/
 ___
 release-team mailing list
 release-team@kde.org
 https://mail.kde.org/mailman/listinfo/release-team

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Apps 14.12 release aftermath / Running KF5 apps in KDE 4

[Jeremy Whiting]

Eike,

Thanks for looking into this and notifying us also. I heard some vague
reports but nothing concrete like this.

On Mon, Jan 26, 2015 at 8:58 AM, Eike Hein h...@kde.org wrote:


 Hi,

 it's becoming increasingly clear from feedback that we didn't
 think the decision to ship KF5 apps in 14.12 through very well.

 Distros are currently rolling it out as an upgrade to KDE 4
 systems over the last 4.x apps, and users are running into the
 following problems:

 * KF5-based apps don't pick up visual settings from KDE 4 and
   can't be configured because System Settings 5 is usually not
   co-installable.

   I believe this needs to be addressed in the QPA plugin we
   ship with Frameworks and have added a new BKO product for
   the plugin as well as opened a ticket:

   https://bugs.kde.org/show_bug.cgi?id=343336

 * Some apps apparently don't use the support class to migrate
   the app config file to the fd.o location, which means from
   the user POV they lose all settings for the app.


I know kns3 isn't using this support class to migrate it's registry of
what's been installed to the new locations it uses. Just curious, what
support class are you referring to here?
I know kanagram/khangman also don't use this, but that's probably not as
important, since they don't have many settings anyway.


   Here we need to go through every app and check and fix it,
   and make sure we don't ship anything without that QA check
   again on future ports.

 I cross-posted this to k-c-d and r-t for visibility - I suggest
 we discuss the Frameworks side on k-c-d and the release QA side
 on r-t.


 Cheers,
 Eike
 ___
 release-team mailing list
 release-team@kde.org
 https://mail.kde.org/mailman/listinfo/release-team

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

dolphin for 14.12 release

[Jeremy Whiting]

Hey Emmanuel,

Looking at 
https://community.kde.org/Frameworks/Application-release-status-December-2014#Applications_which_will_release_their_first_stable_Qt5.2BKF5-based_version_in_December_2014
it seems dolphin is still undecided, but the date has past for
feature, string freeze. Please make sure master branch of dolphin is
qt4 based still for the upcoming release and move Dolphin from the
undecided section there to the qt4 based section. (or if you already
merged the frameworks based code to master branch, move it to the kf5
based section there).

thanks,
Jeremy
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: dolphin for 14.12 release

[Jeremy Whiting]

Ok, perfect, I'll update the wiki.

thanks,
Jeremy

On Thu, Oct 30, 2014 at 1:17 PM, Albert Astals Cid aa...@kde.org wrote:
 He did mail me privately one or two days ago.

 He says that it's going to be kdelibs4 based.

 Cheers,
   Albert

 El Dijous, 30 d'octubre de 2014, a les 10:20:05, Jeremy Whiting va escriure:
 Hey Emmanuel,

 Looking at
 https://community.kde.org/Frameworks/Application-release-status-December-20
 14#Applications_which_will_release_their_first_stable_Qt5.2BKF5-based_versio
 n_in_December_2014 it seems dolphin is still undecided, but the date has
 past for
 feature, string freeze. Please make sure master branch of dolphin is
 qt4 based still for the upcoming release and move Dolphin from the
 undecided section there to the qt4 based section. (or if you already
 merged the frameworks based code to master branch, move it to the kf5
 based section there).

 thanks,
 Jeremy
 ___
 release-team mailing list
 release-team@kde.org
 https://mail.kde.org/mailman/listinfo/release-team

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Fwd: kdeedu-data

[Jeremy Whiting]

Ok 2 is done, 1 has reviews pending then will be done too. KHangMan
will be released based on kf5 and Qt5 and will depend on
libkeduvocdocument and kdeedu-data just like Kanagram. No other
applications look for these .kvtml files (though you could open them
in kwordquiz or parley, by asking it to open them by filename. Crisis
averted.

thanks,
Jeremy

On Mon, Oct 27, 2014 at 6:28 AM, Rex Dieter rdie...@math.unl.edu wrote:
 On 10/26/2014 05:18 PM, Jeremy Whiting wrote:

 Ugh, I saw that on fedora recently. Why do distros do that? I guess
 those same distros also patch KStandardDirs to look for files there ?
 Or set KDEHOME or something so it will look there?


 The why was because that dir was also used by kde3, and kde4 introduced
 various conflicts.  off the top of my head (it's been awhile), there were at
 least 2... kate and khtml

 As to how it's implemented, on fedora at least, we build all kde4 packages
 with a standard set of build flags, one of which is:
 -DDATA_INSTALL_DIR:PATH=/usr/share/kde4/apps
 I believe other distros follow a similar convention here, and probably for
 similar reason(s).

 -- Rex

 ___
 release-team mailing list
 release-team@kde.org
 https://mail.kde.org/mailman/listinfo/release-team
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Fwd: kdeedu-data

[Jeremy Whiting]

Sumski,

Yes, you're correct, that is an issue. We are considering a couple of
fixes for that as outlined below.

1. Merge khangman's frameworks branch to master, so it will be qt5/kf5
based for the upcoming release, This way khangman and kanagram (the
two applications that expect these files in kdeedu-data) will be able
to find them fine.
2. Make kdeedu-data install files into share/apps and modify
libkeduvocdocument to also look for the files there also. This way
whether 1 happens or not both applications will be able to find the
files just fine.

I'll make 2 happen now, then look at what's needed in khangman itself
to possibly do 1 above also by release, we'll see.

thanks,
Jeremy

On Thu, Oct 23, 2014 at 12:08 PM, šumski hrvoje.sen...@gmail.com wrote:
 On Thursday 23 of October 2014 16:33:48 Jeremy Whiting wrote:
 -- Forwarded message --
 From: Jeremy Whiting jpwhit...@kde.org
 Date: Thu, Oct 23, 2014 at 8:31 AM
 Subject: kdeedu-data
 To: kde-packager kde-packa...@kde.org, KDE Edu kde-...@kde.org


 Hey packagers,

 A quick heads up about kdeedu-data strangeness.

 The upcoming KDE Applications 14.12 release will have some
 applications based on kdelibs4 and others based on kf5. Because some
 applications that use libkdeedu/libkeduvocdocument are going to be
 still based on kdelibs4 while others have already been ported to qt5
 and kf5 there will be both libkdeedu and libkeduvocdocument tarballs
 released. Because both used to contain a handful of kvtml files, we
 moved them out into kdeedu-data which both libkdeedu and
 libkeduvocdocument should depend on (or at least khangman(kdelibs4)
 and kanagram(libkeduvocdocument) should depend on in order to run.

 Now kdeedu-data uses ecm instructions to build like other kf5 based
 applications. Is that going to be a problem to make both khangman and
 kanagram run time depend on these packages, while kdeedu-data at build
 time requires ecm to build?

 I'm open to other solutions, but this is the best we could come up
 with at this time.
 But will remaining kde4 apps know to find ${DATA_INSTALL_DIR} spoken with 
 e-c-m
 language? IOW, by default, kde4's ${DATA_INSTALL_DIR} = share/apps, with e-
 c-m it's share...


 Cheers,
 Hrvoje
 thanks,
 Jeremy
 ___
 release-team mailing list
 release-team@kde.org
 https://mail.kde.org/mailman/listinfo/release-team

 ___
 release-team mailing list
 release-team@kde.org
 https://mail.kde.org/mailman/listinfo/release-team

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Fwd: kdeedu-data

[Jeremy Whiting]

Ugh, I saw that on fedora recently. Why do distros do that? I guess
those same distros also patch KStandardDirs to look for files there ?
Or set KDEHOME or something so it will look there?

At any rate, with 2 done and posted to reviewboard. If I set KDEHOME
to /usr/local (my kf5 prefix here) qt4 based khangman works fine here
using the files installed by kdeedu-data into
/usr/local/share/apps/kvtml/en . At any rate I'll do all I can to get
khangman's frameworks port ready by the wed freeze so that won't be an
issue anymore either.

thanks,
Jeremy

On Sun, Oct 26, 2014 at 4:04 PM, šumski hrvoje.sen...@gmail.com wrote:
 On Sunday 26 of October 2014 22:53:57 Jeremy Whiting wrote:
 Sumski,

 Yes, you're correct, that is an issue. We are considering a couple of
 fixes for that as outlined below.

 1. Merge khangman's frameworks branch to master, so it will be qt5/kf5
 based for the upcoming release, This way khangman and kanagram (the
 two applications that expect these files in kdeedu-data) will be able
 to find them fine.
 2. Make kdeedu-data install files into share/apps and modify
 libkeduvocdocument to also look for the files there also. This way
 whether 1 happens or not both applications will be able to find the
 files just fine.

 I'll make 2 happen now, then look at what's needed in khangman itself
 to possibly do 1 above also by release, we'll see.
 Err, sorry, i think this will also cause problems, as some distros customize
 apps dir to e.g. share/kde4/apps...


 Cheers,
 Hrvoje
 thanks,
 Jeremy

 On Thu, Oct 23, 2014 at 12:08 PM, šumski hrvoje.sen...@gmail.com wrote:
  On Thursday 23 of October 2014 16:33:48 Jeremy Whiting wrote:
  -- Forwarded message --
  From: Jeremy Whiting jpwhit...@kde.org
  Date: Thu, Oct 23, 2014 at 8:31 AM
  Subject: kdeedu-data
  To: kde-packager kde-packa...@kde.org, KDE Edu kde-...@kde.org
 
 
  Hey packagers,
 
  A quick heads up about kdeedu-data strangeness.
 
  The upcoming KDE Applications 14.12 release will have some
  applications based on kdelibs4 and others based on kf5. Because some
  applications that use libkdeedu/libkeduvocdocument are going to be
  still based on kdelibs4 while others have already been ported to qt5
  and kf5 there will be both libkdeedu and libkeduvocdocument tarballs
  released. Because both used to contain a handful of kvtml files, we
  moved them out into kdeedu-data which both libkdeedu and
  libkeduvocdocument should depend on (or at least khangman(kdelibs4)
  and kanagram(libkeduvocdocument) should depend on in order to run.
 
  Now kdeedu-data uses ecm instructions to build like other kf5 based
  applications. Is that going to be a problem to make both khangman and
  kanagram run time depend on these packages, while kdeedu-data at build
  time requires ecm to build?
 
  I'm open to other solutions, but this is the best we could come up
  with at this time.
 
  But will remaining kde4 apps know to find ${DATA_INSTALL_DIR} spoken with
  e-c-m language? IOW, by default, kde4's ${DATA_INSTALL_DIR} =
  share/apps, with e- c-m it's share...
 
 
  Cheers,
  Hrvoje
 
  thanks,
  Jeremy
  ___
  release-team mailing list
  release-team@kde.org
  https://mail.kde.org/mailman/listinfo/release-team
 
  ___
  release-team mailing list
  release-team@kde.org
  https://mail.kde.org/mailman/listinfo/release-team

 ___
 release-team mailing list
 release-team@kde.org
 https://mail.kde.org/mailman/listinfo/release-team

 ___
 release-team mailing list
 release-team@kde.org
 https://mail.kde.org/mailman/listinfo/release-team

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Fwd: kdeedu-data

[Jeremy Whiting]

-- Forwarded message --
From: Jeremy Whiting jpwhit...@kde.org
Date: Thu, Oct 23, 2014 at 8:31 AM
Subject: kdeedu-data
To: kde-packager kde-packa...@kde.org, KDE Edu kde-...@kde.org


Hey packagers,

A quick heads up about kdeedu-data strangeness.

The upcoming KDE Applications 14.12 release will have some
applications based on kdelibs4 and others based on kf5. Because some
applications that use libkdeedu/libkeduvocdocument are going to be
still based on kdelibs4 while others have already been ported to qt5
and kf5 there will be both libkdeedu and libkeduvocdocument tarballs
released. Because both used to contain a handful of kvtml files, we
moved them out into kdeedu-data which both libkdeedu and
libkeduvocdocument should depend on (or at least khangman(kdelibs4)
and kanagram(libkeduvocdocument) should depend on in order to run.

Now kdeedu-data uses ecm instructions to build like other kf5 based
applications. Is that going to be a problem to make both khangman and
kanagram run time depend on these packages, while kdeedu-data at build
time requires ecm to build?

I'm open to other solutions, but this is the best we could come up
with at this time.

thanks,
Jeremy
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: kdeedu-data

[Jeremy Whiting]

Sorry, I guess I was unclear, kdeedu-data doesn't require any of
frameworks at build time, only ecm and recent cmake.

BR,
Jeremy

On Thu, Oct 23, 2014 at 8:33 AM, Jeremy Whiting jpwhit...@kde.org wrote:
 -- Forwarded message --
 From: Jeremy Whiting jpwhit...@kde.org
 Date: Thu, Oct 23, 2014 at 8:31 AM
 Subject: kdeedu-data
 To: kde-packager kde-packa...@kde.org, KDE Edu kde-...@kde.org


 Hey packagers,

 A quick heads up about kdeedu-data strangeness.

 The upcoming KDE Applications 14.12 release will have some
 applications based on kdelibs4 and others based on kf5. Because some
 applications that use libkdeedu/libkeduvocdocument are going to be
 still based on kdelibs4 while others have already been ported to qt5
 and kf5 there will be both libkdeedu and libkeduvocdocument tarballs
 released. Because both used to contain a handful of kvtml files, we
 moved them out into kdeedu-data which both libkdeedu and
 libkeduvocdocument should depend on (or at least khangman(kdelibs4)
 and kanagram(libkeduvocdocument) should depend on in order to run.

 Now kdeedu-data uses ecm instructions to build like other kf5 based
 applications. Is that going to be a problem to make both khangman and
 kanagram run time depend on these packages, while kdeedu-data at build
 time requires ecm to build?

 I'm open to other solutions, but this is the best we could come up
 with at this time.

 thanks,
 Jeremy
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: The name of Applications 4.14 + 1

[Jeremy Whiting]

Albert,

I have to admit when I first heard KDE Applications 14.12 it sounded
strange to me. It is very similar on glance to 4.12. But the more I
thought about it the more it grew on me, so I say +1 to the name.

BR,
Jeremy


On Wed, Jul 16, 2014 at 5:19 PM, Albert Astals Cid aa...@kde.org wrote:
 Hi all, please let's keep future discussion in kde-promo since i think this is
 more a promo related thing than anything.

 A while ago we decided that 4.14 will be the last KDE 4 Applications release
 and that after that we would switch (at least for a while) to application
 releases where applications are either kdelibs4 based or KF5 based (on a
 tarball/repository level).

 Now we need a name for that thing.

  * We can't call it 4.15 since the 4.x in there for everybody means based in
 kdelibs4.x

  * We can't call it 5.x since the 5.x in there will make people think all apps
 are KF5.x based

  * My suggestion is call it KDE Applications $YEAR.$MONTH, i.e. if we keep
 with the 4 month schedule next release would be KDE Applications 14.12 and
 next-next KDE Applications 15.04. It has a small problem if we slip the
 release from one month to another the name changes, but we just have to plan
 all the releases early in the release month so that even if it slips it still
 falls inside the month.

  * Another possibility would be KDE Applications 1, that doesn't have the
 problem with the sliping release, but I have to say that I would feel quite
 weird calling our next applications release KDE Applications 1 :D

 Anyone has another suggestion?

 Do we go with KDE Applications $YEAR.$MONTH?

 Cheers,
   Albert

 Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe 
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Questions about KDE 4.14 and later + branches

[Jeremy Whiting]

Hello Christoph,

I have the same question re kanagram. It already has a frameworks
branch which builds and runs, and a soc student is working on
fixes/improvements to master branch. but I wonder if I should ask him
to switch his work to be based on kf5 and Qt5 or let him complete his
project on master (which wont be released) since KDE SC 14.12 will be
what's currently in frameworks branch (I'll of course cherry-pick
what's in master at the end of his project into the frameworks branch
then frameworks will become master I guess at that point).

BR,
Jeremy


On Mon, Jul 14, 2014 at 1:03 PM, Christoph Cullmann cullm...@absint.com wrote:
 Hi,

 perhaps I am only a little confused, but I am not sure how
 Kate (kate.git) should progress now in respect of what is KDELIBS 4.x base
 and what is KF 5.x based.

 At the moment, all branches beside frameworks in kate.git are targeted to 
 kdelibs 4.x.
 That means, Kate for 4.14 will still be a kdelibs 4.x application (same for 
 KWrite).

 For later, I would like to switch that over (and main development) to KF 5.x 
 (which has
 already a nice and working ktexteditor KatePart port).

 What would be the normal transition planned for that?

 Leaving KDE/4.14 the last kdelibs 4.x based branch and just killing master 
 and switching it over
 to what is now in frameworks?

 Greetings
 Christoph

 --
 - Dr.-Ing. Christoph Cullmann -
 AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
 Science Park 1 Tel:   +49-681-38360-22
 66123 Saarbrücken  Fax:   +49-681-38360-20
 GERMANYWWW:   http://www.AbsInt.com
 
 Geschäftsführung: Dr.-Ing. Christian Ferdinand
 Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234
 ___
 release-team mailing list
 release-team@kde.org
 https://mail.kde.org/mailman/listinfo/release-team
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: www/sites/www

[Jeremy Whiting]

Is there a manual step to merge this into
http://www.kde.org/releaseschedule.ics ?

thanks,
Jeremy

On Tue, Apr 22, 2014 at 6:59 AM, Kurt Hindenburg
kurt.hindenb...@gmail.com wrote:
 SVN commit 1385056 by hindenburg:

 KDE SC 4.14 add release schedule in icalendar format.

 CCMAIL: release-team@kde.org




  A Releaseschedulekde414.ics


 ___
 release-team mailing list
 release-team@kde.org
 https://mail.kde.org/mailman/listinfo/release-team
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: unifying libdiff2

[Jeremy Whiting]

Like this ?
http://quickgit.kde.org/?p=libkomparediff2.gita=commith=e37e754e69abec2870dbe29c9a46b6f0d40f0fbe


On Thu, Jul 25, 2013 at 1:26 AM, Burkhard Lück lu...@hube-lueck.de wrote:

 Am Mittwoch, 24. Juli 2013, 21:06:04 schrieb Jeremy Whiting:
  Ok, added to module.git in master branch of release-tools.
 
  As for Messages.sh should it use kompare.pot still? or a new .pot file?

 It is a library used by 1 applications so you should use a separate
 catalog
 e.g. named libkomparediff2 and use the K_CATALOG_LOADER macro to load this
 catalog automatically with the library.

 --
 Burkhard Lück


___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: unifying libdiff2

[Jeremy Whiting]

Ok, added to module.git in master branch of release-tools.

As for Messages.sh should it use kompare.pot still? or a new .pot file?

BR,
Jeremy


On Wed, Jul 24, 2013 at 4:58 PM, Albert Astals Cid aa...@kde.org wrote:

 El Dimecres, 24 de juliol de 2013, a les 16:24:40, Jeremy Whiting va
 escriure:
  It will be released with the SC for 4.12.

 Can you please add it to modules.git in release-tools repo?

 Also please fix i18n, you have i18n() calls and no Messages.sh

  I'll be removing it from both
  kompare.git and kdevplatform.git (it's under plugins/patchreview/
  currently) but I guess I can't nuke it from kdevplatform until after KDE
 SC
  4.12 is released, eh?

 Makes sense.

 Cheers,
   Albert

 
  BR,
  Jeremy
 
  On Wed, Jul 24, 2013 at 4:16 PM, Albert Astals Cid aa...@kde.org
 wrote:
   El Dimecres, 24 de juliol de 2013, a les 16:12:15, Jeremy Whiting va
  
   escriure:
Hello Release team, a quick question.  I've split kompare/libdiff2
 into
it's own git repository libkomparediff2 which builds on its own has
 all
branches/tags, etc. but need it to not be split for KDE SC 4.11 since
that's frozen anyway, so I guess I need to only merge my changes to
  
   kompare
  
to the master branch, and KDE/4.11 branch can be used to release KDE
 SC
4.11.x releases, right?
  
   Yes, that is correct.
  
   Is libkomparediff2 going to be part of the SC for 4.12 or released
   independently?
  
   Cheers,
  
 Albert
  
Kevin,
I've pushed my libkomparediff2 to the new official git repo, if you
could
check it and kompare on my branch builds ok for you I'd appreciate
 it.
  
   then
  
I'll enable the hooks and do the other items on my list (make
  
   kdevplatform
  
use it, check the differences between the two copies, etc.
   
thanks,
Jeremy
   
On Sat, Jul 20, 2013 at 4:25 PM, Kevin Kofler 
 kevin.kof...@chello.at
   
   wrote:
 Hi Jeremy,

 On Friday 19 July 2013 at 17:59:33, Jeremy Whiting wrote:
  Thanks for the guidance.  I did decide the actions and such do
  belong
  inside KompareModelList afterall, and found a way to make
  KomparePart
  get
  the actions from the KompareModelList and add them to it's own
  actionCollection.  I've pushed a branch to kompare called
  
   movelibdiff2
  
  if
  you want to take a look.  It works ok here, but I'll let you guys
  see

 what

  you think of my solution.
 
  My libdiff2 is at scratch/whiting/libdiff2 and builds by itself
 and
  installs a LibKompareDiff2Config.cmake file that libdialogpages
 on
  my
  branch uses to find LibKompareDiff2 variables to build against.

 I looked at your changes, everything looks fine to me, so:

 Ship it!

 Kevin Kofler


___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: [Kde-scm-interest] kdenetwork Git migration

[Jeremy Whiting]

Urs,

I think we are good to go now.  I believe scripty got confused because
there was still content in svn and git.  Albert would know more though.
 And yeah, I think replacing only on trunk is enough iirc.

BR,
Jeremy



On Fri, Jun 7, 2013 at 12:07 AM, Urs Wolfer uwol...@kde.org wrote:

 Kopete looks now also good. Thanks to everyone who has helped with the
 migration work.

 I should only replace (remove) things in SVN trunk, right?

 Also, I have noticed one strange thing: Script Kiddy has removed
 translation stuff from all .desktop files in all kdenetwork project (e.g.
 [1]). Is this intended?

 Anything else what needs to be done? Can we officially open the Git repos
 for developers?

 Bye
 urs

 [1] https://projects.kde.org/**projects/kde/kdenetwork/krdc/**
 repository/revisions/**35c459ca0599371ed382565a65cb98**6688f4db40https://projects.kde.org/projects/kde/kdenetwork/krdc/repository/revisions/35c459ca0599371ed382565a65cb986688f4db40



___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: [Kde-scm-interest] kdenetwork Git migration

[Jeremy Whiting]

I just moved the kdeadmin and kdenetwork stuff from release-tools modules
to modules.git on master branch, next need to do something similar for
KDE/4.10 branch to package them in one tarball like I did in the past for
kdesdk and kdetoys.  Anyway, the list is :
KDEAdmin {kuser, kdeadmin-strigi-analyzers, ksystemlog, kcron }
KDENetwork { kdenetwork-filesharing, kdenetwork-strigi-analyzers, kdnssd,
krfb, krdc, kopete, kget }

BR,
Jeremy


On Thu, Jun 6, 2013 at 3:21 AM, Torgny Nyblom nyb...@kde.org wrote:

 On Thursday 06 June 2013 09.33.53 Urs Wolfer wrote:
  Hi Jeremy
 
  Looks good, thanks a lot! :)
 
  I have cherry-picked all standalone fixes into 4.10 branch. Everything
  should build now in master and 4.10 (except Kopete, which is not online
  yet).
 
  I have also update documentation_paths and get_paths in trunk and branch
  locally; I will commit these change once Kopete is also online.
 
  SVN is looked now, so we do not need to hurry with removing it. I can do
  that in some days.

 With my release-team hat on I'd like to request that a list of all created
 gits that are supposed to be part of KDE SC are sent to the release-team
 list
 so that we can update the release procedure without missing any repo.

 /Regards
 Torgny

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Dependency Freeze Exception Request for KGet

[Jeremy Whiting]

KGet has been moved to git now. kdenetwork in svn is locked also, awaiting
kopete to migrate.  KGet should be fine to work on now though in git.

BR,
Jeremy


On Wed, Jun 5, 2013 at 7:36 PM, David Narvaez david.narv...@computer.orgwrote:

 On Wed, Jun 5, 2013 at 10:34 AM, Jeremy Whiting jpwhit...@kde.org wrote:
  Erm, we are in the process of migrating kget (and the rest of kdenetwork)
  from svn to git, when did you plan on making this change?  I would
 suggest
  doing the change after KGet is safely in git, which should be early next
  week in order to give us time to verify everything has moved and tarballs
  can be built right, etc.

 Noted, let us know when this is done.

 David E. Narváez

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

kdeadmin strigi analyzer

[Jeremy Whiting]

After just migrating kdeadmin from svn to git I added the missing bits to
kcron, kuser, and ksystemlog so they build by themselves and tried to do
the same to kdeadmin-strigi-analyzer then realized it doesn't build
anything since it has IF(KFILE_PLUGIN_PORTED) which isn't defined anywhere
(and hasn't ever been from what I can tell).  In discussing what to do with
it with Albert we thought we might want to just move that git repo to
playground or unmaintained (if there is such a place in projects.kde.org)
and maybe even not include it in the kde 4.10.5 release since it was never
built anyway.

Thoughts?

thanks,
Jeremy Whiting
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: kdeadmin strigi analyzer

[Jeremy Whiting]

Yes, I didn't mean to remove all of kdeadmin, just
kdeadmin-strigi-analyzers which doesn't build and hasn't built for quite
some time from what I can tell.

Jeremy


On Thu, Jun 6, 2013 at 3:32 PM, Vadim Zhukov persg...@gmail.com wrote:

 2013/6/7 Jeremy Whiting jpwhit...@kde.org

 After just migrating kdeadmin from svn to git I added the missing bits to
 kcron, kuser, and ksystemlog so they build by themselves and tried to do
 the same to kdeadmin-strigi-analyzer then realized it doesn't build
 anything since it has IF(KFILE_PLUGIN_PORTED) which isn't defined anywhere
 (and hasn't ever been from what I can tell).  In discussing what to do with
 it with Albert we thought we might want to just move that git repo to
 playground or unmaintained (if there is such a place in projects.kde.org)
 and maybe even not include it in the kde 4.10.5 release since it was never
 built anyway.

 Thoughts?


 Well, at least in OpenBSD it is maintained, except those strigi
 analyzers. I think nobody will cry if that code will bite the dust, but
 ksystemlog and others - why? They compile and work, and I plan to push some
 OpenBSD-related updates to them in the near future...

 --
   WBR,
   Vadim Zhukov

 ___
 release-team mailing list
 release-team@kde.org
 https://mail.kde.org/mailman/listinfo/release-team


___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: [Kde-scm-interest] kdenetwork Git migration

[Jeremy Whiting]

Urs,

I just ran a conversion, and cloned the result and found two problems.  One
is krfb git repo doesn't have kcm_krfb folder inside it.  Looking at the
CMakeLists.txt it's not built anyway, but we need to find out why it's not
there at all imo.

The second problem is that kppp has many differences between svn master and
git master, not sure why, but I'll look into it this evening.  We need
these to be working and right before we remove from svn.

thanks,
Jeremy


On Wed, Jun 5, 2013 at 5:03 AM, Raphael Kubo da Costa rak...@freebsd.orgwrote:

 Urs Wolfer uwol...@kde.org writes:

  kdenetwork will get migrated to Git in the next days (between June 5th
  and June 11th). Please do not commit anything into SVN anymore. Also,
  please wait with any Git commits until further notice.

 Sorry if I've missed this being discussed somewhere else, but doesn't it
 make sense to ask the sysadmins to svn lock kdenetwork to prevent people
 from committing?
 ___
 Kde-scm-interest mailing list
 kde-scm-inter...@kde.org
 https://mail.kde.org/mailman/listinfo/kde-scm-interest

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: [Kde-scm-interest] kdenetwork Git migration

[Jeremy Whiting]

Hmm, actually looking deeper kcm_krfb in svn is an empty folder (not sure
what it's for...)

And the differences in kppp seem weird, http://paste.kde.org/759278/ but
shouldn't affect anything from what I can see. so maybe we're good to go?
should I push this into the main git repos and we can test there? Rerun the
conversion if needed, etc.

BR,
Jeremy


On Wed, Jun 5, 2013 at 10:52 AM, Jeremy Whiting jpwhit...@kde.org wrote:

 Urs,

 I just ran a conversion, and cloned the result and found two problems.
  One is krfb git repo doesn't have kcm_krfb folder inside it.  Looking at
 the CMakeLists.txt it's not built anyway, but we need to find out why it's
 not there at all imo.

 The second problem is that kppp has many differences between svn master
 and git master, not sure why, but I'll look into it this evening.  We need
 these to be working and right before we remove from svn.

 thanks,
 Jeremy


 On Wed, Jun 5, 2013 at 5:03 AM, Raphael Kubo da Costa 
 rak...@freebsd.orgwrote:

 Urs Wolfer uwol...@kde.org writes:

  kdenetwork will get migrated to Git in the next days (between June 5th
  and June 11th). Please do not commit anything into SVN anymore. Also,
  please wait with any Git commits until further notice.

 Sorry if I've missed this being discussed somewhere else, but doesn't it
 make sense to ask the sysadmins to svn lock kdenetwork to prevent people
 from committing?
 ___
 Kde-scm-interest mailing list
 kde-scm-inter...@kde.org
 https://mail.kde.org/mailman/listinfo/kde-scm-interest



___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: [Kde-scm-interest] kdenetwork Git migration

[Jeremy Whiting]

Urs,

Ok, kdenetwork-filesharing, kdenetwork-strigi-analyzers, kdnssd, kget,
kppp, krdc and krfb pushed, tags pushed, hooks enabled, i18n branches set
in projects.kde.org settings, and they are enabled for development.
After kopete is migrated, will you replace the svn content with a README
file as that sysadmin mail said? rather than me putting one in each app's
folder.

BR,
Jeremy


On Wed, Jun 5, 2013 at 1:25 PM, Pali Rohár pali.ro...@gmail.com wrote:

 Kopete git conversion scripts on dewey started.

 On Wednesday 05 June 2013 21:10:10 Urs Wolfer wrote:
  Jeremy, I think you can push into the main repos. The kppp
  thing looks like some SVN keyword. I think this change
  doesn't hurt.
 
  Once you pushed into the main repos, you can can notify me
  again. Then I will test also and cherry-pick the build fixes
  into the 4.10 branch.
 
  @Pali: You can run the conversion for Kopete now also.
 
  @all: Please do not commit anything which is not related to
  the conversion at this time!
 
  I have opened a sysadmin ticket for looking SVN repos until
  Git repos on projects.kde.org look okay and we can remove
  them in SVN.
 
  Bye
  urs
 
  On 2013-06-05 18:58, Jeremy Whiting wrote:
   Hmm, actually looking deeper kcm_krfb in svn is an empty
   folder (not sure what it's for...)
  
   And the differences in kppp seem
   weird, http://paste.kde.org/759278/ [2] but shouldn't
   affect anything from what I can see. so maybe we're good to
   go? should I push this into the main git repos and we can
   test there? Rerun the conversion if needed, etc.
  
   BR,
   Jeremy
  
   On Wed, Jun 5, 2013 at 10:52 AM, Jeremy Whiting
   jpwhit...@kde.org
  
   wrote:
   Urs,
  
   I just ran a conversion, and cloned the result and found
   two problems.  One is krfb git repo doesn't have kcm_krfb
   folder inside it.  Looking at the CMakeLists.txt it's not
   built anyway, but we need to find out why it's not there
   at all imo.
  
   The second problem is that kppp has many differences
   between svn master and git master, not sure why, but I'll
   look into it this evening.  We need these to be working
   and right before we remove from svn.
  
   thanks,
   Jeremy
  
   On Wed, Jun 5, 2013 at 5:03 AM, Raphael Kubo da Costa
  
   rak...@freebsd.org wrote:
   Urs Wolfer uwol...@kde.org writes:
   kdenetwork will get migrated to Git in the next days
   (between
  
   June 5th
  
   and June 11th). Please do not commit anything into SVN
   anymore.
  
   Also,
  
   please wait with any Git commits until further notice.
  
   Sorry if I've missed this being discussed somewhere else,
   but doesn't it
   make sense to ask the sysadmins to svn lock kdenetwork to
   prevent people
   from committing?
   ___
   Kde-scm-interest mailing list
   kde-scm-inter...@kde.org
   https://mail.kde.org/mailman/listinfo/kde-scm-interest [1]
  
   Links:
   --
   [1] https://mail.kde.org/mailman/listinfo/kde-scm-interest
   [2] http://paste.kde.org/759278/

 --
 Pali Rohár
 pali.ro...@gmail.com

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: kdesdk migration

[Jeremy Whiting]

On Mon, Dec 10, 2012 at 10:51 PM, Torgny Nyblom nyb...@kde.org wrote:

 **

 On , Jeremy Whiting wrote:

 Hello release team guys,

 In preparing the kdesdk rules for migrating kdesdk from svn to git I'm
 wondering what the best time would be to migrate.  I see 4.10 beta is to be
 tagged next week, would it be best to get the migration done before then?
 or wait until after 4.10 is finally released towards the end of January?
 Either way I'll do a set of conversions into scratch tonight for the
 application maintainers to check.

 Would this involve a split as well? If not I agree, the sooner the better.
 If it will, I would prefer that the monolithic module would be available
 until 4.9.5 is out. This does not mean that the conversion should not
 happen ASAP but that there needs to be a simple way of recreating the old
 tarball layout and to compile it in the same way that is done now.

Torgny,

Yes, this does involve a split up.  See
http://community.kde.org/KDESDK/Git_Migration#Module_Splitup  I was hoping
we could do the final migration this weekend, but if needed we could wait
until 4.9.5 is released or at least tagged at the end of December.

Release guys,

How are we combining git repos into a module for release these days?  I
remember creating some script to combine and put kde-edu into one folder
for tarring when we did the kde-edu migration, but can't remember what the
tool was or where the script went (and maybe something completely different
is used these days anyway).

BR,
Jeremy



 /Regards

 Torgny

 ___
 release-team mailing list
 release-team@kde.org
 https://mail.kde.org/mailman/listinfo/release-team


___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

kdesdk migration

[Jeremy Whiting]

Hello release team guys,

In preparing the kdesdk rules for migrating kdesdk from svn to git I'm
wondering what the best time would be to migrate.  I see 4.10 beta is to be
tagged next week, would it be best to get the migration done before then?
or wait until after 4.10 is finally released towards the end of January?
Either way I'll do a set of conversions into scratch tonight for the
application maintainers to check.

thanks,
Jeremy
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: kdesdk migration

[Jeremy Whiting]

Albert,

Yep, no worries, I wont rush it.  The rules have been in the works for
about a year by now :)  A couple of motivated students of Tomaz have
checked them and added to them recently and I think it's all in place.
I'll do an initial conversion to scratch tonight and let all the
application maintainers check the result then do the real migration this
weekend if all is well probably.

BR,
Jeremy


On Mon, Dec 10, 2012 at 4:24 PM, Albert Astals Cid aa...@kde.org wrote:

 El Dilluns, 10 de desembre de 2012, a les 13:28:45, Jeremy Whiting va
 escriure:
  Hello release team guys,
 
  In preparing the kdesdk rules for migrating kdesdk from svn to git

 Neat!

  I'm
  wondering what the best time would be to migrate.  I see 4.10 beta is to
 be
  tagged next week,

 Your calendar is wrong, we are tagging RC1 next week

 http://techbase.kde.org/Schedules/KDE4/4.10_Release_Schedule#Tuesday.2C_December_18.2C_2012:_KDE_SC_4.10_Release_Candidate_1_Tagging

  would it be best to get the migration done before then?
  or wait until after 4.10 is finally released towards the end of January?

 If you can get it before RC1, it works for me, after RC1 I think that
 changing
 the package layout it is too much (since it would not be a Release
 Candidate
 anymore :D).

 But please *do not rush* the job, writing svn-git rules is hard and in
 some
 cases we had to revert the migrations because the job was incomplete. Make
 sure you contact the appropiate people so you get proper review.

 Cheers,
   Albert

  Either way I'll do a set of conversions into scratch tonight for the
  application maintainers to check.
 
  thanks,
  Jeremy
 ___
 release-team mailing list
 release-team@kde.org
 https://mail.kde.org/mailman/listinfo/release-team

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KSecrets State?

[Jeremy Whiting]

Albert,

Did ksecrets get into the 4.9 rc2? if so it should probably be removed
from the final release at least.

Jeremy

On Thu, Jul 12, 2012 at 3:58 PM, Nicolás Alvarez
nicolas.alva...@gmail.com wrote:
 2012/7/10 Albert Astals Cid aa...@kde.org:
 El Dimarts, 10 de juliol de 2012, a les 10:01:53, Rex Dieter va escriure:
 On 07/10/2012 09:56 AM, Jeremy Whiting wrote:
  It seems it has been moved to playground from kdelibs, but the
  application in kdeutils is still sitting there.  Shouldn't that be
  moved to playground also until it works?

 yes, +1

 If noone disagrees, I'll ask sysadmin on thursday to move the app to
 playground too.

 I have now moved KSecretsService (repo ksecrets.git) to playground/utils.

 (as you probably know, this doesn't affect the git clone URL, only
 projects.kde.org)

 --
 Nicolás
 ___
 release-team mailing list
 release-team@kde.org
 https://mail.kde.org/mailman/listinfo/release-team
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KSecrets State?

[Jeremy Whiting]

It seems it has been moved to playground from kdelibs, but the
application in kdeutils is still sitting there.  Shouldn't that be
moved to playground also until it works?  Every time I build with
kdesrc-build here I get ksecretsserviced which doesn't work, causing
havoc with gnome-keyring which does.

thx,
Jeremy

On Mon, May 21, 2012 at 12:26 AM, Valentin Rusu k...@rusu.info wrote:
 Hello Anne-Marie, Rex


 On 05/18/2012 02:37 PM, Rex Dieter wrote:

 On 05/17/2012 07:01 AM, Anne-Marie Mahfouf wrote:

 A few weeks ago, KSecrets working state was challenged and considered as
 still alpha but as we could not agree on removing it from 4.8 releases,
 it stayed there.
 Now is the question on whether it improved for 4.9 and should be kept in
 the 4.9 release series or if it should be put in a development area
 again.
 Valentin, what's your opinion? Did people try it through the 4.8
 releases and reported problems that you improved? What is your vision
 for the future?



 Well, unfortunately too few people attempted to test the service so I
 haven't got the amount of feedback I was looking for.



 Without any positive feedback on either issue, it seems to me that
 ksecrets is doing more harm than good atm, and removing from 4.9 should be
 considered.


 I think that'll be better that way. I'll have some more time to work on it
 the fall of the summer, when the strategic project I'm working on for my
 employer will go into production.

 Regards,


 --
 Valentin Rusu (IRC valir, KDE vrusu)
 KSecretsService (former KSecretService, KWallet replacement)
 ___
 release-team mailing list
 release-team@kde.org
 https://mail.kde.org/mailman/listinfo/release-team
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: git workflow draft

[Jeremy Whiting]

Ok it seems most people with a preference prefer KDE/X.Y over X.Y and for
valid reasons
1) Other non-kde blessed branches can have obvious names.
2) Kdelibs, base, etc. are already KDE/X.Y
3) More modules are already KDE/X.Y than X.Y so less to fix when enforcing
consistency. (after looking at which repos would need to change, I'm not so
sure about this one...)

Thus I propose we agree to use KDE/X.Y for official kde release branches
going forward and after tagging tomorrow put a notice on relevant mailing
lists and on techbase.  Then one week later perform the required changes to
existing repositories.
1 kdegraphics
2 kdeedu
3 kdeutils
4 kdepim
5 kdepim-runtime
6 kdeplasma-addons
7 kdepimlibs

If I've missed any in the above list, please add them.

best regards,
Jeremy

On Wed, Aug 31, 2011 at 5:00 AM, Sebastian Kügler se...@kde.org wrote:

 On Friday, August 26, 2011 12:06:26 Stephen Kelly wrote:
   Was this decided upon at some point?  I got conflicting stories from
   sysadmin and other developers.  Yesterday after migrating
   kdeaccessibility to git I was asked by a sysadmin to rename the X.Y
   branches to KDE/X.Y  I think concensus and consistency are important
   here.  Was there a decision that the official branches should be named
   X.Y?
  
   My vote goes to KDE/X.Y, it is clearer what it means.
 
  When the frameworks get split out into multiple repos, will they still
 use
  branch names KDE/5.0? What will that mean? Or will we come up with
 another
  scheme then?

 I think they should, here's my reasoning:

 The KDE part of the branch name means it's our official branch, i.e. it's
 done by KDE (not by individuals acting on their own), so basically our
 official namespace. We use $name/feature elsewhere, and I think KDE/5.37
 would
 blend in nicely here. On top of that, it gives some continuity.

 Cheers,
 --
 sebas

 http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: git workflow draft

[Jeremy Whiting]

I forgot to mention some details about my proposal. See below.

On Wed, Aug 31, 2011 at 9:07 AM, Jeremy Whiting jpwhit...@kde.org wrote:

 Ok it seems most people with a preference prefer KDE/X.Y over X.Y and for
 valid reasons
 1) Other non-kde blessed branches can have obvious names.
 2) Kdelibs, base, etc. are already KDE/X.Y
 3) More modules are already KDE/X.Y than X.Y so less to fix when enforcing
 consistency. (after looking at which repos would need to change, I'm not so
 sure about this one...)


Part of the problem with some repositories using X.Y branch naming and
others using KDE/X.Y is that scripts and people that work with our
repositories need to know which ones use which scheme.

My proposal to rename the branches is this.  I (or someone else with access
to each repository) would checkout X.Y branch as KDE/X.Y then push it back
to the repository.  Then the old X.Y branches on the repository would be
removed.  This makes all the branches that are part of KDE SC follow the
consistent KDE/X.Y naming.  Any existing clones with tracking branches to
X.Y named branches would then not be updated unfortunately.  Which is the
reason for the announcement, posting the decision on techbase, including
instructions for updating tracking branches and so on.

In most cases, anyone with a clone without tracking branches will need to do
this:
git remote update
git remote prune origin (or whatever they named the remote)

In cases where tracking branches to X.Y branches are created, they will need
to be recreated to track KDE/X.Y instead.

I hope this clarifies my proposal a bit.  Feel free to ask any questions.

Jeremy

Thus I propose we agree to use KDE/X.Y for official kde release branches
 going forward and after tagging tomorrow put a notice on relevant mailing
 lists and on techbase.  Then one week later perform the required changes to
 existing repositories.
 1 kdegraphics
 2 kdeedu
 3 kdeutils
 4 kdepim
 5 kdepim-runtime
 6 kdeplasma-addons
 7 kdepimlibs

 If I've missed any in the above list, please add them.


 best regards,
 Jeremy


 On Wed, Aug 31, 2011 at 5:00 AM, Sebastian Kügler se...@kde.org wrote:

 On Friday, August 26, 2011 12:06:26 Stephen Kelly wrote:
   Was this decided upon at some point?  I got conflicting stories from
   sysadmin and other developers.  Yesterday after migrating
   kdeaccessibility to git I was asked by a sysadmin to rename the X.Y
   branches to KDE/X.Y  I think concensus and consistency are important
   here.  Was there a decision that the official branches should be
 named
   X.Y?
  
   My vote goes to KDE/X.Y, it is clearer what it means.
 
  When the frameworks get split out into multiple repos, will they still
 use
  branch names KDE/5.0? What will that mean? Or will we come up with
 another
  scheme then?

 I think they should, here's my reasoning:

 The KDE part of the branch name means it's our official branch, i.e.
 it's
 done by KDE (not by individuals acting on their own), so basically our
 official namespace. We use $name/feature elsewhere, and I think KDE/5.37
 would
 blend in nicely here. On top of that, it gives some continuity.

 Cheers,
 --
 sebas

 http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9



___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: git workflow draft

[Jeremy Whiting]

On Tue, Feb 15, 2011 at 10:51 AM, Aaron J. Seigo ase...@kde.org wrote:

 hi all

 so after the meeting on Sunday, here is where we are in terms of a draft
 workflow. more complete meeting minutes can be seen here:

http://titanpad.com/SnJwFW2iXL

 the goal of the meeting was to come up with a draft of a mutually agreeable
 git workflow for kdelibs and kde-runtime. the hope is that this can become
 a
 template for the rest of the SC modules (kde-workspace will follow the
 kdelibs
 workflow, for instance), as well as as many other KDE projects as possible.
 this is to help ensure a general continuity to how we work across KDE.

 Topic Branches
 =

 All new development should happen in a branch. Git makes branches very
 cheap
 and they can be local or remote. There are few if any really good reasons
 not
 to use branches, so development directly in master should be generally
 discouraged.

 Topic / feature branches should be public and pushed to the main repository
 where they are easy for others to find and collaborate on. They should
 start
 as a branch off of master. We do not want git to become, even
 unintentionally,
 a road to segregated, private development at the expense of our
 collaboration
 as a community. With public branches in a shared repository, even a git
 pull
 will inform of new development that is happening. Git then becomes an
 important piece of our development communication with each other: a new
 branch
 means new activity.

 Only features / topics that are intended from the state to be merged with
 master should end up in the main repository, however. More experimental
 and/or
 long term efforts (an example presented was the kconfig refactor leading up
 to
 4.0) should start in a personal clone, and when/if the work crosses the
 border
 into this is realistically going to be merged with master it can be moved
 into a branch in the main repository.

 After merge with master, topic branches should be deleted from the main
 repository.

 Branch Naming: if a branch is specific to a subproject, e.g. solid, specify
 it
 in the branch name such as solid/udevbackend. This will make it easier to
 use git branch listings (along with grep, etc) to pick out branches of
 interest based on the project in question. If there is not a sepcific
 subproject that it belongs to, give it a good descriptive name such as
 pluggable-kconfig.

 No branches should be prefixed with KDE; we consider that a reserved
 name.
 Nor topic should branches be numeric in nature (such as a version number)
 as
 those are reserved for actual release branches. (Sys admin at the meeting
 indicated that it is likely they will eventually put a push hook in place
 that
 prevents such incorrectly named branches.)


Was this decided upon at some point?  I got conflicting stories from
sysadmin and other developers.  Yesterday after migrating kdeaccessibility
to git I was asked by a sysadmin to rename the X.Y branches to KDE/X.Y  I
think concensus and consistency are important here.  Was there a decision
that the official branches should be named X.Y?  Is that documented
somewhere (I spent some time looking, but didn't find it).  If not we should
reach concensus and also fix the repositories that are not following this
standard sooner than later imo.  This will help greatly in the long run.

Thoughts, opinions, etc.
Jeremy



 Branch names should not include the committer name as we have git log and
 it
 will help discourage ego coding where one person has overt ownership of
 the branch. This is still a team effort after all :)

 Dead branches: on every maor every release, a check will be done on
 branches
 in the main repository. Any branches that have not seen any work done on
 them
 in the last TBD: 12? 18? months  will be deleted. Deleted branches are
 backed up automatically on git.kde.org, so work will be retrievable. This
 will
 keep our branch count sane over the years.

 Open questions / topics for further discovery:

* documenting best practices for keeping a topic branch in sync with
 master, keeping in mind that later a merge from the topic branch to master
 needs to be done and the git history sould be kept as clean as possible

* process for announcing that a branch is ready to be merged so as
 to
 gather feedback (particularly important for the shared crown jewels in
 kdelibs); this is something like a kdereview 2.0 though on the level of
 feature branches.

* topic branches and our release cycle: is it acceptable to create a
 new
 topic branch even when we are in feature freeze?

* more advanced workflows involving, e.g., an integration branch is
 not
 something we seem equipped for right now as it brings overhead and
 additional
 coordination with it. Perhaps in the future though 

* best practice recipes for merging, e.g. using git merge --log

 Bugfixes
 ===
 The big question here was forward-porting vs. backporting. Backporting has
 the
 

Re: Heads-up: kdeutils is moving to git

[Jeremy Whiting]

I'm looking to migrate kdeaccessibility this weekend also.  It's mostly
ready, just polishing it a bit in svn first (making each application build
on its own or part of kdeaccessibility).  I'll backport these changes to the
4.7 branch when it's in git.

I'm wondering the same thing, kdeaccessibility has a Mainpage.dox (as did
kdeedu before it split) that we are wondering where to keep also, besides
the top CMakeLists.txt for the released tarball.  I agree a git repo for
each module makes sense rather than putting this stuff into superbuild
(which I discussed with Allen the other night). So it would be something
like this:

kdeaccessibility.git (holds CMakeLists.txt, and Mainpage.dox)
-- jovie.git
--kaccessible.git
--kmag.git
--kmousetool.git
--kmouth.git

with similar setups for kdeedu, kdegraphics, etc.

On the other hand if Dirk is going to use superbuild to do the release
tarballs we could just dump this non-superbuild stuff into there
Mainpage.dox, any top level README, etc. since we need to have module
specific CMakeLists.txt in there anyway for superbuild to work.

thoughts?
Jeremy

On Fri, Aug 19, 2011 at 5:37 AM, Yury G. Kudryashov
urkud.ur...@gmail.comwrote:

 Thomas Zander wrote:

  What do others think about a solution of that kind?
  And is it applicable to our other (former) modules too?
 There is a superbuild script; you can find details in kde-buildsystem ML.
 --
 Yury G. Kudryashov,
 mailto: ur...@mccme.ru

 ___
 release-team mailing list
 release-team@kde.org
 https://mail.kde.org/mailman/listinfo/release-team

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.7.0 tarballs (try#1) uploaded

[Jeremy Whiting]

Dirk,

I just wanted to say thank you for all that you do in preparing the
releases.  You rock.

BR,
Jeremy

On Fri, Jul 22, 2011 at 9:32 AM, Dirk Mueller muel...@kde.org wrote:


 Hi,

 I just finished uploading the first set of KDE 4.7.0 tarballs. Those are
 the
 split tarballs that I mentioned before, I have not succeeded yet in
 creating
 merged tarballs again.

 kde-l10n is still being generated, I'll upload it shortly.

 Please drop an email about show stopper issues to release-team@kde.org,
 and
 any compilation issues or other messups with the tarballs to kde-
 packa...@kde.org, and I'll respond.

 Thanks!

 Dirk
 ___
 release-team mailing list
 release-team@kde.org
 https://mail.kde.org/mailman/listinfo/release-team

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Status of KDE 4.7.0?

[Jeremy Whiting]

Yep, that should be fixed with the commit I did 2 days ago.

Jeremy

On Thu, Jul 21, 2011 at 8:45 AM, Rex Dieter rdie...@math.unl.edu wrote:

 On 07/20/2011 04:15 PM, Dirk Mueller wrote:

  by schedule I should start tagging KDE 4.7.0 tomorrow. Does anybody know
 about
  show stoppers?

 this is worrisome, with a unspecified commit that might fix it
 (unconfirmed),
 http://bugs.kde.org/show_bug.cgi?id=277760

 so, hard to tell, yet.

 -- rex
 ___
 release-team mailing list
 release-team@kde.org
 https://mail.kde.org/mailman/listinfo/release-team

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Further git migrations (and splits)

[Jeremy Whiting]

On Wed, Jun 22, 2011 at 7:23 AM, Raphael Kubo da Costa kub...@gmail.comwrote:

 Dirk Mueller muel...@kde.org writes:

  On Friday 17 June 2011, Nicolas Alvarez wrote:
 
  kdeutils is supposed to release with split tarballs (of course, the
 build
  system in 4.6 has been tweaked to also work as a monolithic tarball for
 the
  4.6.5 release).
 
  Lets hope so. Are the branch names in those git modules at least
  consistent?

 Yes. All SVN branches follow the 'x.y' naming scheme (with no KDE/). The
 ruleset file for this is in [1]. Future branches should follow the same
 convention.

 [1]
 https://projects.kde.org/projects/playground/sdk/kde-ruleset/repository/revisions/master/entry/kdeutils/common-branch-rules

  I'm not sure what's the status of kdeaccessibility, I'll check now.

  Regarding your main question: we have both KDE 4.7.0 and 4.6.5 imminent.
 
  It seems the only sensible solution is to either delay the split until
 4.7.0
  is over (which is a pain because it means that I gotta collect the leaves
 for
  4.7.1, which is supposed to be a minor release), or we need to do it
 before
  4.7.0, essentially before RC1, which is however supposed to be done
 today.
 
  I see no easy solution. what is your timeline for the conversions?

 On the kdeutils side, the migration rules have been ready for a few
 months. However, I'll have some time to properly handle this migration
 only next month. We are not in a hurry to move, so at least kdeutils can
 have its migration delayed until it is OK for you and the rest of the
 release team.


Same for kde-accessibility.  There is general concensus among the active
kde-accessibility developers that we want split repos, though Gunnar (the
release coordinator) hasn't given any input at all...  Anyway, we are ok to
move at any convenient time.  Though personally I'd prefer a time when I
could have some time (maybe a week) to test the resulting repositories and
building split/together so as to not recreate the kdeedu issues we had
earlier.

thanks,
Jeremy

 ___
 release-team mailing list
 release-team@kde.org
 https://mail.kde.org/mailman/listinfo/release-team

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Fwd: KDE 4.6.3 tarballs (try#1 part1) uploaded

[Jeremy Whiting]

kdeedu/cmake no longer exists, each project has a cmake folder underneath it
if it needs cmake modules.  Also, LibKdeEduConfig.cmake which helps
applications find libkdeedu comes from libkdeedu/LibKdeEduConfig.cmake.in.

On Sat, Jun 4, 2011 at 3:42 AM, Dirk Mueller muel...@kde.org wrote:

 On Friday 03 June 2011, Jeremy Whiting wrote:

  I believe you can tag it from git.  Nicolas made each application
 buildable
  standalone or as a group.  The only trick is that libkdeedu needs to be
  built first, but I believe he make some CMake argument you can pass to
 make
  them use relative paths.  I'll check with him.

 I see that this works, however the previous directory kdeedu/cmake/modules
 is
 now completely missing.

 I was expecting this to be in libkdeedu, but I can not find it
 (FindKDEEdu.cmake for example). where is it?

 Thanks,
 Dirk

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: git migration, next steps

[Jeremy Whiting]

On Fri, Jun 3, 2011 at 9:11 AM, Eric Hameleers al...@slackware.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1


 On Fri, 3 Jun 2011, Jeremy Whiting wrote:

  Dirk, all,

 As you may or may not know kdeaccessibility and kdeutils are ready to
 migrate to git (when the freeze is over, don't worry).  And we'd like to
 know what the feeling is about the best time to migrate to minimize
 packaging/releasing stresses.  We'd also like to know what
 packagers/release-team think of the split repos already done in kde-edu,
 etc. Should we provide artificial monolithic tarballs?

 thanks,
 Jeremy Whiting


 Hi Jeremy

 Thanks for asking this, really appreciated.


It needs discussing, so I brought it up.


 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.


As a developer preferring split git repos I'm not against this solution,
assuming dirk wants to go for this.  My plan for kdeaccessibility is to make
one simple CMakeLists.txt that can be used with a tarball of each
application beneath it to simply create what exists in svn now.


 I expressed my thoughts on the split of kdeedu in an earlier post and
 coincidentally 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.  Fragmenting the source tarballs may be only one step but
 seeing what happens in GNOME land, with Redhat employees forcibly pushing
 people into directions they do not want to be taken, I would welcome it if
 KDE would remain the sane, independent desktop enviroment, or even Software
 Collection, that I have come to love.


I was involved with the kdeedu split and I agree it wasn't very well done.
Part of that was bad assumptions on my part, but I think we've learned from
the mistakes made there.  I also don't see how smaller tarballs == more
burden, but I've never been a packager.  I don't see how it creates
something different than the sane, independent desktop environment either,
could you explain that a bit?

thanks,
Jeremy



 Cheers, Eric

 - -- Eric Hameleers al...@slackware.com
 Jabber: al...@jabber.xs4all.nl
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (GNU/Linux)
 Comment: For info see http://quantumlab.net/pine_privacy_guard/

 iEYEARECAAYFAk3o+cAACgkQXlaqr6dcvaC6dgCfeQLtEetvS4t/MEZmIFkrgsEg
 naIAn12z4bp/1EjO00dKiL/HkVizoRVR
 =3XmU
 -END PGP SIGNATURE-

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.6.3 tarballs (try#1 part1) uploaded

[Jeremy Whiting]

Dirk,

At this point, Nicolas has tried the reverting changes to build alone, and
has found that the kdeedu svn-git migration is incomplete.  I suggest we
either release 4.6.3 from the branches/KDE/4.6/kdeedu rev 1227326 or not
release kdeedu as part of 4.6.3 at all.  I don't think it's worth holding
the release up for us to fix the git migration and create the tarball
properly.

Jeremy

On Tue, May 3, 2011 at 6:46 AM, Jorge Manuel B. S. Vicetto 
jmbsvice...@gentoo.org wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 02-05-2011 21:56, Jeremy Whiting wrote:
  Dirk,
 
  I got all the 4.6 branches to build as a whole kdeedu module using the
  attached CMakeLists.txt.  I only changed the CMAKE_CURRENT_SOURCE and
 such
  in those that wouldn't build, but maybe we should change them all.  At
 any
  rate, would you like me to put this simple CMakeLists.txt somewhere (svn
 or
  git) or do you just want to hold on to it until 4.6.x is done.  Are we
 going
  to ship kdeedu as one tarball forever? or will 4.7 be separate tarballs?

 If the release team is considering splitting tarballs for future
 releases, as a Gentoo packager I'd like to ask you to warn us with
 enough advance so that we can review our packaging of KDE.
 It would also help if there were any policies or guidelines about
 independent releases of KDE apps like what just happened with marble
 so that packagers can know whether they should expect that or not.

  thanks,
  Jeremy
 
  ___
  release-team mailing list
  release-team@kde.org
  https://mail.kde.org/mailman/listinfo/release-team

 - --
 Regards,

 Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
 Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.17 (GNU/Linux)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iQIcBAEBAgAGBQJNv/kgAAoJEC8ZTXQF1qEP8JIP/iXb2OueZw3YOubfNXENl1eM
 m6pplaGiLQpua3Mf38g47KPbPmNtRvMGOr39djZsF7BaD8/MnEJIkCm/RY8jAOKG
 N5OD1ne7Z98BnSyuxXTglGa042GLMo5iJlsbJ/mzLVf3L6mBWChKPr5Gjy7xcFlM
 If6wjOV6oMfj5IOhm9NfcxwzobOIBH9++fQjpOrWE02XpQCP7+hwRy1j8ecYrosn
 ODD4OpA8eqgr+7a47/v/M8kCIg14g3UONMWx+F1K4LNjYLR+wlsB9PgkYBvpe78h
 Tx0L+JvHFr+sqhCoPDH+xP+81M07Uf9Qm2U/93eFq4R9tYY9/B3CgI1ub2vd9PMm
 9H74EZxE0CNhpoLNqFfjhlMDFC7pCHMVJH5bEHah3UtqTb9CHlNASvK9Bn0ZHfAk
 fHy7t8UqI7lFj/wzEm/1UaHm9CF4A/i6hZUcD59qz8/6838I1XpcRdZmWdVDijo0
 DWv2HGrKgX/XTXCHVZpDb/tVVghyqhKHGRh4RffktEfXKMOnjLFjTvlfxLJTIPYh
 3g7wIk8IazXrNYG2PwfdbvtjBmMdlxCAccnc44vUULWnJYIS4Cf8sT1rIwNz40/B
 m4cNHXZhXrl5ZElD3ke19tbXWHUahZR5DkIZ6Kb6G3NezGuDfcl6PtaCVnLeyiw7
 ks4eekmJ9tOPvQ4e4tfV
 =Bnm1
 -END PGP SIGNATURE-
 ___
 release-team mailing list
 release-team@kde.org
 https://mail.kde.org/mailman/listinfo/release-team

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.6.3 tarballs (try#1 part1) uploaded

[Jeremy Whiting]

Dirk,

I got all the 4.6 branches to build as a whole kdeedu module using the
attached CMakeLists.txt.  I only changed the CMAKE_CURRENT_SOURCE and such
in those that wouldn't build, but maybe we should change them all.  At any
rate, would you like me to put this simple CMakeLists.txt somewhere (svn or
git) or do you just want to hold on to it until 4.6.x is done.  Are we going
to ship kdeedu as one tarball forever? or will 4.7 be separate tarballs?

thanks,
Jeremy

On Sun, May 1, 2011 at 9:30 PM, Raphael Kubo da Costa kub...@gmail.comwrote:

 Jeremy Whiting jpwhit...@kde.org writes:

  Where are the 4.6.3 tarballs hosted? I'd like to get a fix for the kdeedu
  build issues (I made them all build individually after they were migrated
 to
  git).

 They're currently only available to packagers in ktown. Perhaps Dirk or
 someone from release-team can give you access to it.
 ___
 release-team mailing list
 release-team@kde.org
 https://mail.kde.org/mailman/listinfo/release-team

add_subdirectory(libkdeedu)
add_subdirectory(blinken)
add_subdirectory(cantor)
add_subdirectory(kalgebra)
add_subdirectory(kalzium)
add_subdirectory(kanagram)
add_subdirectory(kbruch)
add_subdirectory(kgeography)
add_subdirectory(khangman)
add_subdirectory(kig)
add_subdirectory(kiten)
add_subdirectory(klettres)
add_subdirectory(kmplot)
add_subdirectory(kstars)
add_subdirectory(ktouch)
add_subdirectory(kturtle)
add_subdirectory(kwordquiz)
add_subdirectory(marble)
add_subdirectory(parley)
add_subdirectory(rocs)
add_subdirectory(step)
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.6.3 tarballs (try#1 part1) uploaded

[Jeremy Whiting]

On Mon, May 2, 2011 at 4:08 PM, Dirk Mueller muel...@kde.org wrote:

 On Sunday 01 May 2011, Mark Davies wrote:


   on kubuntu which doesn't work since it seems to ship the old
   CMakeLists.txt from before but the cmake configuration has
  Couldn't see your log at that url but presume I'm hitting the same
  thing.  Below patches fix some of it but still missing a
  FindLibKdeEdu.cmake for parley and kalgebra and something for
  Avogadro in kalzium.

 I seem to be stuck on those problems as well. I've tried for the last few
 hours to figure out how to easily make those git modules build when
 libkdeedu
 is in the same tarball, but it seems the whole infrastructure for that is
 missing now.

 Anyone who can help with that?


Dirk,

Nicolas Alvarez and I have been testing ways to make the applications depend
on libkdeedu without making it a separate package, but it is trickier than
expected.  We think the best thing to do for the 4.6.3 (and further 4.6
releases) would be to undo the changes I did to make each app build
standalone after the move to git. (putting back in the relative paths to
libkdeedu and such)  So kdeedu 4.6 will always only build as a group, not
standalone since libkdeedu wasn't set up as a proper library back then.

Sound ok?
Jeremy



 Thanks,
 Dirk
 ___
 release-team mailing list
 release-team@kde.org
 https://mail.kde.org/mailman/listinfo/release-team

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: KDE 4.6.3 tarballs (try#1 part1) uploaded

[Jeremy Whiting]

Where are the 4.6.3 tarballs hosted? I'd like to get a fix for the kdeedu
build issues (I made them all build individually after they were migrated to
git).

Thanks,
Jeremy

On Sat, Apr 30, 2011 at 5:31 PM, Manuel Tortosa manutort...@gmail.comwrote:

 The KDEEdu tarball seems completelly borked:

 http://paste.kde.org/43837/




 Best Regards.
 -
 Manuel Tortosa
 manutort...@chakra-project.org
 The Chakra Project
 ___
 release-team mailing list
 release-team@kde.org
 https://mail.kde.org/mailman/listinfo/release-team

___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Restriction for moves from svn to git.

[Jeremy Whiting]

On Friday, April 22, 2011 05:36:49 PM Raphael Kubo da Costa wrote:
 Tom Albers t...@kde.org writes:
  Dear Release Team,
  
  Since I'm less than impressed by some of the movements from svn 
to git
  [1], and considering we should not have to deal which such things
  during the final release stage, I'ld like to propose a restriction for
  all remaining main modules to move from svn to git during the 
period
  from Beta 1 tagging up to the release day of KDE 4.7 [2].
  
  Thursday, May 19, 2011: KDE 4.7 Beta 1 Tagging
  Wednesday, July 27, 2011: KDE 4.7 Release
  
  If there are two supporters and no objections, I'll announce this 
next
  Wednesday or so.
 
 Have we reached any consensus here?

I support that and hope I can get kdeaccessibility migrgated by May 
19th :)

Jeremy

 ___
 release-team mailing list
 release-team@kde.org
 https://mail.kde.org/mailman/listinfo/release-team
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team