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 &
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 - > I will also remind you that KDE is as popular as it is today ONLY > because it > is widely packaged in distributions. Without packaging, KDE's > userbase would > be only an extremely tiny fraction of what it is now. I can also > point you to > several projects which have been forked into irrelevance because they > ignored > distributions' needs (see e.g. XFree86). Do not bite the hand that > feeds you! This is a very one sided look at things. You can only live if someone else makes great software. So, also for you goes: don't bite the hand that feeds you. Let's face reality: we need each other. I suggest you lower your voice a view pitches and instead of constantly screaming (and threatening us like in this mail) work productively to get a good work flow, which works for both sides. 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
KDE 4.7 beta 2 as monolitic tarballs.
Hi, I think we have to respond to the current problems with the beta 1 release. The adaption among distro's wasn't what we are used to due to our unclear message about if this layout is going to be final. I suggest that we also add monolithic tarballs, starting from beta 2. This way we have split and combined tarballs. And I suggest that we continue to do this for the whole 4.7 cycle. And we need to discuss this again for 4.8. The big problem here is that the release-team has no resources to generate these monolithic tarballs. If we were to decide this, we need help from the buildsystem to adapt our scripts to generate them. The question to the buildsystem guys is, if anyone wants to stand up and help with this. 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: 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 - > 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.
- Original Message - > Seriously, though, you can still publish a KDE *SC* 4.8 (or 5.0 or > whatever) > and a corresponding release schedule called exactly that. I think it is even more confusing to release kde sc 4.8 with for example, platform 5, pim 4.7 and plasma 2. What exactly does 4.8 stand for in that case? > This is absolutely true. Creating distro packages from such a version > mix will > become a nightmare. Not to speak of the problem that there will not > be a > common "KDE SC experience" across all distros anymore but a pretty > much random > collection of modules according to the individual release plans of > both > modules and distros. (Not to speak of us source-based distros with > "rolling > releases".) I doubt the release schedule can keep that together. If the platform releases version 5, distro's need to package it and then ship 4 too and some kde modules will be compatible with platform 5 and some won't ever. So, however we turn it, I see we can add some structure, but I do think that structure needs to be set on a per module base, no longer on a central base. > Even today, some distros have either not even started working on the > 4.7 beta > because of the comparedly small mess we're already facing today. My > guess is > that those alphas (at different milestones) won't get much testing at > all > because we, as packagers, will likely have a hard time puzzling all > the pieces > together properly - and some of us most likely won't even bother to > try. Sure, and we can see a 'deadlock' in this mailinglist with that subject. Some packagers are ok with splitting, some want it consistent and some want it monolotic. I think the module maintainers should have a bigger role and responsibility here, as there can not be one guy on this list which decides all this. I'm very concerned about the 4.7 release tbh, because I don't see a solution appearing while we need one asap. Maybe if we split it up and have responsible 'leaders' for each module we can prevent such situations and have a better uniform communication. > So, if they don't like to work toward it, there won't be unified KDE > SC > releases anymore? And even if there are, there will be only *two* > releases a > year? I'd consider that a *major* step beackwards. 2 or also for all the minor release of just 12 release moments a year, that was not the point. That are details... > > > Coordinate? We *create* releases and manage them. > > We can still package and release them if you like, that's > > independent of > > the schedules. > > Uhm... No? *What* are you going to package? How are you going to make > sure > whatever you decide to package is actually going to work with the > other > modules? Of course, you can randomly pick some date, package and > release > whatever is available at that point but, from a QA point of view, > this might > not be the wisest approach to release engineering. Well, it's up to the module maintainers to work out the release schedule to reach a stable release at the release point. I think that will work fine. We won't go randomly tarball some random folder. Thanks for the mail. It helps to clarify this idea better. 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.
- Original Message - > Weren't you the one proposing that subprojects should adopt their own > git > workflows? I'm quite puzzled about how problematic this would be. Since KDE is the community, how can we do a KDE 4.8? And then Platform will call itself 5 if I understood correctly. So how do we call a new release schedule then? Then there will be a new workflow for kdelibs, with new policies about what to release from which branch. I just don't think one release schedule will fit all modules. Just like kdepim could not follow the release schedule the last releases, kdebindings have troubles following it now and then, kdevelop followed it now and then and koffice wants to follow it again, I think it's time for more 'freedom' in this area... > Are you serious that you want to decouple the release of our > frameworks from > each other? THat would create a huge mess, extreme amounts of > overhead, be > very destructive to our community... This puzzles me as I know how > much you > love KDE. What does my love for KDE have to do with it? I think it's good for KDE to let each module set their freezes on their own, depending on which work flow they will adapt. If we decide it early the module maintainers have time enough to get used to creating the schedule. I assume Platforms will need several alpha releases to test their work and have different milestones, not being bound to a central schedule will be helpful there. We can set a preferred release day twice a year, which every module can work to if they like. > Coordinate? We *create* releases and manage them. We can still package and release them if you like, that's independent of the schedules. Best, Toma -- 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: 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
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
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 - > 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: 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: 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 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: Add some apps to the 4.7 release?
Hi, - Original Message - > Hi Thomas, > > On Saturday, May 14, 2011 21:28:40 Thomas Zander wrote: > > I've been stabilizing and making ready for release some apps (in > > git) and I > > would like to get them released in the 4.7 release compilation. > > For 4.7, the hard feature freeze has already passed, it's too late to > add apps > at this point. You've also completely ignored existing review > processes, as > laid out on techbase. From a pure process POV, that's a bunch of > show- > stoppers. I think it is important to know which scenario Thomas wants: 1. Make KOffice part of the main modules. That's indeed past the freeze date, lacks review and lacks maintainers for all apps, so that's a no-go. 2. Keep KOffice as it is and release together with the other parts of the SC. That's fine for me. KOffice is part of the KDE infrastructure and therefore allowed to join the SC release. More below, as I assumed Thomas applied for this scenario. > I don't have a problem with you releasing KOffice separately, but at > the same > time as the SC releases, but I don't think we should make it part of > the KDE > SC. We have released extragear application at the same time as the main modules. We even released completely unmaintained applications at the same time as the main modules. I don't see any reason why we would deny this to the KOffice team. Just as Amarok is welcome to release at the same day as the SC, KOffice is too. And they both can have their lines in the announcement. Just because I don't like Amarok, does not entitle me to block it. If we don't want KOffice in the SC, it's time to say that it should leave the KDE infrastructure. Again, I'm not talking about scenario 1. Which I would oppose as well. Best, -- Tom Albers ___ 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: Restriction for moves from svn to git.
- Original Message - > ...personally I think it > shouldn't be penalized if it takes a bit longer than that since > any delay would be in the pursuit of greater quality, and that > it should be allowed to migrate. It's about a disruption in the release process (release script stability, fixed tarbal layout, stability for developers in a bugfix period), it's not about not appreciating their work. I like things to have settled in svn or git at the time of the beta 1 tagging. If they can't make it before that day, they would need to wait 2 months until trunk opens again. Best, -- Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Restriction for moves from svn to git.
Dear Release Team, Since I'm less than impressed by some of the movements from svn to git [1], and considering we should not have to deal which such things during the final release stage, I'ld like to propose a restriction for all remaining main modules to move from svn to git during the period from Beta 1 tagging up to the release day of KDE 4.7 [2]. Thursday, May 19, 2011: KDE 4.7 Beta 1 Tagging Wednesday, July 27, 2011: KDE 4.7 Release If there are two supporters and no objections, I'll announce this next Wednesday or so. Best, -- Tom Albers KDE Sysadmin [1] before I get mails about being negative again: I've also been impressed by the smoothness of some migrations, like kdepim. [2] kdegraphics is still not completed, for that module goes that it should be frozen during this period. So no changes, what's in svn stays there during this period. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.2 tarballs (try#1)
- Original Message - > On Monday 04 April 2011, Andreas K. Huettel wrote: > > On Friday 01 April 2011 21:47:44 Dirk Mueller wrote: > > > I just finished uploading the first set of tarballs. > > > > BTW, the files are public on ftp.kde.org now... Intention or > > accident? :) > > That was not intentional, somebody has removed the hidden permissions > from the > directory yesterday. Just to add what I think that happened: Instead of hiding the directory initially you hid the whole stable tree. Yesterday you fixed the stable tree, but that did open op the 4.6.2 folder as it seems as it was not hidden in the first place, except that the whole stable tree was hidden so the effect was the same. Best, -- 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 - > Ok, so we leave out kde-graphics on 4.6.2 ? Ok. New plan: Every maintainer of a git repo of kde-graphics *has* to mail the release-team that he wants to be included in the 4.6.2 release. He has to indicate from which git branch the code should be pulled. Projects currently in SVN need to move to git ASAP so they can also be included in the upcoming tarball. I will check the following things for each mail: - Code has to compile standalone, if not, we can not include it, it's your responsibility. If you need help, please mail kde-core-devel or kde-buildsystem asap so they can help you. - Go to projects.kde.org, and the settings and make sure the right branch is selected. - I will remove the folder from the svn 4.6 branch. We need to clean up this mess ASAP. Those who want to be included in the 4.6.2 release have to reply before monday 28th. Best, -- 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
4.6.2
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? Best, -- Tom Albers KDE Sysadmin ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.6.1 tarballs (try #1) uploaded
- Original Message - > Does Kopete have a binary compatibility policy? Or should it raise the > lib so version? afaik, the minor point release policy should now apply, right? http://techbase.kde.org/Policies/Minor_Point_Release_Policy -- 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: 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: 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 - > 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 - > 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: [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: 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-team&m=128916138705044&w=2 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 - > 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: 4.6 Scheduler: Request for 4.6 Beta 3
- Original Message - > On Mon, Dec 13, 2010 at 08:05, Anne-Marie Mahfouf > 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: 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 - > > We really need the extra time; data migration is still taking time > > to get > > right. > For having tried KMail trunk (and reverted to 4.4) I can only agree. That brings out the question if 2 weeks will make the needed difference... If pim is not ready after that two weeks and needs more time, do we insert another beta? Is the wish to insert another beta to test code changes, or is it simply to have more time (which is fine too)? Maybe pim needs more time, and should skip .0? 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 - > Well, having this duplicated code everywhere for even more months > (look at > lxr.kde.org to see what I mean) is enough to make me want this bugger > ASAP. It's not months, in a month or so trunk is open again. > Agreed, unfortunate timing, but I had to make sure I could recollect > from the > different forks (and I probably missed some). So, you are suggesting introducing a new class to kdelibs after beta 1 has been released which will immediately be used by half a dozen applications within KDE SC and Extragear. Introducing an important new class and only letting it get half the testing it should have sounds bad to me. That also increases the chance of being stuck with an API which is not optimal for all the apps and which we can not change because it is already released. > My concern is that if we give it six more months we'll be at the same > point > for 4.7 (since PIM and Extragear tend to use only released kdelibs). In a month trunk is open and you can fix them all, no six months there. Only some ifdefs for extragear apps probably, but you would need those now as well probably, right? > I'm > definitely not interested in doing this work again, it's already been > painful > enough If you are going to blackmail me with 'now or never', by all means commit. I've no intention in upsetting you or destroying this valueable work. I only want optimal KDE releases. 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" 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 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: New (optional but preferred) dep introduced in 4.5 - Opentts
On Mon, 5 Jul 2010 11:53:23 +0200, Maciej Mrozowski 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: Observations and personal conclusions on the KDE release process since 4.0
On Tue, 29 Jun 2010 21:52:00 +0200, "Wulf C. Krueger" 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
Re: Proposal: Implementing signing process for official tarballs (try #1)
On Fri, 28 May 2010 23:32:58 +0200, Dirk Mueller 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
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: KDE 4.4.4 packages ready (try #1)
On Fri, 28 May 2010 22:36:21 +0200, Joanna Rutkowska 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 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 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
g 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
Re: Early Branch.
On Fri, 21 May 2010 01:05:00 +0200, Sebastian Kügler wrote: > Why not create a work branch for the feature development? That would have been fine if I would have known you had a problem with it. The exception request for edu was made a month ago, and nobody objected to it, nobody even replied to it, so I considered it to be ok. In that light I considered KDEPIM could just jump on the exact same train. > I'm actually not too happy with individual modules branching off for > bugfixing > and using trunk for feature development. We have a freeze for a reason > (common > rythm of development, reaching acceptable level of quality), and if we > need to > explain SVN users which trunk branches are frozen, which ones are open for > features, and which ones should get the bugfixes, we're making things > *really* > complicated, as policies are KDE SC-wide, not only apply to a subset of > the > modules within it. It's not that bad as you describe. The branch is created in order to comply to the freezes we have set. We now have a clear distinction for what is stable and where features are going. It's not making things '*really* complicated', they just branch of a bit early, just like we would have done at release candidate time. Maybe we should just consider it as an experiment for the 'always in trunk' we talked about years ago. Let's see if it works out for edu and pim and _consider_ this the default for 4.6, and yes that needs discussion in any case. > I get it that feature development in trunk is easier, > but > the main focus is getting our current trunk release ready. That holds true > for > other modules as well, and it requires a bit of discipline from all or us. > Opening up parts of trunk for feature development just sends out the wrong > message, and I fear it might have negative effect on the quality of the > upcoming release. We're in release mode now, and it's not like that should > come as a surprise to anyone. > I'm not convinced we should open up trunk for development on features > we're > not even planning to release inside KDE SC now (i.e. akonadi / kmail > mobile). I don't think it will have any negative outcome, although you can only be sure if the time arrives. In any case in both cases a feature branch would have been created, there was no way around that. Doing it trunk with the branch for the stable stuff makes a lot of lives easier. Maybe not for release managers, but it is for teams working on those. Both teams have indicated that they will double check everything is kept in sync between the two code trees regarding bugfixes. For translators it is transparant. > Also, asking for delaying the PIM release because there's not enough time > to > get it to an acceptable level of quality in time for 4.5.0, and at the > same > time requesting opening trunk for new features is a bit odd. I do know the > business background here, but I would highly appreciate if KDE schedules > were > taken into account as well. Again, this situation is exactly to facilitate that. The PIM people need to honor the KDE Schedule and they know it. But you need to consider that PIM development is largely relying on commercial development, which has sometimes have a different schedule. We need to find a balance between that. Forking PIM because the schedule does not match the commercial one is to be avoided and on the other side delaying the releases because the commercial agenda does not match is unacceptable too. Balance. With this important kdepim release coming up, we need another month. But there are so many pim-developers that the features go hand-in-hand with them. Testing and creating the mobile apps makes sure they run into all kinds of bugs they have to fix and which also apply to the desktop applications. > I get it that lots of stuff is happening in PIM, and I'm really happy > about > that, but we need to keep things sane for others as well, and maintain a > leveled community. Agreed. Again I think we need to consider it as an experiment and let it go for now. We can decide to never do it again in the end if it sucks big time. Best, -- 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: 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
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: Akonadi Meeting: exception request. / Porting Status?
On Mon, 10 May 2010 18:11:24 +0200, Jos Poortvliet wrote: > On Mon, May 10, 2010 at 12:11 PM, Sebastian Kügler wrote: >> Hi PIMsters, > > > >> 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: Akonadi Meeting: exception request. / Porting Status?
On Mon, 10 May 2010 12:11:25 +0200, Sebastian Kügler 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: KDE SC 4.5 schedule
Op Monday 29 March 2010 19:02 schreef u: > On March 27, 2010, Simon Edwards wrote: > > 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 > > the result will be poorer APIs than necessary. those of us working on new API > often do not get critical feedback on API related issues, particularly the > detail oriented sort. already some things leak through and make it into final > releases, despite doing API reviews at the project level (e.g. on plasma- > devel) and subsequently asking for review elsewhere (e.g. k-c-d). the less > time we have to do this, the more warts that will slip through. > > i understand that the ballance point is binding releases, but i question > prioritizing those efforts over the sanitation of the C++ APIs that underly > them. > > if bindings need extra time to release, could we do bindings releases N weeks > after the Development Platform C++ release? this would avoid a trade off > between "rushed bindings" and "more warts in the C++ API". I don't think a separate release from kdebindings is managable in the current team. What we could do is a soft api freeze, where api changes are allowed, but need to be CCMAIL'ed to the kde-bindings ml. And set a hard api freeze (a week before rc1 tagging?) where no api changes are allowed anymore. Could that help? Toma -- 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: KDE SC 4.5 schedule
Op Friday 26 March 2010 21:34 schreef u: > Toma has noted that he won't be available to draft the 4.5 schedule. This is > something that needs to get done. Here's a draft based on the 4.3 schedule to > get us started with: Thanks for that excellent work. I've changed the schedule a bit to reflect the following: This cycle we saw that a beta1 and hard feature freeze at the same date was not optimal. People committing features last minute made packaging beta 1 a nightmare. I've now set the hard feature freeze 1 week before tagging. This cycle we experimented a bit with a message freeze where typo fixes were allowed. I've no made it part of the release schedule by introducing a soft message freeze and a hard message freeze. See techbase page for details. We also experimented with releasing rc's asap after tagging. This went pretty well, though innocent looking commits broke the tarballs. To prevent that, i've introduced a tagging freeze. This means 24h before tagging no commits other than build fixes should be committed. All other commits are not allowed (including showstoppers). Showstoppers should go through reviewboard, so we can determine if it is indeed a showstopper and if it is safe to commit in relation to all platforms we support. Final problem we had this cycle was changing dependencies until late in the schedule. I want to stop that insanity. So I added a dependency freeze at the soft feature freeze time. People should by then know what they want to add as features for that cycle and think about the dependencies they need. During the dependency freeze it is not allowed to introduce new dependencies or raise the version of existing dependencies. I hope you agree to these changes so we can make the schedule final soonish. http://techbase.kde.org/Schedules/KDE4/4.5_Release_Schedule Best, 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: 4.5 schedule on Techbase?
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. Any special wishes let me know! Toma___ 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 02:22 schreef u: > Am Freitag, 19. Februar 2010 01:56:50 schrieben Sie: > > fixed thanks ;) > > So which is the correct version for this cycle? 2.0.2 or 2.0.5? > Kubuntu has 4:2.0.3-kde4.4.0really2.0.2-kde4.4.0-0ubuntu1, which is a bit too > long :). At KDE SC 4.4.1 which will appear in two weeks or so, we will ship 2.0.5. I don't care much how ubuntu calls it, I assume that will be fixed to after this change. Toma -- KDE Developer___ 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: 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: 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 > 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: 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: Porting r1086506 to 4.4.0 tag
PleasOp Monday 8 February 2010 21:05 schreef u: > As in the subject. The commit above (r1086506) is critical for KAuth + polkit- > qt-1 to work, and it should be ported to 4.4.0 tag before release. See the > commit log message. > > Thanks, Can you please check if the tag contains the fix? AFIACS this is already in the tarballs... Best, Toma___ 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: [Nepomuk] kde-4.4, virtuoso-6.1.0, and virtuosoconverter
Op Thursday 4 February 2010 16:02 schreef u: > On 02/04/2010 07:43 AM, Sebastian Trueg wrote: > > Rex Dieter wrote: > >> FYI, > >> http://kde-apps.org/content/show.php/Nepomuk+Virtuoso+Converter > >> > >> 1. The requirements for kde-4.4/nepomuk have changed pretty late in the > >> game (after all 4.4rc's). > > > > No, they did not. I always said that Virtuoso 6 would be the dependency > > for KDE 4.4. You can not add a new dependency for KDE 4.4 the day before the release without testing. I consider it a new feature which is not allowed since ages. for KDE 4.5 I've planned to add it to the release schedule explicitly to make it even more clear. It is too late in the cycle for 4.4 to change this dependency. Really. Some packagers can not add a new dependency to their repository in one day and have prepared the KDE 4.4 packaging based on the 4.4 release candidates we have given them. Please don't do this. > Fact is that we're in a bad situation of now requiring something that's > been untested and it's data is incompatible with what was tested. +1 Unacceptable imho. > > Anyway, the converter is hacky tool allowing early adopters of KDE 4.4 > > who already tries Nepomuk with Virtuoso 5 (and thus, compile > > themselves!) to easily convert their data. Distro's who have provided RC's to their users are now more or less obliged to run that script. Virtuoso was made a hard dependency (at least for anyone compiling kdepim) so all svn users also need to update. Best, Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: kde-4.4, virtuoso-6.1.0, and virtuosoconverter
Op Thursday 4 February 2010 14:15 schreef u: > FYI, > http://kde-apps.org/content/show.php/Nepomuk+Virtuoso+Converter > > 1. The requirements for kde-4.4/nepomuk have changed pretty late in the > game (after all 4.4rc's). That is not allowed. Please revert the offending commit. Best, Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE SC 4.4 RC 3
Op Saturday 30 January 2010 08:44 schreef u: > Am Dienstag, 26. Januar 2010 18:40:04 schrieb Tom Albers: > > 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. > > Are there any major problems we should know about? I don't want to push just > curious. No problem, just Dirk not being around. Guess by now it starts to get useless to still create a RC3. Best, Toma -- KDE Developer___ 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 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
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: KDE 4.4 Beta1 Tagging ahead
Op Monday 7 December 2009 02:58 schreef u: > On Sunday 06 December 2009 9:03:33 am Allen Winter wrote: > > On Tuesday 01 December 2009 9:25:54 am Allen Winter wrote: > > > On Tuesday 01 December 2009 09:17:40 Sebastian Kügler wrote: > > > > On Tuesday 01 December 2009 12:27:50 Sebastian Kügler wrote: > > > > > On Monday 30 November 2009 16:02:28 Allen Winter wrote: > > > > > > On Monday 30 November 2009 09:29:58 Sebastian Kügler wrote: > > > > > > > On Monday 30 November 2009 15:04:05 Allen Winter wrote: > > > > > > > > On Monday 30 November 2009 08:44:28 Dirk Mueller wrote: > > > > > > > > > On Thursday 26 November 2009, Tom Albers wrote: > > > > > > > > > > > want to ship outdated betas, since that makes bughunting > less > > > > > > > > > > > fun. > > > > > > > > > > > > > > > > > > ok, I'll tag tonight Beta1. Okay with everyone? > > > > > > > > > > > > > > > > Not ok with me. > > > > > > > > [...] > > > > Qt 4.6.0 was released today and contains a workaround for this problem. > > > > A > > > > more proper fix went into 4.6.1, so we're peachy. Right? :) > > > > kde-qt master doesn't work . > > offiical Qt4.6.0 doesn't work either. > > > > also there may be an infinite loop in QMap::findNode(). or at least khtml > > is > > going to an infinite loop using QMap someplace. > > > > Kontact trunk is simply unusable. > > > > kdepim is out of the 4.4 release until these issues can be addressed. > > > Good news. > I fixed the the silent KOrganizer killer bug; it turned out that in Qt4.6 > you must initialize a scene rectangle when constructing a QGraphicsScene > or later trying to access the QGraphicsScene rectangle causes all sorts of > problems. > This is apparently a behavior change with Qt 4.6. > > So I feel much better actually being able to run KOrganizer again. > > DBus stuff works too -- apologies to all those I pissed-off. > > Ok, kdepim seems groovy again. That's great news. Can you send a note to kde-packag...@kde.org with the patch in there. I assume packagers would like to include that fix. Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Fwd: Re: KDE/kdelibs/nepomuk/rcgen
Op Tuesday 1 December 2009 08:58 schreef Volker Krause : > Sebastian Trueg wrote: > > > SVN commit 1056485 by trueg: > > > > Fixed pseudo-inheritance implementation for the fast classes > > This seems to break the build of kdepim: > http://my.cdash.org/index.php?project=kdepim > > It apparently creates a class (NepomukFast::Attachment) that inherits from > itself. Reverting this change fixes it. > > regards > Volker Althoug kdepim is no part of beta1, a fix or revert should be included in the beta1. I really hate people breaking stuff on different area's the last couple of days. I suggest we act firmer. For example 2 days before tagging we call out a general commit freeze until tagging is over. During that time only release-team reviewed commits are possible. Best, Toma___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
