Re: Dropping kdelibs4-based applications in KDE Applications 17.12

[Dominik Haumann]

On Thu, Nov 10, 2016 at 11:42 PM, Albert Astals Cid  wrote:
> Hi, my proposal would be to make KDE Applications 17.08 the last release we
> accept applications based on kdelibs4, that means people have a year until KDE
> Applications 17.12 to port the applications from the list below to KF5.
>
> The ones that aren't ported we would just drop to unmaintained or if they have
> an active developer team that somehow doesn't want to move to KF5 they could
> move to "extreagear".
>
> I know lots of you would want to see this happen *now* but remember there's
> people using those apps so dropping them makes them no good.
>
> Comments?

I think this is a very good idea and support this.

However, the list you provided is possibly longer, for instance there
are applications that are not part of this the Applications release. I
*know* that this sounds like it's off-topic, but I don't think it is
for the following reason:

What do you think about having a Randa meeting (or similar) with focus
on finishing ports to KF5? Would that make sense?

I'm thinking of apps like Kile or similar that while already ported,
still don't have a stable release. I'm pretty sure there are many
more.

Such an initiative would also show that we don't simply drop old apps,
instead, we would show that we care to bring along as many apps as we
can.

Of course, this would only work if we find enough developers that join
such an event.

Greetings
Dominik

Re: KF 5.6 changelog

[Dominik Haumann]

On Saturday 03 January 2015 15:38:15 David Faure wrote:
 On Saturday 03 January 2015 14:32:58 Dominik Haumann wrote:
  @David: libgit2 v0.21 is known to have issues that crash ktexteditor.
  Therefore, we depend on the currently unreleased libgit2 v0.22. This
  dependency is optional, so this dep is no issue at all.
 
 OK, I have repackaged ktexteditor with that fix.
 
 
 ktexteditor v5.6.0-rc2
 0f037f4685945a8db21b0acacc75ab4f7c01c993
 fa7589930038a4dfc68e791355c30e42f175cf8c93123478274cac75f25da7e8  
 sources/ktexteditor-5.6.0.tar.xz

Thanks a lot  sorry for the inconvenience!

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

Re: CHANGELOG keyword

[Dominik Haumann]

On Friday 10 October 2014 21:53:50 Albert Astals Cid wrote:
 Hi people, as discussed in Brno we want the CHANGELOG keyword for automatic
 filling of release notes.
 
 I've added it with a description to
 https://techbase.kde.org/Policies/Commit_Policy#Special_keywords_in_GIT_and_
 SVN_log_messages
 
 What do you think? Should i mail kde-devel, kde-core-devel about it?

As I understand, CHANGELOG was introduced for the frameworks modules.
If I use it in for instance the Kate application (kate.git), CHANGELOG: will 
probably not have any effect, right? Or are there plans to generate changelogs 
also for other pars of KDE code?

 We'll obviously also need a script to parse them :D

I think it's good to have CHANGELOG:
However, when I committed today I basically have this commit log:


Title: fix: guard against broken code folding state on disk

REVIEW: 120506
CHANGELOG: guard against a possibly broken code folding state on disk


In essence, I have the same commit message twice: once in the title, and once 
after CHANGELOG:

I'd like to suggest that if CHANGELOG: is followed by no string, then fall 
back to the title of the commit. So my commit would look like this:

Title: fix: guard against broken code folding state on disk

REVIEW: 120506
CHANGELOG:


Does that make sense  is that doable?

PS: Besides that, I'm often using git-cola, which auto-wraps by default at 
column 72. I personally like that, but in the case of the CHANGELOG: feature 
I'm then limited to ~60 characters, which pretty much again equals what I use 
in the title.

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

Re: 4.11.2 is released

[Dominik Haumann]

On Tuesday, October 01, 2013 07:42:51 PM Albert Astals Cid wrote:
 http://kde.org/announcements/announce-4.11.2.php

I there any reason why Kate is listed twice on [1] ? Once in version 4.10.5, 
and once for 4.11.2.

[1] http://www.kde.org/info/4.11.2.php

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

Re: Re: Exception for Nepomuk Ebook Indexers

[Dominik Haumann]

On Thursday, June 20, 2013 20:55:36 Alexander Neundorf wrote:
 On Thursday 20 June 2013, Vishesh Handa wrote:
  On Thu, Jun 20, 2013 at 7:32 PM, Mario Fux KDE ML kde...@unormal.org
 
 wrote:
   Am Donnerstag 20 Juni 2013, 14.51:38 schrieb Vishesh Handa:
   Hey guys
   
   Morning
   
   I wanted Nepomuk to have some ebook indexers for this release, but I
   never got around to implementing them. I was hoping someone else would
   implement them, since they are so simple, but that never happened.
   
   Anyway, I spent some time today and implemented both epub and mobi
   analyzers. The epub analyzer uses the libepub library, and for the
   mobipocket analyzers I've just copied the code from
   kdegraphics-mobipocket.
   
   I'm not so happy about this part copied the code. Is it not possible
   to
   just use it without duplicating the code?
  
  I couldn't see a way this late into the release.
  
  Ideally, kdegraphics-mobipocket should be creating a library and
  installing it. It currently does not do that. One could make it
  install the library and the headers, but then there are issues of
  binary compatibility.
 
 Copying code is not good.
 OTOH, making code part of a shared library also comes with a cost.
 So I'd say it's probably ok to have the code copied, at least for now.

This is a perfect moment for the infamous quote

  Temporary workarounds tend to become permanent ones. [1]

Oh well, feel free to ignore my mail, just couldn't resist :-P

Greetings,
Dominik

[1] http://lists.kde.org/?l=kde-core-develm=121795820106078
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: playground folder in the kate repo

[Dominik Haumann]

Hi Albert,

On Saturday, 9. June 2012 00:17:55 Albert Astals Cid wrote:
 Hi guys, having the playground folder inside the kate repo is kind of
 confusing since for example the plugin that was added yesterday just showed
 up in scripty in kde-baseapps in the master branch.
 
 Thing is the master branch is what will become 4.9 and translators are
 working on it, so in their world that new plugin is something that will be
 part of 4.9 when it will not.
 
 Is there any reason you don't use separate playground repos like everyone
 else does?

No, there is no reason (I for one simply wasn't aware of it). So to fix it, 
it's ok to delete the code for now (I'm back tomorrow, so if anyone can do it 
earlier, please do so).

Btw, the same probably holds for the pate plugin. This has nothing to do with 
GSoC, though.

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

Re: Status of KDE 4.7.0?

[Dominik Haumann]

On Wednesday, 20. July 2011, Dirk Mueller wrote:
 Hi,
 
 by schedule I should start tagging KDE 4.7.0 tomorrow. Does anybody know
 about show stoppers?

There is a bug in kdelibs so that no all plugins appear in Kate:
- https://bugs.kde.org/show_bug.cgi?id=275548
- https://git.reviewboard.kde.org/r/101610/

It's no critical show-stopper, but it certainly would be good to have it 
fixed rather sooner than later!

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

Re: Question about git repository layout + releases

[Dominik Haumann]

On Thursday, 21. October 2010, Eike Hein wrote:
 On 10/21/2010 07:08 PM, Dominik Haumann wrote:
  This is not entirely correct: True, we want to move the git repo to
  KDE's git infrastructure. Christoph could still merge all changes back
  to svn (just like he does now); this is no issue. Hence, no problem
  for the release cycle.
 
 Well, that's not what Christoph wrote in the bug report, nor
 in his mail to this list:
 
 No my question: Whereas the git stuff is no problem itself, is it then
 still possible to have the kate repo auto-released with KDE SC like atm?

sorry, you're right, of course. This is something Christoph should again 
clarify.

 If that's not on the agenda (for now), then just moving the repo
 is no problem from the sysadmin side.
 
 Unless release-team objects to having SC stuff on git.kde.org until
 the modules migrate. But I'd advise against such an objection because
 the consequence would be that you guys just continue to use Gitorious,
 even without kde-developers, and that sort of fragmentation doesn't
 help anyone.

Yes, so basically this were two questions in one :)

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

Re: Question about git repository layout + releases

[Dominik Haumann]

On Thursday, 21. October 2010, Eike Hein wrote:
 On 10/21/2010 06:06 PM, David Faure wrote:
  I'm not sure, but it seems to me that the sysadmin team (not me, the
  actual sysadmins) has currently a better overview on the git migration
  than release- team. You should probably ask them (#kde-sysadmin on
  irc, or sysadmin@ email).
 
 Actually we (sysadmin team) asked them to ask you guys :-)
 
 Moving the Kate repo from Gitorious to git.kde.org is a non-issue;
 what they want to do in addition to that is stop using SVN entirely
 and require release-team to integrate the contents of their git
 repo into KDE SVN release tarballs. That needs someone other than
 sysadmin to make a call here.

This is not entirely correct: True, we want to move the git repo to KDE's 
git infrastructure. Christoph could still merge all changes back to svn 
(just like he does now); this is no issue. Hence, no problem for the release 
cycle.

In the long run, we indeed would like to consider just using the Kate git 
repository for Kate development (maybe even with KTextEditor interfaces 
included, which atm are in kdelibs). But this is not (neccessarily) related 
to the move we are talking about, and can still be done when kdelibs also 
moved to git.

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

announcements (was: Re: tags/kdesupport-for-4.2)

[Dominik Haumann]

Hi,

On Saturday 03 January 2009, Tom Albers wrote:
 Hi,

 In preparation of the release of 4.2.0, I've created the
 tags/kdesupport-for-4.2. This tag of kdesupport should be used when you
 compile the 4.2 branch in the future.  Trunk's version of kdesupport
 should be used to compile KDE trunk (which would be KDE 4.3.0).

 At least Akonadi will probably commit some KDE 4.2.x incompatible changes
 in kdesupport trunk as soon as KDE 4.2 is branched.

 Request to all kdesupport maintainers: add the version of your software
 into that tag soon please.

Can we have an announcement for this on kde-cvs-announce once this is 
mandatory? Same applies for when the freeze is over and all other 
milestones as well :-)

We've had a thread about this quite some time ago, but I'd like to stress 
this again.

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

Re: A Proposal: EOL 4.1, Branch 4.2, Start 4.3

[Dominik Haumann]

On Friday 05 December 2008, Allen Winter wrote:
 Howdy,
[...]
 Communicate that bugfixing is still a top priority until 4.2.0 is
 released.

I think you can't stress this enough as committing twice is an additional 
burden, and at this point it's especially important that the fixes get into 
the branch.

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

Re: Improving Communication

[Dominik Haumann]

On Tuesday 09 September 2008, Allen Winter wrote:
 Howdy,

 I think we do a terrible job  of keeping the community informed about
 approaching milestones.

 Let's brainstorm about ways we can provide consistent, timely
 reminders/nags. The KDE community should except on-time notifications in
 a known set of channels.

 What channels?  Currently we send email to k-c-d and/or k-d mailing
 lists. Are these the right channels?  Should we use an RSS feed?  others?

Isn't the most important one missing? kde-cvs-announce. Once there was a 
time where all contributors with an svn account were subscribed. I guess 
that's still the case? But it's really silent. A perfect place for those 
announcements though.

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

Kate KDE 4.1 feature plan

[Dominik Haumann]

Hi everyone,

according to [1] the KDE 4.1 feature plan is open until 31 March 2008. There 
is a Kate developer sprint on 11th-13th of April, that's why we wanted to 
ask for an excpetion for Kate until after this weekend (who knows what will 
come out of the meeting in advance). The affected parts are 
- kdelibs/interfaces/ktexteditor,
- kdelibs/kate, and
- kdesdk/kate

Thanks,
Dominik

[1] http://techbase.kde.org/index.php?title=Schedules/KDE4/4.1_Feature_Plan
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: [kde-ev-marketing] [Kde-hci] Suggested release schedule for KDE 4.0

[Dominik Haumann]

On Thursday 08 March 2007, Aaron J. Seigo wrote:
  KDE 4.0 will be reviewed as a Vista competitor,

 that's a marketing issue, and the key is expectation management and clear
 communication about how the development process works.

  and it would make a
  disastrous impression if core elements of the user interface are either
  not present yet or have an extremely bad usability because of a rushed
  schedule. It would also make a disastrous impression if important
  desktop applications (e.g. kdepim) are missing from the KDE 4.0 end
  user release.

 it could be disastrous if we try and tell the world that 4.0 is The
 Release To End All Releases. it doesn't need to be disastrous if we
 communicate the difference and relationship between KDE4 and the 4.0
 release milestone.

this is a very important point Stephan Binner already brought up in his 
blog 'Disambiguation KDE 4, did you mean KDE 4.0?' - see also:
http://www.kdedevelopers.org/node/2600

KDE4 != KDE4.0
very few (users?) are aware of this I fear :)

Dominik
(crossposted kde-hci, I'm not subscribed, though)
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team