Re: do you need www.kde.org write access?
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?
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
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
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
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
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
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
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
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
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: More Plasma bug fix releases
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: oxygen-icons & plasma-workspace-wallpapers moved to git
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
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 : > > > 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
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
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: Missing branch for plasma-sdk
On Monday, June 22, 2015 13:01:52 David Faure wrote: > On Thursday 18 June 2015 17:48:01 Sebastian Kügler wrote: > > You can branch off of KDE/Active4 (or just use that one, if it suits you), > > that is the KDE4-based stable branch. Master is frameworks-based. > > Anything that is kde4 based suits "me" ;) > > But I don't see a KDE/Active4 branch in extragear/sdk/plasma-sdk... > > extragear/sdk/plasma-sdk (master) >git branch -a > * master > remotes/origin/Plasma/5.3 > remotes/origin/master > remotes/origin/plasmate/1.0 I confused it, sorry. The last KDElibs4-based branch is plasmate/1.0. -- 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: Missing branch for plasma-sdk
On Thursday, June 18, 2015 17:15:02 Bhushan Shah wrote: > On Thu, Jun 18, 2015 at 4:40 PM, David Faure wrote: > > This problem is still there. > > (I get spammed about it every day by the lxr cron job...) > > > > Can I create a branch then, for plasma-sdk's kde4 version? > > I'd say go ahead with this. > > > Shall I call it KDE/4.14 for consistency? > > I am not too sure about this, as this is not released with KDE > Applications 4.x release and may lead to confusion. Simple kde4 would > do IMO. You can branch off of KDE/Active4 (or just use that one, if it suits you), that is the KDE4-based stable branch. Master is frameworks-based. Thanks for the note. 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: KDE Frameworks·5.11.0: trashcan applet fails
On Tuesday, June 16, 2015 18:06:06 Bhushan Shah wrote:
> On Tue, Jun 16, 2015 at 8:33 AM, Rex Dieter wrote:
> > Yes, per the aforementioned bug reports, trying to place the trashcan
> > applet yields:
> >
> > Error loading Applet: package inexistent
>
> I debugged this little bit and found that trash applet have
> X-KDE-Library set in its metadata.desktop which is unused. I removed
> it now however I see that if condition added in
> 462ad8a6cae22bc2855c8e4461ca503d6fd15884,
>
> +if (!offer->property("X-Plasma-API").toString().isEmpty() &&
> +offer->property("Library").toString().isEmpty()) {
>
> is removed in ea924b14691da3819ca17d876f63ffc686fcf840 as I think
> there is no replacement for this in KPluginMetadata or something..
>
> If we want to make it backwards compatible this case should be handled
> somehow or otherwise any other desktop files which are ported to QML
> and have stray X-KDE-Library needs fixing.
There's not reason why this can't be done (in a similar way) with
KPluginMetaData, you can go through KPluginMetaData::rawData() to look up
these keys.
--
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
On Wednesday, June 17, 2015 21:39:47 Kevin Ottens wrote: > On Wednesday 17 June 2015 05:19:57 Sebastian Kügler wrote: > > 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. > > Seeing this argument being used by you, of all people, honestly makes me > nervous. > > I know I used the "respect the elders" phrase in a keynote at Akademy. > During the QA, I got pointed at the risk of it, which I agreed to... but > couldn't find a better wording. > > In any case, the idea was that it was a cultural thing that I believe > people keep in mind in their interactions and I just pointed it was there. > It is not meant as something someone could or should use as a different way > to say "now please shut up and disappear". > > Whatever I may think about the initial proposal, the counter-proposal or > the content of the discussion, I really don't like to see such a card > played. It's the best way to drown all of us in formaldehyde. On the other hand, we also consistently suck at decision-making when someone Seeing this thread, the ratio pro/con of it, and the previous one which also dragged on forever, I wonder how much more energy we're going to waste. Now Christian is a guy we can trust, but we have seen before that if there's not clear consensus in the sense of "100% of the stakeholders agree, not just 99%), we keep wasting our energy on these discussion. That's why I consciously pointed it out. I agree that it should be an exception, and not a way to shut someone up (that wasn't my intention anyway), but I wonder when enough of the people who really can judge this have given their opinion, and nothing new coming to the table, and it is indeed time to lay it to sleep and trust the people we know we can trust. I've seen so much energy wasted in KDE for a lack of clear decision-making process, and we have been through multiple iterations of trying to fix it (the Technical Working Group, for example), and we haven't found a better model. It's a hard problem, and we haven't solved it, maybe it's unsolvable, but it should be OK to ask someone to apply the "trust model", even in case of disagreement, especially when the opinions are so clearly telling us. How many more emails that all say essentially the same are we going to waste on this? It's not a productive thing, and hasn't been for a while (no new arguments coming to the table), and it's starting to get harmful. Let's not get too meta here, though. 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
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
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: KDE Frameworks·5.11.0: trashcan applet fails
On Monday, June 15, 2015 19:58:43 Rex Dieter wrote: > Anyone else seeing problems with trashcan applet loading? > > Seems installing plasma-framework-5.11.0 causes it (5.10.0 was fine). Did you get any error message? If so, which? -- 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
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: Future frameworks releases
On Tuesday, June 09, 2015 10:39:58 Christian Mollekopf wrote: > On Monday 08 June 2015 11:21:56 Benjamin Reed wrote: > > On 6/8/15 11:02 AM, Eric Hameleers wrote: > > > The only sane way forward is that every Frameworks release contains > > > all Frameworks tarballs, regardless of updates since the previous > > > public release. Every Framework should adhere to the overall version > > > number. > > > > Yeah, this proposal makes no sense to me. If you want to individually > > manage a library with an independent numbering scheme, then shouldn't it > > be a separate/external project? The whole point of the "framework" is > > to provide a monolithic thing that has everything you need. > > If that's the point of frameworks, being that monolithic thing, then indeed > you are right. But I really hope it isn't. It's not about being monolithic, it's about stable and reliable interfaces, version numbers and APIs are a big part of that, and that's why frameworks can't just be removed and added back from one release to another, and why version numbers need to be consistent across the whole set of frameworks. Introducing exceptions increases the complexity of dealing with frameworks, their value really is in shared processes and requirements. I am strongly against watering it down. If some library is better off with its own versioning scheme and release process, then it simply should not be part of our Frameworks releases, but something else (which is entirely possible, still). 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
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: KDE Frameworks·5.10.0
On Monday, May 04, 2015 14:14:12 David Faure wrote: > On Monday 04 May 2015 12:06:13 Sebastian Kügler wrote: > > I've noticed that tags for the latest releases seem to be missing in most > > frameworks. Is that a matter of pushing those, or do you need a list with > > repos that are missing tags? > > Neither. It's a matter of you fetching them > git fetch --tags > otherwise tags (which are not on a branch) aren't fetched. Ah, yes, that! 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: KDE Frameworks·5.10.0
On Sunday, May 03, 2015 19:07:10 David Faure wrote: > Here's KDE Frameworks 5.10.0. > > New frameworks: none this time. > > I suspect that knewstuff will need an update though, I found API issues in > the new classes there, and notified the author. But everything else should > be good, so we might as well get started. > > Public release on Friday. > > Thanks for the packaging work! I've noticed that tags for the latest releases seem to be missing in most frameworks. Is that a matter of pushing those, or do you need a list with repos that are missing tags? 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: This is not working [for me]
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..
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: CHANGELOG keyword
On Sunday, October 12, 2014 19:04:54 Michael Pyne wrote: > On Sun, October 12, 2014 00:30:43 Albert Astals Cid wrote: > > > once after CHANGELOG: > > I'm not against an empty CHANGELOG: meaning the tool has to use the title, > > but i'd still want to have the possibility to have a separate line, my > > titles are usually "more geeky" and I would not want them in a public > > consumption changelog so i'd have to craft something more user-friendly in > > the CHANGELOG: entry. > > > > > > > > What do others think? > > I think allowing CHANGELOG: to have a more descriptive title, while falling > back to the commit title if CHANGELOG: is left blank, makes perfect sense > and is a good idea. Was thinking the same. It feels silly having to repeat a perfectly crafted commit message/title, but that's not always very clear to end-users (which the changelog is really for). I like that fallback solution. 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.0
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: Plasma 5.1 beta tars
On Saturday, September 27, 2014 07:30:39 Martin Gräßlin wrote: > On Friday 26 September 2014 19:46:27 Albert Astals Cid wrote: > > El Divendres, 26 de setembre de 2014, a les 19:33:47, Martin Gräßlin va > > > On Friday 26 September 2014 19:26:20 Albert Astals Cid wrote: > > > I think there was a typo: KF5 5.3 will be released before the final > > > Plasma > > > 5.1, not 2. > > > > Still, at the moment, we have put out some tarballs that are uncompilable. > > > > What's the point? > > P.S: Sure i know I can compile them using some git version somewhere, but > > that's not how one is supposed to do releases. > > ok, I see the problem. As it was me who introduced the hard dependency on > new 5.3 API, let me say sorry for that. I was not aware that it will > create problems. Given that the release schedule was prepared in a way that > we can depend on KF5.3 I didn't expect that depending on 5.3 would create > packaging problems. I could easily revert the commits, but it would only > fix half of the problem as also code in plasma depends on plasma-framework > - even if it doesn't use new API. > > For the next release cycle we should be aware of that problem and ensure > that we do not depend on unreleased frameworks. We talked about this during today's meeting. We want to improve the timing so that this doesn't happen, possibly put both, beta and final onto the same Frameworks dependency. -- 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
On Friday, July 25, 2014 01:53:50 Aleix Pol wrote: > On Thu, Jul 24, 2014 at 10:39 PM, Albert Astals Cid 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!
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
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
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
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
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
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
Re: Plasma Next alpha release engineering bits
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
Plasma Next alpha release engineering bits
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
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
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 ur
Re: change of program icon
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
Re: change of program icon
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: Plasma Next Release Plans
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
Plasma Next Release Plans
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: KDE's opinion on SC 4.13 for Kubuntu 14.04
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: git organisation for frameworks
On Thursday, December 05, 2013 20:49:29 David Faure wrote: [...] > E.g. karchive will be in frameworks/karchive, in terms of projects.kde.org > organization. > > Any objections? > > Seems clear to me, but Ben wanted to make sure before we proceed I like that, would like to do the same kind of grouping for Plasma eventually. -- 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
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
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: Release Cycle
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: kde-workspace 4.10.90 ABI breakage in libtaskmanager
On Sunday, July 21, 2013 17:20:13 Aaron J. Seigo wrote: > On Sunday, July 21, 2013 15:50:52 Sebastian Kügler wrote: > > We have a release blocker here. If nobody steps up to look into this, I'll > > use git log / git blame and a long pointy stick. > > What we have is a change in policy. To recap: > > * the libraries in kde-workspace have no ABI or API commitments. none. > * the libraries in kde-workspace have changed ABI and API multiple times in > the past, and this has not always (ever?) been accompanied by changes of > the .so version > * modules outside of kde-workspace should NOT be using these libraries, but > though several do, in particular libkworkspace [1] > > there are a number of things that could be done to improve this situation: > > * not installing headers; unfortunately there are users of these libraries > and they will likely complain if we stop installing headers. still, this > may be wise to do > * bumping .so versions on every single API/ABI incompatible release (which > has been numerous in the 4.x series); given the lack of ABI/API > committment, this seems a little academic in nature > > personally i’d vote for not installing headers and let builds break. > > i’m fine with bumping the .so number of the library as well, though i don’t > consider that a compelling solution to the real problem of using libraries > outside of kde-workspace that are specifically not intended to be used > outside of kde-workspace. > > [1] there is one weak exception to this: kdeplasma-addons which is for all > intents and purposes a kde-workspaces sub-module I suppose we had installed the header already in previous releases? In that case, it's probably wiser (given that we're at RC stage) to just bump the .so version and revisit this situation for Plasma2? -- 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-workspace 4.10.90 ABI breakage in libtaskmanager
Hey Plasmoids, We have a release blocker here. If nobody steps up to look into this, I'll use git log / git blame and a long pointy stick. :-) On Thursday, June 27, 2013 19:44:07 Albert Astals Cid wrote: > El Dijous, 27 de juny de 2013, a les 15:52:13, Philip Muskovac va escriure: > > Hi, > > > > b7e30e489f21e09f31e04dab6e8f130764e63671 from Aaron > > > > #MISSING: 4:4.10.90# > > > > _ZN11TaskManager4Task12addTransientEmRK10NETWinInfo@ABI_4_3 4:4.8.3 -> > > TaskManager::Task::addTransient(unsigned long, NETWinInfo const&) > > > > > > and 42c8fde45cfde9cb594d7468c5a91b372cca3664 from Gregor Tätzner > > > > #MISSING: 4:4.10.90# > > > > _ZN11TaskManager9BasicMenuC1EP7QWidgetPNS_8TaskItemEPNS_12GroupManagerE5QL > > i > > stIP7QActionESA_@ABI_4_3 4:4.8.3 -> > > TaskManager::BasicMenu::BasicMenu(QWidget*, TaskManager::TaskItem*, > > TaskManager::GroupManager*, QList, QList) > > > > #MISSING: 4:4.10.90# > > > > _ZN11TaskManager9BasicMenuC1EP7QWidgetPNS_9TaskGroupEPNS_12GroupManagerE5Q > > L > > istIP7QActionESA_@ABI_4_3 4:4.8.3 -> > > TaskManager::BasicMenu::BasicMenu(QWidget*, TaskManager::TaskGroup*, > > TaskManager::GroupManager*, QList, QList) > > > > break the ABI of libtaskmanager.so.4 in 4.10.90. > > > > Could we please get those back as KDE_DEPRECATED or instead get the > > SOVERSION bumped? Thanks! > > Since this a ABI break in a private library outside kdelibs and kdepimlibs > i'm going ahead with the beta2 release. Whatever needs to be fixed can be > done for RC1. > > Cheers, > Albert -- 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-workspace 4.10.90 ABI breakage in libtaskmanager
Hey Plasmoids, We have a release blocker here. If nobody steps up to look into this, I'll use git log / git blame and a long pointy stick. :-) On Thursday, June 27, 2013 19:44:07 Albert Astals Cid wrote: > El Dijous, 27 de juny de 2013, a les 15:52:13, Philip Muskovac va escriure: > > Hi, > > > > b7e30e489f21e09f31e04dab6e8f130764e63671 from Aaron > > > > #MISSING: 4:4.10.90# > > > > _ZN11TaskManager4Task12addTransientEmRK10NETWinInfo@ABI_4_3 4:4.8.3 -> > > TaskManager::Task::addTransient(unsigned long, NETWinInfo const&) > > > > > > and 42c8fde45cfde9cb594d7468c5a91b372cca3664 from Gregor Tätzner > > > > #MISSING: 4:4.10.90# > > > > _ZN11TaskManager9BasicMenuC1EP7QWidgetPNS_8TaskItemEPNS_12GroupManagerE5QL > > i > > stIP7QActionESA_@ABI_4_3 4:4.8.3 -> > > TaskManager::BasicMenu::BasicMenu(QWidget*, TaskManager::TaskItem*, > > TaskManager::GroupManager*, QList, QList) > > > > #MISSING: 4:4.10.90# > > > > _ZN11TaskManager9BasicMenuC1EP7QWidgetPNS_9TaskGroupEPNS_12GroupManagerE5Q > > L > > istIP7QActionESA_@ABI_4_3 4:4.8.3 -> > > TaskManager::BasicMenu::BasicMenu(QWidget*, TaskManager::TaskGroup*, > > TaskManager::GroupManager*, QList, QList) > > > > break the ABI of libtaskmanager.so.4 in 4.10.90. > > > > Could we please get those back as KDE_DEPRECATED or instead get the > > SOVERSION bumped? Thanks! > > Since this a ABI break in a private library outside kdelibs and kdepimlibs > i'm going ahead with the beta2 release. Whatever needs to be fixed can be > done for RC1. > > Cheers, > Albert -- 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?
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
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: Disable by default KRandR in 4.11
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: Release Strategy Proposal
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: > >> > > >> > 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. > >> > > >> > >> 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
Re: Release Strategy Proposal
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
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: Release Strategy Proposal
Hi Alex, On Friday, April 26, 2013 18:35:41 Alexander Neundorf wrote: > On Friday 26 April 2013, Sebastian Kügler wrote: > > > > 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. > > > > 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
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
On Friday, April 26, 2013 15:37:09 Frank Reininghaus wrote: > 2013/4/26 Sebastian Kügler: > > > > 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. > > > 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
Release Strategy Proposal
Hi, 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. 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: stepping back from release duties
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
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
www/sites/www
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 @@ Latest Announcements -KDE Ships Third Release Candidate of Plasma Workspaces, Applications and Platform 4.10 -On 18th January 2013, KDE has released the third release candidate of the 4.10 Workspaces, Applications and Development Platform. +KDE Announces Plasma Workspaces, Applications and Platform 4.10 +February 6, 2013. KDE is delighted to announce its latest set of releases, providing major updates to +KDE Plasma Workspaces, KDE Applications, and the KDE Platform. +Version 4.10.0 provides many new features, along with improved stability and performance. Find out more about 4.10's improvements in our visual feature guide. -KDE Ships Second Release Candidate of Plasma Workspaces, Applications and Platform 4.10 -On 4th January 2013, KDE has released the second release candidate of the 4.10 Workspaces, Applications and Development Platform. - - KDE Ships January Updates to Plasma Workspaces, Applications and Platform 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. -KDE Announces Plasma Workspaces, Applications and Platform 4.9 -August 1, 2012. KDE is delighted to announce its latest set of releases, providing major updates to -KDE Plasma Workspaces, KDE Applications, and the KDE Platform. -Version 4.9.0 provides many new features, along with improved stability and performance. - - View more announcements... --- trunk/www/sites/www/info/releases.php #1337828:1337829 @@ -8,16 +8,18 @@ Current KDE SC Releases -KDE SC 4.9.5 (stable version) +KDE SC 4.10.0 (stable version) + Previous KDE Releases +KDE 4.9.5 KDE 4.9.4 KDE 4.9.3 KDE 4.9.2 ___ 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
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
4.10 announcement ready for translation
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] Nepomuk - Changing the Resource class behaviour
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: Nepomuk - Changing the Resource class behaviour
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 - Changing the Resource class behaviour
On Tuesday, January 22, 2013 14:10:05 Christian Mollekopf wrote: > The sooner the better, but something for the release-team to answer. I > don't think it's that much of a problem that we absolutely have to get it > into 4.10.0, is it? My take: Put it into master now, put it into KDE/4.10 once 4.10.0 is out so it gets some exposure and ends up in 4.10.1. 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 SC 4.11 Release Schedule
On Thursday, January 17, 2013 00:15:13 Albert Astals Cid wrote: > El Dimecres, 16 de gener de 2013, a les 14:22:23, Sebastian Kügler va > > 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. > > Let's do it right then :-) > > Putting down a "good idea" because we are "doing it wrong", doesn't seem > like the way to improve ;-) Sure. What could also help to bring down the necessity of the release process is daily snapshots, such as the Neon images or the KDE4 Daily openSUSE live cd that were there for a while, but that does involve someone doing this, and it can be a high-maintainance thing. > And yes, we need the quality team to read the emails that say we are going > to do a release. Not sure what more they need from us, if they know it'd be > good to know. Well, whatever leads to a working process. :) This takes a bit of time, and I think the previous release worked better than this one, but we still need to improve this process. > > > 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? > > Let's put it the other way around, why we have 5/6 days for betas and x.y.z > releases? Why should RC be special? > > > It's not one day, > > It is one day > > July 22: KDE 4.11 Tagging Freeze for Release Candidate 2 > July 23: KDE 4.11 Release Candidate 2 Tagging > > > 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. > > Right, i agree the more "old" the packages are the worse they are for > testing, but on the other hand we have those 5/6 days gaps for betas and > for x.y.z > > One could say that oldness for x.y.z is less critical and we want to give > packagers time to get binary packages out, fair enough, but shouldn't beta > and rc follow the same way? I think so, yes. > Also if we are concerned about "old"-ness in the testing phase, we could > introduce weekly unofficial releases, just run the script, put on the ftp > and let distros package them if they want, no announcement, no extra check > everything compiles, etc. Sounds like a good idea. > If Torgny gets the automatic packaging up in jenkins that'd be even easier > to do :-) 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 SC 4.11 Release Schedule
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
Re: Fwd: www/sites/www
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
KDE Ships Second Release Candidate of Plasma Workspaces, Applications and Platform 4.10
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: Another RC?, was: Re: Akonadi-Nepomuk Feeder Improvements
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
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
Hi Vishesh, On Saturday, December 22, 2012 15:26:10 Vishesh Handa wrote: > On Sat, Dec 22, 2012 at 3:07 PM, Frank Reininghaus > 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
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
Re: 4.9.5?
On Thursday, December 06, 2012 16:22:23 Torgny Nyblom wrote: > As said I can do the packaging but as for the public announcement my > language skills are sadly not up to par so we need someone that can take > that part if we descide to make a 4.9.5. I can do the announcement. -- 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
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 @@ + +5th December 2012 - KDE Ships December Updates to Plasma Workspaces, Applications and Platform + +"KDE Ships 4.9.4 Workspaces, Applications and Platform." + + 4th December 2012 - KDE Announces 4.10 Beta 2 --- trunk/www/sites/www/index.php #1327413:1327414 @@ -42,16 +42,16 @@ Latest Announcements +KDE Ships December Updates to Plasma Workspaces, Applications and Platform +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. + + KDE Ships Second Beta of Plasma Workspaces, Applications and Platform 4.10 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. -KDE Ships November Updates to Plasma Workspaces, Applications and Platform -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. - - Plasma Active 3 Improves Performance, Brings New Apps 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. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
www/sites/www
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 @@ Latest Announcements -KDE Ships First Beta of Plasma Workspaces, Applications and Platform 4.10 -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. +KDE Ships Second Beta of Plasma Workspaces, Applications and Platform 4.10 +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. KDE Ships November Updates to Plasma Workspaces, Applications and Platform --- trunk/www/sites/www/info/releases.php #1327264:1327265 @@ -12,7 +12,7 @@ -KDE SC 4.10 Beta 1 (unstable version, only for testing) +KDE SC 4.10 Beta 2 (unstable version, only for testing) Previous KDE Releases ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdegraphicslibs (Was: libkdcraw api compatibility?)
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: kdegraphicslibs (Was: libkdcraw api compatibility?)
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
www/sites/www
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 @@ -Plasma Desktop with Dolphin and Gwenview +Plasma Desktop with Dolphin @@ -21,7 +21,7 @@ -Qt Quick in Plasma Workspaces -- 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. +Qt Quick in Plasma Workspaces -- 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. New Screen Locker -- A new screen locking mechanism based on QtQuick brings more flexibility and security to Plasma Desktop. @@ -30,10 +30,10 @@ Animated Wallpapers -- Thanks to a new QtQuick-based wallpaper engine, animated wallpapers are now much easier to create. -Improved Zooming in Okular -- 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. +Improved Zooming in Okular -- 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. -Faster indexing -- 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. +Faster indexing -- 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. Color Correction -- 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 @@ KJumpingCube has seen a large number of improvements making the game more enjoyable. -More improvements can be found in the http://techbase.kde.org/Schedules/KDE4/4.10_Feature_Plan";>4.10 Feature Plan. 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 http://techbase.kde.org/Schedules/KDE4/4.10_Feature_Plan";>4.10 Feature Plan. 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 http://bugs.kde.org";>bugs.kde.org. --- trunk/www/sites/www/index.php #1325822:1325823 @@ -42,6 +42,10 @@ Latest Announcements +KDE Ships First Beta of Plasma Workspaces, Applications and Platform 4.10 +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. + + KDE Ships November Updates to Plasma Workspaces, Applications and Platform 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 --- trunk/www/sites/www/info/releases.php #1325822:1325823 @@ -11,9 +11,9 @@ KDE SC 4.9.3 (stable version) - + +KDE SC 4.10 Beta 1 (unstable version, only for testing) + Previous KDE Releases
Re: Binary packages section of info/release.php pages
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
www/sites/www
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 @@ --- trunk/www/sites/www/announcements/index.php #1324280:1324281 @@ -10,13 +10,19 @@ + +6th November 2012 - KDE Ships November Updates to Plasma Workspaces, Applications and Platform + +"KDE Ships 4.9.3 Workspaces, Applications and Platform." + + 15th October 2012 - Plasma Active 3 Improves Performance, Brings New Apps "KDE Releases Third Version of Cross-Device UX." - + 2nd October 2012 - KDE Ships October Updates to Plasma Workspaces, Applications and Platform "KDE Ships 4.9.2 Workspaces, Applications and Platform." --- trunk/www/sites/www/download/index.php #1324280:1324281 @@ -86,7 +86,7 @@ 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 -4.9.2 Info Page for details. +4.9.3 Info Page for details. KDE 3 series --- trunk/www/sites/www/index.php #1324280:1324281 @@ -42,6 +42,12 @@ Latest Announcements +KDE Ships November Updates to Plasma Workspaces, Applications and Platform +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. + + Plasma Active 3 Improves Performance, Brings New Apps 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. --- trunk/www/sites/www/info/releases.php #1324280:1324281 @@ -8,7 +8,7 @@ Current KDE SC Releases -KDE SC 4.9.2 (stable version) +KDE SC 4.9.3 (stable version)
Re: Request for adding new plugin for Dolphin
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
Re: polkit-kde-kcmmodules editing /usr
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
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
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 @@ +2nd October 2012 - KDE Ships October Updates to Plasma Workspaces, Applications and Platform + +"KDE Ships 4.9.2 Workspaces, Applications and Platform." + + + 4th September 2012 - KDE Ships September Updates to Plasma Workspaces, Applications and Platform "KDE Ships 4.9.1 Workspaces, Applications and Platform." --- 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. --- 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. --- 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, максимально интегрируясь в их среды. --- trunk/www/sites/www/contact/about_kde_uk.inc #1318784:1318785 @@ -9,7 +9,7 @@ Про KDE -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. --- trunk/www/sites/www/index.php #1318784:1318785 @@ -42,8 +42,8 @@ Latest Announcements -KDE Ships September Updates to Plasma Workspaces, Applications and Platform (KDE SC 4.9.1) -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. +KDE Ships October Updates to Plasma Workspaces, Applications and Platform (KDE SC 4.9.2) +On 2nd October 2012, KDE has released updates to their workspaces, applications and development platform. Significant bugfixes include improvements to the Kontact Suite, bugfixes in Dolphin, Plasma and many more corrections and performance improvements all over the place. KDE Announces Plasma Workspaces, Applications and Platform 4.9 --- trunk/www/sites/www/info/releases.php #1318784:1318785 @@ -8,7 +8,7 @@ Current KDE S
Re: 4.9.2 announcement?
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
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
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
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
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: Release Script (KF5)
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: Release Script (KF5)
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
