Re: do you need www.kde.org write access?

[Sebastian Kügler]

Hi David,

On zaterdag 10 maart 2018 09:15:17 CET David Faure wrote:
> On mercredi 7 mars 2018 13:43:44 CET Sandro Knauß wrote:
> > > Earlier versions used to have an API for programmatic access. Not sure
> > > about now, but I assume so.
> 
> > We also have a library for that: kde/pim/kblog. That gives you a Qt
> > interface for several CMS API including wordpress...
> 
> But our announcement pages are not blogs. Will this allow me to not only add
> pages (not blog posts) and to edit the main page?
> 
> I would be so happy if someone would figure out all this and provide me with
> a command-line solution for adding KF5 release info pages and inserting
> text into the main page... I didn't sign up for figuring out webby stuff 

We're currently collecting requirements which aren't satisfied by the new 
wordpress backend, "not making dfaure a webmaster" is among them (in different 
wording). :-)

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org

do you need www.kde.org write access?

[Sebastian Kügler]

Hi all,

We have been working on a modernized website and backend for www.kde.org. The 
new site will do away with the old PHP custom CMS and will run wordpress 
instead.

This means that access control will be different, so we have to make sure that 
we do not interrupt critical workflows by cutting people off from write access 
to WKO. This is why I wrote this email.

Please reply at least to the kde-www list with your name, KDE identity name 
and the reason why you'd need write access to WKO so we can make this process 
run smoothly. Also, be a good neighbor and poke your friendly release manager, 
fellow promo person or whoever in your opinion may need write access to also 
reply to this email.

After this, we need to make sure that everybody involved actually knows what 
to do on the new website, but let's first sort out access permissions.

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org

Re: Plasma 5.7.4 is out

[Sebastian Kügler]

On Friday, September 9, 2016 11:58:25 PM UTC Andreas Müller wrote:
> On Tue, Aug 23, 2016 at 6:46 PM, David Edmundson
> 
>  wrote:
> > https://www.kde.org/announcements/plasma-5.7.4.php
> > 
> > Regards
> > 
> > David
> 
> I did not find anything in announcement: What happened
> to  plasma-mediacenter?

It moved to extragear, but that should not have happened during a stable 
release cycle, but only for the next feature release.

Jonathan, can you check?
-- 
sebas

http://www.kde.org | http://vizZzion.org

Re: Plasma 5.7.0 tars

[Sebastian Kügler]

On Monday, July 4, 2016 1:59:41 PM CEST David Edmundson wrote:
> I meant "if we accidentally released libkscreen 5.6" as "libkscreen 5.7
> beta", please tell me.
> 
> We didn't.

Ok, good. Thanks for checking!
-- 
sebas

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

Re: Plasma 5.7.0 tars

[Sebastian Kügler]

On Monday, July 4, 2016 1:29:55 PM CEST David Edmundson wrote:
> ... and if not, I need to know, because that means that
> 
> - nobody tested the changes in libkscreen's master in the beta
> - the test reports that I did get from the beta are meaningless (which could
> be a good thing ;))
> 
> Could you check?
> 
> I don't know what you mean, but the tarballs that are up are fine.

I meant "if we accidentally released libkscreen 5.6" as "libkscreen 5.7 beta", 
please tell me.
-- 
sebas

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

Re: Plasma 5.7.0 tars

[Sebastian Kügler]

On Thursday, June 30, 2016 11:06:46 PM CEST Harald Sitter wrote:
> On Thu, Jun 30, 2016 at 4:45 PM, David Edmundson
> 
>  wrote:
> > *sigh* seems so. Yet plasma-workspace is from the right branch and it's
> > done by an automated script(!)
> 
> Haven't we fixed that for beta already?

... and if not, I need to know, because that means that

- nobody tested the changes in libkscreen's master in the beta
- the test reports that I did get from the beta are meaningless (which could 
  be a good thing ;))

Could you check?
-- 
sebas

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

Re: More Plasma bug fix releases

[Sebastian Kügler]

On Wednesday, October 28, 2015 09:11:13 PM Sandro Knauß wrote:
> I see it more as meta informations about patches, to be able to use 
> it as argument for pushing things more easily futher down to the user.

The git log contains this metainformation in the form of the BUG field.
-- 
sebas

http://www.kde.org | http://vizZzion.org

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

Re: More Plasma bug fix releases

[Sebastian Kügler]

On Tuesday, October 27, 2015 06:05:48 PM Scott Kitterman wrote:
> On Tuesday, October 27, 2015 10:01:47 PM Luca Beltrame wrote:
> > Il Tue, 27 Oct 2015 14:18:01 -0700, Eric Hameleers ha scritto:
> > > No, of course not. I consider the git branch to be in eternal flux. The
> > > git HEAD may contain valuable usability patches but also other meh stuff
> >
> > 
> >
> > Thanks to technical (CI, automated testing) and social (widespread code
> > review) measures, this assumption IMO does no longer hold true for the
> > vast majority of cases.
> 
> How does CI or automated testing prevent commits of marginal value in a
> stable  branch (i.e. "meh stuff")?

Any examples for "meh" stuff?

To answer your question, it doesn't (and I think that is pretty obvious), so I 
wonder why you're asking?
-- 
sebas

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

Re: More Plasma bug fix releases

[Sebastian Kügler]

On Tuesday, October 27, 2015 10:58:34 PM Albert Astals Cid wrote:
> El Tuesday 27 October 2015, a les 14:39:15, Eric Hameleers va escriure:
> > On Tue, 27 Oct 2015, Albert Astals Cid wrote:
> > > El Tuesday 27 October 2015, a les 14:18:01, Eric Hameleers va escriure:
> > >
> > > Yes, of course yes.
> > >
> > > Every single patch commited to a stable branch is a bugfix and thus the
> > > developer considers critical and should be released as soon as possible
> > > to
> > > users, otherwise instead of to the stable branch the developer would
> > > commited the patch to the development branch.
> >
> > You developers are so funny, my false teeth fell out from shaking.

If you really want to promote uncalled-for sarcasm, an us vs. them attitude 
and -- frankly -- a lacking sense of humour, this is the wrong place. Let's 
keep it a bit more productive here, please.

> I did a serious reply to your comment and all i got back was sarcasm,
> please  let's try to be constructive, otherwise what's the point of having
> this discussions?
> 
> Do you really think we commit things that are not bugfixes to stable
> branches?
> 
> Can you name some "meh stuff" that was commited to a stable branch and in
> your  opinion should have waited for the next major release?

Indeed, our git stable branches are exactly what you were asking for (in so 
far I understand you well enough). It's a set of patches we deem critical 
bugfixes to our stable branches.

If I were to supply you with a patch set I'd recommend to apply on top of the 
latest release, I'd simply give you exactly the patches in that branch: they 
have been reviewed and even give you the most likely working snapshot, usually 
this is the best tested (CI and manual) stuff you can get.

I simply don't see the difference between what you're after and our git stable 
branches, so if I don't understand you well, a clearer explanation would be 
helpful. As Albert said, examples for a git stable branch that does not meet 
your requirement would also be useful, so we can look at it, and if needed 
make adjustments. I'd be happy to hear what "meh" stuff ended up in bugfix 
releases, because if it's really a "meh" patch (bringing unnecessary risks at 
not enough gain), we can try harder to prevent these from getting in. (I'm not 
aware of any, so I'm not even sure there is a problem.)
-- 
sebas

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

Re: More Plasma bug fix releases

[Sebastian Kügler]

On Tuesday, October 27, 2015 01:51:55 PM Martin Graesslin wrote:
> I was thinking about the problem of how we can get bug fixes quicker to our 
> user. With a three month release cycle a one-month bug fix cycle sounds too
> long to me.
> 
> So I thought we should make bug fix releases faster and more often. In 5.4
> we  already went for this partially by having the first bug fix earlier. I
> wanted to know how much work this would mean for our distributions. If we
> ship out way more bug fix releases, would you be able to work with it?
> Would it block you? Would you have to skip releases? Or is it just pressing
> a button to run automatic scripts which upload your packages?
> 
> What had I been thinking about? I was thinking about a Fibonacci based
> release  schedule. This gives us quick bug fix releases directly after the
> release with slowly larger intervals. Of course it would mean tag and
> release happens on same day.
> 
> So a hypothetical release schedule for Plasma 5.5 could look like:
> * 2015-12-08: 5.5.0
> * 2015-12-15: 5.5.1
> * 2015-12-22: 5.5.2
> * 2016-01-05: 5.5.3
> * 2016-01-26: 5.5.4
> (* 2016-03-01: 5.5.5)
> 
> Opinions?

What I'd really like to see (in extension to Martin's proposal) is that 
distros actually ship our updates. *That* would make it really high impact. If 
we do a 5.5.42, but distros keep the patch-level version, it's pretty useless 
to the vast majority of users. If distros would actually ship our patch-level 
releases reliably, that'd all be much more worthwhile.

What's really bothering me is the terrible long time it takes us to ship 
updates to users, more often than not, that time is expressed in months, not 
weeks, due to the update policies.

That said, if it has a positive impact and will actually be used, I'd like 
more frequent stable updates as well.
-- 
sebas

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

Re: More Plasma bug fix releases

[Sebastian Kügler]

On Tuesday, October 27, 2015 06:25:42 AM Eric Hameleers wrote:
> I like the idea of getting more visibility for bugfixes that will give 
> the enduser a better Plasma experience. Ideal for me would be a patch 
> tracker (not the same as a bug tracker) where intermediate patches are 
> made available that are scheduled for inclusion in the next release. 
> That allows me as a package builder to assimilate those patches if I 
> think they can not wait until the next release.

That sounds like you just want the latest stable git branch, in this example 
Plasma/5.5?
-- 
sebas

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

Re: oxygen-icons & plasma-workspace-wallpapers moved to git

[Sebastian Kügler]

On Wednesday, September 16, 2015 11:52:02 Jonathan Riddell wrote:
> I think the default wallpaper should be kept alongside plasma-workspace,
> less chance of not having it installed by accident

+1. We need at least one default wallpaper working, the rest is optional.
-- 
sebas

Sebastian Kügler|http://vizZzion.org| http://kde.org

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

Re: kio-extras into applications

[Sebastian Kügler]

On Thursday, July 02, 2015 12:38:24 David Faure wrote:
 On Thursday 02 July 2015 13:07:45 Alexander Potashev wrote:
  2015-07-02 12:54 GMT+03:00 Sebastian Kügler se...@kde.org:
   If for example I want to use fish:// for my desktop folderview, I'd have
   to install something from applications. That's what I meant.
 
 Yes, and you also need to install something from applications if you want
 to  edit that image file that you see in folderview. You see it as a very
 different thing because one is a plugin and one is an application, but to
 the end user, it's both need something more, install something more, very
 broadly speaking.
 
 I think you also need to install something from applications if you want to 
 read the help file for desktop folderview
 
  Nitpicking: there are application outside of KDE Application that let
  you access fish://, for example Krusader.
 
 You are both right, no contradiction there.
 
  But still, there is nothing wrong in installing only kio-extras from
  KDE Applications and nothing else from it.
 
 Yep. On the other hand, telling people to install a part of Plasma to get 
 fish:// support in kwrite sounds very wrong to me.
 
   Surely it does, as soon as an app developer wants to integrate a
   specific
   protocol for their app (and not just any protocol, like KIO), then
   this
   would be needed. I imagine getting something from a webdav server, or
   storing a file on a specific backup service.)
 
  If an app developer wants to integrate WebDAV with the help of KIO,
  then kio-extras will be a run-time dependency, so there's absolutely
  no reason for having kio-extras in Frameworks.
 
 Bad example, since WebDAV is implemented by kio_http which is in kio itself 
 
 But yeah, you could come up with a case where an application developer 
 specifically needs a particular kioslave as the central piece of the 
 application; in such case I could actually be convinced to add it to
 kio.git,  provided that it doesn't add dependencies. Or as you say, that's
 just a matter of documenting a runtime dependency. I'm sure we have other
 cases of apps that need each other at runtime...

Thanks, that's useful information, and a possible strategy for improvement 
should that case arise.

I'm OK with moving kio-extras into applications.
-- 
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: kio-extras into applications

[Sebastian Kügler]

On Thursday, July 02, 2015 11:34:56 David Faure wrote:
 On Tuesday 30 June 2015 11:03:21 Sebastian Kügler wrote:
  On Tuesday, June 30, 2015 12:00:31 Jonathan Riddell wrote:
   Plasma 5.3.2 is out and in August the 3 releases are closely aligned
   so it's a chance to move things about while minimising the overlap.
   kio-extras has been suggested to be moved to Applications instead of
   Plasma as it's needed by people who use Applications but don't use
   Plasma.  Should I request the move and into which sub-module?
 
  
 
  Doesn't this give us the same problem, only the other way around?
 
 I don't see that. You install a Plasma desktop. Then you need a text
 editor,  you install kwrite. Then you need support for sftp://, you install
 kio-extras. The latter integrates with the desktop differently than the
 former, but other than that, it's all about additional features at runtime,
 which you can install from KDE Applications, no matter which
 workspace/desktop you're using.

If for example I want to use fish:// for my desktop folderview, I'd have to 
install something from applications. That's what I meant.

 I strongly believe kio-extras should be in applications.

I have no strong preference, was just wondering how it makes the situation 
better. (Ok, maybe the example I gave is very power-usery, so it may indeed be 
more widely used by apps, but it's not really an apps-specific thing, more 
something like a runtime extension for possibly everything.)

 I am not opposed to having it in frameworks if that's the consensus, but I 
 find it arguable. It brings features to users (like apps), not to
 application  developers (like frameworks).

Surely it does, as soon as an app developer wants to integrate a specific 
protocol for their app (and not just any protocol, like KIO), then this 
would be needed. I imagine getting something from a webdav server, or storing 
a file on a specific backup service.)

Don't count this as veto, just food for thought, please.
-- 
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: kio-extras into applications

[Sebastian Kügler]

On Tuesday, June 30, 2015 12:00:31 Jonathan Riddell wrote:
 Plasma 5.3.2 is out and in August the 3 releases are closely aligned
 so it's a chance to move things about while minimising the overlap.
 kio-extras has been suggested to be moved to Applications instead of
 Plasma as it's needed by people who use Applications but don't use
 Plasma.  Should I request the move and into which sub-module?

Doesn't this give us the same problem, only the other way around?
-- 
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: Future frameworks releases

[Sebastian Kügler]

On Tuesday, June 16, 2015 11:45:06 Christian Mollekopf wrote:
  Let's not forget that we're talking about a few hundred deployers here,
  and 
  perhaps a lot more we don't know about, and then hopefully a whole lot
  more in 
  the future. The consistency across frameworks at this basic project
  management 
  level just cannot be underestimated, and that's why I think that the
  proposal 
  of different versions, and different modules per release of frameworks is
  a /really bad idea/.
 
 I absolutely agree with our point that we should keep things for
 deployers as easy as possible,
 and I think that is entirely possible with a reasonable amount of
 effort.
 I'm also very willing to propose solutions for problems that I'm made
 aware of.

Now multiply what you think is a reasonabe effort with the number of 
downstreams and you end up with an unreasonable amount, and the mandate for us 
to keep things as simple as possible. The proposal of different release 
rhythms and versions is now completely unreasonable.

I think you're vastly underestimating the value of consistency, and frankly, 
I'm at a loss why as you're usually a very reasonable guy. Maybe you should 
just trust the amount of negative reactions (and the fact that they come from 
/all the right people/ and forget about your proposal. Trust the elders.

Cheers,
-- 
sebas

Sebastian Kügler|http://vizZzion.org| http://kde.org

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

Re: Future frameworks releases

[Sebastian Kügler]

On Tuesday, June 16, 2015 11:45:06 Christian Mollekopf wrote:
 On Thu, Jun 11, 2015, at 08:56 PM, Sebastian Kügler wrote:
  On Tuesday, June 09, 2015 10:08:06 Christian Mollekopf wrote:
   I'm sorry for the friction this causes right now, but in the long run I
   really  don't see how this makes life harder for everyone else.
 
  Here's an example from some recent packaging experiments. I wrote a
  script to 
  update the packages, with frameworks, it was a very easy thing, I change
  one 
  global version number, and I could check out a tag (same tag for every 
  framework) from git, then roll a tarball from those tags and build it. 
  Verifying that everything's OK was again a matter of checking the results 
  against one single version.
 
  This process would have been a LOT more work with different version
  numbers, let alone some packages being excluded in certain releases,
  because all of a sudden, I'd have to keep track of all this manually.
 
 Getting the latest tag on master is entirely possible without knowing
 the version number
 (git describe --abbrev=0 --tags). Verifying that everything is ok indeed
 would be
 a bit more involved. So yes, it can get a bit more complex, but not a
 whole lot really.

It's possible, but it's cumbersome, involves more server roundtrips and 
parsing, and is a lot harder to verify manually.

In the current model, it's as simple as 
version = 5.11 for the setup (in my example script)

and 

ls -l|grep -v 5.11

to verify that everything went well.

That's a simple and almost fail-safe solution.

  Let's not forget that we're talking about a few hundred deployers here,
  and 
  perhaps a lot more we don't know about, and then hopefully a whole lot
  more in 
  the future. The consistency across frameworks at this basic project
  management 
  level just cannot be underestimated, and that's why I think that the
  proposal 
  of different versions, and different modules per release of frameworks is
  a /really bad idea/.
-- 
sebas

Sebastian Kügler|http://vizZzion.org| http://kde.org

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

Re: Future frameworks releases

[Sebastian Kügler]

On Tuesday, June 09, 2015 10:08:06 Christian Mollekopf wrote:
 I'm sorry for the friction this causes right now, but in the long run I
 really  don't see how this makes life harder for everyone else.

Here's an example from some recent packaging experiments. I wrote a script to 
update the packages, with frameworks, it was a very easy thing, I change one 
global version number, and I could check out a tag (same tag for every 
framework) from git, then roll a tarball from those tags and build it. 
Verifying that everything's OK was again a matter of checking the results 
against one single version.

This process would have been a LOT more work with different version numbers, 
let alone some packages being excluded in certain releases, because all of a 
sudden, I'd have to keep track of all this manually.

Let's not forget that we're talking about a few hundred deployers here, and 
perhaps a lot more we don't know about, and then hopefully a whole lot more in 
the future. The consistency across frameworks at this basic project management 
level just cannot be underestimated, and that's why I think that the proposal 
of different versions, and different modules per release of frameworks is a 
/really bad idea/.

Cheers,
-- 
sebas

Sebastian Kügler|http://vizZzion.org| http://kde.org

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

Re: This is not working [for me]

[Sebastian Kügler]

On Monday, March 02, 2015 20:00:14 Alex Merry wrote:
  But we need to make this work better for my sanity for 15.08 otherwise 
  I'm out.
 
  Does anyone have any magic solution?
 
 I wonder if part of the problem is a lack of clear definition as to who 
 compromises the release team. For example, I hang around on this mailing 
 list mostly to keep an eye on what's going on, and I'm sure others do too.
 But  with large groups of people, you get the bystander effect, where
 everyone assumes someone else will do the work. And in practice, that
 someone seems to end up being you.

The definition of the release team was initially to have a forum of modules 
maintainers that take decisions and do the work. This has worked in the 
beginning, but I think we've all become complacent (or perhaps Albert has just 
doing a very good job!) that involvement in the release team got less and 
less.

 Would it be useful to have a core of 3-5 named decision makers, who have 
 to agree between them for any exceptions to the freezes etc? That way, 
 it's not all on you - it's not you being the bad guy, it's the team 
 making a decision.

Named, I dunno. Self-selected did work better in the past for us. We may find 
another modus operandi that works for us now.
Immediately, I think more involvement by everybody who cares would go a long 
way in supporting Albert.

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: Plasma 5.1 new tars coming..

[Sebastian Kügler]

On Tuesday, October 14, 2014 11:22:39 Jonathan Riddell wrote:
 I just noticed at the last minute that the Plasma tars didn't have
 their internal version numbers updated to 5.1.0, the script I wrote to
 make that easier must have only updated master and not branch.  I'm
 going to reroll the tars now to fix the version number.  Sorry folks.

That also means that we've pushed back Plasma 5.1.0 to tomorrow, today, we'll 
release 4.14.2, then.
-- 
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: Plasma 5.1.0

[Sebastian Kügler]

On Thursday, October 09, 2014 21:36:58 Albert Astals Cid wrote:
 El Dijous, 9 d'octubre de 2014, a les 14:26:48, Jonathan Riddell va 
escriure:
  Plasma 5.1.0 tars up now at
 
   http://starsky.19inch.net/~jr/tmp/plasma-5.1.0/
 
  and coming soon to depot
 
  
 
  sha256 sums at
 
   https://www.kde.org/info/source-plasma-5.1.0.inc
  
 
  Release due on Tuesday.
 
 4.14.2 release is also on Tueday, maybe i should move it to wednesday?

I think that would make sense. I'm prepping the Plasma 5.1.0 release notes 
now. If need be, we can also push that one one day forward.

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: feature exception for kapptemplate Frameworks template

[Sebastian Kügler]

On Friday, July 25, 2014 01:53:50 Aleix Pol wrote:
 On Thu, Jul 24, 2014 at 10:39 PM, Albert Astals Cid aa...@kde.org wrote:
 
 El Dijous, 24 de juliol de 2014, a les 11:53:15, Jonathan Riddell va 
escriure:
  I'd like to ask for a feature exception for 4.14 for adding a Frameworks
  template to kapptemplate
  
  Add KDE Frameworks 5 simple app
  https://git.reviewboard.kde.org/r/119388/
 
 Looks ok to me.
 
 More opinions?
 
 Cheers,
   Albert
 
  Jonathan
 
 +1
 I'm unsure it matters much, but I don't think it will hurt.

I'd find it useful.
-- 
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: Plasma 5.0.0!

[Sebastian Kügler]

On Friday, July 11, 2014 18:20:58 Wulf C. Krueger wrote:
 On Fr 11 Jul 2014 18:00:40 CEST, Jonathan Riddell wrote:
  Another try for baloo, I made an empty tar somehow
 
 Thanks for your efforts!
 
 I think it might be a good idea, though, to verify tarballs (and ideally
 their contents, including compiling them) *before* announcing them.

He didn't announce them (we will do that tomorrow, once all the verification 
is done). He was asking for help in making sure the tarballs are OK. Release 
management is a lot of work, it can't be done by just one hand. By making the 
location of these work-in-progress tarballs known, we can spread this work and 
achieve better quality results.

Thanks for participating in this. :)

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: KF5 beta3

[Sebastian Kügler]

Hi Eric,

On Tuesday, June 03, 2014 12:49:01 Eric Hameleers wrote:
 I did however have to write a couple of patches to get everything 
 compiling. Well, except kdepimlibs (frameworks branch) which I can not 
 get to compile no matter what I try.
 
 The four patches I created are attached for those who may want them.

Could you submit them to reviewboard? Tagged with the right repo, they'll 
reach their maintainer and can get picked up there.

Thanks,
-- 
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

Plasma Next release schedule changes

[Sebastian Kügler]

Hey all,

We had to delay the Plasma Next release, because Frameworks will only be 
released July 1st. Jonathan has adjusted the online schedule, the short 
version of the relevant part is:

* Beta 2: Thu June 5 tagging, Tue 8 June release
* Release Candidate: Thu 3 July tagging, Tue 8 July release
* Final Release: Thursday July 10 tagging, Tuesday 15 July release

The long version can be found on:

http://techbase.kde.org/Schedules/Plasma/2014.6_Release_Schedule

If you see problems with it, holler.

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: Fwd: KDE Frameworks Release Cycle

[Sebastian Kügler]

On Sunday, April 27, 2014 15:55:07 Albert Astals Cid wrote:
 El Diumenge, 27 d'abril de 2014, a les 15:15:32, David Faure va escriure:
  FYI.
 
 Interesting fact here that original the mail was just sent to k-f-d and
 k-c-d.
 
 I am seeing similar patterns in the plasma land, where they went their own
 way  with the releasing discussion and only sent to this list after the
 discussion happened (or that's my impression) (Note i'm not complaining of
 being left aside since actually i was there in person for the KF5
 dicussion).
 
 I'm just raising the question if we want to:
  a) Try to make the KF5 and plasma people work more in the release-team
 list  when discussing about releases
  b) Rename the release-team list to kde-applications-release-team or
 something  like that to make it clear it is about KDE Applications side
 of the previous three Applications, Plaform and Workspaces sides of a
 release
  c) Disband the relase-team altogether.
 
 I'd like a) to happen but i can see if being hard so i'm open to anything 
 people want

a), but instead of doing the full discussion on release-team, I think it makes 
sense to first find out what the team doing the software itself wants, and in 
that phase, the discussion is best held on, e.g. plasma-devel, and when 
there's a consensus is reached, taken to release-team for further discussion.

That is in fact how I see the past discussions. If it felt like a finished plan 
is presented to the release-team, that was not, at least my, intention, and we 
can make sure in the future it's clearer.
-- 
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

wiki page with Plasma Next Alpha1 packages

[Sebastian Kügler]

Hi packagers,

If you're preparing packages for the upcoming Plasma Next Alpha 1, please add 
a pointer to this page: http://community.kde.org/Plasma/Next/UnstablePackages

Thanks,
-- 
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: Plasma Next alpha release engineering bits

[Sebastian Kügler]

On Thursday, March 06, 2014 10:49:21 Jos Poortvliet wrote:
 On Wednesday 05 March 2014 13:10:12 Sebastian Kügler wrote:

  As we're planning to release the first alpha of Plasma Next next week, I'd
  like to go over some details that need discussing.
 
  - promo preparations
 
 You want the same as for the Frameworks alpha's? As in, very plain and
 simple  as we did the 'noise' in the earlier Tech Preview article:
 http://dot.kde.org/2014/03/04/kde-frameworks-5-alpha-two-out
 
 If so, I'd be happy to take care of it.

That would totally rock. I can help with nice material to go along with it, 
and the text of course.

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: Plasma Next alpha release engineering bits

[Sebastian Kügler]

On Thursday, March 06, 2014 15:12:32 Jos Poortvliet wrote:
 On Thursday 06 March 2014 11:32:03 Sebastian Kügler wrote:
  On Thursday, March 06, 2014 10:49:21 Jos Poortvliet wrote:
   On Wednesday 05 March 2014 13:10:12 Sebastian Kügler wrote:
   
  
   You want the same as for the Frameworks alpha's? As in, very plain and
   simple  as we did the 'noise' in the earlier Tech Preview article:
   http://dot.kde.org/2014/03/04/kde-frameworks-5-alpha-two-out
  
   
  
   If so, I'd be happy to take care of it.
 
  
 
  That would totally rock. I can help with nice material to go along with
  it,
  and the text of course.
 
 If you braindump to me the major changes since the tech preview and have a 
 picture or two, I'll do the rest.
 
 What's the date?

Tagging next Thursday, hopefully pretty quickly then the Alpha release (as 
packages pass smoke testing). I'll be travelling starting on Thursday, so how 
about we chat about it on, say, Monday, if that fits  yourschedule?
-- 
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

Plasma Next alpha release engineering bits

[Sebastian Kügler]

Hi,

As we're planning to release the first alpha of Plasma Next next week, I'd 
like to go over some details that need discussing.

- promo preparations
- tagging / tarballing: can happen anytime on Thursday next week
- smoke-testing of packages
- rolling out packages on Monday, or sooner depending on testing?

We'll need someone to roll the tarballs and put them on the download site. Who 
is willing to help here?

Affected repositories:

- plasma-framework
- kde-workspace
- kde-runtime
- kwin-compositing-kcm

Am I missing something, perhaps the wallpapers? We have some bits in kde-
baseapps that could be useful, should we include that as well (as sort of 
limited tarball)?

This means: don't make changes to frameworks other than plasma-framework that 
are required, we'll not be able to include them in the Alpha.

It also means that if you have invasive changes, get them in NOW, we need some 
time to stabilize them.

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: change of program icon

[Sebastian Kügler]

Hey,

On Tuesday, March 04, 2014 00:55:37 Albert Astals Cid wrote:
 El Dilluns, 3 de març de 2014, a les 22:47:06, Sebastian Kügler va escriure:
  On Monday, March 03, 2014 19:27:29 Albert Astals Cid wrote:
   El Dilluns, 3 de març de 2014, a les 13:10:30, Sebastian Kügler va 
 escriure:
   The old icon didn't either (or that's what i think by looking at it), so
   no
   consistency problem is introduced.
 
  The old icon is much more oxygeny than the newly proposed one, so yes,
  it
  introduces a consistency problem.
 
 Ok, i'll accept your opinion since i'm obviously lacking in artistic skills 
  
   I agree their opinion is interesting, and if they can provide a better
   icon
   that is oxygen-like Wolfgang is probably interested.
  
   But i disagree kde-artists should have the power to block an icon change
   they  didn't contribute over and that affects a single application?
 
  Saying that artists are only allowed to change the work they've committed
  before is making sure we won't ever get anything done professionally in
  that area.
 
 Hmmm, ok, I may have expressed myself correctly, let me try to rephrase.
 
 This icon is *not* an oxygen icon, it is an hi-color icon. Oxygen iconset
 can  still provide a better icon if the oxygen authors have time for it. As
 I said, I am sure Wolfgang would appreciate help with the icon, but
 ultimately, he is the maintainer of that application, so he gets to choose
 what application he ships (more over when it's an hi-color iconset icon, so
 he's not even claiming it to be oxygen-y).
 
 Does this make more sense?
 
   In my opinion this is amonsgt the maintainer of the application and the
   release-team (that is the one that enfonces the Freezes).
 
  Then your opinion means that the release-team can block, but cannot
  explicitely allow.
 
 Probably wrong wording on my side again. The Freezes are what creates the 
 blocks and the r-t gives exceptions on these freezes. This is how we have 
 always worked as far as i can remember.

I was confused, I didn't know Wolfgang maintained Kahjongg, that obviously 
changes the situation and my judgement of it.

   With my release-team hat, I say you can change it in KDE/4.13 since
   you've
   already changed it in master and I don't see a need to delay it.
 
  So we're back to doing willy-nilly art work without no concept whatsoever?

I realize (after being prodded, granted ;)) that this may sound offending: 
it's not meant that way. What I wanted to express is that doing single icons 
in a rather ad-hoc way leads to ... well, let's describe it as KDE3 visuals, 
like a meal done by 5 cooks that don't talk to each other. :)

In any case: Wolfgang, please don't take offense.

  Let's at least bring it up with the artists and give them a chance to chip
  in. Nobody is talking about blocking anything, but outright ignoring
  artists opinion (and diminishing their efforts this way) is not how we
  should work together.
 
 Why haven't you CC'ed them yet?

Good point, maybe I didn't want to step on anybody's toes.

  My experience is that they're happy to help (modulo time problems, of
  course), not 'happy to block', and they're usually the first ones to
  acknowledge a visual problem -- which this clearly is.
 
 Time problems are¿where? big, my experience is that i've never been able to 
 get an icon i needed from the artist team because they always had more
 important things to do (which i understand and i'm not complaining about)

Yes, we have a resource problem in our art department. We can't solve this by 
ignoring the artists' opinions, but ironically by involving them more. Lately, 
an artwork team is building up, which provides a good opportunity to re-think 
our modus operandi there.

  My experience is also that by not even considering their opinion, or just
  by not even choosing the right channel for this, we're making sure that
  we're not a community welcoming to artists. Just because we *can* commit
  anything doesn't mean we *should* ignore the expertise and input of
  domain experts.
 You mean the artists don't have a representative on the release-team? Why? 
 They should. This way the release-team could function correctly in the art-
 related freezes.
 
  The issue at hand is by no means so urgent that we should skip over
  meaningful ways of improving the situation, and we have more suitable
  channels for that than the r-t list.
 
 I disagree, as I said, this is about a Freeze exception and the r-t should
 be  the one to decide. If the artist have decided to not be part of the r-t
 or the r-t has not done enough to engage artists to be part of it, that's a
 different thing and it indeed needs fixing.

For most artists, reading all emails on r-t is a waste of time. I think in the 
(rather few) cases where we have such questions, involving them actively is 
actually a fine method.

  Frankly, I also think we can do better than the proposed icon.
 
 We can always do better. That's not the question

Re: change of program icon

[Sebastian Kügler]

On Tuesday, March 04, 2014 11:13:29 Sebastian Kügler wrote:
  Probably wrong wording on my side again. The Freezes are what creates the 
  blocks and the r-t gives exceptions on these freezes. This is how we have 
  always worked as far as i can remember.
 
 I was confused, I didn't know Wolfgang maintained Kahjongg, that obviously 
 changes the situation and my judgement of it.

And that, as it just struck me, was due to a mixup of names. I was thinking of 
another Wolfang Ro*, so probably should stop using globbing when thinking of 
names. ;)

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: change of program icon

[Sebastian Kügler]

Hi Wolfgang,

On Monday, March 03, 2014 01:27:42 Wolfgang Rohdewald wrote:
 Am Montag, 17. Februar 2014, 23:14:56 schrieb Albert Astals Cid:
  Wednesday, February 26, 2014 has
 
   * KDE SC 4.13 Artwork and Bindings Freeze
 
 would it be too late to give the game Kajongg a new program icon?
 The new one looks better with smaller resolutions.
 
 Here it is:
 http://www.rohdewald.de/oss/kajongg.svgz 

This doesn't follow the Oxygen style, which introduces a consistency problem. 
An icon change like this would have to be discussed on the kde-artists list, 
not on release-team.

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: change of program icon

[Sebastian Kügler]

Hi,

On Monday, March 03, 2014 19:27:29 Albert Astals Cid wrote:
 El Dilluns, 3 de març de 2014, a les 13:10:30, Sebastian Kügler va escriure:
 
  On Monday, March 03, 2014 01:27:42 Wolfgang Rohdewald wrote:
   Am Montag, 17. Februar 2014, 23:14:56 schrieb Albert Astals Cid:
  
   would it be too late to give the game Kajongg a new program icon?
   The new one looks better with smaller resolutions.
  
   Here it is:
   http://www.rohdewald.de/oss/kajongg.svgz
 
  This doesn't follow the Oxygen style, which introduces a consistency
  problem. 
 
 The old icon didn't either (or that's what i think by looking at it), so no 
 consistency problem is introduced.

The old icon is much more oxygeny than the newly proposed one, so yes, it 
introduces a consistency problem.

  An icon change like this would have to be discussed on the
  kde-artists list, not on release-team.
 
 I agree their opinion is interesting, and if they can provide a better icon 
 that is oxygen-like Wolfgang is probably interested.
 
 But i disagree kde-artists should have the power to block an icon change
 they  didn't contribute over and that affects a single application?

Saying that artists are only allowed to change the work they've committed 
before is making sure we won't ever get anything done professionally in that 
area.

 In my opinion this is amonsgt the maintainer of the application and the 
 release-team (that is the one that enfonces the Freezes).

Then your opinion means that the release-team can block, but cannot 
explicitely allow.

 With my release-team hat, I say you can change it in KDE/4.13 since you've 
 already changed it in master and I don't see a need to delay it.

So we're back to doing willy-nilly art work without no concept whatsoever? :(

Let's at least bring it up with the artists and give them a chance to chip in. 
Nobody is talking about blocking anything, but outright ignoring artists 
opinion (and diminishing their efforts this way) is not how we should work 
together.

My experience is that they're happy to help (modulo time problems, of course), 
not 'happy to block', and they're usually the first ones to acknowledge a 
visual problem -- which this clearly is.

My experience is also that by not even considering their opinion, or just by 
not even choosing the right channel for this, we're making sure that we're not 
a community welcoming to artists. Just because we *can* commit anything 
doesn't mean we *should* ignore the expertise and input of domain experts.

The issue at hand is by no means so urgent that we should skip over meaningful 
ways of improving the situation, and we have more suitable channels for that 
than the r-t list. 

Frankly, I also think we can do better than the proposed icon.

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

Plasma Next Release Plans

[Sebastian Kügler]

Hi all,

The Plasma team has settled on a release schedule for the first stable 
released based on Qt5 and KF5. You can find the schedule here:

http://techbase.kde.org/Schedules/Plasma/2014.6_Release_Schedule

For those too lazy to click: We'll release .0 on 17th June, two alphas, a beta 
and an RC before. Feature freeze is looming in March already.

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: Plasma Next Release Plans

[Sebastian Kügler]

On Wednesday, February 19, 2014 21:01:52 Martin Graesslin wrote:
 On Wednesday 19 February 2014 20:42:15 Albert Astals Cid wrote:
  El Dimecres, 19 de febrer de 2014, a les 15:01:50, Sebastian Kügler va

   The Plasma team has settled on a release schedule for the first stable
   released based on Qt5 and KF5. You can find the schedule here:
   
   http://techbase.kde.org/Schedules/Plasma/2014.6_Release_Schedule
  
  I find interesting that you reintroduced the concept of soft vs hard
  freeze.
  
  Can you explain the rationale behind getting them back? Do you think the
  single freeze we introduced in the latest 4.x is working worse than
  soft+hard freeze?
 
 I just checked our discussion (for reference mail by d_ed to plasma-devel on
 January, 29th). His request was to have two feature freezes allowing to
 have certain aspects unfinished at freeze 1. So I'd say it's completely
 unrelated to the SC freezes as it's for the special situation of the
 current development state.

Yes, I think it's specific to this release cycle, as we have a wider gap from 
port everything and possibly break stuff to stable software, so it makes 
sense to me to have a process with more steps in between.

What I've seen myself is that focus is shifting towards solving bugs and 
making things work, the two freezes give opportunity to ease into 
stabilization phase, while some things are still being completed.

I think once we've finished this bigger transition, we can get back into the 
proven rhythm, and possibly tweak it. There were some discussions about 
shorter release cycles, this certainly warrants picking up again.

As to point releases, we haven't talked much about that, but experience 
teaches that especially after the big transition, we should be prepared to 
ship updates in short order. For that, I'd like to (at least?) keep the once-
a-month-a-point-release cycle. We should start scheduling this as well.

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: KDE's opinion on SC 4.13 for Kubuntu 14.04

[Sebastian Kügler]

On Sunday, January 19, 2014 23:28:46 Albert Astals Cid wrote:
  My question now is. Do you think that 4.13 (rc) will be reliable
  enough for a release product and do you want us to try push for 4.13
  or would you prefer us to release with 4.12?
 
 Personally, a RC is not for production, since well, it's an RC
 
 Having a look at the timings, since 4.13.0 is released in April 16 and the 
 Final Relase of KUbuntu 14.04 is not until April 17 you could have 4.13.0 as
 a  0-day update, obviously this doesn't solve the problem of the CD not
 including it, but who does not install updates after installing something?
 

Also, probably relevant: If you're going to install 4.12, the user runs it for 
a day or two, Nepomuk does its thing, then upgrades to 4.13 with the switch to 
Baloo, that's unnecessarily error-prone.

 So I'd go with 4.13.

^ That.
-- 
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: Jumped the gun on 4.11.1

[Sebastian Kügler]

Hi,

On Monday, September 02, 2013 10:13:27 sfal...@gmail.com wrote:
 Hey guys, sorry about this, but we did accidentally let 4.11.1 out into the 
 wild ahead of release announcement. Somebody brought this to our
 attention, and we've depublished our repo on openSUSE OBS, and wiped the
 binaries.
 
 Again, sorry about this.   I'll make sure to pay better attention to
 release  announcements in the future.

Thanks for letting us know, and be proactive about it. These things happen, 
but can always be corrected.

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: Release Cycle

[Sebastian Kügler]

On Thursday, August 22, 2013 08:07:22 Jos Poortvliet wrote:
  What you just did means that KDE SC 4.12 will in fact be a 5 month
  release cycle. Earlier there was talk about outlining the future
  releases. That blog/news item is probably going to have to take the
  new 5 month cycle into account.
 
 Yes. What about this then:
 ===
 KDE frameworks 5 preview 1 December 2013
 KDE frameworks 5 release 1st half 2014
 KDE Workspaces 4.11 is last release (LTS)

KDE Workspaces 2.0 preview 1st Q1/2013
KDE Workspaces 2.0 release 2nd Q2/2013

 KDE Applications 4.12 December 18 2013
 KDE Applications 4.13 June 2014
 
 As with any schedule for a major technological transition, please note that 
 the above is subject to change.
 ==
 
 If this is OK then we'll communicate it this way.

This is how I imagine it, and what we're aiming at.
-- 
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: Release Cycle

[Sebastian Kügler]

On Thursday, August 22, 2013 15:38:20 Sebastian Kügler wrote:
 KDE Workspaces 2.0 preview 1st Q1/2013
 KDE Workspaces 2.0 release 2nd Q2/2013

It's hard to write, let me try again:

KDE Workspaces 2.0 preview Q1/2014
KDE Workspaces 2.0 release Q2/2014

This sounds more like it. :)
-- 
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: Shift releases?

[Sebastian Kügler]

On Thursday, July 18, 2013 01:56:41 Albert Astals Cid wrote:
 Because of akademy and other stuff we shifted RC1 for 6 days, do you think
 it  makes sense to shift all the releases one week or just keep the current
 release schedule?
 
 I think I prefer keeping the current one, but I'm open to comments :-)

I don't see a compelling reason to change our schedule.
-- 
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: Disable by default KRandR in 4.11

[Sebastian Kügler]

On Thursday, July 04, 2013 01:06:27 Àlex Fiestas wrote:
 I want to propose to disable by default KRandR from kde-workspace release
 for 4.11.
 
 While I'm considered the maintainer of KRandR truth is I have never been it,
 I just made it work around 4.7 times but it is still full of bugs and
 annoyances.  Since we have KScreen (which tomorrow I will propose for
 Extragear)

I think this should go into SC, not just extragear. Very much so since it 
would replace krandr there.

The functionality of plugging in an extra screen or unplugging it is very much 
needed for most systems, that's not extragear.

 which almost all distributions are shipping I see no point on
 keeping KRandR around, specially in 4.11 that will be the last release of
 4.11.
 
 KScreen is rock solid, it has two maintainers taking care of it, it is way
 more advanced and complete than KRandR and it is trusted enough so
 distributions like RHEL are going to ship it.
 
 Ideally I would like to remove the source code completely, but I guess we
 are too late into 4.11 to do such thing.

+1 for replacing krandr with kscreen.

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: Disable by default KRandR in 4.11

[Sebastian Kügler]

On Thursday, July 04, 2013 17:05:59 Martin Graesslin wrote:
 On Thursday 04 July 2013 16:34:18 Àlex Fiestas wrote:
   I think this should go into SC, not just extragear. Very much so since
   it
   would replace krandr there.
  
   The functionality of plugging in an extra screen or unplugging it is
   very
   much needed for most systems, that's not extragear.
 
  Let's put it on Extragear first, and decide how to do the moving to the SC
  once plasma-workspaces 2 is released (since KScreen as bluedevil as
  plasma-nm should be released with it).
 
 Better idea: let's sit down together at akademy and discuss it in person

Good call. Objection withdrawn, +1 from my side. :)

We'll need to make sure towards packagers to make it available though.
-- 
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: Release Strategy Proposal

[Sebastian Kügler]

On Tuesday, May 07, 2013 21:34:47 Albert Astals Cid wrote:
 El Dimarts, 7 de maig de 2013, a les 09:25:13, Aaron J. Seigo va escriure:
  On Tuesday, May 7, 2013 00:51:56 Albert Astals Cid wrote:
   To be honest from a release team point of view I feel here that the
   plasma
   guys are forcing a whole module lock down without any reason
 
  we've shared our reasons, so i don't know why you say this.
 
   and without the
   agreement of everyone involved in the module,
 
  who, exactly?
 
   so I'd like to hear that
   explanation of why we need to go your way too, if possible.
 
  read our previous emails on the matter.
 
 Ok, discussed this on IRC with Aaron so it did not end up in an infinite
 ping- pong of messages.
 
 He has convinced me that seems to be an agreement on all the interested
 stake- holders in kde-workspace to do the freeze.
 
 Please if that's not correct people speak up.

In fact, it wasn't even Aaron's idea, he was just supportive of this, and 
helped to make it happen.

Of course, I'm 100% behind the freeze as well.
-- 
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: Release Strategy Proposal

[Sebastian Kügler]

Hi Frank,

On Friday, April 26, 2013 17:16:06 Frank Reininghaus wrote:
 2013/4/26 Sebastian Kügler:
  On Friday, April 26, 2013 15:37:09 Frank Reininghaus wrote:
  2013/4/26 Sebastian Kügler:
   tldr
   Let's make 4.11 the last feature release for platform and workspace in
   the
   4 series, make 4.11 a long term maintainance release.
   /tldr
  
  What exactly is part of this proposal then? Is it
  
  (a) All modules which are released as part of the KDE SC 4.11, or
  (b) only kdelibs, kde-runtime (and kde-workspace)?
  
  Sorry if this is a stupid question, but apparently, I'm still not
  familiar enough with the SC/Platform/Workspace/... terminology
  
  Good question: The initial thinking is kdelibs, kde-runtime,
  kde-workspace. I think it's too early for kde-baseapps to jump on this
  bandwagon, but you might have a different opinion on this -- or not. :)
  That's what I'd like to find out here. :)
 
 Thanks for the clarification!
 
 I agree that it might be too early to feature-freeze and string-freeze
 kde-baseapps and some other modules now.

How do you feel about extending Dolphin 4.11 support to two years?

That's the second part of the proposal, I think we mainly concentrated on what 
to freeze so far, and freeze and extended support are orthogonal. Looking at 
our downstreams probably holds the more modules we can ship with extended 
upstream support in 4.11, the better. On the other hand additional branches 
are more work.

Feedback from other module maintainers is most welcome, of course.

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

Release Strategy Proposal

[Sebastian Kügler]

Hi,

tldr
Let's make 4.11 the last feature release for platform and workspace in the 4 
series, make 4.11 a long term maintainance release.
/tldr

I would like to propose the following for our release planning in the next 
year:

- Make 4.11 Platform and Workspaces a long-term maintainance release with 
  bugfix updates for two years

- After 4.11.0, shift feature development to Frameworks 5 and Plasma 
  Workspaces 2, in order to not delay this forever

- Applications are not part of this proposal, we'd need feedback from App 
  module maintainers. It doesn't need to be decided along with this proposal 
  though. For now, App developers should be encouraged to make releases on top 
  of 4.x, and jump onto KF5 when it's ready

Reasons:
* This strategy will cement our leading role as desktop environment
* It eases transition to KF5/PW2 by giving ample room to keep the old version
* It communicates that we do not abandon SC4, but actively support it
* It makes downstreams happy, particularly those with long term releases as 
  they will have a version with multiple years of bug fixes to focus on
* kdelibs 4.x is already feature frozen, we plan to do the same for Plasma 
  after 4.11 and concentrate on PW2 then

How this will look like exactly:

4.11 gets out as normal, but with the clear message: This is going to 
maintained for a longer period of 2 years: If you're doing an Enterprise 
distro, this one is the one you want


Of course, this being a proposal, its main purpose is to sollicit feedback, 
but I'd also move towards a solution, as far as this describes common ground 
among all stakeholders.


What do you think?
-- 
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: Release Strategy Proposal

[Sebastian Kügler]

On Friday, April 26, 2013 15:37:09 Frank Reininghaus wrote:
 2013/4/26 Sebastian Kügler:
  tldr
  Let's make 4.11 the last feature release for platform and workspace in the
  4 series, make 4.11 a long term maintainance release.
  /tldr

 What exactly is part of this proposal then? Is it
 
 (a) All modules which are released as part of the KDE SC 4.11, or
 (b) only kdelibs, kde-runtime (and kde-workspace)?
 
 Sorry if this is a stupid question, but apparently, I'm still not
 familiar enough with the SC/Platform/Workspace/... terminology

Good question: The initial thinking is kdelibs, kde-runtime, kde-workspace. I 
think it's too early for kde-baseapps to jump on this bandwagon, but you might 
have a different opinion on this -- or not. :) That's what I'd like to find 
out here. :)

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: Release Strategy Proposal

[Sebastian Kügler]

On Friday, April 26, 2013 08:44:35 Rex Dieter wrote:
 With my packager-hat on, this raises some concern about future possible 
 version assumptions being broken (ie, packaging that assumes constant 
 versioning across all kde core packages).  That's something that will 
 have to be dealt with sooner or later (with frameworks5) anyway, so 
 maybe it's not necessarily a bad thing.

Yeah, something we have to figure out. My thinking (and I'm undecided on which 
way to go there):

- If we only increase version numbers for the things that actually get feature  
  
  updates, we might create confusion as to what fits together

- If we keep all numbers consistent (basically our current release policy -- 
all get the same number), people might misunderstand, distros might not dare 
upgrading to, for example 4.12 because they want to ship long-term-maintained 
code.

Input, especially from distros is most welcome to fledge this out futher.

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: Release Strategy Proposal

[Sebastian Kügler]

Hi Alex,

On Friday, April 26, 2013 18:35:41 Alexander Neundorf wrote:
 On Friday 26 April 2013, Sebastian Kügler wrote:

  tldr
  Let's make 4.11 the last feature release for platform and workspace in the
  4 series, make 4.11 a long term maintainance release.
  /tldr
 
 IMO this is not about handling releases, but about the mid-term development 
 strategy of KDE.
 I think setting the direction for KDE is not task of the release team.

This thread is not about setting the direction perse, it's about asking 
feedback from involved parties. I was actually wondering wether or not to CC: 
k-c-d, but decided against to first have a few more directly related people 
weigh in: i.e. if the release team says it can't be done, we have to go back 
to the drawing board.

 I think this should be discussed more public, i.e. on k-c-d.
 
 Beside that, trying to get KF5 more into a working-towards-a-release 
 development mode seems like a good idea to me.

That's an intended side-effect.

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: Release Strategy Proposal

[Sebastian Kügler]

Hey,

On Friday, April 26, 2013 23:28:34 Albert Astals Cid wrote:
  Of course, this being a proposal, its main purpose is to sollicit
  feedback,
  but I'd also move towards a solution, as far as this describes common
  ground among all stakeholders.
 
  What do you think?
 
 I'm all for it if modules want to do this, what we're going to need the
 list  of exact modules that stop development of new features and make sure
 all the parties that live under that module agree, i.e. kde-workspace has
 solid and powerdevil stuff in there. Have you talk to this guys and do they
 agree to the feature freeze?

The idea actually came up at a barbecue where Alex Fiestas (CC:'ed) was 
present, and about to head off to Brno for the Solid sprint.

One thing I checked with him afterwards is was about a possible rewrite of 
parts of powerdevil, but I believe in the end the Solid team decided against 
the rewrite, so that is probably off the table.

Another, possibly intrusive thing is the introduction of KPeople, a framework 
to normalize the concept of Contacts across the workspace. I don't know 
enough to judge this, input here is welcome in how far this needs changes all 
over the workspace, or would need adjustments to the presented plan. Martin 
(also CC:'ed), maybe you could weigh in here?

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: stepping back from release duties

[Sebastian Kügler]

On Tuesday, February 19, 2013 20:26:26 Albert Astals Cid wrote:
 El Dimarts, 19 de febrer de 2013, a les 15:38:49, Torgny Nyblom va escriure:
  On Tuesday 19 February 2013 13.19.37 Sebastian Kügler wrote:
  [...]
 
   I decided to take a step back
 
  [...]
 
  I just wanted to say Thank you for you work (on releases and on all other
  KDE stuff)!.
 
 +1

Cheers, and thanks to you both for being people that I have no problem handing 
over release duties. And thanks for doing it, of course!

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

stepping back from release duties

[Sebastian Kügler]

Hi all,

I've been doing releases of KDE (SC) for a long time now (way beyond 100 
individual releases). I think it's time others jumped in here as well.

As that's always hard when the old grumpy guy still sits there, I decided to 
take a step back and have others jump in here.

That means that I'll not be feeling responsible for releases anymore, and that 
in order to get these things done, others will have to take action.

For minor releases, Togge and Albert are already doing a wonderful job (there 
were two releases already where I didn't have to lift a finger, without any 
hickups).

For major releases, it means that a bit more planning especially for the 
upcoming version is needed. As the work is already well-spread, the main thing 
is that someone needs to step in and coordinate, make sure all the individual 
things happen, and that these individual pieces become a whole in the end.

That person won't be me, though. (But in case the next coordinator needs help 
or advise, I'm just around the corner, ready to answer questions.)

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: [kde-promo] 4.10 announcement ready for translation

[Sebastian Kügler]

On Monday, February 04, 2013 20:13:10 Albert Astals Cid wrote:
 Unfortunately you forgot to tell the translators.

Ah, I was assuming someone would take it from here. Can someone still do that, 
after the past days of webmonkeying, I don't quite feel like managing 
translations.
-- 
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

www/sites/www

[Sebastian Kügler]

SVN commit 1337829 by sebas:

Release 4.10.0

CCMAIL:release-team@kde.org


 M  +0 -3  announcements/4.10/applications-it.php  
 M  +0 -3  announcements/4.10/applications.php  
 M  +0 -4  announcements/4.10/index-it.php  
 M  +0 -4  announcements/4.10/index.php  
 M  +0 -3  announcements/4.10/plasma-it.php  
 M  +0 -3  announcements/4.10/plasma.php  
 M  +0 -3  announcements/4.10/platform-it.php  
 M  +0 -3  announcements/4.10/platform.php  
 M  +4 -12 index.php  
 M  +4 -2  info/releases.php  


--- trunk/www/sites/www/announcements/4.10/applications-it.php #1337828:1337829
@@ -1,7 +1,4 @@
 ?php
-if (!$_GET[letmein]) {
-exit();
-}
 
   $release = '4.10';
   $release_full = '4.10.0';
--- trunk/www/sites/www/announcements/4.10/applications.php #1337828:1337829
@@ -1,7 +1,4 @@
 ?php
-if (!$_GET[letmein]) {
-exit();
-}
 
   $release = '4.10';
   $release_full = '4.10.0';
--- trunk/www/sites/www/announcements/4.10/index-it.php #1337828:1337829
@@ -1,9 +1,5 @@
 ?php
-if (!$_GET[letmein]) {
-exit();
-}
 
-
   $release = '4.10';
   $release_full = '4.10.0';
   $page_title = KDE Software Compilation 4.10;
--- trunk/www/sites/www/announcements/4.10/index.php #1337828:1337829
@@ -1,9 +1,5 @@
 ?php
-if (!$_GET[letmein]) {
-exit();
-}
 
-
   $release = '4.10';
   $release_full = '4.10.0';
   $page_title = KDE Software Compilation 4.10;
--- trunk/www/sites/www/announcements/4.10/plasma-it.php #1337828:1337829
@@ -1,7 +1,4 @@
 ?php
-if (!$_GET[letmein]) {
-exit();
-}
 
   $release = '4.10';
   $release_full = '4.10.0';
--- trunk/www/sites/www/announcements/4.10/plasma.php #1337828:1337829
@@ -1,7 +1,4 @@
 ?php
-if (!$_GET[letmein]) {
-exit();
-}
 
   $release = '4.10';
   $release_full = '4.10.0';
--- trunk/www/sites/www/announcements/4.10/platform-it.php #1337828:1337829
@@ -1,7 +1,4 @@
 ?php
-if (!$_GET[letmein]) {
-exit();
-}
 
   $release = '4.10';
   $release_full = '4.10.0';
--- trunk/www/sites/www/announcements/4.10/platform.php #1337828:1337829
@@ -1,7 +1,4 @@
 ?php
-if (!$_GET[letmein]) {
-exit();
-}
 
   $release = '4.10';
   $release_full = '4.10.0';
--- trunk/www/sites/www/index.php #1337828:1337829
@@ -42,14 +42,12 @@
 
 h2a name=announcementsLatest Announcements/a/h2
 
-pba href=announcements/announce-4.10-rc3.phpKDE Ships Third Release 
Candidate of Plasma Workspaces, Applications and Platform 4.10/a/bbr/
-On 18th January 2013, KDE has released the third release candidate of the 4.10 
Workspaces, Applications and Development Platform.
+pba href=announcements/4.10KDE Announces Plasma Workspaces, 
Applications and Platform 4.10/a/bbr/
+February 6, 2013. KDE is delighted to announce its latest set of releases, 
providing major updates to
+a href=announcements/4.10/plasma.phpKDE Plasma Workspaces/a, a 
href=announcements/4.10/applications.phpKDE Applications/a, and the a 
href=announcements/4.10/platform.phpKDE Platform/a.
+Version 4.10.0 provides many new features, along with improved stability and 
performance. Find out more about 4.10's improvements in our a 
href=announcements/4.10visual feature guide/a.
 /p
 
-pba href=announcements/announce-4.10-rc2.phpKDE Ships Second Release 
Candidate of Plasma Workspaces, Applications and Platform 4.10/a/bbr/
-On 4th January 2013, KDE has released the second release candidate of the 4.10 
Workspaces, Applications and Development Platform.
-/p
-
 pba href=announcements/announce-4.9.5.phpKDE Ships January Updates to 
Plasma Workspaces, Applications and Platform/a/bbr/
 On 2nd January 2013, KDE released an update to its applications, workspaces 
and development platform.
 The update contains 36 bugfixes for components such as the Kontact Groupware 
suite, the Dolphin file manager and
@@ -60,12 +58,6 @@
 On 15th October 2012, KDE has released Plasma Active Three, a new version of 
KDE's user experience for emerging devices. Plasma Active 3 improves 
performance in the underlying engines significantly, provides more apps and a 
more polished user experience.
 /p
 
-pba href=announcements/4.9KDE Announces Plasma Workspaces, 
Applications and Platform 4.9/a/bbr/
-August 1, 2012. KDE is delighted to announce its latest set of releases, 
providing major updates to
-a href=announcements/4.9/plasma.phpKDE Plasma Workspaces/a, a 
href=announcements/4.9/applications.phpKDE Applications/a, and the a 
href=announcements/4.9/platform.phpKDE Platform/a.
-Version 4.9.0 provides many new features, along with improved stability and 
performance.
-/p
-
 p
 View a href=announcements/ title=View older announcementsmore 
announcements.../a
 /p
--- trunk/www/sites/www/info/releases.php #1337828:1337829
@@ -8,16 +8,18 @@
 h2Current KDE SC Releases/h2
 
 p
-a href=4.9.5.phpKDE SC 4.9.5/a (stable version)
+a href=4.10.0.phpKDE SC 4.10.0/a (stable version)
 /p
 
+!--
 p
 a href=4.9.90.phpKDE SC 4.10 Beta 2/a (unstable version, only for 
testing)
 /p
-
+--
 h2Previous KDE Releases/h2
 
 ul
+lia href=4.9.5.phpKDE 4.9.5/a/li
 

4.10 announcement ready for translation

[Sebastian Kügler]

Hi,

The announcement can now be translated, it's in the usual place in the www svn 
repo.

Thanks everybody for the work so far!

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: Nepomuk - Changing the Resource class behaviour

[Sebastian Kügler]

On Tuesday, January 22, 2013 09:32:56 Allen Winter wrote:
  : remove the API in 4.11
 
 will that work?

No, as far as I can see, it's kdelibs and we can't remove API there. Deprecate 
it would be.
-- 
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: [Nepomuk] Nepomuk - Changing the Resource class behaviour

[Sebastian Kügler]

On Tuesday, January 22, 2013 22:15:28 Vishesh Handa wrote:
 This change only affects nepomuk-core.
 
 If there are no problems, I will do the following -
 
 * Implement these changes in master
 * leave 4.10.0 alone.
 * Implement these changes in KDE/4.10 in time for 4.10.1
 
 By changes, I mean removing the automatic updates AND adding the new API.

I'm cool with that.
-- 
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: KDE SC 4.11 Release Schedule

[Sebastian Kügler]

On Tuesday, January 15, 2013 23:27:53 Albert Astals Cid wrote:
 I'd like to propose some changes for 4.11, i'd like everyone to comment
 
 1) Drop Betas to 1
 It doesn't seem to me that having extra betas gives us much more
 quality,  so my suggestion is to drop Beta 2 and move Beta 1 to happen in
 Beta 2 time (moving also Hard Freeze) which gives us 2 more weeks for
 feature development
 
 2) Drop RCs to 1
 Same thing, it did not feel to me as that it gave us much, drop RC2
 and RC1  one week into the future

This can only work if the quality effort starts timely (which didn't happen 
for 4.10, it only really got into gear for RC1, way too late).

We need closer collaboration between release-team, quality team and other 
parties. Only if we're sure that that process works better, we can think of 
decreasing the amount of pre-releases.

 3) Increase RC time between tag and packaging
 One day between tagging and release is crazy, let's have 5/6 days as
 we  have for the other releases

Why?

It's not one day, but as soon as tarballs are happy, so flexible instead of 
crazy short. We made this flexible because there's no need to wait if the 
tarballs are ready, every day that the tarballs wait in ready state before 
they're released decreases the usefulness of testing results. In my opinion, 
this is still valid and should be kept.

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

KDE Ships Second Release Candidate of Plasma Workspaces, Applications and Platform 4.10

[Sebastian Kügler]

A little belated, but here it is:

KDE Ships Second Release Candidate of Plasma Workspaces, Applications and 
Platform 4.10 (4.10 RC2):

* http://kde.org/announcements/announce-4.10-rc2.php

-- 
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: Fwd: www/sites/www

[Sebastian Kügler]

On Friday, January 04, 2013 21:38:51 Torgny Nyblom wrote:
 On Friday 04 January 2013 21.24.56 Torgny Nyblom wrote:
  On Friday 04 January 2013 17.27.50 Albert Astals Cid wrote:
   Any taker for the remaining tasks?

   Someone with more knowledge than me needs to do kde-annou...@kde.org,
   kde-
   press-announce and dot.kde.org
  
  kde-{press-}anno...@kde.org is done, Jos seems to have done dot.
 
 Seem like the press mail was denided by a moderator... so that part is still
 missing.

Fixed. :)
-- 
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: Another RC?, was: Re: Akonadi-Nepomuk Feeder Improvements

[Sebastian Kügler]

On Sunday, December 30, 2012 02:41:43 Scott Kitterman wrote:
 Assuming 4.10.1 and 4.10.2 slip similarly, that would result in the next 
 Kubuntu release having 4.10.1 instead of 4.10.2.  We might also have to
 make  some adjustments to our internal testing milestone schedule.
 
 4.10.2 would come out a day or two before Kubuntu 13.04 (far to late for
 pre- release updates) so we'd get to release without the current KDE
 SC.  We do ship the point releases as post-release updates, so they would
 get to users eventually, but post-release QA is a lot more work for us.
 
 This isn't precisely a problem, but changing the release cycle now is not
 idea  for us.  As long as 4.11 drops back into the usual time slot (and
 doesn't also slip), then the impact would not be major.

Would adding in two instead of three weeks work for you?
-- 
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

Another RC?, was: Re: Akonadi-Nepomuk Feeder Improvements

[Sebastian Kügler]

On Friday, December 28, 2012 21:54:17 Andreas K. Huettel wrote:
 Seriously. I know I'm probably just putting my foot in my mouth once more 
 here, but:
 
 What are betas and rc's for, if not for stabilizing code and progressing to 
 smaller and smaller non-intrusive changes? If you decide do kick out and
 replace a large chunk of code between rc1 and rc2, 2 weeks before release,
 you may as well re-label the 4.10.0 release beta1.

Maybe we should do that. Vishesh has a patch for Dolphin's filepreviewer that 
is also waiting, and with the akonadi Nepomukfeeder fixes, we could consider 
putting another release candidate in, do the actual release three weeks later 
than planned, BUT ship an SC with much improved Nepomuk, which will probably a 
lot of users happy. Aside from that, the testing initiative was geared up a 
bit late this time around, we only announced that in the last RC.

Who would be in favour of inserting another RC and three weeks to get 
Christian's and Vishesh's Nepomuk patches in *and* rockstable? Would it create 
any timing problems for distros that are going to ship 4.10? How does testing 
and user feedback look so far, with RC1?
-- 
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: Exception for Dolphin - KFileMetadataWidget

[Sebastian Kügler]

Hi Vishesh,

On Saturday, December 22, 2012 15:26:10 Vishesh Handa wrote:
 On Sat, Dec 22, 2012 at 3:07 PM, Frank Reininghaus
 frank7...@googlemail.com wrote: If many people thought that the benefits
 of the new widget outweigh the risks, I would say let's merge it - I
 don't want to be blamed by future users of KDE 4.10 for holding back useful
 things if there is no good reason for it. But at the moment, it seems that
 there are more people who are worried about the risks, so I feel that it
 should
 better wait until KDE 4.11.
 
 From what I have noticed most people just don't respond, and that is taken
 as a sign of acceptance. So one cannot really infer that there are more
 people who are worried about the risks. Just that 2 people who disagree
 have raised their voice.
 
 Is there something I can do to reduce these risks?
 
 From what I see there are 3 use cases -
 
 1. Using it when Nepomuk enabled
 2.1. Using it when Nepomuk is disabled
 2.2. Using it when Nepomuk is enabled but the file has no meta-data
 
 So, the concern of using the widget in unknown ways doesn't really come into
 play.
 
 I hope I'm not being rude. I just really really want to get this widget into
 4.10. Otherwise I'm going to have to spend 2-3 days (maybe even more?)
 fixing up the old deprecated Nepomuk code and the KFileMetadataWidget. I
 rather focus on other things.

Understandable, and in principle I agree. The user in me even wants this to go 
in, but my experience as release manager says otherwise. We're more than a 
month past feature freeze, and we have those freezes for a good reason: 
stability, being able to test code and iterate a few times over them.

Also, we have been bitten by this kind of last minute changes in the past, 
repeatedly, and especially by Nepomuk (though not exclusively).

That's why I'm so hesitant about this change. Ultimately, I'd leave the 
decision to Frank, but seeing he's also not convinced, I think we should just 
postpone this merge to 4.11, as sour as this might be.

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: Exception for Dolphin - KFileMetadataWidget

[Sebastian Kügler]

On Friday, December 21, 2012 16:27:17 Vishesh Handa wrote:
 So, may I merge my patch into kde-baseapps 4.10? It will get tested more
 thoroughly in RC2.

I'm very uneasy with merging something this big and intrusive into 4.10 at 
this point. I also don't see why it has to go into 4.10, sure, it's all nice, 
but certainly not critical, especially since ...

Would it not cause functional regressions, since the old indexer would index 
many more file types than the new indexing services in nepomuk-core?
-- 
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

www/sites/www

[Sebastian Kügler]

SVN commit 1327414 by sebas:

Release 4.9.4

CCMAIL:release-team@kde.org


 A announcements/announce-4.9.4.php   
announcements/announce-4.9.3.php#1327262
 M  +6 -0  announcements/index.php  
 M  +6 -6  index.php  


--- trunk/www/sites/www/announcements/index.php #1327413:1327414
@@ -10,6 +10,12 @@
 /p
 p /
 
+!-- 4.9.4 released --
+strong5th December 2012/strong - a href=announce-4.9.4.phpKDE Ships 
December Updates to Plasma Workspaces, Applications and Platform/a
+br /
+emKDE Ships 4.9.4 Workspaces, Applications and Platform./em
+p /
+
 !-- 4.10 beta2 released --
 strong4th December 2012/strong - a href=announce-4.10-beta2.phpKDE 
Announces 4.10 Beta 2/a
 br /
--- trunk/www/sites/www/index.php #1327413:1327414
@@ -42,16 +42,16 @@
 
 h2a name=announcementsLatest Announcements/a/h2
 
+pba href=announcements/announce-4.9.4.phpKDE Ships December Updates to 
Plasma Workspaces, Applications and Platform/a/bbr/
+On 5th December 2012, KDE has released an update to its applications, 
workspaces and development platform.
+The update contains 71 bugfixes for components such as the Kontact Groupware 
suite, the Dolphin file manager and
+the Plasma workspaces.
+/p
+
 pba href=announcements/announce-4.10-beta2.phpKDE Ships Second Beta of 
Plasma Workspaces, Applications and Platform 4.10/a/bbr/
 On 4th December 2012, KDE has released a second beta version of the 4.10 
Workspaces, Applications and Development Platform. This pre-release contains 
numberous improvements to usability and performance as well as a host of new 
bugfixes and features.
 /p
 
-pba href=announcements/announce-4.9.3.phpKDE Ships November Updates to 
Plasma Workspaces, Applications and Platform/a/bbr/
-On 6th November 2012, KDE has released on update to its applications, 
workspaces and development platform.
-The update contains 86 bugfixes for components such as the Kontact Groupware 
suite, the Kate editor and
-the Plasma Desktop workspace.
-/p
-
 pba href=announcements/plasma-active-threePlasma Active 3 Improves 
Performance, Brings New Apps/a/bbr/
 On 15th October 2012, KDE has released Plasma Active Three, a new version of 
KDE's user experience for emerging devices. Plasma Active 3 improves 
performance in the underlying engines significantly, provides more apps and a 
more polished user experience.
 /p
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

www/sites/www

[Sebastian Kügler]

SVN commit 1327265 by sebas:

Release 4.10 Beta2

CCMAIL:release-team@kde.org


 M  +2 -2  index.php  
 M  +1 -1  info/releases.php  


--- trunk/www/sites/www/index.php #1327264:1327265
@@ -42,8 +42,8 @@
 
 h2a name=announcementsLatest Announcements/a/h2
 
-pba href=announcements/announce-4.10-beta1.phpKDE Ships First Beta of 
Plasma Workspaces, Applications and Platform 4.10/a/bbr/
-On 21st November 2012, KDE has released a first beta version of the 4.10 
Workspaces, Applications and Development Platform. This pre-release contains 
numberous improvements to usability and performance as well as a host of new 
bugfixes and features.
+pba href=announcements/announce-4.10-beta2.phpKDE Ships Second Beta of 
Plasma Workspaces, Applications and Platform 4.10/a/bbr/
+On 4th December 2012, KDE has released a second beta version of the 4.10 
Workspaces, Applications and Development Platform. This pre-release contains 
numberous improvements to usability and performance as well as a host of new 
bugfixes and features.
 /p
 
 pba href=announcements/announce-4.9.3.phpKDE Ships November Updates to 
Plasma Workspaces, Applications and Platform/a/bbr/
--- trunk/www/sites/www/info/releases.php #1327264:1327265
@@ -12,7 +12,7 @@
 /p
 
 p
-a href=4.9.80.phpKDE SC 4.10 Beta 1/a (unstable version, only for 
testing)
+a href=4.9.90.phpKDE SC 4.10 Beta 2/a (unstable version, only for 
testing)
 /p
 
 h2Previous KDE Releases/h2
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

www/sites/www

[Sebastian Kügler]

SVN commit 1325823 by sebas:

Release 4.10 Beta1

CCMAIL:release-team@kde.org



 M  +5 -5  announcements/announce-4.10-beta1.php  
 M  +4 -0  index.php  
 M  +3 -3  info/releases.php  


--- trunk/www/sites/www/announcements/announce-4.10-beta1.php #1325822:1325823
@@ -12,7 +12,7 @@
 div  align=center style=width: auto; margin-top: 20px; margin-botton: 
20px;
 a href=announce-4.10-beta1.pngimg src=announce-4.10-beta1_thumb.png 
align=center width=640 alt=Plasma Desktop with the Dolphin file manager 
title=Plasma Desktop with the Dolphin file manager //a
 br /
-emPlasma Desktop with Dolphin and Gwenview/em
+emPlasma Desktop with Dolphin/em
 /div
 
 
@@ -21,7 +21,7 @@
 
 ul
 li
-strongQt Quick in Plasma Workspaces/strong -- Qt Quick is continuing 
to make its way into the Plasma Workspaces. Plasma Quick, KDE's extensions on 
top of QtQuick allow deeper integration with the system and more powerful apps 
and Plasma components. Plasma Containments can now be written in QtQuick. 
Various Plasma widgets have been rewritten in QtQuick, notably the system tray, 
pager, notifications, lock  logout, weather and weather station, comic strip 
and calculator plasmoids.
+strongQt Quick in Plasma Workspaces/strong -- Qt Quick is continuing 
to make its way into the Plasma Workspaces. Plasma Quick, KDE's extensions on 
top of QtQuick allow deeper integration with the system and more powerful apps 
and Plasma components. Plasma Containments can now be written in QtQuick. 
Various Plasma widgets have been rewritten in QtQuick, notably the system tray, 
pager, notifications, lock  logout, weather and weather station, comic strip 
and calculator plasmoids. Many performance, quality and usability improvements 
make Plasma Desktop and Netbook workspaces easier to use.
 /li
 li
 strongNew Screen Locker/strong -- A new screen locking mechanism based 
on QtQuick brings more flexibility and security to Plasma Desktop.
@@ -30,10 +30,10 @@
 strongAnimated Wallpapers/strong -- Thanks to a new QtQuick-based 
wallpaper engine, animated wallpapers are now much easier to create.
 /li
 li
-strongImproved Zooming in Okular/strong -- A technique called tiled 
rendering, which internally splits up the document in parts and only renders 
visible parts allows Okular to zoom in much more while reducing memory 
consumption. Okular Active, the touch-friendly version of the powerful document 
reader is now part of KDE SC.
+strongImproved Zooming in Okular/strong -- A technique called tiled 
rendering allows Okular to zoom in much further while reducing memory 
consumption. Okular Active, the touch-friendly version of the powerful document 
reader is now part of KDE SC.
 /li
 li
-strongFaster indexing/strong -- A new indexer allows the Nepomuk 
semantic engine faster indexing of files. The new Tags kioslave allows users to 
browse their files by tags in any KDE-powered application.
+strongFaster indexing/strong -- Improvements in the Nepomuk semantic 
engine allow faster indexing of files. The new Tags kioslave allows users to 
browse their files by tags in any KDE-powered application.
 /li
 li
 strongColor Correction/strong -- Gwenview, KDE's smart image viewer 
and Plasma's window manager now support color correction and can be adjusted to 
the color profile of different monitors, allowing for more natural 
representation of photos and graphics.
@@ -60,7 +60,7 @@
 strongKJumpingCube/strong has seen a large number of improvements 
making the game more enjoyable.
 /li
 /ul
-More improvements can be found in the a 
href=http://techbase.kde.org/Schedules/KDE4/4.10_Feature_Plan;4.10 Feature 
Plan/a. As with any large number of changes, we need to give 4.10 a good 
testing in order to maintain and improve the quality and our user's user 
experience when they get the update.
+More improvements can be found in the a 
href=http://techbase.kde.org/Schedules/KDE4/4.10_Feature_Plan;4.10 Feature 
Plan/a. As with any large number of changes, we need to give 4.10 a good 
testing in order to maintain and improve the quality and user experience when 
users install the update.
 
 Actual users are critical to maintaining high KDE quality, because developers 
simply cannot test every possible configuration. We're counting on you to help 
find bugs early so they can be squashed before the final release. Please 
consider joining 4.10 thoroughly and report any bugs you find to a 
href=http://bugs.kde.org;bugs.kde.org/a.
 
--- trunk/www/sites/www/index.php #1325822:1325823
@@ -42,6 +42,10 @@
 
 h2a name=announcementsLatest Announcements/a/h2
 
+pba href=announcements/announce-4.10-beta1.phpKDE Ships First Beta of 
Plasma Workspaces, Applications and Platform 4.10/a/bbr/
+On 21st November 2012, KDE has released a first beta version of the 4.10 
Workspaces, Applications and Development Platform. This pre-release contains 
numberous improvements to usability and performance as well 

Re: kdegraphicslibs (Was: libkdcraw api compatibility?)

[Sebastian Kügler]

On Wednesday, November 21, 2012 14:25:22 Allen Winter wrote:
 On Wednesday 21 November 2012 07:33:28 PM Albert Astals Cid wrote:
  El Dimecres, 21 de novembre de 2012, a les 11:38:09, Allen Winter va 
escriure:
   Sounds like we need a new module for graphics libraries.
   Along the lines of kdepimlibs, but for graphics
 
  Why? The people developing those libraries don't want to maintain the
  ABI/API  of these libs during all the life of 4.x
 
 We have (had) a policy that no application-module-library should used
 by applications outside that module.
 
 i.e we can't have kphotoalbum dependent on libkdcraw from kdegraphics
 
 I think this is still a good policy.
 
 But we know that digikam, kphotoalbum, etc. does rely on libs from
 kdegraphics.
 
 If we put such libs in a new module called kdegraphicslibs and enforce the
 ABI/API restrictions there, then we can eliminate these problems in the
 future.
 
 I think kdepimlibs has proven this to be a successful strategy.
 Lots of non-kdepim stuff depends on kdepimlibs and we haven't had
 ABI/API complaints problems from that combination in a long time.
 
 Some libraries are widely used and can conceptually be thought of as core
 libs. Perhaps libkdcraw is such a library.

One question to consider is wether this split should be done before 
Frameworks5, or as part of it. I think the Frameworks5 approach (so putting 
kdcraw, libkipi into separate packages and ship them as separate frameworks.

In any case, we should commit to binary compatibility similar to kdelibs for 
these, if possible, but that depends on their authors. (It's just as broken a 
process right now, however, from a deployment point of view.)

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: kdegraphicslibs (Was: libkdcraw api compatibility?)

[Sebastian Kügler]

On Wednesday, November 21, 2012 21:01:10 Albert Astals Cid wrote:
  One question to consider is wether this split should be done before
  Frameworks5, or as part of it. I think the Frameworks5 approach (so
  putting
  kdcraw, libkipi into separate packages and ship them as separate
  frameworks.

 We do that already.

Ah, ok. Thanks for the clarification. :)
-- 
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: Binary packages section of info/release.php pages

[Sebastian Kügler]

On Friday, November 09, 2012 00:27:18 Albert Astals Cid wrote:
 I was looking today at http://www.kde.org/info/4.9.3.php#binary and see 
 there's only the Kubuntu information there when i know a few more distros
 have  released 4.9.3 packages.
 
 Do we still need that? It looks a bit sad how it looks right now (and has 
 looked in the various releases).
 
 Do we want to remove it?
 
 Do we want to replace it with something else?
 
 Ideas?

In its current state, I'd say: ditch it. If packagers would like to see their 
binary packages listed there (and it's not just one or two distros), then we 
need to find a way to add the binary packages as they arrive. Could be a 
manual thing, asking someone to add a link there, even, or we put it on a wiki 
page, making it less maintainance work for the release team and easier to edit 
for those that would like to see their packages advertised.
-- 
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: Request for adding new plugin for Dolphin

[Sebastian Kügler]

On Monday, November 05, 2012 21:50:01 Albert Astals Cid wrote:
 What do others say?

No objection from me, neither, asuming the code is properly reviewed of 
course.

 Of course you still have to go trhough the review process (i.e. kdereview, 
 etc).
-- 
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

www/sites/www

[Sebastian Kügler]

SVN commit 1324281 by sebas:

release 4.9.3

CCMAIL:release-team@kde.org


 M  +1 -1  announcements/announce-4.9.3.php  
 M  +7 -1  announcements/index.php  
 M  +1 -1  download/index.php  
 M  +6 -0  index.php  
 M  +2 -1  info/releases.php  


--- trunk/www/sites/www/announcements/announce-4.9.3.php #1324280:1324281
@@ -1,5 +1,5 @@
 ?php
-  $page_title = KDE Ships October Updates to Plasma Workspaces, Applications 
and Platform;
+  $page_title = KDE Ships November Updates to Plasma Workspaces, Applications 
and Platform;
   $site_root = ../;
   include header.inc;
 ?
--- trunk/www/sites/www/announcements/index.php #1324280:1324281
@@ -10,13 +10,19 @@
 /p
 p /
 
+!-- 4.9.2 released --
+strong6th November 2012/strong - a href=announce-4.9.3.phpKDE Ships 
November Updates to Plasma Workspaces, Applications and Platform/a
+br /
+emKDE Ships 4.9.3 Workspaces, Applications and Platform./em
+p /
+
 !-- plasma active two released --
 strong15th October 2012/strong - a href=plasma-active-three/Plasma 
Active 3 Improves Performance, Brings New Apps/a
 br /
 emKDE Releases Third Version of Cross-Device UX./em
 p /
 
-!-- 4.9.1 released --
+!-- 4.9.2 released --
 strong2nd October 2012/strong - a href=announce-4.9.2.phpKDE Ships 
October Updates to Plasma Workspaces, Applications and Platform/a
 br /
 emKDE Ships 4.9.2 Workspaces, Applications and Platform./em
--- trunk/www/sites/www/download/index.php #1324280:1324281
@@ -86,7 +86,7 @@
 p
 KDE SC 4.9 is the version for the majority of end users that look
 for the latest stable KDE software release. Please see the
-a href=/info/4.9.2.php4.9.2 Info Page/a for details.
+a href=/info/4.9.3.php4.9.3 Info Page/a for details.
 /p
 
 a name=v3.5/ah3KDE 3 series/h3
--- trunk/www/sites/www/index.php #1324280:1324281
@@ -42,6 +42,12 @@
 
 h2a name=announcementsLatest Announcements/a/h2
 
+pba href=announcements/announce-4.9.3.phpKDE Ships November Updates to 
Plasma Workspaces, Applications and Platform/a/bbr/
+On 6th November 2012, KDE has released on update to its applications, 
workspaces and development platform.
+The update contains 86 bugfixes for components such as the Kontact Groupware 
suite, the Kate editor and
+the Plasma Desktop workspace.
+/p
+
 pba href=announcements/plasma-active-threePlasma Active 3 Improves 
Performance, Brings New Apps/a/bbr/
 On 15th October 2012, KDE has released Plasma Active Three, a new version of 
KDE's user experience for emerging devices. Plasma Active 3 improves 
performance in the underlying engines significantly, provides more apps and a 
more polished user experience.
 /p
--- trunk/www/sites/www/info/releases.php #1324280:1324281
@@ -8,7 +8,7 @@
 h2Current KDE SC Releases/h2
 
 p
-a href=4.9.2.phpKDE SC 4.9.2/a (stable version)
+a href=4.9.3.phpKDE SC 4.9.3/a (stable version)
 /p
 
 !--p
@@ -18,6 +18,7 @@
 h2Previous KDE Releases/h2
 
 ul
+lia href=4.9.2.phpKDE 4.9.1/a/li
 lia href=4.9.1.phpKDE 4.9.1/a/li
 lia href=4.9.0.phpKDE 4.9.0/a/li
 lia href=4.8.5.phpKDE 4.8.5/a/li
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: polkit-kde-kcmmodules editing /usr

[Sebastian Kügler]

On Thursday, October 25, 2012 14:38:01 Robby Workman wrote:
 On Thu, 25 Oct 2012, Kevin Kofler wrote:
  On Thursday 25 October 2012 at 09:47:08, Andrea Scarpino wrote:
  I cannot help here as we don't provide it in our repos.
  
  We (Fedora) neither.
  
  But on Arch Linux we have the same kind of issue with KDM; it stores the
  configs in /usr/share/config/kdm.
  How do you handle that?
  
  In Fedora, /usr/share/config/kdm is a symlink to /etc/kde/kdm.
 
 Ditto for Slackware.

The obvious question here is: If everybody changes it, why do we ship it that 
way?
-- 
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: Feature Freeze and Review Board

[Sebastian Kügler]

On Wednesday, October 24, 2012 14:10:43 Albert Astals Cid wrote:
   So personally i'd like that you guys still add the stuff to the
   feature plan.
  
   And when we are at it: could we change trunk to whatever is better
   fitting?
  
   Can we just be smart people and accept that trunk is just a word
   and that
   the rest of the people is smart enough too and understand that for
   git it
   means master?
  
   Because what other word are you suggesting instead of trunk?
 
  maybe release branch?
 
 Not really sure that'd be clearer, is anyone reading this and has an
 opinion?

I agree with whoever mentioned bikeshedding. trunk, master and release 
branch are all fine and I think clear enough. Or one could just use them all 
three.

As to the real issue: I think stuff submitted to review board should get the 
same handling as if it were put on the Feature Plan, i.e. only be applied to 
the hard freeze. That's most in line with what we actually want to achieve. We 
should encourage adding it to the feature plan as well, so the RB only is 
just an exception we know how to handle.

Now let's get back to work =)
-- 
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

www/sites/www

[Sebastian Kügler]

SVN commit 1318785 by sebas:

release 4.9.2 :)

CCMAIL:release-team@kde.org


 M  +6 -0  announcements/index.php  
 M  +1 -1  contact/about_kde-et.inc  
 M  +1 -1  contact/about_kde.inc  
 M  +1 -1  contact/about_kde_ru.inc  
 M  +1 -1  contact/about_kde_uk.inc  
 M  +2 -2  index.php  
 M  +3 -2  info/releases.php  


--- trunk/www/sites/www/announcements/index.php #1318784:1318785
@@ -11,6 +11,12 @@
 p /
 
 !-- 4.9.1 released --
+strong2nd October 2012/strong - a href=announce-4.9.2.phpKDE Ships 
October Updates to Plasma Workspaces, Applications and Platform/a
+br /
+emKDE Ships 4.9.2 Workspaces, Applications and Platform./em
+p /
+
+!-- 4.9.1 released --
 strong4th September 2012/strong - a href=announce-4.9.1.phpKDE Ships 
September Updates to Plasma Workspaces, Applications and Platform/a
 br /
 emKDE Ships 4.9.1 Workspaces, Applications and Platform./em
--- trunk/www/sites/www/contact/about_kde-et.inc #1318784:1318785
@@ -16,7 +16,7 @@
 sealhulgas interneti- ja veebi-, multimeedia-, meelelahutus-, õpi-, 
 graafika- ja tarkvara arendamise rakendused. KDE tarkvara on tõlgitud enam 
 kui 60 keelde ning selle loomisel on peetud silmas kasutamise lihtsust 
-ja tänapäeva hõlbustusnõudeid. KDE4 rakendused töötavad raskusteta nii 
+ja tänapäeva hõlbustusnõudeid. KDE rakendused töötavad raskusteta nii
 Linuxi, BSD, Solarise, Windowsi kui ka Mac OS X süsteemides.
 /p
 
--- trunk/www/sites/www/contact/about_kde.inc #1318784:1318785
@@ -17,7 +17,7 @@
 applications, multimedia, entertainment, educational, graphics and 
 software development. KDE software is translated into more than 60 
 languages and is built with ease of use and modern accessibility 
-principles in mind. KDE4's full-featured applications run natively on 
+principles in mind. KDE's full-featured applications run natively on
 Linux, BSD, Solaris, Windows and Mac OS X.
 /p
 
--- trunk/www/sites/www/contact/about_kde_ru.inc #1318784:1318785
@@ -15,7 +15,7 @@
 офисный пакет, пакет-органайзер для совместной работы и сотни программ 
совершенно разного предназначения,
 включая программы для работы с сетью и интернет, графикой, мультимедийные, 
развлекательные программы,
 а также средства для их разработки. KDE переводится на более чем 60 языков и 
построен на принципах
-простоты изучения и гибкости в дальнейшей работе. Многие программы KDE4 
работают на всех основных платформах — 
+простоты изучения и гибкости в дальнейшей работе. Многие программы KDE 
работают на всех основных платформах —
 Linux, BSD, Solaris, Windows и Mac OS X, максимально интегрируясь в их среды.
 /p
 
--- trunk/www/sites/www/contact/about_kde_uk.inc #1318784:1318785
@@ -9,7 +9,7 @@
   Про KDE
 /h2
 p align=justify
-KDE — це міжнародна команда розробників, які створюють вільне програмне 
забезпечення з відкритим кодом для стаціонарних і портативних комп’ютерів. 
Серед продуктів KDE сучасна стільнична система для платформ Linux і UNIX, 
повноцінний офісний комплекс та комплекси програм для групової роботи, а також 
сотні програмних продуктів у багатьох категоріях, зокрема інтернет- та 
веб-програми, мультимедійні програми та програми для розваг, освітні, графічні 
програми  та програми для розробки. Програмне забезпечення KDE перекладено 
більш ніж 60 мовами, 
 його створено простим у користуванні з врахуванням сучасних принципів 
ергономіки. Програми KDE4 можуть виконуватися у середовищах Linux, BSD, 
Solaris, Windows і Mac OS X.
+KDE — це міжнародна команда розробників, які створюють вільне програмне 
забезпечення з відкритим кодом для стаціонарних і портативних комп’ютерів. 
Серед продуктів KDE сучасна стільнична система для платформ Linux і UNIX, 
повноцінний офісний комплекс та комплекси програм для групової роботи, а також 
сотні програмних продуктів у багатьох категоріях, зокрема інтернет- та 
веб-програми, мультимедійні програми та програми для розваг, освітні, графічні 
програми  та програми для розробки. Програмне забезпечення KDE перекладено 
більш ніж 60 мовами, 
 його створено простим у користуванні з врахуванням сучасних принципів 
ергономіки. Програми KDE можуть виконуватися у середовищах Linux, BSD, Solaris, 
Windows і Mac OS X.
 /p
 
 hr /
--- trunk/www/sites/www/index.php #1318784:1318785
@@ -42,8 +42,8 @@
 
 h2a name=announcementsLatest Announcements/a/h2
 
-pba href=announcements/announce-4.9.1.phpKDE Ships September Updates 
to Plasma Workspaces, Applications and Platform (KDE SC 4.9.1)/a/bbr/
-On 4th September 2012, KDE has released updates to their workspaces, 
applications and development platform. Significant bugfixes include 
improvements to the Kontact Suite, bugfixes in Dolphin and many more 
corrections and performance improvements all over the place.
+pba href=announcements/announce-4.9.2.phpKDE Ships October Updates to 
Plasma Workspaces, Applications and Platform (KDE SC 4.9.2)/a/bbr/
+On 2nd October 2012, KDE has released updates to their workspaces, 
applications and development platform. Significant bugfixes include 

Re: 4.9.2 announcement?

[Sebastian Kügler]

On Monday, October 01, 2012 08:58:54 Torgny Nyblom wrote:
 As the public release comes closer I was wondering if anyone has written the
 announcement?

It's on my plate for tomorrow. Announcements for dot-releases are usually done 
on release day.
-- 
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: Regression causing Freeze in KWin 4.9.1

[Sebastian Kügler]

On Wednesday, September 05, 2012 16:07:30 Allen Winter wrote:
 Hot fixes should be sent to kde-packagers as a patch, or even better as a
 commit number.
 
 Example:
 
 Dear packagers, we found a bad bug in kde-foo that causes the following
 terrible things to happen. Please apply commit abc123 to your kde-foo
 packages and distribute this new version to your users as soon as
 possible.
 
 I don't think we want to respin tarballs for bugfixes.  To my recollection,
 we never have.

Right, tarballs are final. It would only introduce confusion (which version 
of the 4.9.1 tarball do you have?), so we better avoid it. 

We can always increase the version number and release 4.9.2 tomorrow, with 
just this one fix. Do we want to do that?
-- 
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

4.9.1 is out

[Sebastian Kügler]

Hey all,

Congratulations and thanks for all your work to 4.9.1, which is now out in the 
wild.

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: Killing announcements/changelogs/changelog*.php

[Sebastian Kügler]

On Wednesday, August 15, 2012 12:44:09 Albert Astals Cid wrote:
 What do you guys think?

With Albert. What he says. +1.
-- 
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: KDE 4.8.5 tarballs available

[Sebastian Kügler]

On Sunday, August 05, 2012 23:09:17 Dirk Mueller wrote:
 I think we're ready to go. will enable syncing now, we can announce
 tomorrow  morning.

Announcement is out, thanks everybody!
-- 
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: Re: Release Script (KF5)

[Sebastian Kügler]

On Thursday, July 12, 2012 20:00:27 Michael Jansen wrote:
   Do you really think forcing an update of unchanged modules for our
   convenience will help those of us trying to use plasma for mobile
   devices?
  
  That's the work of the distributor for those mobile devices.
 
  
 Exactly as i said. For our convenience we put the work on their shoulders.
 This will hurt the plasma mobile effort. 

FWIW, that assumption is wrong: Having version numbers be in line with each 
other makes our work easier, because we can just check if all packages are at 
least at version X.Y.Z and don't need special knowledge about which packages 
did indeed have commits in a certain period.

That's no different from normal distribution.
-- 
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: Release Script (KF5)

[Sebastian Kügler]

Hi,

On Wednesday, July 18, 2012 13:25:55 i...@michael-jansen.biz wrote:
  This will hurt the plasma mobile effort.
  
  FWIW, that assumption is wrong: Having version numbers be in line 
  with each
  other makes our work easier, because we can just check if all
  packages are at
  least at version X.Y.Z and don't need special knowledge about which 
  packages
  did indeed have commits in a certain period.
  
  That's no different from normal distribution.
 
 So you consider it less work to repackage 60 modules instead of 12?
 
 You consider it less strain on your servers and users bandwidth to send 
 them 60 repackaged modules instead of 12?
 
 Really?

Yes. Especially, if the chance is really low that a package did not change at 
all. I've explained our *current* version numbering so many times that an even 
more complex one is just quadrupling the trouble, making it much more likely 
to have outdated packages and not notice them.

A common version number provides great value.

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: Re: Changes to the kde-cvs-announce mailing list

[Sebastian Kügler]

On Sunday, July 15, 2012 22:20:13 David Faure wrote:
 Sysadmins are meta-moderators anyway (e.g. I can approve a mail on any
 mailing-list).

So you have time left for emergency moderation? ;)

/rhetorical question
-- 
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

4.9 RC2 is out

[Sebastian Kügler]

Thanks to Albert and Torgny, 4.9 RC2 is out.

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: Re: KDE 4.8.5 planning

[Sebastian Kügler]

Hey,

On Saturday, July 07, 2012 13:34:07 Michael Jansen wrote:
Also, *before* you start doing partial releases, please present an
exact
definition of the dependencies *between versions*.
   
   As i see that you are on the release-team list. May i ask why you voice
   your objections the exact same moment someone wants to try something we
   discussed here on the list for quite some time instead of actively
   participating this to the discussion before?
  
  So, where has this been discussed before? Are you refering to the split
  release proposal between frameworks, workspaces and apps? If so, that's at
  the earliest post Frameworks 5 material, but as there is no firm support
  for that, I suppose even Frameworks 5 timeframe will still see our
  monolithic releases, until we decide (not just discuss!) to do otherwise.
  
  If it's about something else, could you provide a pointer, because I seem
  to have missed that discussion.
 
  
 Let me point you to the discussion.
  
 The discussion is on this list. Can't find it? It is called release script.

Ha, I hadn't read that whole thread yet. It seems to be about implementation 
details of a certain script. Thanks for the pointer.

 It is my attempt to hammer out with everyone involved what releasing really
 means. To get people to talk about what changes are needed to make live
 easier for kde, kde-packagers, distro-packages and really anyone. 
 So whe can automate it and everyone is happy.
  
 You got each and every mail of the discussion since you are subscribed. Ok.
 A few are kde-buildsystem only. 
 Since Andreas took my hint and provided some helpful insights it is now
 quite a big thread. About 30 emails on this list. Hard to miss. 
 So you chose to not read the discussion? Or failed to understand? Or already
 forgot? Is this list so high volume you have to skip some? 
 So i am still wondering what this mailing list brings to the table. Noone
 seems to read it. If they do they do not care enough to contribute until
 called out. 
 And the people on this list are the ones that should care.

That conclusions seems to be drawn too quickly. You're right in that I don't 
care about every single technical detail, but gotta admit: it's well hidden 
under a subject that doesn't immediately suggest that this is worth reading if 
you're not quite so interested in the technical bits. Aaaanyway...

 Which leaves me wondering why i care.

Don't worry, I was just asking the question because I care. Thanks for the 
pointer, I'll catch up on that.

Also, let's all try to be less tensed. I know there's a lot of changes going 
on right now, but if we just sit down and deal with these changes, the end 
result will be better and things will settle down for sure again as well. If 
you think it's too much for you, that's unfortunate, but please try to avoid 
dragging others down by (incorrectly) second guessing their motivations. We're 
all here with the same goal, and it's not an easy one. Let's give ourselves 
some room for that, and recognize that we're doing some hard work, where 
frustration sometimes can happen, but we're there to support each other.

Have a nice day,
-- 
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: Re: KDE 4.8.5 planning

[Sebastian Kügler]

On Thursday, July 05, 2012 19:51:41 Michael Jansen wrote:
Will that be a normal release (i.e. full KDE SC) or just kdelibs?
   
   This might be a nice time to try only releasing the packages that have
   changes.
  
  Please dont change that within stable series.

I fully agree with that. It's stable release for a reason, not the time to 
experiment with something so fundamental as this.

  Also, *before* you start doing partial releases, please present an exact
  definition of the dependencies *between versions*.
 
 As i see that you are on the release-team list. May i ask why you voice your
 objections the exact same moment someone wants to try something we
 discussed here on the list for quite some time instead of actively
 participating this to the discussion before?

So, where has this been discussed before? Are you refering to the split 
release proposal between frameworks, workspaces and apps? If so, that's at the 
earliest post Frameworks 5 material, but as there is no firm support for that, 
I suppose even Frameworks 5 timeframe will still see our monolithic releases, 
until we decide (not just discuss!) to do otherwise.

If it's about something else, could you provide a pointer, because I seem to 
have missed that discussion.

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: Re: KDE 4.8.5 planning

[Sebastian Kügler]

On Thursday, July 05, 2012 18:07:47 Allen Winter wrote:
 On Thursday, July 05, 2012 01:00:11 PM Dirk Mueller wrote:
  I guess with all the kdelibs mess we should redo another 4.8.5 release.
  Does anyone have suggestions for a release plan?
  
  I would like to do tagging either tomorrow morning or in the last July
  week, as I'm on vacation in between.
  
  Any preference?
 
 Since we haven't communicated our plans to the developers wrt a 4.8.5
 I would suggest we decide to wait until the last July week.  The alternative
 of tomorrow morning is too soon.
 
 If we can agree on that, I volunteer to send a email letting people know.
 
 Also I will say that there are no plans for a 4.8.6.

+1
-- 
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: Release-team bof

[Sebastian Kügler]

On Thursday, June 28, 2012 18:27:29 Albert Astals Cid wrote:
 Anyone is attending Akademy? Do you guys think it makes sense to schedule a 
 bof for the release-team?

Definitely, I'll be in.
-- 
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: Proposed adjustments to our release cycles

[Sebastian Kügler]

On Monday, June 18, 2012 00:26:13 Albert Astals Cid wrote:
  * Need more people to do the tarball packaging/releasing (since if you 
 propose to release that often you can't expect the same person to be doing 
 packages almost weekly or byweekly given the release dates won't probably 
 align)
 
  * Uncertainity on the current release state. We have people that don't
 know  the current state of the release and commit new features or new
 strings when we are frozen, and that's with just one release schedule, i
 can imagine the mess with N different release schedules
 
  * The difficulty of coding for N releases. Since the releases an not
 aligned  anymore, you have to maintain code and #ifdefs for new features
 that depend on new versions of parts X of the stack that may or might not
 be used by people compiling the application. We've have some bad
 experiences with expected versions on the stack so i hope you're
 understanding this is not a theoretical scenario.
 
 What's your opinion on these issues?

Especially on the last issue, I think it's important that we create a proper 
platform definition and communicate that upfront. That definition would 
include dependencies (package + version) of our own Frameworks that are 
required, and of their dependencies, including for example X, Mesa, QtJSon, 
libmysqlclient, etc.

I suppose most of this information can be extracted from CMake, even.
-- 
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

Proposed adjustments to our release cycles

[Sebastian Kügler]

Hi all,

During our sprint in Pineda de Mar, we sat down and thought about how our 
release cycles relate to the structures in our software, we came up with the 
following proposal we'd like you to consider and provide feedback about.

Starting with KDE Frameworks 5, we will release Frameworks, Workspaces and 
Applications each with their own release cycles. Each of these releases would 
be a set of tarballs of the latest stable versions of the application (or 
codebase in more general). 
As an example, Frameworks could release updates every 2 months, while our 
application collection is updated monthly. New iterations of the workspaces 
come every four months. (These numbers are completely arbitrary, and here only 
for illustration purpose!)

More specifically for the Workspaces, we would like to release all workspaces 
at the same time.

This model would

* Allow components to skip releases if they need to take a longer development 
  cycle
* encourage developers to have an always releasable master
* put more emphasis on continuous integration and other automated testing

As far as we can judge, this would be in line with our communication strategy, 
and allow us to target different groups more clearly. That is something to 
streamline with the people at kde-promo, though.

Opinions?

Aurelien, David, Dario, Vishesh, Alex, Aleix, Martin, Martin, Marco, Björn, 
Kevin, and
-- 
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: Nepomuk crashes in 4.8.4 fixed in KDE/4.8.x branch

[Sebastian Kügler]

On Thursday, June 14, 2012 01:31:18 Albert Astals Cid wrote:
 Vishesh fixed the KDE/4.8.x branch of kdelibs. Can you guys verify it also
 fixes the issues for you?
 
 If so, what's the next step? Release an early 4.8.5? Repackage 4.8.4
 kdelibs?
 
 Ideas?

4.8.5 from my POV. We can do a 4.8.6 later, but I think we shouldn't re-
release a version (will lead to bugzilla headaches) and we also should not 
change version numbering scheme. Patch updates at 4.8.x, so our next patch 
release (even if it just contains one important fix) has to be 4.8.5.

My opinion, anyway. :)
-- 
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

www/sites/www

[Sebastian Kügler]

SVN commit 1300408 by sebas:

Release 4.9 Beta2

\o/

CCMAIL:release-team@kde.org


 M  +4 -4  announcements/announce-4.9-beta2.php  
 M  +6 -0  announcements/index.php  
 M  +6 -6  index.php  


--- trunk/www/sites/www/announcements/announce-4.9-beta2.php #1300407:1300408
@@ -9,7 +9,7 @@
 
 June 13, 2012. Today KDE released the second beta for its renewed Workspaces, 
Applications, and Development
 Platform. With API, dependency and feature freezes in place, the KDE team's 
focus is now on fixing
-bugs and further polishing new and old functionality. Highlights of 4.9 
include, but are not limited to:
+bugs and further polishing new and old functionality. Highlights of 4.9 will 
include, but are not limited to:
 
 ul
 li
@@ -23,13 +23,13 @@
 Many performance improvements and bugfixes improve the overall user 
experience, making the KDE Applications and Workspaces more productive and fun 
to use than ever before.
 /li
 /ul
-More improvements can be found in the a 
href=http://techbase.kde.org/Schedules/KDE4/4.9_Feature_Plan;4.9 Feature 
Plan/a. As with any large number of changes, we need to give 4.9 a good 
testing in order to maintain and improve the quality and our user's user 
experience when they get the update. Therefore, in tandem with this first 4.9 
beta, we also announce a testing initiative lead by KDE's Testing Team.
+More improvements can be found in the a 
href=http://techbase.kde.org/Schedules/KDE4/4.9_Feature_Plan;4.9 Feature 
Plan/a. As with any large number of changes, we need to give 4.9 a good 
testing in order to maintain and improve the quality and our user's user 
experience when they get the update.
 
 h2Testing in Progress/h2
 p
 The KDE Testing Team carries on testing with Beta2. The testing effort
-started with 4.9 Beta 1. 83 bugs reports were opened or
-confirmed, 29 of them are already closed, the bugs having been fixed.
+started with 4.9 Beta 1. 101 bugs reports were opened or
+confirmed, 33 of them are already closed, the bugs having been fixed.
 Some regressions in QML applets were identified and fixed. A few bugs were 
also corrected without anyone opening a bug report. Newcomers joined the team 
and are doing a great job. The KDE Testing Team is happy to welcome more 
people. It is easy to get involved: install the Beta 2 from your distribution 
and choose an area of
 testing, all details are available on the a 
href=http://community.kde.org/Getinvolved/Testing/Beta;wiki/a. We are also 
available on IRC Freenode in the #kde-testing channel and
 via our a href=https://mail.kde.org/mailman/listinfo/kde-testing;mailing 
list/a.
--- trunk/www/sites/www/announcements/index.php #1300407:1300408
@@ -10,6 +10,12 @@
 /p
 p /
 
+!-- 4.9 Beta2 released --
+strong13th June 2012/strong - a href=announce-4.9-beta2.phpKDE 
Announces 4.9 Beta2/a
+br /
+emKDE Provides Test Release for 4.9 Beta2 Workspaces, Applications and 
Platform./em
+p /
+
 !-- 4.8.4 released --
 strong8th June 2012/strong - a href=announce-4.8.4.phpKDE Ships June 
Updates to Plasma Workspaces, Applications and Platform/a
 br /
--- trunk/www/sites/www/index.php #1300407:1300408
@@ -42,16 +42,16 @@
 
 h2a name=announcementsLatest Announcements/a/h2
 
+pba href=announcements/announce-4.9-beta2.phpKDE Announces 4.9 
Beta2/a/bbr/
+June 13, 2012. KDE released the second beta for its renewed Workspaces, 
Applications, and Development
+Platform. With API, dependency and feature freezes in place, the KDE team's 
focus is now on fixing
+bugs and further polishing new and old functionality.
+/p
+
 pba href=announcements/announce-4.8.4.phpKDE Ships June Updates to 
Plasma Workspaces, Applications and Platform (KDE 4.8.4)/a/bbr/
 On 8th June 2012, KDE has released updates to their workspaces, applications 
and development platform. Significant bugfixes include improvements to the 
Kontact Suite, bugfixes in Dolphin and many more corrections and performance 
improvements all over the place.
 /p
 
-pba href=announcements/announce-4.9-beta1.phpKDE Announces 4.9 Beta1 
and Testing Initiative/a/bbr/
-June 4, 2012. KDE released the first beta for its renewed Workspaces, 
Applications, and Development
-Platform. With API, dependency and feature freezes in place, the KDE team's 
focus is now on fixing
-bugs and further polishing new and old functionality.
-/p
-
 pba href=announcements/4.8KDE Plasma Workspaces, Applications and 
Platform 4.8 Improve User Experience/a/bbr/
 On 25th January 2012, KDE has released 4.8.0, containing compelling new 
features and improvements to the a href=announcements/4.8/plasma.phpPlasma 
Workspaces/a, the a href=announcements/4.8/applications.phpKDE 
Applications/a and the a href=announcements/4.8/platform.phpKDE 
Development Platform/a./p
 
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Re: ALERT: KDElibs (at least) 4.8.4 is actually 4.8.80+

[Sebastian Kügler]

On Sunday, June 10, 2012 01:22:03 Kevin Kofler wrote:
 On Sunday 10 June 2012, Nicolás Alvarez wrote:
  Why not start now and make the next kdelibs 4.8.5? Releasing a kdelibs
  4.9 will just add to the confusion of how kdelibs development is
  working.
 
 Because having a kdelibs version different from (and especially lower than)
 the  KDE SC version messes up our packaging pretty badly.

I'd consider that a bug in your packaging. There's no absolute requirement of 
an app for a specific version of kdelibs. If your packages need that, you 
should probably fix them. The decoupling of libs and apps, and especially the 
modularization of kdelibs into Frameworks will only reveal more problems with 
your packages.
-- 
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: Re: ALERT: KDElibs (at least) 4.8.4 is actually 4.8.80+

[Sebastian Kügler]

On Monday, June 11, 2012 16:25:17 Scott Kitterman wrote:
 Currently my About KDE says:
 
 Platform Version 4.8.3 (4.8.3)
 
 Once kdelibs versioning is desynchronized from the rest of the platform,
 what  version is it?

At least application-version and underlying-platform-version might (or might 
not) differ. the KDE Platform will end with 4.x, after that, we'll start 
releasing KDE Frameworks, which is the successor to the development platform 
a.k.a. kdelibs++. The new naming is to reflect the increased modularity and 
decreased interdependence.
-- 
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: Re: ALERT: KDElibs (at least) 4.8.4 is actually 4.8.80+

[Sebastian Kügler]

On Sunday, June 10, 2012 20:17:56 Wulf C. Krueger wrote:
 On 10.06.2012 15:27, Albert Astals Cid wrote:
  - - Before announcing the tarballs, build the whole thing at
  least once.
  
  We do that, that's why we have a week before the release where
  packagers get access to pre-release tarballs.
 
 No, that's for us packagers to do our thing. What you give us
 should, as a rule, build and install properly.

As Albert says, it's really a difference in perception. We decide to put 
tarballs up as soon as possible, even while we're still testing them. If we 
decided to run a test before that, we'd have people asking for it right away 
as well.

That is really easy to solve: Only build the tarballs we actually put our 
final tag on. You'll have the updates later in your repos, but you won't get 
any of the smoke test problem.
-- 
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

[kdelibs/KDE/4.8] kio/kio: Fix build for Qt 4.8

[Sebastian Kügler]

Git commit c1f6c3980d92c2109f3f2ab3bd1fada31a0e4ecd by Sebastian Kügler.
Committed on 06/06/2012 at 16:02.
Pushed by sebas into branch 'KDE/4.8'.

Fix build for Qt 4.8

Patch by Annma

CCMAIL:release-team@kde.org

M  +16   -4kio/kio/tcpslavebase.cpp

http://commits.kde.org/kdelibs/c1f6c3980d92c2109f3f2ab3bd1fada31a0e4ecd

diff --git a/kio/kio/tcpslavebase.cpp b/kio/kio/tcpslavebase.cpp
index 480dd04..3101bff 100644
--- a/kio/kio/tcpslavebase.cpp
+++ b/kio/kio/tcpslavebase.cpp
@@ -363,11 +363,14 @@ int TCPSlaveBase::connectToHost(const QString host, 
quint16 port, QString* erro
   the SSL handshake, then that combination will be cached using KIO's 
internal
   meta-data mechanism in order to speed up future connections to the same 
host.
 */
+
 QSslConfiguration sslConfig = d-socket.sslConfiguration();
+#if QT_VERSION = 0x040800
 const bool isSslCompressionDisabled = 
sslConfig.testSslOption(QSsl::SslOptionDisableCompression);
 const bool shouldSslCompressBeDisabled = 
config()-readEntry(LastUsedSslDisableCompressionFlag, 
isSslCompressionDisabled);
 sslConfig.setSslOption(QSsl::SslOptionDisableCompression, 
shouldSslCompressBeDisabled);
-
+#endif
+
 const int lastSslVerson = config()-readEntry(LastUsedSslVersion, 
static_castint(KTcpSocket::SecureProtocols));
 KTcpSocket::SslVersion trySslVersion = 
static_castKTcpSocket::SslVersion(lastSslVerson);
 KTcpSocket::SslVersions alreadyTriedSslVersions = trySslVersion;
@@ -409,29 +412,37 @@ int TCPSlaveBase::connectToHost(const QString host, 
quint16 port, QString* erro
 if (d-autoSSL) {
 SslResult res = d-startTLSInternal(trySslVersion, sslConfig, 
3 /*30 secs timeout*/);
 if ((res  ResultFailed)  (res  ResultFailedEarly)) {
+#if QT_VERSION = 0x040800
 if 
(!sslConfig.testSslOption(QSsl::SslOptionDisableCompression)) {
 sslConfig.setSslOption(QSsl::SslOptionDisableCompression, 
true);
 continue;
 }
+#endif
 
 if (!(alreadyTriedSslVersions  KTcpSocket::SecureProtocols)) {
 trySslVersion = KTcpSocket::SecureProtocols;
 alreadyTriedSslVersions |= trySslVersion;
+#if QT_VERSION = 0x040800
 sslConfig.setSslOption(QSsl::SslOptionDisableCompression, 
false);
+#endif
 continue;
 }
 
 if (!(alreadyTriedSslVersions  KTcpSocket::TlsV1)) {
 trySslVersion = KTcpSocket::TlsV1;
 alreadyTriedSslVersions |= trySslVersion;
+#if QT_VERSION = 0x040800
 sslConfig.setSslOption(QSsl::SslOptionDisableCompression, 
false);
+#endif
 continue;
 }
 
 if (!(alreadyTriedSslVersions  KTcpSocket::SslV3)) {
 trySslVersion = KTcpSocket::SslV3;
 alreadyTriedSslVersions |= trySslVersion;
+#if QT_VERSION = 0x040800
 sslConfig.setSslOption(QSsl::SslOptionDisableCompression, 
false);
+#endif
 continue;
 }
 }
@@ -449,11 +460,12 @@ int TCPSlaveBase::connectToHost(const QString host, 
quint16 port, QString* erro
 
setMetaData(QLatin1String({internal~currenthost}LastUsedSslVersion),
 QString::number(trySslVersion));
 }
-
+#if QT_VERSION = 0x040800
 if (sslConfig.testSslOption(QSsl::SslOptionDisableCompression)  
!shouldSslCompressBeDisabled) {
 
setMetaData(QLatin1String({internal~currenthost}LastUsedSslDisableCompressionFlag),
 QString::number(true));
 }
+#endif
 return 0;
 }
 Q_ASSERT(false);
@@ -568,10 +580,10 @@ TCPSlaveBase::SslResult 
TCPSlaveBase::TcpSlaveBasePrivate::startTLSInternal (KTc
 //setMetaData(ssl_session_id, d-kssl-session()-toString());
 //### we don't support session reuse for now...
 usingSSL = true;
-
+#if QT_VERSION = 0x040800
 kDebug(7027)  Trying SSL handshake with protocol:  version
   , SSL compression ON:  
sslConfig.testSslOption(QSsl::SslOptionDisableCompression);
-
+#endif
 // Set the SSL version to use...
 socket.setAdvertisedSslVersion(version);
 
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team

Re: Why are 4.8.80 packages already out in the wild?

[Sebastian Kügler]

On Monday, June 04, 2012 01:26:01 Kevin Kofler wrote:
 On Monday 04 June 2012, Albert Astals Cid wrote:
  It's not about hurting or not (that it does, see how Martin got confused
  and  probably lost time wondering how something like that could be
  happening).
 
 Oh, and what Martin actually got confused by is a failure of processes on
 the  KDE end: The Bugzilla entry for the new (pre)release should be created
 no later than the first try of tarballs. How else are we, the packagers,
 supposed to report bugs we find in the tarballs, if they're not of release-
 blocking importance? When you create the tarballs, the component should
 already be in place.

That means that people report bugs against different incarnations of the same 
packages, which makes bugs hard to find -- it doesn't work as we can't verify 
the exact state of the code a bug is filed against.

We've handled package level problems via email in direct contact with 
packagers who encountered the issues, and that worked fine so far. I suggest 
we stick to it.
-- 
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: Calling off Beta1

[Sebastian Kügler]

On Tuesday, May 29, 2012 19:55:02 Albert Astals Cid wrote:
 the release dude does the releases.

Correction: 

The release *team* does the releases

Now that is clear, can we work as a team here, and discuss problems instead of 
making such decisions unilaterally?
-- 
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

#kde-release-team

[Sebastian Kügler]

Hey,

In order to improve communication among release team members, we've created 
#kde-release-team on Freenode's IRC network.

If you're involved, please join.

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: Calling off Beta1

[Sebastian Kügler]

On Tuesday, May 29, 2012 23:53:50 Albert Astals Cid wrote:
   I'm sorry for being naïve and expecting people would care about having a
   proper release. It won't happen again.
 
  Noe this It won't happen again doesn't mean I'm walking off from the
  create tarballs duty, it just means that instead of waiting for people
  to
  fix their stuff until the day before the release I'll cancel the release
  with more days of anticipation.
 
 And when i say I'll cancel the release I mean I will talk with the rest
 of  the team to cancel the release.

Heh, OK :)

By the way, even if this topic generated a lot of heat, please all keep in 
mind that we're in a transition period right now, where hitches along the way 
are to be expected. Do see them as hitches we are overcoming and problems we 
are solving instead of Armageddons. :-)

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