Re: Source Signing
I'ld also like to add that currently some developers have access to do releases directly - I've also seen those people putting the files on the ftp-server for other projects then the original intention had been. I would like to propose that *all* releases should follow the below proposal, effectively that would involve that the direct access would be cancelled for those currently having access to the ftp-server directly. This means an improved paper trail for those releases too and further reduces the effect of compromised accounts and / or tarballs. Best, Tom Albers KDE Sysadmin - Op 19 sep 2019 om 13:46 schreef Ben Cooksley : > On Thu, Sep 19, 2019 at 1:24 PM Harald Sitter wrote: > > At akademy we had a poorly attended bof about release artifact > > signing. Jonathan raised the concern that while we generally sign our > > stuff we do not actually verify the signatures properly so coverage > > and reliability is dodgy at best. > > This largely factors into what Friedrich raised a while ago in > > https://phabricator.kde.org/T11304. > > (The stuff below only partially affects kf5,apps,plasma as their > > release processes are slightly different...) > > To get a source tarball released any one person can create a tarball, > > upload it to the relevant server and file a syadmin ticket. > > It is then upon the sysadmins to decide on a case by case basis if a > > given person should be allowed to even make a release of our software. > > This is hugely informal. > It is correct that there is no formally defined list of people who are > allowed to make releases of a given package. > For the most part, the checking process is reliant upon our knowledge > of who is involved with what project. > > What's more as far as we are aware the sysadmins currently do not > > verify or require signatures, so if an identity account of a developer > > was compromised malicious releases could be uploaded and published. > It is correct that we do not validate the GPG signatures submitted to us. > > And following the delivery pipeline, the distributions then again have > > to employ informal checks to verify the signatures, if they verify > > them at all. > > To deal with these problems we, Albert, Jonathan and I, concluded that > > it would be a good idea to formalize this process. The sysadmins > > should keep a keyring of public "release keys", and before making > > their first (source) release developers need to request release > > permission. That is to say they need to pop their gpg key somewhere > > (e.g. gitlab) and sysadmins then need to "vet" this person before > > picking the gpg key into their keyring. > > When someone uploads a source tarball we can then require it to have > > an associated signature. Sysadmins can gpg-verify the signature and by > > extension the uploaded artifact. Because of the keyring this could be > > fully automated and replace the current (presumably manual) shasum > > checks and hopefully make sysadmin's life easier. > While the process is manual in so far as a Sysadmin has to look at it, > the process has by-and-large been automated. > When someone submits a file for release, we run each hash/filename > pair through a script, which takes three parameters: > 1) The destination of the file > 2) The hash of the file > 3) The name of the file to be released. > The script then validates the hash, and if all is well prompts if it > is okay to proceed with moving the file to it's final destination. > This provides a reasonable degree of assurance that the file released > is the one that the person originally uploaded, but you are correct > that it does not defend against attacks where someone's Identity > account has been compromised. > > On the distribution side the keyring can be used to reduce the amount > > of trust-on-first-use that has to be put into a new key as the > > sysadmin's release keyring would only contain vetted keys, > > demonstrating some minimal trust already. > > An unfortunate side effect is that the release process gets yet > > another step: getting your gpg key verified by sysadmins. A one-time > > step, but a step nonetheless. > > Currently our stance is that none of this would apply to non-source > > releases because there may be conflicting signature systems already in > > place. Notable example is windows where .exes have their own signing > > system already, so requiring gpg on top of that is probably useless. > > TLDR: no source releases without gpg signature, sysadmins maintain > > public keyring of developers who are allowed to release and use it to > > verify uploads, distros ca
Re: Request to access early KDE packages for OpenBSD porting team
He/you can file a ticket at sysadmin.kde.org, if there are any existing openBSD packagers on the list, we need their names mentioned in the ticket. Tom Albers KDE Sysadmin - Oorspronkelijk bericht - Hi sysadmins is it you who handle such requests or what is the procedure? /Regards Torgny On Saturday 04 May 2013 13.16.09 Vadim Zhukov wrote: Hello. I'm Vadim Zhukov, and last 3 years I'm working on porting KDE4 to OpenBSD. I have successfully offered quite a few releases as of today in WIP (work-in-progress) semi-official ports repository. And now KDE4 is imported in x11/kde4 official ports tree: http://www.openbsd.org/cgi-bin/cvsweb/ports/x11/kde4/ . While it's not enabled by default (due to some conflicts with KDE3, which would stay for a while), it's already usable and I have some successful reports. I want to offer KDE4 releases to OpenBSD users as fast as possible, and thus request access to closed packager's place. I didn't find whom I should contact, so asking here. If I'm wrong, please, direct me in the right way. I'm registered as zhukov on identity.kde.org. Thank you for reading this. -- WBR, Vadim Zhukov ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Review Request 109505: Use -J when tar-ing the files
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109505/#review29286 --- Ship it! - Tom Albers On March 15, 2013, 6 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/109505/ --- (Updated March 15, 2013, 6 p.m.) Review request for Release Team and Tom Albers. Description --- I was just told that it's quite common to ship packages in this format, so maybe it's interesting that such script uses it. It's more compressed, in the end. Diffs - createtarball/create_tarball.rb 6f77acd Diff: http://git.reviewboard.kde.org/r/109505/diff/ Testing --- I made a kde-gtk-config package and it seemed to work. Thanks, Aleix Pol Gonzalez ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: 4.9 SC RC1 tarballs are up
- Oorspronkelijk bericht - Anyone knoss why we decided to have only one day of turnaround for RC's between tagging and announcing? Yes. The idea is that the RC's should be ok to release. We have had all the beta's and all freezes are in place. This should make sure the tarballs are in a releasable state at any time. So, it's not so much about the functionality of the software (though grave bugs are always important of course), but more the technical aspect of packaging the tarballs that is tested, make sure that it compiles on all targets with all of the current versions of all the dependencies. btw, it's not that it has to be one day, the idea is more that it is released as soon as the basic checks are done. That can take one day, or 3 days, it is up to the release manager to decide. Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] smokekde build failures in beta2 tarballs:
- Oorspronkelijk bericht - The version number seems to suggest otherwise, but 2.7.57 is more recent than 2.7.6. I'm slightly confused by this remark. Would anyone have the same idea when we release KDE 4.10 after KDE 4.9 ? Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: tarball generation question
- Oorspronkelijk bericht - Hi, I was asked by the folks that maintain the VCS source imports for Ubuntu how exactly you are generating the xz tarballs. Currently their scripts fail to reproduce the tarballs once the source is imported (they told me it failed for analita 4.8.2 at least [1]) So could you please tell me what application, version and parameters you are using to generate the tarballs? Philip Muskovac [1] http://package- import.ubuntu.com/status/analitza.html#2012-04-04%2002:06:33.804866 Hi, You can read about this issue in the archives, read the full thread: http://www.mail-archive.com/release-team%40kde.org/msg05497.html Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Why are 4.8.80 packages already out in the wild?
- Oorspronkelijk bericht - Well...In Arch I released the packages some hour before Tom's thread about calling off beta1. Please try not to confuse me with Albert. Best, Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Calling off Beta1
Hi, For those distro's that already uploaded packages to their repo's, I suggest that you add a patch that removes the 'beta 1' designation and just continue to upload it as a trunk snapshot if you can not stop it anymore. I assume you have only uploaded it to an unstable part of the repo. If bugreports come it, developers can still look at them, it's just that we won't announce beta 1. Tagging of beta 2 is planned for next week, so it's not the end of the world. The work you did for beta 1 can probably be applied for beta 2, so the argument that there has been a great investment in time does hold and will benifit you for beta 2. Tom Albers KDE ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Replacement of download.kde.org.
- Oorspronkelijk bericht - Today/this weekend is a fine time :) Thanks Allen, I've now replaced download.kde.org with the new setup. It might take a bit for the ip-number change to propagate though. Let us know if there are any problems. Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Replacement of download.kde.org.
Dear release-team, The sysadmin team is slowly planning to replace download.kde.org with a new version. We are currently testing its replacement. The summary is that nothing will change, but the question is when is a suitable time in the release planning to execute this switch? For those interested in the juicy details, read on... Current situation - You are creating a page like: http://www.kde.org/announcements/announce-4.8.1.php - That holds a link to http://download.kde.org/download.php?url=stable/4.8.1/ (step 1) - This is a list of mirrors (step 2), - When clicked on a mirror, you get to the specified folder (step 3). A couple of problems: it's not user friendly, why should a user select a mirror? The detection of the nearest mirror is ... sub-optimal and it does not take into account if that mirror in reality has the files needed. New situation. - You are creating a page like: http://www.kde.org/announcements/announce-4.8.1.php - That holds a link to http://download.kde.org/download.php?url=stable/4.8.1/ (step 1) - When clicked on a mirror, you get to the specified folder (step 2). So, one step less. When clicked on a certain file in the listing from step 2, it will automatically select the best mirror (geographically closest, currently up and serving the file) and fetches it from that mirror. Another page you are creating currently is: http://www.kde.org/info/4.8.1.php On that page are links to: http://download.kde.org/stable/4.8.1/src/analitza-4.8.1.tar.xz In the current situation, after a click you get to see the mirror selection page. In the new setup, this step is skipped and you will immediately download that file from the correct mirror. Additionally, you could decide to start appending '.mirrorlist' to the urls, for example: http://download.kde.org/stable/4.8.1/src/analitza-4.8.1.tar.xz.mirrorlist This will lead to a page (after we switch) you can see here: http://mirrorbrain-test.kde.org/stable/4.8.1/src/analitza-4.8.1.tar.xz.mirrorlist The advantage would be that this page provides metalinks and hashes. Metalinks are becoming more popular and allowes users to simultaneously download from multiple mirrors, verify hashes of the parts downloaded for those fragments, and we can also provide torrent links and stuff like that. In summary: we hope to provide a drop in replacement for download.kde.org, which is way smarter with the displayed mirrors, increased user friendliness and increased functionality. What we need from you guys is a Saturday or Sunday in the next month or so when we are allowed to switch download.kde.org over to the new system. Best, Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Increased size of ftp.kde.org
Hi, After consulting this list earlier about our ever growing size of ftp.kde.org, sysadmin has now increased the size from 40GB to 100GB. No changes to the tree structure has been made. It is just an increase in size. I've updated http://www.kde.org/mirrors/ftp_howto.php to reflect this change. This will give us some room to grow, to keep older versions of KDE releases available and have room to better support the big Windows binaries of our releases. If there are any objections or concerns, let us know. Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
No more release schedules.
Hi, Since it seems some modules are going to have their own numbers and some modules will have a different (git) workflow, which will inevitably result in different release schedules, I propose we stop producing the central release schedule as we have now. So http://techbase.kde.org/Schedules/KDE4/4.7_Release_Schedule is the last one we provide. From here on, I think it would be best if the module maintainer or the particular git maintainer sets up a release schedule for their own module / repo. He can use the sofware in playground/utils/releaseschedule for their convenience. Of course this list can be used to coordinate a combined release between modules and what not. Even if this plan is vetoed away, I personally will not make a new schedule, as I have no idea how to do that in the new setup and I've little interest in studying the new setup. Best, -- Tom Albers KDE ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: No more release schedules.
- Original Message - So what do you suggest? Having a central release at a certain date but let the modules decide when to the freezes? Yes. Do beta version count as releases and are done centrally by the release team Yes. or are they in the responsibility of the module maintainer? They are in the end. We are just the 'tool' for packaging, releasing and announcing.. Let's just look at the leas invasive option: module maintainers decide when to freeze; releases happen centralized. This sounds OK so far because e.g. kdegames might need less stabilization time than kdelibs. Exactly. However, even this least invasive change brings problems for coordinating translations. If every module has its own string freeze and its own doc string freeze, it becomes way harder to keep track of where it makes sense to work and where still can be major changes. I don't see in which scenario this won't happen. We just need to have proper communication. From my point of view having a combined release schedule is a good thing and should be kept in place. Combined release dates are fine indeed. Don't know how to do a combined release schedule... I think this everyone does whet he wants atmosphere comes from individual merchendising of individual teams. The whole Plasma/Platform/Active thingy is hardly understood by the majority of the KDE contributors and it just seems to them that there is a bunch of people going mobile and taking KDE with them regardles of what the other, more boring modules want. Those that do the work decide. If the Platforms want to do have a different git workflow with different branches, i bet there is a need for different freezes. I think it's good to facilitate that, before they will do it themselves. Best. -- Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: No more release schedules.
Hi, The release-team mailinglist is for release coordination, reaching consensus and then announce the outcome on the appropiate lists. I think I started a valid discussion, which can be discussed maturely inside the release-team, it was not meant to be passed to a wider audience. You have now included kde-devel and kde-packager which was not intended. If the outcome is that it was a bad suggestion that's fine, it won't happen. But you approaching those lists is very premature and harms this discussion very much. - Original Message - would appreciate it if you all there upstream would just stick to KDE, because that is what everyone uses. Nothing else. Not on-topic for this list at all, nor relevant for this thread... Basically this is nothing but a dissolution of the KDE project as a whole. Really, read my mails carefully. My plan is to facilitate a trend that is going on for a bit now, which i see accelerated by the platform 10 outcome. Sure, we'll end up with a lot of projects using and enhancing kdelibs (or whatever becomes of that), but there will be no coherence anymore. That's a very limited view. I think it's fine that modules have different scopes at different points in time, with different freeze and work flow requirements. Ignoring that would do KDE harm. That both makes no sense. Suggestion 1 fails completely with the if they like part, since we all know already how much pain the out of sync kdepim caused. Yes, so facilitate this mechanism better. Now we let Allen do the pim releases basically on his own. He had to do all the hard work of tarballing, dealing with translations etc. Why don't we setup the r-t as a team which can facilitate the release whenever the module maintainer deams it needed. Of course based on a proper schedule. Suggestion 2 fails with the independent of the schedules part, because you can't release somthing that is not stabilized and tested. Did I write anywhere that we would tarball some random branch at some random time? That's not the plan. Let the module maintainer set their own freezes, make their own schedule. Best, -- Tom Albers KDE ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: No more release schedules.
- Original Message - My main concern with disparate releases would be that it would be impossible to test all the possible combinations properly. Every distribution would end up with its own combination of versions, with the potential for incompatibilities nobody else can reproduce. A whole distro is about making software work together. But see further down... Having KDE's own packages also released in an uncoordinated fashion Wow. Who suggested that? That would make a mess indeed. I certainly did not ever suggest that. If you think so, pleas reread all my mails. I've suggested that every module maintainer sets his own release schedule. It's not uncoordinated at all. It's just that the freeze for kdelibs can happen on a different time and that the version number at the end can be whatever they like. Another issue is that it would really swamp most distribution's KDE software packaging teams to have to package a new release of package XYZ every day. That's not what I suggested. I hope people can now stop twisting my words and reading things that are not there. Then let the module maintainer decide what is stable for a point release and what not, but not proclaim a major release at a random point in time. But that's just another suggestion thrown into the mix.) Isn't that what I suggest? Best, -- Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KNotify patch exception
- Original Message - Hi KDE Release team! I'd like to ask for an exception for a small patch adding a nice (and important) feature into KNotify. Let me explain - currently you can set only one icon for all your notification events. But if you have events like error and info, one icon is just not enough. So this patch allows you to set an icon per defined event. For example, in KDE-Telepathy, we aim for deep system integration and this patch is really important for us, so we can use different icons per event as we have several different events, info, error and warning. With the desktop integration in mind, it makes perfect sense to not use any generic Telepathy icon, but rather a special icon for all the events. And I'd like to get this patch in for KDE 4.7, because otherwise we could start using this as soon as January, which is a bit unfortunate. The patch itself is backwards compatible, so totally nothing would be broken and everyone would only gain. It was reviewed and approved (see [0]). So, I'm kindly asking you for an exception to let this patch in for 4.7. Would that please be possible? No objection from me. Toma -- Tom Albers KDE Release Team ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
playground/utils/releaseschedule
SVN commit 1235143 by toma: Dependency freeze 2 weeks before first beta. CCMAIL: release-team@kde.org M +1 -1 mainclass.cpp --- trunk/playground/utils/releaseschedule/mainclass.cpp #1235142:1235143 @@ -260,7 +260,7 @@ makePair( sffreeze ) ); timeline.insert( timelinePoint.addDays( ui-hardFeatureFreeze-value() * -7 ), makePair( hffreeze ) ); -timeline.insert( timelinePoint.addDays( ui-dependencyFreeze-value() * -7 ), +timeline.insert( timelinePoint.addDays( ui-dependencyFreeze-value() * -14 ), makePair( depfreeze ) ); timeline.insert( timelinePoint.addDays( ui-sofApiFreeze-value() * -7 ), makePair( safreeze ) ); ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Need longer freeze time before tagging
- Original Message - Stephen Kelly wrote: How much time are you suggesting? What would you think of two weeks? Or three? Revising this idea again, can we make hard dependency freeze happen at the same time as soft feature freeze? Currently it happens at the same time as hard feature freeze. http://techbase.kde.org/Schedules/KDE4/4.7_Release_Schedule The rationale is that you should only list features you want to rely on in a dependency if the dependency is already released. Additionally, that happens a month before tagging, which is more realistic for dealing with breakage given summer and skiing holidays around our typical release seasons. How about that? Lets first try with 2 weeks before beta1. It should give enough time to revert, block, solve issues. If it's not enough we can move it up earlier. Let's not take to big of a step. -- Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Need longer freeze time before tagging
- Original Message - Albert Astals Cid wrote: A Thursday, June 02, 2011, Stephen Kelly va escriure: Hi, The ongoing mess regarding the shared desktop ontologies shows that the time between hard feature freeze and tagging is not long enough. Making destructive or potentially destructive changes on the day of freeze (and one week before tagging) is a very bad idea. If it happens anyway, then hopefully schedule changes can soften the blow in the future. I propose a smaller 'merge window' in release branches and a bigger time between hard freeze and the start of the tagging cycle. Clearly one week is not enough to fix messes. That will give everyone more time (before tagging) to fix messes introduced on the day of freeze in the future. Thoughts? Of which time are you speaking about exactly, the one between Dependency Freeze and Beta 1 Tagging? Sort of I guess. If a feature or dependency bump which creates a mess is committed on the day of feature freeze I don't think there is enough time to fix it and at the same time stay relaxed because there is only a week. In the 4.7 schedule it was between 12th May and 19th May. I was away travelling for part of that week. How much time are you suggesting? What would you think of two weeks? Or three? Again, is this about the feature freeze or dependency freeze? Best, -- Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Need longer freeze time before tagging
- Original Message - Tom Albers wrote: Again, is this about the feature freeze or dependency freeze? Best, Both I think. In the SDO case, there was a dependency bump and a port to the features of the more recent release in kdepim, which resulted in effective source incompatibility being introduced. Right, so if we move dependency freeze one week earlier, it would be solved... +1 to that Best, -- Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDEPIM 4.6RC2 Tarballs (try #1)
That wont be ktown, but ftpmaster.kde.org. Best, Tom Albers Op 29 mei 2011 om 01:53 heeft Allen Winter win...@kde.org het volgende geschreven: Howdy, KDEPIM 4.6 RC2 is now released. Soon you will find tarballs on ktown in ftp://ktown.kde.org/pub/kde/unstable/kdepim/4.5.97 sha1sums 4f2248666c4bdbf081c40616835f7154bd604135 kdepim-4.5.97.tar.bz2 daa5aa06e493b051e8369a77508ec348e4d3690d kdepim-runtime-4.5.97.tar.bz2 Translations are included as with all the previous KDEPIM 4.6 beta tarballs. Please test these and let me know if they build ok for you. Our goal is to release KDEPIM 4.6.0 final with the next KDE SC 4.6.4 bugfix release in eary June. For best results, please use with the most recent releases of Akonadi, Soprano, kdelibs4.6 and kdepimlibs4.6 Regards, Allen, KDEPIM Module Coordinator and Release Dude ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
[4.7 Beta1 blocker] KIO Broken.
Hi, According to http://bugs.kde.org/273783 KIO is broken. Although this could be introduced after Dirks tag, but that would mean someone broke the tag freeze. Can someone confirm and find a solution ASAP? Best, Tom -- Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Restriction for moves from svn to git.
- Original Message - Have we reached any consensus here? Apparently there is no need for this. Best, Toma -- Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: 4.6.2
- Original Message - A Diumenge, 20 de març de 2011, Tom Albers va escriure: Hi, 4.6.2 is approaching. Can someone make a list again, like last time what needs to be packaged from where? This time before Dirk starts to yell at me :) I think most is the same except kde-graphics maybe? Are the branches renamed already? Who has the overview? Most of kdegraphics projects migrated to git still have a 4.6 branch in svn too (i was [almost] totally ignored when suggesting that was a bad idea and would confuse people) so good luck finding where you have to package them. Ok, so we leave out kde-graphics on 4.6.2 ? Best, -- Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re:
Nicolas has been unsubscribed... - Original Message - ...EEE! Try to click here and have some fun! http://niftytrends.megabyet.net/links.php?yfortune=22u9 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team -- Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Minor releases KDE 4.6
4.6 minors and 4.7 Pushed to techbase and ics. Toma ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Minor releases KDE 4.6
Hi, I've adapted the app to include a schedule for minors as well. Release on 1st tuesday of the month + tagging on the thursday before. This results in: === Thursday, February 24, 2011: KDE 4.6.1 tagging === === Tuesday, March 1, 2011: KDE 4.6.1 release === === Thursday, March 31, 2011: KDE 4.6.2 tagging === === Tuesday, April 5, 2011: KDE 4.6.2 release === === Thursday, April 28, 2011: KDE 4.6.3 tagging === === Tuesday, May 3, 2011: KDE 4.6.3 release === === Thursday, June 2, 2011: KDE 4.6.4 tagging === === Tuesday, June 7, 2011: KDE 4.6.4 release === === Thursday, June 30, 2011: KDE 4.6.5 tagging === === Tuesday, July 5, 2011: KDE 4.6.5 release === I think the amount of backporting decreases a bit at the end, so an alternative would be to delay the .4 tagging/release 1 month and not do a .5. I'ld vote for this alternative personally. If ok, I'll add it to techbase and the ical, together with the KDE 4.7 schedule Albert suggested. Best, -- Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-scm-interest] Re: Kate App/Part/KWrite = kate.git
- Original Message - A Dissabte, 29 de gener de 2011, Christoph Cullmann va escriure: On Sunday 16 January 2011 13:11:47 Christoph Cullmann wrote: Hi, is it ok to now move that stuff to the kate.git for KDE 4.7? KTextEditor can reside in kdelibs, to keep BC /SC (I will sync it if changes occur). This would remove: kdelibs/kate kdesdk/kate kdebase/apps/kwrite (and I guess the doc/.. stuff for the apps need to move and what-I-don't know i18n scripts + packaging must change) But the part/application code really should be only in one place. Given that most people work only in kate.git, this will avoid my hassle with syncs, I will only keep syncing /trunk = git, to avoid any losses until this is done, thought. As no reaction until now and kdelibs moves git now already, I intend to move kate part out of kdelibs and only let it be in kate.git (same for kwrite in kdebase and kate in kdesdk). I propose the weekend 15.-16. Feb for the move (which more or less would only be a delete in git/svn of the old copies). I guess this needs coordination to have for example still working i18n (as the docbooks would move too and the i18n stuff needs fixing). Therefore CC Albert, would that date be ok for you to help me a bit with this? Or should I delay and ask on i18n for help? With kdelibs now being a git, it really is not that nice for contributors of kate part to clone whole kdelibs... I'm sorry but having an own repo for kate with all the stuff in there is a no go from the i18n point of view. Because the tool can not cope with it? -- Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Kate App/Part/KWrite = kate.git
- Original Message - A Dissabte, 29 de gener de 2011, Albert Astals Cid va escriure: A Dissabte, 29 de gener de 2011, Christoph Cullmann va escriure: On Sunday 16 January 2011 13:11:47 Christoph Cullmann wrote: Hi, is it ok to now move that stuff to the kate.git for KDE 4.7? KTextEditor can reside in kdelibs, to keep BC /SC (I will sync it if changes occur). This would remove: kdelibs/kate kdesdk/kate kdebase/apps/kwrite (and I guess the doc/.. stuff for the apps need to move and what-I-don't know i18n scripts + packaging must change) But the part/application code really should be only in one place. Given that most people work only in kate.git, this will avoid my hassle with syncs, I will only keep syncing /trunk = git, to avoid any losses until this is done, thought. As no reaction until now and kdelibs moves git now already, I intend to move kate part out of kdelibs and only let it be in kate.git (same for kwrite in kdebase and kate in kdesdk). I propose the weekend 15.-16. Feb for the move (which more or less would only be a delete in git/svn of the old copies). I guess this needs coordination to have for example still working i18n (as the docbooks would move too and the i18n stuff needs fixing). Therefore CC Albert, would that date be ok for you to help me a bit with this? Or should I delay and ask on i18n for help? With kdelibs now being a git, it really is not that nice for contributors of kate part to clone whole kdelibs... I'm sorry but having an own repo for kate with all the stuff in there is a no go from the i18n point of view. Let me be a bit more clear. It's a no go since it totally breaks the module concept KDE and thus KDE i18n has been using forever. That is, in which of this packages [ http://l10n.kde.org/stats/gui/trunk-kde4/team/ca/ ] do i extract the po files that originate from the kate repo? As I see it, answers can be: * In a new top level package - no go for me since kate is in no way more important than say k3b * Each file in a totally different package - no go for me since it means having to add manually rules for each of the .po files you create from the kate repo So this is why i think it's a no go, and why opossed ages ago already. Ok, so let's work on the issues, instead of declining it. Since KTextEditor remains in kdelibs, why is kate 'special'? Why can't we put it in extragear/utils ? Best, -- Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Kate App/Part/KWrite = kate.git
- Original Message - A Dissabte, 29 de gener de 2011, Christoph Cullmann va escriure: On Saturday 29 January 2011 14:04:42 Albert Astals Cid wrote: So this is why i think it's a no go, and why opossed ages ago already. Ok, so let's work on the issues, instead of declining it. Since KTextEditor remains in kdelibs, why is kate 'special'? Why can't we put it in extragear/utils ? As far as I understood Cristoph idea was have a kate repo somewhere but on release stage Dirk would distribute the things as they are distributed now, e.g. katepart would end in kdelibs, kwrite in kdebase and kate in kdesdk. So if we put it in extragear/utils we are lying to our translators and to people that might use svn as source for their packages, etc. No really. Actually my (or the kate teams) plan was: - remove Kate Part + App + KWrite from their current places - keep ktexteditor where it is (to have BC+SC kept) and have a small copy in kate.git to allow easier development (which I will keep in sync with the REAL on in kdelibs - have kate.git packaged as kate.tar whatever with kde releases So the kate.git package will conflict with the kdelibs one as both will provide ktexteditor? Well, i guess you can have some smart cmake hackery to fix this issue (though i'm really oposed to duplicate code i won't block the transition because of that) I have no problem to be moved to extragear, but I would like to remain in the normal KDE SC release. And I don't see this as a special wish, given for example kdesdk will for sure split anyway up, why is it a problem if kate splits out first? How will other split modules be handled? I have no problem if kate stays in the kdesdk group, if there is any or any other toplevel group. I not insist on some toplevel kate whatever thing, just a place where the kate.git can be and be packaged with the KDE release. Ok, misunderstanding from my side then, having kate.git inside extragear- devtools or maybe kde-runtime (since it provides kwrite and katepart that for me are basics especially katepart) totally works for me (and my l10n concern is vanished) Great! The only problem that remains is the releasing bit. But we can work that out later I guess. I like the suggestion to put it here: https://projects.kde.org/projects/kde/kdebase I'ld even would suggest doing it today, since all devels need to re-setup their build system anyhow. Best, -- Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Kate App/Part/KWrite = kate.git
- Original Message - On Saturday 29 January 2011 15:24:57 Tom Albers wrote: No really. Actually my (or the kate teams) plan was: - remove Kate Part + App + KWrite from their current places - keep ktexteditor where it is (to have BC+SC kept) and have a small copy in kate.git to allow easier development (which I will keep in sync with the REAL on in kdelibs - have kate.git packaged as kate.tar whatever with kde releases So the kate.git package will conflict with the kdelibs one as both will provide ktexteditor? Well, i guess you can have some smart cmake hackery to fix this issue (though i'm really oposed to duplicate code i won't block the transition because of that) I will change the current CMakeLists.txt to only build ktexteditor if one explicitly requests it (like -DBUILD_KTEXTEDITOR=1) and document that for people wanting standalone kate.git development on older kdelibs). This would avoid problems for any non-kate developer or packager with conflicting installed stuff. I have no problem to be moved to extragear, but I would like to remain in the normal KDE SC release. And I don't see this as a special wish, given for example kdesdk will for sure split anyway up, why is it a problem if kate splits out first? How will other split modules be handled? I have no problem if kate stays in the kdesdk group, if there is any or any other toplevel group. I not insist on some toplevel kate whatever thing, just a place where the kate.git can be and be packaged with the KDE release. Ok, misunderstanding from my side then, having kate.git inside extragear- devtools or maybe kde-runtime (since it provides kwrite and katepart that for me are basics especially katepart) totally works for me (and my l10n concern is vanished) Great! The only problem that remains is the releasing bit. But we can work that out later I guess. I like the suggestion to put it here: https://projects.kde.org/projects/kde/kdebase I'ld even would suggest doing it today, since all devels need to re-setup their build system anyhow. I have no problem with that be done today. And I don't oppose the location, am fine with it. Greetings Christoph Ok. Can you throw in a request at https://sysadmin.kde.org/svnaccount/repo-request.php I'll create it after projects.kde.org is back up. -- Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Kate App/Part/KWrite = kate.git
- Original Message - On Saturday, January 29, 2011, Christoph Cullmann wrote: On Saturday 29 January 2011 18:36:17 Aaron J. Seigo wrote: On Saturday, January 29, 2011, Christoph Cullmann wrote: - keep ktexteditor where it is (to have BC+SC kept) and have a small copy in kate.git to allow easier development (which I will keep in sync with the REAL on in kdelibs i can't imagine ever allowing a project that isn't in kdelibs today to do this. as such, i cringe at reading this. it seems extremely fragile and is going to be amazingly confusing to people who may wish to contribute, particularly casually (as i did in a small way last year when i used the KTextEditor interface in plasma-desktop) since you wish to stay with the SC releases, so we don't need to worry about API drift between components due to being outside of a shared release cycle, is there _any_ reason why KTextEditor has to stay in kdelibs? can we just make KTextEditor a dependency for apps that require it and provide a CMake module to find it? I have no problem to move ktexteditor, too. I only found it more easy for the packagers to do it that way, as all compile time dependencies stay the same. .. until you get to packaging the kate repository and have to figure out which KTextEditor to package? it just seems extremely sloppy. what do the packagers and release team think about having this code dupliated in two places in the SC? Beside, I did the syncing of ktexteditor since more than one year now and really, there is nearly no change. yes, it's doable. the question is if it is desirable :) But yes, I would be more happy with one place too, I only not like the idea to enforce people to have kdelibs.git just to test new extensions. this is an issue where we are mostly guessing at cause and effect based on intuition and occasional anecdote. there is just no point, imho, to trying to figure it out with discussion. what we can do is employ the good old scientific method: we have a hypothesis, it makes predications, let's run an experiment and see what the actual effects are. which to me means getting KTextEditor out of kdelibs so we can see what the real effects of more aggressive modularization of KDE Platform are. this kind of experimentation leaves me feeling a bit uncomfortable, but lacking resources and expertise to imperically gather the required data and make an informed decision, it's probably the best we can do. if we start it now, we have an entire release cycle to determine early effects, and we can always reverse course later on if needed. the results of this experiment, whose effects would be fairly limited (not everything uses the KTextEditor interface :) but broad enough to be meaningful, should give us very useful data to use in deciding what to do withe other similar cases. this would require that the kate team would need to pay more than the usual attention to development process effects and be wiling/able to report them back to the rest of us at intervals (2-3 times over the next year?). what do others thinks? too crazy? reasonable idea? worth trying? not worth the hassle for packagers and developers? Worth trying. Some feedback from a packager would be nice though. -- Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: 4.7 Release Schedule
- Original Message - Here a wonderful schedule generated by Tom's program. What do you guys think? Fine by me. 2 beta's and 2 rc's is working nicely for us I think. Also the cycle as a whole seems to work ok. -- Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Question about moving packages *out* of a module before release.
- Original Message - Hi all, I've got a question regarding kdesrc-build, my updater-builder thing in kdesdk/scripts. It occurred to me today as I was updating the documentation in a branch so as to avoid interfering with the message freeze that I'm probably going about this the wrong way. There was a point in time where it made sense for what was then kdecvs-build to be in kdesdk/scripts, since it was similar to kde-build in kdesdk/scripts, it used to be small ;), and I think it may have even pre- dated Extragear and at least wasn't far off. However, I've always handled my own releases, there's been a separate website, etc. I even used to routinely update it during freeze and although I've brought that up before myself, with no major dissent about breaking anything, I'm thinking that it makes more sense to split kdesrc-build off from the rest of kdesdk/scripts when it's moved to git.kde.org. So, with that in mind, is there any opposition to removing kdesrc-build from kdesdk/scripts prior to the 4.6 release? I'm not talking about doing it tonight by any means, but it seems like a better idea if it's going to be moved out of kdesdk/scripts to do so before a point release as opposed to after one. What I don't want to do is derail the preparations being made by e.g. release team, translators, packagers, distributions, etc. so I want to make sure that moving would not interfere with the release process. Regards, - Michael Pyne Packagers should have the packaging scripts pretty much ready for the release. Removing a binary will cause work for them. Since we have shipped this for years + the fact that it is not broken, I don't see a reason why it should happen in this RC-stage. Why not remove it from trunk (KDE 4.7) only and leave it in 4.6? Best, -- Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Moving 4.6 to git next Tuesday or Wednesday
- Original Message - Why didn't these objections surface before when we asked and not now when we tell what will happen, or was they just forgotten/ignored? They were not raised because the idea up to now was to keep 4.6.x from svn and do 4.7 from git, which would make dec 22 an excellent date. Now that it appears 4.6.x also seems to come git, this date is unfortunate. See for example http://lists.kde.org/?l=kde-release-teamm=128916138705044w=2 Best, -- Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: 4.6 Scheduler: Request for 4.6 Beta 3
- Original Message - I'm waiting for objections. I'm going to raise one :( So far we don't have any objections. If there are no objections in day or so I will offiically change the release schedule. Will's question is not answered yet. | Would the PIM team spend the extra 2 weeks on the desktop | versions or | on Kontact Mobile? Yes to both. I've read Tills mail and it is pretty clear to me. The focus for KDAB lies on the mobile version for the next two months. That means the desktop version will benefit from bugfixes in the underlying libs and akonadi, but KMail desktop will receive only little love. Although Till thinks KMail is ready enough to be release, I get the impression that it's not from several reports. Anyhow, I think 2 weeks delay will not solve much. Especially, Kevin asked for more time to work on data migration issues which mainly affect the desktop. Although this is a very import argument, I'm not sure two weeks is enough. And when the data migration might be ok, kmail itself might not be up for the end-user job yet. My proposal would be to continue with the schedule as planned, the kdepim team would need to decide to either release it as normal, relase it but mark the kdepim/kmail part as 'experimental', or skip the .0. Best, -- Tom Albers KDE ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: 4.6 Scheduler: Request for 4.6 Beta 3
- Original Message - On Mon, Dec 13, 2010 at 08:05, Anne-Marie Mahfouf an...@kde.org wrote: On xxMondayxx 13 xxDecemberxx 2010 14:35:07 Tom Albers wrote: - Original Message - I'm waiting for objections. I'm going to raise one :( So far we don't have any objections. If there are no objections in day or so I will offiically change the release schedule. Will's question is not answered yet. | Would the PIM team spend the extra 2 weeks on the desktop | versions or | on Kontact Mobile? Yes to both. I've read Tills mail and it is pretty clear to me. The focus for KDAB lies on the mobile version for the next two months. That means the desktop version will benefit from bugfixes in the underlying libs and akonadi, but KMail desktop will receive only little love. Although Till thinks KMail is ready enough to be release, I get the impression that it's not from several reports. Anyhow, I think 2 weeks delay will not solve much. Especially, Kevin asked for more time to work on data migration issues which mainly affect the desktop. Although this is a very import argument, I'm not sure two weeks is enough. And when the data migration might be ok, kmail itself might not be up for the end-user job yet. My proposal would be to continue with the schedule as planned, the kdepim team would need to decide to either release it as normal, relase it but mark the kdepim/kmail part as 'experimental', or skip the .0. Best, I agree that delaying everything for a hypothetical benefit is too much, especially if we considere that the current release schedule is tied to the git migration. Speaking of that, I think the Git people who want to move on 20th December must write all mailing lists in order to make it clear to every KDE contributor what is going to happen and when. Can we as the Release Team ask them to do so? I, as a Git person, asked the release team to send something over the announcement list last week. In the normal course of doing the conversion I've been emailing lists relevant to what I'm working on to double-check my work. Today I'm going to send out a big cross-post for projects in kdebase-workspace/runtime (assuming sysadmins upload the repos). But I think something more formal broad-spectrum from the release team would be nice. Ian Thread hyjacking... -- Tom Albers KDE ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Moving 4.6 to git next Tuesday or Wednesday
- Original Message - Dirk, We were discussing in #kde-sysadmin whether it made sense to move not just trunk/4.7 development to Git next week, but 4.6 as well. No one really likes the idea of having two SCMs active at the same time, which was the current plan. Do you consider putting together the release scripts in time for 4.6.0 to be a blocker? Since i18n is staying in SVN the complicated part of the release script won't change any. And kdelibs, kdebase-*, and kdepim* are all basically staying with a 1-repo-1-tarball ratio, so they shouldn't be much trouble. (kdebindings might be more complicated since they want to split up into about 6 or so tarballs at the same time as their git release, though still 1 repo:1 tarball, but that isn't the subject of this email) So if we did the git transition next week, 4.6 rc1 would be the last release to come out of SVN. We see the alternative as doing the transition shortly after the 4.6.0 release next month. But (speaking for myself) I'd only want to delay the release until next month if we know for sure that there is a good reason to; eg you need this time. Thanks, Ian Monroe I object to the transition next week of the 4.6.x code. I propose to do the transition after the 4.6.0 has been released. Reasons: - developers need to learn git / re-setup their system, which is very unfortunate in rc-time where every single development hour should be put in bugfixing. - if something goes wrong there is no possibility to correct that without delaying rc2 and 4.6.0 - the release scripts can not be tested for rc2, remember that the release candidate tarballs are created, small test build and released, there is not a week between the tarball and the release as is the case with the beta's. Best, -- Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Git transition for kdelibs and kdebase
- Original Message - I understand that the kdepim is moving to Git on Dec 20th, since this lines up with the release schedule. I've started work with the Git transition for kdelibs and kdebase. My goal is to do the git conversion at the same time. So I'm just double checking that this makes sense with the release team. Thanks, Ian Monroe I can't see the difference between packaging kdepim from git and packaging kdelibs from git, scripts need to be adjusted anyways, applying that to more modules should not matter much... Right? As long as the structure is being kept the same. You might want to discuss it with kcd though... Best, -- Tom Albers ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-pim] Re: kdepimlibs and kdateedit
- Original Message - A Dissabte, 27 de novembre de 2010, Kevin Ottens va escriure: On Thursday 4 November 2010 10:08:45 Kevin Ottens wrote: On Thursday 4 November 2010 09:52:41 John Layt wrote: I'd like to see all the date/time widgets in KDE reviewed and amalgamated as much as possible in kdelibs, or at least made consistent in behaviour and appearance. I just didn't have the time in 4.6. Unless you really want to move them to kdepimlibs for 4.6, I'd be happy to make it one of my priority items for 4.7. I think I've the most refined copy in zanshin. I was planning to push it in kdelibs for 4.6 but couldn't find the time. Actually I was also waiting for some feedback of the Skrooge guys who have yet another copy, but I didn't hear from them... I should poke the relevant person again I think. :-) OK, turns out I could sit with Stephane Mankowski today during the KDE Hacking Session in Toulouse and we made KDateEdit ready for inclusion in kdelibs. Timing wise it's rather unfortunate since we're after the freeze. For sure we can land this improved version in kdelibs 4.7, but if the release team agrees to an exception I could take the time to make it into 4.6. @Release team: Go, No-Go? That's what Allen told me on a patch i wanted to add The Hard API Freeze doesn't occur until 20 December. So you really don't need an exemption -- all you really need is the approval of the core devs for this one, which you have it seems. However, we are in Soft API Freeze so you should CC the kde-bindings folks on your commit. So i guess you need to seek approval of k-c-d and that would be it? My intention with api freeze was to allow polishing of existing api. New classes in kdelibs are new features imho. I don't see an urgent reason for an exception tbh. Beta1 is already released. Best, -- Tom Albers KDE Release Team ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.5.4 tarballs (try#1) uploaded
- Original Message - Seems the folder rights are set wrong: Hopefully fixed without making it public. Best, Toma -- Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Move kdeplasma-addons to git - take 2
Hi, - Original Message - but that will require support from the release team as the release of kdeplasma-addons for 4.6 would have to come from git.kde.org instead of svn.kde.org. if the release team members veto that for the 4.6 release, then we will need to consider the second (or some other?) option. For now that will end up on Dirks plate. Considering that he has not been that active the last months, except for the basic release work, I'm not sure this is a good idea. At least we should not do it until we get an explicit ok from him. KDEPIM will switch on December 22, the day after the branch is created for the 4.6 cycle. I suggest for now to match their schedule so the 4.6.x will keep coming from svn and the 4.7 comes from git. Matching it also has it advantages regarding notifying developers of the important changes and maybe the promo team can do something with that too. But that's all minor. and perhaps sysadmin could help us by making that area of svn read-only on the day the git import is scheduled to start. That's no problem at all. Just make a note of that in the bugreport asking for the git repo (which should be done at least a week in advance) or ask one of us on irc. Best, -- Tom Albers KDE Release Team Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.5.3 tarballs (try#1) uploaded
Hi! Can you file a bugreport for that please? This bug is no showstopper for KDE releases and can not be resolved by mentioning it here. - Original Message - kde-l10n-de still has this blank-bug in taskbar for layout-switcher: http://chakra-project.org/temp/phil/4.5.2-taskbar-kblsw.png Hope it gets solved quickly. Best, -- Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Question about git repository layout + releases
- Oorspronkelijk bericht - This is not entirely correct: True, we want to move the git repo to KDE's git infrastructure. Christoph could still merge all changes back to svn (just like he does now); this is no issue. Hence, no problem for the release cycle. As Eike said, this is not what we understood. So if this is the real question, this is a no-brainer imho. If everything is merged back to SVN there is no issue to discuss for the release-team. Best, -- Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Should kde-qt go 4.7 now?
- Oorspronkelijk bericht - On Monday 20 September 2010 15:37:38 Sebastian Kügler wrote: On Saturday, September 18, 2010 13:43:35 Marco Martin wrote: to keep the thing alive... so in the end what we will do? basically most of the work i'm doing for kde 4.6 depends on qt 4.7 so would be neat to know :p Pending any strong objections, let's move make trunk depend on Qt 4.7 as soon as Thiago finds time to switch the kde-qt tree. (Thiago, please let the lists in this email's header know when you do.) If you want to object, please do so with (a) good reasons, (b) before Wednesday, so we can move on with this. Wouldn't it make more sense to do this something like two weeks after that switch happens? So people actually have some time to update there qt builds? +1 -- Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: migrating KDE's main modules to git
On Mon, 23 Aug 2010 18:06:02 -0700, Aaron J. Seigo ase...@kde.org wrote: * Is the November 17th date a hard date requirement, or can we start moving main modules into git.kde.org earlier if we are ready to do so? Why / why not? Without talking to the rest of the KDE sysadmin, I think we can facilitate a move for the main modules on an earlier date. We can somewhat compact and mix everything listed starting from september 29, but we do want to have some room to do some testing with some smaller projects before we move main modules, as the impact for that is many times bigger. If there is a plan for the main modules to move say after October 15 or so, I'm pretty sure we can facilitate that. We just want to know in time. * The projected delay is due to waiting on password-ssh account conversions; can we get guidance on the nature of the delay? (e.g. latest date willing to wait, or if sys admin is not willing to make that call and therefore KDE needs to provide such a definition for sys admin to simply implement.) The someone aggresive blog and recent mails did make some accounts switch. We currently have around 20 passwd based accounts that have committed more than 10 times this year. Tonight we will put in an ACL which prevent those people from committing and ask to contact us instead, in the next week we will probably catch some of those 20 remaining accounts with that. In other words, I don't think there will be a delay in the schedule at this point. Finally, we used to have a TODO tracker on the wiki here: http://techbase.kde.org/Projects/MovetoGit Obviously, this is pretty much out of date with regards to the current state of things. Can someone with the knowledge of what's happening update the times of ites that the sys admin plans have taken care of? Will do. the people on the scm interest are the best equipped to come up with these answers, as you have the knowledge. please come up with a recommendation (or a limited set of competing recommendations for KDE to chose from, if that's not possible) in written form. include the workflow, benefits and challenges. include what new efforts, if any, are needed to achieve the recommendation. Although this is an item for the scm-interest people, I would like to give an heads-up that the people behind the sysadmin team are preparing a document which will exactly cover this. It will include an *advise* only, as the scm-interest list should decide, but in any case, this document could (and should) easily be rewritten with the final outcome of that discussion. I can almost hear everyone *sigh*-ing that there will be another upcoming discussion about all this, but I would like to have a discussion based on a document which lists advantages and disadvantages and within that document describes the consequences for all the affected systems we will be using. It's not just the layout of git.kde.org, but also reviewboard, gosa and redmine are involved. We will give an overview about the consequences for all these systems and will present some practical problems we are running into and ask for help resolving those. I hope this discussion will be done objectively and with renewed eyes from everyone, iow, don't hold firmly to the previous positions you have taken, but be open to look at, and consider, alternatives and work productively to the solution that is best for KDE. Can you please provide k-c-d with a firm time commitment as to when this document will be delivered so that we can track its progress along with all the other bits that are flying about? It's not so important if it takes one week or three weeks, we just need (and deserve!) to know when to expect this guidance so we can start crafting migration rules that follow this. The people behind the sysadmin team will bring out the advise somewhere in the next 2 weeks. We'll do our best to do it asap. Best, -- Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: New (optional but preferred) dep introduced in 4.5 - Opentts
On Mon, 5 Jul 2010 11:53:23 +0200, Maciej Mrozowski reave...@gmail.com wrote: As of July 2nd, kdeaccessibility/jovie introduces new optional (but preferred when both Speechd and Opentts are found) dependency in 4.5 branch (and trunk) - Opentts. No that it's any problem for me as a packager, but I thought introducing new dependencies that late (after May 11th: Dependency Freeze) should require exemption[1] or at least public announcement. 1. http://techbase.kde.org/Schedules/KDE4/4.5_Release_Schedule#May_11th:_Dependency_Freeze True. This has to be made optional for 4.4. If not possible, please revert it. -- Tom Albers KDE Developer ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: New (optional but preferred) dep introduced in 4.5 - Opentts
On Mon, 5 Jul 2010 11:53:23 +0200, Maciej Mrozowski reave...@gmail.com wrote: As of July 2nd, kdeaccessibility/jovie introduces new optional (but preferred when both Speechd and Opentts are found) dependency in 4.5 branch (and trunk) - Opentts. No that it's any problem for me as a packager, but I thought introducing new dependencies that late (after May 11th: Dependency Freeze) should require exemption[1] or at least public announcement. 1. http://techbase.kde.org/Schedules/KDE4/4.5_Release_Schedule#May_11th:_Dependency_Freeze Ah, misread. It is optional already.. If so, I dont think it is a problem -- Tom Albers KDE Developer ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Observations and personal conclusions on the KDE release process since 4.0
On Tue, 29 Jun 2010 21:52:00 +0200, Wulf C. Krueger philant...@exherbo.org wrote: Hello! Please don't take any of the following personally - it's not meant to offend anyone. Hi, Thanks for the overview, it was a nice read. While you have valid points, some are not. The biggest problem you seem to have is with announcing untested tarballs. You have to understand that we are announcing them to the packagers. They help to find problems with the tarballs. That's perfectly fine. If they have a problem and don't want to run into the chance of starting from scratch, they can wait untill we officially announce the tarballs. At that point the tarballs are ready and with help of the distro's that do have tried to build it, we know for a fact that it will build on almost every machine. The option to prevent this is, as you suggested, to first build everything our self. Then pass it to the packagers so they can prepare packages, then announce it. That will set us back a week in every release. This is not possible as in that case there would for example be a week between release and the next tagging, which gives no time to incorporate bugs from a previous release. QA-wise even worse. Last point I would like to comment about is your statement that an increase in minor releases says something about the quality. That's untrue, the minor releases are time based (released at the first Wednesday of the month iirc) and or not based on the amount of bugs solved at all. Again thanks for the overview, I'm sure I'll scan through it again when making the next round of schedules and see if we can improve some items. -- Tom Albers KDE Developer ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.5 Beta2 (4.4.85) uploaded
Hi Dirk, Did you pick kdeedu from the 4.5 branch? Tom Albers -- KDE Sysadmin and Developer Op maandag 07 juni 2010 10:05:38 schreef Dirk Mueller: Hi, I just finished uploading the first set of tarballs for KDE 4.5 Beta2, which was actually planned to be done end of last week, however I was offline and I didn't have time to do them before leaving due to various private life issues. Lets delay the release until Thursday, I hope this is enough time assuming the current set of tarballs compile+work good (still building them). Thanks, Dirk ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: 4.4.5?
Op dinsdag 01 juni 2010 15:58:14 schreef Allen Winter: On Tuesday 01 June 2010 9:49:00 am Anne-Marie Mahfouf wrote: On Tuesday 01 June 2010 15:29:13 Allen Winter wrote: It is done. - update TechBase schedule, done - blog 4.4.5 is coming, done - email 4.4.5 is coming, done - update #kde-devel topic, done - anything else? I'll try to blog mid June about it! Thanks Allen, If Amazon can email me reminders about stuff, I wonder why we can't? The 4.6 schedule now contains a link to an .ics file. Needless to say, everyone can put that in korganizer and get their reminders. I can even add the alerts to the ics I guess Best, Toma ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
playground/utils/releaseschedule
SVN commit 1132325 by toma:
Typo fixes are allowed up to the hard message freeze, not beta2.
CCMAIL:release-team@kde.org
M +2 -2 mainclass.cpp
--- trunk/playground/utils/releaseschedule/mainclass.cpp #1132324:1132325
@@ -67,7 +67,7 @@
in strings can be fixed. No major new strings changes
should
be done. It is ok to remove strings. Exception:
Artwork
(try to keep the number of new strings low anyways).
- Exception: Typo fixes can be fixed until Beta2 is
released
+ Exception: Typo fixes can be fixed until the Hard
Message Freeze,
but you have to mail kde-i18n-doc saying you made a
typo fix
change.;
break;
@@ -280,7 +280,7 @@
text.append( DTSTART: + dt.toString( Qt::ISODate ) + Z\n );
text.append( SUMMARY: + i.value().first + \n );
QString desc(i.value().second);
-desc.remove(\n, );
+desc.replace('\n',' ');
text.append( DESCRIPTION: + desc + \n );
text.append( END:VEVENT\n\n);
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: Proposal: Implementing signing process for official tarballs (try #1)
On Fri, 28 May 2010 23:32:58 +0200, Dirk Mueller muel...@kde.org wrote: I'm fine with providing a signature again, but fact is that nobody requested them again so far. Just providing the md5sums on the website was enough so far - people are mostly concerned about incomplete/wrong downloads rather than malicious attacks. I'ld be in favor to reintroduce it again. Although I'm happy with a simple setup. Signing with your personal key would be ok for me, provided we mention that on the info page, which resides in svn. Best, -- Tom Albers KDE Developer ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.4.4 packages ready (try #1)
On Fri, 28 May 2010 22:36:21 +0200, Joanna Rutkowska joa...@invisiblethingslab.com wrote: On 05/28/2010 10:29 PM, Dirk Mueller wrote: Hi, sorry for the late notice, but I uploaded a few hours ago the KDE 4.4.4 tarballs (including l10n). Testbuilds are still running. Release is scheduled for Tuesday next week. So, any plans to add digital signature for this? joanna. The discussion is in full swing, it is unrealistic to expect it for these tarballs. Best, -- Tom Albers KDE Developer ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE SC 4.6 Schedule
On Wed, 26 May 2010 22:00:38 +0100, Albert Astals Cid aa...@kde.org wrote: I like it. Albert Thanks, I've put the schedule online now. -- Tom Albers KDE Developer ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Early Branch.
On Fri, 21 May 2010 11:10:55 +0200, Volker Krause vkra...@kde.org wrote: We (KDAB/Intevation) have a intermediate deadline for the kdepim mobile work next week Wednesday, so we will go with the work branch until then and hopefully the situation will be resolved by then and I'll adapt our workflow to whatever is decided here. Well if you already done that, discussing this is a waste of time. I feel tackled from two sides now, did not saw that one coming. Nice lesson for the future... Best, -- Tom Albers KDE Developer ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE SC 4.6 Schedule
Freeze for Release Candidate 2 During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the affected maintainers as reviewer. Tuesday, January 4, 2011 - Release Candidate 2 Tagging Trunk is frozen for release candidate tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. Wednesday, January 5, 2011 - Release Candidate 2 Release The release candidate is tagged from the branch. Only urgent fixes, such as those fixing compilation errors, should be committed.As soon as the RC has been confirmed to build it will be released immediately. Wednesday, January 19, 2011 - Final Tag The branch is frozen for final release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. Wednesday, January 26, 2011 - Release Final release is released for general consumption. -- Tom Albers KDE Developer ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Early Branch.
Hi, The KDEPIM whishes to branch early, as there are lots of development in KDEPIM, a feature branch is needed. To keep the workflow a bit sane, I suggested that next to KDE-EDU, aslo KDEPIM branches of. All KDEPIM releases will come from that 4.5 branch. Feature development can then continue in trunk. Any objections to this request? If not, Dirk, can you set that up? Toma -- KDE Developer___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Early Branch.
On Thu, 20 May 2010 21:42:49 +0200 (CEST), annemarie.mahf...@free.fr wrote: On Thursday 20 May 2010 19:11:38 Tom Albers wrote: Hi, The KDEPIM whishes to branch early, as there are lots of development in KDEPIM, a feature branch is needed. To keep the workflow a bit sane, I suggested that next to KDE-EDU, aslo KDEPIM branches of. All KDEPIM releases will come from that 4.5 branch. Feature development can then continue in trunk. Any objections to this request? If not, Dirk, can you set that up? Toma Can someone branch kdeedu as well (quite quickly as we're just starting the meeting but we don't have enough karma) kdeedu trunk will be then open for 4.6 and 4.5 will be in branches/KDE/4.5/kdeedu (probaly) Thanks in advance, Done Tom Albers KDE Developer ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Translations branch
hey tsdgeos, Can you swith the translations for edu and pim to the branch? Best, -- Tom Albers KDE Developer ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Akonadi Meeting: exception request. / Porting Status?
On Mon, 10 May 2010 12:11:25 +0200, Sebastian Kügler se...@kde.org wrote: Hi PIMsters, On Sunday 09 May 2010 17:26:55 Allen Winter wrote: On Wednesday 14 April 2010 10:28:35 am toma wrote: Akonadi will have a meeting from may 13th to may 16th. During this meeting we will hack at some small features. As kdepim is undergoing major changes due to the conversion to the Akonadi pillar, it is difficult to implement no new features during such a meeting. More importantly there will be an API review of new API introduced in the KDE 4.5 development cycle. This usually means tons of little changes, such as renames and additional consts, etc. I hereby ask an exception from the soft API freeze and Feature Freeze during this meeting. In practise, that means we might slip in one or two features and we won't mail the kde-bindings people on API changes for kdepimlibs and kdepim. I hope this is ok. Please still notify the bindings teams of those changes. Exception doesn't mean that no communication is needed, but that unexpected API changes might show up. In the release-team, regular trouble is API changes that aren't yet reflected in bindings (hence the API freeze in our current schedule), so we shouldn't void that by not even notifying people who need to get into action for a release that builds. As the binding people have announce to move the bindings to kdepimlibs, I don't think it is needed, but if you insist... This request has been here for several weeks without objection. Let's assume this request has been granted. I'd be very interested in the KMail porting status as of now. As we're roughly around feature freeze, I'd expect the KMail Akonadi port to be finished by now. Also, in the case of an email client, we might need more testing to not harm our user base. I didn't find the KAddressbook migration in 4.3 to be smooth at all (loss of features, hangs in KMail, no migration of my existing data). I've yet to see one machine where it was transparant to the users, and judging by the PIM list, the issues are on the radar of the PIM team. If that experience is anything to go by for 4.5 and the KMail migration, I'm very concerned (of my own data and setup time, but also for many of our users who are less patient than I am in this regard). I think we need to apply special care and QA here to not burn many of our users. Can you soothen my concerns? When would be a good moment to start testing KDE PIM 4.5? I've svn switched those modules to the 4.4 version until further notice when you guys began porting, but haven't seen any meaningful communication about stability and progress of this critical KDE SC component. Thanks, That's one of the goals of the meeting. I will sent a summary after the meeting. -- Tom Albers KDE Developer ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Akonadi Meeting: exception request. / Porting Status?
On Mon, 10 May 2010 18:11:24 +0200, Jos Poortvliet jospoortvl...@gmail.com wrote: On Mon, May 10, 2010 at 12:11 PM, Sebastian Kügler se...@kde.org wrote: Hi PIMsters, snip When would be a good moment to start testing KDE PIM 4.5? I've svn switched those modules to the 4.4 version until further notice when you guys began porting, but haven't seen any meaningful communication about stability and progress of this critical KDE SC component. Yes, communication is lacking now. I'd love to see a little more blogging and info for users, even a call for testing or help if there are issues - let us know what is going on. Even if it's just a few bullet points on a blog or a repost of an important mail to the pim mailinglist... Doesn't have to be complicated. And if there is or might be an issue, we should communicate it to our users, rally some support in testing or even patches... You can't expect 10 new developers in a week but by having regular updates people will have more feeling with PIM and are more inclined to help out. If you need help with this, just let me know, the promo team is surely willing to help but we need at least SOME input! Cheers, Jos Thanks Jos, I'ld love a dedicated promo/marketing dude that comes to every pim akonadi meeting, blogs regular announcements and updates and tries to educate the developers. I've indicated that a couple of times here and there, but apart from some incidental help (which I appreciate), nothing structural has been done. And I think that is very needed. Best, -- Tom Albers KDE Developer ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE SC 4.5 schedule
Op Saturday 27 March 2010 23:29 schreef u: I strongly want to see an API freeze kick in at this time too. No more changes to APIs or header files (except docs) after this date, including older APIs and newly introduced libraries/APIs. I, and I think the other bindings people really need to have solid (not shifting!) ground to work on at this time in the schedule. Even minor changes which are often easy enough to fix, cause problems by breaking builds requiring new tarballs or packages to be made etc etc. Good idea. If that would make the creation of tarballs for kde-bindings module less painful, I think everyone agrees. I suggest we try this out this cycle and see how it works out. I've added the API-Freeze to the schedule. Toma -- KDE Developer___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: 4.5 schedule on Techbase?
Op Wednesday 24 February 2010 12:32 schreef u: Op Wednesday 24 February 2010 12:05 schreef u: Hi team Is there a 4.5 schedule that can be published on Techbase? People here at SUSE are asking me. Will Roughly look at 4.4 and add 6 months. I hope I find a minute this week to make the detailled schedule. I've very limited time the next 3-4 weeks. Someone else should make it. I won't be around much anymore. Toma -- KDE Developer___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kmldonkey version problem
Dear KMLDonkey devels, We received below message. You probably have done a 2.0.5 release your self and have not updated the createtarball script. In that script 2.0.2 is indicated as the current version number. If you are making your own releases, do you want to stop us making them? If so please turn of the kde_release=yes bit to no in that same config. Let us know. Best, Toma KDE Release Team Member. Op Thursday 18 February 2010 00:12 schreef u: Hello, in the kmldonkey about dialog it says it is version 2.0.5, but on ktown there is 2.0.2. So something is wrong here and as advised in #kde-devel, I post it to this list. Regards Christian ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kmldonkey version problem
Op Friday 19 February 2010 01:25 schreef u: If you are making your own releases, do you want to stop us making them? No we aren't doing release by us own, i think some error occurred in numbering of version, please continue to manage release and tell me how to fix this numbering issue Hi, Thanks for your mail. Please update trunk/KDE/kdesdk/scripts/createtarball/config.ini to reflect the correct version number in that case. Best, Toma -- KDE Developer___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kdereview maintainership
Op Friday 24 July 2009 00:04 schreef u: On Thursday 23 July 2009, Tom Albers wrote: In any case preventing kdereview becomes a dumping ground. Which will happen without maintainer. So, another fun job up for taking. i watch over kdereview/plasma already and plasma-related stuff that goes in there having another person to help with the rest of the stuff would be great, but i'm willing to spend a bit more time in kdereview. it's already part of my weekly workflow as it is. Aaron, Can you update: http://techbase.kde.org/Projects/Release_Team ? Best, Toma -- KDE Developer___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Fwd: Am I the only person that ever checks sha1sums? :)
Both are fixed now. Best, Toma Op Monday 15 February 2010 22:08 schreef u: Release Team, Apparently SHA1 sums are wrong on some of the tarballs? (See below) Regards, - Michael Pyne -- Forwarded Message -- Subject: Am I the only person that ever checks sha1sums? :) Date: Monday 15 February 2010, 14:54:53 From: Charles Johnston char...@infoplatter.com To: kde-de...@kde.org The two files: kdebase-4.4.0.tar.bz2 and oxygen-icons-4.3.5.tar.bz2 do not match the sha1sums that are listed for them. Either the sums or the files are messed up. Any idea why? Did they get re-rolled and somebody forget to update the sums? Thanks Charles Johnston char...@infoplatter.com Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe - Toma -- KDE Developer___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: showstoppers
Op Tuesday 9 February 2010 09:39 schreef u: - The dbus registration leak (with nepomuk as prime suspect), possibly due to r1084698, cf the thread from that commit. No fix yet. Is there a bugreport where i can read more about this? Who is working on it? Solutions? Revert the commit? - The polkit-qt-1 fix (r1086506). The latest tarball has that fix afaik: 6ee8c548e42b0bb65ebc4752c2493cc2 kdelibs-4.4.0.tar.bz2 Best, Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.4.0 release planning / RC3
Op Tuesday 26 January 2010 11:47 schreef u: Currently, the schedule doesn't have a RC3 planned. Should I add one inbetween? I would suggest somewhen end of this week/beginning next week, just to ensure that we're shipping a somewhat stable release. +1 Tag on thursday morning (28th), release later the same day or friday? Not a big announcement is needed imho, more like an extra build check. After that the final 4.4.0 tag on wednesday(3rd) and release on tuesday(9th). Best, Toma ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
KDE SC 4.4 RC 3
Hi, The release team has decided to insert an additional Release Candidate before the final 4.4.0. This release candidate will be tagged next thursday (28th) and will be released as soon as the tarballs are confirmed to be ok, ideally the same day. The extra RC is added due to the struggle we had with the RC2 tarballs. We want to make sure everything is ok now, so the 4.4.0 release will not be delayed by similar issues. Please double check all your commits into the 4.4 branch, to make sure they are safe, compile and do not cause trouble for the kde-bindings people or other platforms than the one you are on. The tagging of 4.4.0 is not delayed due to this extra RC and is still planned for feb 3rd, with the release on Feb 9th. Best, Toma -- KDE Developer___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-bindings] KDE 4.4 RC1 (4.3.90) tarballs uploaded
Op Thursday 21 January 2010 12:22 schreef u: I don't think we need a strict ban. I think the problem is that the kde bindings release schedule is unavoidably slightly behind the KDE libraries release schedule. However, the overall KDE release schedule doesn't take this into account. Certainly we didn't need the KDE 4.4 release to be branched off from the trunk a month before the actual release, while we are right in the middle of trying to sort out kdebindings. Can you send me an email with how the release schedule should be adapted in your opinion? When I create the 4.5 schedule I can incorporate your wishes - if possible of course.. Best, Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.4 RC1 (4.3.90) tarballs uploaded
Op Wednesday 20 January 2010 20:17 schreef u: A strict ban on header file changes during the RC phase would be a good way to help reduce these kinds of last minute problems. Even in these late stages the plasma team are still stuffing around with their (new) APIs. I'ld rather use my.cdash.org's nightly builds and make the module maintainer responsible to keep it green at all times during rc phase and simply revert offending commits. Toma -- KDE Developer___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: branches/KDE/4.4/kdelibs/cmake/modules
Op Thursday 07 January 2010 20:20 schreef u: SVN commit 1071246 by neundorf: -we require 2.6.2, nothing else, we can discuss a higher version for 4.5, not for 4.4.x. How can you change like the most important property of our buildsystem while branching for the release without even letting kde-buildsystem or the maintainer (me) know ??? Alex Hi Alex, Your frustration is noted and we will try to inform you next time. In this case the problem was detected based on the rc1 tarballs. The time between tagging RC1 and the release is very, very limited, just a couple of hours. The simple option in this case was to increase the dependency... In my opinion that is exactly what a RC is for, finding these problems, find a fix before the final release. If a developer does not like the fix, he can still fix it before final. But again, we failed to communicate to you, a simple message 'Hi Alex, we fixed it temporary, but you might want to review our solution' should have been send. Hope this clarifies, Best, Toma -- KDE Developer___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE Feel Good Release Planning
Op Wednesday 06 January 2010 18:51 schreef u: Tacky title notwithstanding, Dirk will tag -rc1 later tonight. We want this to be a Feel Good release, and settled with the following (for now, you might want to object, in that case: do it now): - Tagging of rc1 tonight, in the coming hours - RC1 gets out as soon as it Feels Good, i.e. builds and is not an obvious lemon - Branching 4.4/ and re-opening trunk happens when tagging RC2 (19th Jan) (*) The rest, we want to keep as is laid out in the schedule. After branching , we would like to stress that your main work branch is 4.4 then, so we can iron out a bunch of more kinks and make people even happier about 4.4.1 (remember, that's what they'll all be using for half a year or more). As to the later branching, it's a balance between we want people to actually run and polish the release and we don't want to hold back to many people by too strict commit rules in the freeze. If everybody's OK with this, I'll change techbase. http://techbase.kde.org/Schedules/KDE4/4.4_Release_Schedule Cheers, The schedule says RC1 is branch point, I really don't see any urgent reason in this mail to deviate from that. If we want to we can change it for the 4.5 schedule of course... Toma -- KDE Developer___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE/kdebase/runtime/platforms/win
Op Wednesday 30 December 2009 10:10 schreef u: On Wednesday 30 December 2009 04:33:28 Patrick Spendrin wrote: For this special code I checked all changes myself and as maintainer I'd say they are ok. They are windows specific anyway... ;-) Yep, this is quite OK. But what about others? (this is a question not to you, but a general one ;)) It's really great effort to go and fix this, but my concern is that such changes shouldn't be done a) in pre-release time and b) without an explicit review by maintainers of the code. That's why I'd suspend such changes until 4.4 will be released. I have seen quite some releases when innocent pre-release change introduced a grave bug :) Cheers, Dmitry. I agree. I've said the same thing yesterday on IRC. I think it would be best to prevent 'krazy fixes' after beta2 has been tagged, with the exception of license changes and maybe one or two other checks. Anyone objecting if I explicitly add that to the 4.5 schedule? Tom Albers -- KovoKs B.V. KvK: 1104 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Tagging Release delayed for KDE SC 4.4-beta1
Op Sunday 29 November 2009 17:32 schreef u: On Thursday 26 November 2009 9:30:35 am Tom Albers wrote: Hi, You don't have to have crystal ball to know we can not tag today. We have postponed tagging until monday and the release on thursday. This is only for KDE SC 4.4-beta1. The KDE SC 4.3.4 release schedule is not affected. What does this mean: - The feature freeze has *not* moved to monday. No new features are allowed, we are in hard feature freeze. - Please try to fix the nepomuk build system issue and other issues before sunday midnight so no more delays will happen. - Try to get everything reviewed by someone else before you commit, to be sure nothing breaks. There is at least 1 showstopper Qt bug in the git kde-qt that prohibits me from being able to run KOrganizer at all for the past several weeks. QTBUG-5588 Until this and any other showstopper Qt bugs are fixed I don't think we should start the beta phase of the 4.4 release. Reading that bug, it might happen that the bug is only fixed in 4.6.1. That means delaying the beta phase until Qt 4.6.0 or even 4.6.1 is out? Can we find a work around? Like requiring a patched Qt to be present? Toma -- KDE Developer___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Drop KDevelop out of 4.4
Op Sunday 29 November 2009 14:36 schreef u: I'm sad to say this, but the KDevelop team won't have KDevelop4.0 ready to release with KDE 4.4. We've had some discussions in the last 2 days and think its best if we drop out before the beta1 so it won't be confusing. Sad indeed. We've also decided as this gets too much an anoyance for everybody, so we'll be moving kdevplatform and kdevelop from KDE/ to extragear where it belongs according to KDE policies. @Dirk: I don't have enough karma to do that move myself, so I'd like to ask you (or somebody else who has the power) to move kdevplatform and kdevelop to extragear/sdk. Also kdewebdev/quanta needs to be moved there too as it depends on kdevplatform. Move has been completed. The buildsystem and l10n will hopefully be adjusted soonish. Toma -- KDE Developer___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.4 Beta1 Tagging ahead
Op Thursday 26 November 2009 13:42 schreef u: On Thursday 26 November 2009 13:16:05 Dirk Mueller wrote: On Thursday 26 November 2009, Jonathan Riddell wrote: We're unlikely to be able to make packages for both available by release time, I'd prefer a delay in the beta. A delay in release or a delay in tagging? I assume that 4.4 beta1 will take a bit more. is a release on thursday okay with everyone? Yep, that's OK with me. We might also want to postpone tagging then, maybe until Monday (if that works for you). That gives us some time to fix all the brokenness that occurred due to people rushing their stuff in before the freeze. We also don't want to ship outdated betas, since that makes bughunting less fun. +1. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Tagging Release delayed for KDE SC 4.4-beta1
Hi, You don't have to have crystal ball to know we can not tag today. We have postponed tagging until monday and the release on thursday. This is only for KDE SC 4.4-beta1. The KDE SC 4.3.4 release schedule is not affected. What does this mean: - The feature freeze has *not* moved to monday. No new features are allowed, we are in hard feature freeze. - Please try to fix the nepomuk build system issue and other issues before sunday midnight so no more delays will happen. - Try to get everything reviewed by someone else before you commit, to be sure nothing breaks. Met vriendelijke groeten, Tom Albers. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.4 Beta1 Tagging ahead
Op Tuesday 24 November 2009 11:17 schreef u: according to the schedule, we're planning to tag KDE 4.4 Beta1 in two days. Does that sound reasonable to everyone? Any blocking issues? It does mean we have tagging and releasing 4.3.4 and 4.4-beta1 at exactly the same dates. Are we - packaging, promo/marketing - and the packagers up for that challenge? Best, Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Freeze exemption for PA integration into Phonon
Op Wednesday 18 November 2009 18:10 schreef u: Hi! Colin Guthrie has been working on better integration of PulseAudio in Phonon, but AFAIK it is now too late for getting it into 4.4, without getting and exemption from the freeze. But IMHO (and Eike Hein, who reminded me about this issue :-), distros will most probably just go ahead and patch in coling's work anyways, if it isn't available in KDE itself. The KDE-module in question is kdebase-runtime (and also Phonon itself, but that's another story). Another tiny snag is that it depends on an unreleased version of PulseAudio (because whoever packaged up the last PA release forgot to include coling's work), but I assume spring-release distros will have an up-to-date version, so if we just check for the right PA version while building, we should be OK. Mandriva's latest release already includes coling's work, so it has already received a fair amount of testing. So before you all start going around in circles screaming pulseaudio pt, if PA isn't available at build-time, all the PA-specific stuff becomes nops (and possibly completely optimized away? I don't have enough compiler-fu). And if Phonon is built with PA integration, but the PA daemon isn't available for some reason (it crashed, or isn't installed, for example), it degrades gracefully. I think this is the truth, the whole truth and nothing but the truth, so help me God, but if I'm wrong, please correct me. :-) Or ask. Or grant an exemption, if you find the kindness in your hearts to do so. A link to the patches would have been nice ;-) If there are good, working and tested cmake and ifdefs, I suggest we include it now, ship it in the beta and possibily in the first release candidate. If we get complains or unsolvable issues we can remove it for the final release if needed. Please wait 24h for other opinions, if noone objects or raises possible issues, please merge it in asap, so we can at least have some basic testing before we package the beta. Toma -- KDE Developer___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Qt 4.6 KDE 4.4.0
Op Wednesday 23 September 2009 21:41 schreef u: It is time to take a decision about Qt 4.6 KDE 4.4.0. I'ld like to announce the following to kcd and kd next saturday. In the past we decided that these things require two explicit +1's. As those are missing, I won't announce this. Best, Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Qt 4.6 KDE 4.4.0
Dear release team, It is time to take a decision about Qt 4.6 KDE 4.4.0. I'ld like to announce the following to kcd and kd next saturday. --- ** Qt 4.6 dependency in trunk ** The release team has decided that KDE 4.4.0 will depend on Qt 4.6. To give developers the time to work with Qt 4.6, we have decided that from Saturday October 10th* trunk will start depending on Qt 4.6. Everyone need to update the coming two weeks to that version of Qt. Thiago recommends to use the following git repository: if you want to help Qt development and fix the issues found before the 4.6.0 release, the unpatched branch is recommended: qt.gitorious.org/qt/qt branch 4.6-stable if you want to do KDE development, the 4.6-stable-patched would be recommended, This contains the kde patches and will trail behind 4.6-stable, so you may need to merge 4.6-stable yourself if you need the latest fixes: qt.gitorious.org/qt/kde-qt branch 4.6-stable-patched **Release Schedule Change** The expected release dates of Qt's RC and the final release currently clash with KDE's release schedule. Therefore we have decided to shift the KDE release by two weeks. This will give us approx. 2 weeks between Qt's RC and KDE's beta 1 and 2 weeks between the expected Qt final release and the start of our release candidate cycle. Of course we are not sure that Qt will release at those times, but with the former schedule it was to close to eachother. Qt will let the release team know if the schedule changes and we'll decide what to do at that moment. The complete release schedule for KDE 4.4.0 now looks like this: * 1.0 October 10th, 2009: Trunk depends on Qt 4.6 * 1.1 November 4th, 2009: Soft Feature Freeze * 1.2 November 25th, 2009: Hard Feature Freeze * 1.3 November 25th, 2009: Message Freeze. * 1.4 November 25th, 2009: Tag KDE 4.4 Beta 1 * 1.5 December 1st, 2009: Release KDE 4.4 Beta 1 * 1.6 December 1st, 2009: Documentation/Handbook Freeze * 1.7 December 16nd, 2009: Tag KDE 4.4 Beta 2 * 1.8 December 22th, 2009: Release KDE 4.4 Beta 2 * 1.9 Januari 5th, 2010: Artwork and Bindings Freeze * 1.10 January 5th, 2010: Tag KDE 4.4 RC 1 * 1.11 January 6th, 2010: Release KDE 4.4 RC 1 * 1.12 January 19th, 2010: Tag KDE 4.4 RC 2 * 1.13 January 20th, 2010: Release KDE 4.4 RC 2 * 1.14 February 3rd, 2010: Tag KDE 4.4 * 1.15 February 9th, 2010: Release KDE 4.4 Toma KDE Release-Team * Oct 10, that's also the first day of the Munich dev sprint - Let me know if you object to this text or have improvements. Toma -- KDE Developer ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.3.2 Schedule
Op Wednesday 23 September 2009 22:21 schreef u: On Wednesday 23 September 2009, Allen Winter wrote: The last Thursday of this month is 24 September 2009 (tomorrow) Dirk, will you be tagging tomorrow? and releasing on Tues 29 Sept? I would rather like to delay it by one week. Lets tag on October 1st and release on October 6th. Okay with everyone? +1 Toma -- KDE Developer___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Release Schedule 4.4
At Thursday 27 August 2009 01:00, you wrote: Am Mittwoch 26 August 2009 22:23:33 schrieb Tom Albers: This schedule will become final next saterday, unless someone objects. What is the reason for having about one week between tagging and release of the beta versions but only one day for the RCs? Imho the delay for RCs should be higher than for betas. (e.g. two days for rc and one for beta) Pierre No, the normal packaging to release cycle is ~5 days. Only if we apply that normal cycle to rc's the rc's would not get any useful testing, as their interval is set to two weeks. So the RC's follow a package-and-release cycle, with minimal testing. I do think that we need to stress to people to only fix showstoppers from rc1 stage. In the last cycle we saw that people were insanely backporting their fixes between rc1 and rc2, which made rc2 rather bad, causing us to insert the rc3. We can try to prevent that this time. Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.4 Schedule
At Friday 07 August 2009 09:03, you wrote: Le Friday 07 August 2009, Allen Winter a écrit : On Thursday 06 August 2009 2:02:07 pm Albert Astals Cid wrote: I have some people already asking me about the 4.4 schedule, do we have an answer to that other than the blank page in http://techbase.kde.org/Schedules/KDE4/4.4_Release_Schedule ? Not yet. Guess we should start discussing. I assume everyone is still ok with the 6 month cycle? (except annma, of course). Please respond with any release date blockers you may know about in early 2010. ie. sprints, meetings, conferences, .. let's block-off known bad dates first. Do we want to depends on Qt 4.6 or not? Few new feature of Qt Q 4.6 that might be interresting for KDE include: state machine API, animation API, graphics effects, webkit improvement in case we want the webkit part, mouse gestures, and more. There is no official date for the release of Qt 4.6, but it should be should be end of 2009 or early 2010. The alpha (technology preview) is planed in september. So Qt seems to be schedguled a little bit before KDE. But Qt can possibly be delayed if Nokia's QA think the release is not ready, and we should not forget that if we want to include new features, trunk (or at least part of it) should start depending on Qt 4.6 earlier in the development process. Is it OK if trunk depends on alpha or beta of Qt? (we already did in in KDE 4.1) Maybe it is an idea to team up with Qt and try to release on the exact same day? Can give both a bunch of added publicity and would be nice to try. To let that work we might want to be a bit flexible on the release date I guess. We can do that. But we need to set a max date on which we are going to release anyways, even if Qt is not ready yet. In return we need to know from Nokia something like two weeks before they are going to release (but then we depend on a TP of 4.6 for the 4.4.0 release, so might want to do a 4.4.1 quickly after that). The advantage is not purely the big news splash but also an immediate real-world showcase for Qt 4.6. Just an idea. Best, Toma ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
kdereview maintainership
Hi, Just removed my name from the module maintainers table as being the kdereview maintainer. So if anyone wants to pick it up, feel free. Basically it means tracking the stuff that goes in gets announced on k-c-d and after the review period make sure it moves out or back to playground. In any case preventing kdereview becomes a dumping ground. Which will happen without maintainer. So, another fun job up for taking. Best, Toma -- KDE Extragear Developer___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: pre-releases of rc1
At Saturday 11 July 2009 00:47, you wrote: Okay, most people chose thursday tagging and tuesday release. this is also quite close to what we already do, so that should be fine :) So we gain almost nothing, right? Best, Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.3.0 RC2 released
Op Friday 10 July 2009 21:00 schreef u: I don't think it is a show stopper, but it is anoying for sure ;) If you think that, I don't think it should go to these two important mailinglists. Toma -- KDE Developer___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: branches/KDE/4.3/kdebase/workspace/plasma/dataengines/keystate
At Sunday 05 July 2009 12:19, you wrote: SVN commit 991554 by mleupold: Backport of r991543: Add the keystate engine to the build which I forgot when moving it from kdereview. Are you sure you want to do that? I mean it is even after tagging of RC2. Are you sure it can not break anything else? Crash plasma or whatever else can happen? Note: I don't really object, just want to make sure we get a nice 4.3.0 release. Best, Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: pre-releases of rc1
Op Sunday 05 July 2009 15:05 schreef u: Four weeks between RC1 and the final version is too long. This one is accidental and caused by akademy being now, we needed to branch / rc somewhat early this time. Toma -- KDE Developer___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Permission Request to Backport a Desktop File Addition to kdebase 4.3
Op Tuesday 30 June 2009 22:11 schreef u: A Dimarts, 30 de juny de 2009, Fredy Yanardi va escriure: Hello all, I implemented a small feature for konqueror's searchbar plugin[1]. This new feature requires new property in the kdebase's webshortcut searchprovider desktop file, [Suggest] that contains the suggestion service for a specific search provider [2]. Since this request has been committed to the konq-plugins extragear module as well, it will be included in the konq-plugins extragear accompanying KDE 4.3. (KDE extragear has different release schedule, doesn't it?). But if the searchprovider desktop file addition is not in the kdebase 4.3, this feature is just non-functional (but no harm at all). Hence I request to backport the searchprovider desktop file additional property to kdebase 4.3 to make this feature also functional in KDE 4.3. Since it is a property addition to the desktop file, it should not affect any other KDE modules, hence it is harmless. But if it is not allowed, we already have this for 4.4 :) (I still have few TODOs for this feature, one is supporting opensearch) In my opinion we are too late in the process for new features, besides i'm not sure if that'd need new strings to translate but then it would be a double no from my side. Albert I agree with Albert, hard freeze is there for ages already. And it is on a very visible point in KDE, so we want it properly tested before releasing it... Besides the plugins are released at the same time as konq, so that's no convincing argument. Toma -- KDE Developer___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: rc2?
At Monday 29 June 2009 09:54, you wrote: On Monday 29 June 2009, Tom Albers wrote: will there be an rc2? i know plasma at least would appreciate such a thing, though i think we can also manage without if it's too big of a deal. Hm? We haven't even released RC1 yet! The tag and the tarballs have changed even yesterday evening. ah, then i don't need to worry. thanks :) reason is that i've got a handful of reports from 4.3 rc1 marked as unlisted binary from at least 4 different people. for now i'll assume they meant built from source like the rest of the 4.3 rc1 reports that have been filed. sorry for the noise. We should try to make sure this is the case. Do you happen to have the br's or email addresses of those so we can contact them to verify? Or we can ignore it ;-) Best, Toma ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.3 RC1 preparations
At Tuesday 23 June 2009 11:11, you wrote: b) do we branch? it was my understanding based on the discussions that we want to branch before this years akademy. I would like to start to branch then to /branches/KDE/4.3 and tag the RC from there. Yes we branch. d) kdepim tarball splitting is now finalized? Afaik kdepim/akonadi is completely standalone now, so that tarball can be created yes. But iirc akonadiconsole depends on one or two classes in kdepim/akonadi and we have no idea if that is a problem or how to solve that. Best, Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-pim] kdepim runtime
Op Wednesday 17 June 2009 23:48 schreef u: To me (as a semi-outsider) the best option seems to be to leave everything as it is for now and revisit the split of kdepim into runtime and apps when all apps have been ported to Akonadi (or when the amount of parallel branches has dropped again after GSOC is finished). Mailody is ready for a beta cycle / release, but i refuse to do that while depending on the whole of kdepim. So I really would prefer it for 4.3. If kdepim/akonadi is independent of the rest in kdepim then it can still be packaged in a kdepim-runtime tarball even if it is not moved to kdepim/runtime/akonadi or kdepim/runtime or whatever. That's the plan I think. Toma -- KDE Developer___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.3 Beta2 tagged and tarballs uploaded (try#1)
At Thursday 04 June 2009 03:07, you wrote: kdeedu (step) relies on the development version of eigen, that will become eigen 2.1. but eigen 2.1 won't be released before kde 4.3. Hi, That's a violation of what we have discussed earlier iirc. KDE should only depend on stuff that is properly released. Toma ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.3 Beta1 packages (4.2.85)
At Thursday 07 May 2009 16:12, you wrote: Hi, I've generated a first set of KDE 4.3 beta1 tarballs last night based on the 4.2.85 tag that I created before, and it doesn't look good, a lot of modules fails to compile for me, and I'm still busy figuring out how to fix them . the failures I see are essentially equivalent to what is on http://ktown.kde.org/~dirk/dashboard/ Please help to get this resolved, otherwise it doesn't make sense to upload the beta1 tarballs. Thanks, Dirk There's also the problem that the tagging was a day later than expected, and exactly that day someone made a protocol change in Akonadi. So although it will compile with the 1.1.85 akonadi tarball, it won't work. I'll fix it as soon as I get a reply on this issue on the kdepim mailinglist and I find some time... Best, Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.3 Beta1 packages (4.2.85)
At Thursday 07 May 2009 16:18, you wrote: At Thursday 07 May 2009 16:12, you wrote: Hi, I've generated a first set of KDE 4.3 beta1 tarballs last night based on the 4.2.85 tag that I created before, and it doesn't look good, a lot of modules fails to compile for me, and I'm still busy figuring out how to fix them . the failures I see are essentially equivalent to what is on http://ktown.kde.org/~dirk/dashboard/ Please help to get this resolved, otherwise it doesn't make sense to upload the beta1 tarballs. Thanks, Dirk There's also the problem that the tagging was a day later than expected, and exactly that day someone made a protocol change in Akonadi. So although it will compile with the 1.1.85 akonadi tarball, it won't work. I'll fix it as soon as I get a reply on this issue on the kdepim mailinglist and I find some time... Best, Toma Pimlibs tag has been changed to not include that commit. So the 1.1.85 akonadi tarball *can* be used with the kdepimlibs tarball Dirk will provide. Best. Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
kdepim runtime
Hi DIrk, * As discussed today, we would like to have a kdepim-runtime tarball, we would like to have it contain the content of /trunk/KDE/kdepim/akonadi. It should be able to compile stand alone and only contains the stuff that is a runtime dependency for akonadi application. That way for example Mailody can depend on that package instead of depending on the whole of kdepim. We should decide about the renaming kdepim/akonadi to kdepim/runtime/akonadi or we could create a kdepim-runtime next to kdepim as top level folder. I really don't care about what solution will be taken as I can not oversee the build consequences at all. So I think the experts should give their opinion about that. I hope we can do this for the 4.3 releases. Does not have to be for the tagged beta of course, althought that would be nice for the packagers to adapt to the change. Toma -- KDE Developer___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
