Re: Heads-up: kdeutils is moving to git
On Sunday, August 21, 2011 17:46:29 Aaron J. Seigo wrote: > kdesrc-build was recommended again .. i took the time tonight (after a long > day in Taipei working on behalf of KDE) to examine it "from scratch" again. > > first the good news: it took me less time to set up this time than in the > past, so it is indeed improving. there is no doubt that it is an impressive > tool. I've been gone for awhile. (Kind of still am, I'm on open Wifi right now...) and so once normal Internet access resumes I'll be able to help on whatever is deemed necessary. I'll even be "on vacation" (though unpacking and doing other moving-related errands) which should help with the timeframe. > * a script / tool to set up kdesrc-build. the config file is much clearer > now, but there are too many little details that require knowledge of how > things work and/or are easy to overlook. a tool that asks questions like > "Where should KDE software be installed?", "Do you have a commit account > for KDE?", etc. and forms an appropriate config file would pull this tool > to within reach of just about everyone There actually used to be just such a tool (an online rc-file creator). I'd like to think it wouldn't be too hard to whip something up in one of those crazy modern Web frameworks or something. An easier thing might be just have kdesrc-build do the asking itself if run without an rc-file. I can see about doing something like that tonight. If anyone has more specific suggestions just let me know. Regards, - Michael Pyne signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Heads-up: kdeutils is moving to git
Like Aaron, I also have the greatest respect for the people doing the migration, I migrated koffice and that took a lot of time and effort (not to mention the many nights that test conversions were run on my only laptop with enough space) The emails were also not read by me to be an objection, more as a signaling that we have an open issue that needs solving. :) (to recap) The issue is that people following kde development previously had to know only a couple of module-names and a repeated update and compile was enough to stay up-to-date. Now people have to manually identify each sub-project and manually browse the projects.kde.org website and manually go a clone of each project. Added repos are almost guarenteed to be missed. On Sunday 21 August 2011 17.46.29 Aaron J. Seigo wrote: > kdesrc-build was recommended again .. i took the time tonight (after a > long day in Taipei working on behalf of KDE) to examine it "from scratch" > again. > > first the good news: it took me less time to set up this time than in the > past, so it is indeed improving. there is no doubt that it is an > impressive tool. Same here, I tried and failed some monts ago, now it seemed to behave better. The README still misses a "how thit works in 3 steps" and I ignored it and typed the command to compile kdeutils. The tool responded by doing a checkout of qt-copy. This is in line with what the description of the tool says; «kdesrc-build is a tool to allow you to easily build KDE from its source repositories. » This, however, is not directly similar to the problem that is being put forward :) Most self-compiler I know don't actually want a full build of KDE, they just want to replace one module with the development version of it. So the tool as it is now is not a natural-match. Maybe it can be changed to do that, but until that date I would say that we still need an automated way to; * allow user to select from all top-level modules. (kdebase, kdeedu etc) * initial checkout of repos * update of all repos and detecting new projects that can be cloned too. * optional are things like detecting new branches and allowing the user to switch to the 4.7 branch once it gets created. -- Thomas Zander ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Heads-up: kdeutils is moving to git
On Friday 19 August 2011, Jeremy Whiting wrote: > I'm looking to migrate kdeaccessibility this weekend also. It's mostly > ready, just polishing it a bit in svn first (making each application build > on its own or part of kdeaccessibility). I'll backport these changes to > the 4.7 branch when it's in git. > > I'm wondering the same thing, kdeaccessibility has a Mainpage.dox (as did > kdeedu before it split) that we are wondering where to keep also, besides > the top CMakeLists.txt for the released tarball. I agree a git repo for > each module makes sense rather than putting this stuff into superbuild > (which I discussed with Allen the other night). So it would be something > like this: > > kdeaccessibility.git (holds CMakeLists.txt, and Mainpage.dox) > -- jovie.git > --kaccessible.git > --kmag.git > --kmousetool.git > --kmouth.git > > with similar setups for kdeedu, kdegraphics, etc. > > On the other hand if Dirk is going to use superbuild to do the release > tarballs we could just "dump" this non-superbuild stuff into there > Mainpage.dox, any top level README, etc. since we need to have module > specific CMakeLists.txt in there anyway for superbuild to work. > > thoughts? What I gathered from the Buildsystem BoF at the Desktop Summit: * Dirk will not use Superbuild * the distros, including Slackware, are ok with fine-grained source tarballs * but, if we break big tarballs into smaller ones, this should be done in a way that the packagers are informed about the situation, and if possible it should not be done in a patch level release. Alex ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Heads-up: kdeutils is moving to git
On 08/21/2011 05:46 PM, Aaron J. Seigo wrote: please keep in mind this is about ensuring our existing and potential contributors can continue to follow what we are doing. I agree this is a super-important goal and I'm sure we can still improve on meeting it. Your kdesrc-build suggestions all sound really good to me. I'm CC'ing mpyne here, I'm sure he'll be interested in at least the optional deps reporting one as a concrete coding task in his codebase. The "interactively generate the config" part I could imagine as being added directly to kdesrc-build, too - say, coming up on first run when there's no rc file around yet. -- Best regards, Eike Hein ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Heads-up: kdeutils is moving to git
On Sunday, August 21, 2011 17:29:22 you wrote: > Do you realize how few people workon doing the thankless and unsexy job of > making these moves happen(I'm not among them, so I'm not defending myself > here) and that itsucks when their motivation gets threatened further by this > kindof response? i apologize if that is how this came across. my goal is and was not to discourage or berate those working on the git migration. rather, i'm very aware of the challenges those trying their best to keep up with KDE development are faced with. i am doing my best to ensure they do not fall behind and away, as has happened previously. i do not expect those doing the migration to produce the solution, but to perhaps give us the time to create them as they need to be. i've communicated in the past what is needed, and those recommendations are based on actual feedback from and interactions with new and old contributors who are failing to keep up with our move to git. while our migrations are opening new horizons, it's also closing existing ones and that's something we can improve on. kdesrc-build was recommended again .. i took the time tonight (after a long day in Taipei working on behalf of KDE) to examine it "from scratch" again. first the good news: it took me less time to set up this time than in the past, so it is indeed improving. there is no doubt that it is an impressive tool. what we need to put the bar low enough: * a script / tool to set up kdesrc-build. the config file is much clearer now, but there are too many little details that require knowledge of how things work and/or are easy to overlook. a tool that asks questions like "Where should KDE software be installed?", "Do you have a commit account for KDE?", etc. and forms an appropriate config file would pull this tool to within reach of just about everyone * a simple recipe on techbase.kde.org stating that this is how to build KDE modules as a casual observer / follower * some small adjustments, such as not following qt-kde in our git repo, but upstream qt, noting when an optional dependency is missing (looking at the perl code, this looks like it should be easy enough) i'm very hestitant to say "i will do this" as i'm already extremely overloaded with Active and my other responsibilities. however, none of the above is overly difficult, so there is the possibility i will do so. don't let that stop anyone else. please keep in mind this is about ensuring our existing and potential contributors can continue to follow what we are doing. it is not a random complaint, nor is it a dodge on the work being done on the git migrations. that work is, in itself, of high quality. how we present and make it available to our broader community is where we (as a community) need to improve on. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Heads-up: kdeutils is moving to git
On Sunday, August 21, 2011 10:11:08 Raphael Kubo da Costa wrote: > Sorry, I'm still trying to understand the goal here: are you thinking of > some sort of shell script that creates a kdeutils directory, clones all the > git repositories and creates a top-level CMakeLists.txt? it doesn't need to be a shell script (see the superbuild repo, for instance), but yes, that is the functionality i'm looking for since its the functionality that will create the least disruption in our community. it's also a way to ensure that people can passively follow a genre of applications in KDE such as utils: when a new util pops up, it can be added to the build by the developers and with the next build, you will "magically" have it added to your set of compiled apps. this is an effect we used to benefit from with the combined big modules and one we have lost (hopefully temporarily) due to the git repo splittings. the last wave of git migrations, done as they were, had a measurably negative impact on contribution that took months for us to recover from. the goal is to avoid repeating that by preserving workflows and keeping the bar as low as possible to keeping up with what is happening in the various topical communities in kde (such as utilities). -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Heads-up: kdeutils is moving to git
On 08/21/2011 05:58 AM, Aaron J. Seigo wrote:
On Sunday, August 21, 2011 00:10:07 Nicolas Alvarez wrote:
Superbuild is unrelated and orthogonal to the code in kdeutils to
allow building as a single module.
yes, and that's the challenge here: it takes ~10 seconds to put a bunch of
"add_subdirectory" calls into a CMakeLists.txt file. the issue is having to
manually keep up a bunch of git repositories individually, from cloning to
pulling, ensuring they are in the correct hierarchy initially on disk, etc.
I'm getting a really weird deja-vu here.
This issue of "how do we deal with sets of repositories" has been
discussed many times over the last four years. Every time it was
discussed, the solution that resulted was "write some kind of tool
to handle them, operating on a master file of repo info". This was
the case even when it was you and Chani who was taking the lead on
the git migration - that's what you guys put into the task wiki for
it.
So that's exactly what we did and have today:
* https://projects.kde.org/kde_projects.xml contains hierarchical
information about projects and their repositories.
* kdesrc-build has support for using the above XML file to under-
stand the notion of "kdeutils" and clone, pull and build it.
kdesrc-build is not something scary. It's a proven, well-documented
tool with a stable and dependable maintainer who has worked on it
for years and has been swift to adapt to new requirements. Dis-
missing it ('"use kdesrcbuild" and similar answers are not good
enough') doesn't make any sense to me. Handling repo sets is a non-
trivial problem that takes work to solve, and that work has been
done here. There's no magic simpler way. Other communities who
have the same kind of problem had to write similar tools (e.g.
Android's "repo" tool).
So ... why are we now pretending that (a) this is a new problem and
(b) the only ever proposed solutions don't already exist?
Further, why is this getting dumped on the fine folks who did the
kdeutils migration? I'm incredibly pissed that what's probably the
smoothest and best-prepated git migration done yet is being buried
under this amount of bitching. Do you realize how few people work
on doing the thankless and unsexy job of making these moves happen
(I'm not among them, so I'm not defending myself here) and that it
sucks when their motivation gets threatened further by this kind
of response?
--
Best regards,
Eike Hein
___
release-team mailing list
release-team@kde.org
https://mail.kde.org/mailman/listinfo/release-team
Re: Re: Heads-up: kdeutils is moving to git
A Diumenge, 21 d'agost de 2011, Nicolás Alvarez vàreu escriure: > On 8/21/11, Aaron J. Seigo wrote: > > On Sunday, August 21, 2011 00:10:07 Nicolas Alvarez wrote: > >> Superbuild is unrelated and orthogonal to the code in kdeutils to > >> allow building as a single module. > > > > yes, and that's the challenge here: it takes ~10 seconds to put a bunch > > of "add_subdirectory" calls into a CMakeLists.txt file. the issue is > > having to manually keep up a bunch of git repositories individually, > > from cloning to pulling, ensuring they are in the correct hierarchy > > initially on disk, etc. > Correct, because that's not the problem it's supposed to solve. The > CMakeLists.txt with add_subdirectory lines is just if someone wants to > make a tarball that works just like the old kdeutils.tar before the > split, ie. "recreate the 'whole module' build". For *that* task, I > think superbuild is the wrong tool. For example, if Dirk makes a > monolithic kdeutils tarball, he should use this instead of superbuild. > > I see superbuild as a third tool in the same category as kdesrc-build > and build-tool, cloning and pulling a bunch of git repositories, > ensuring they are in the correct hierarchy on disk, etc. And it's > probably a good task for that job. > > But this is the release-team list, so here I'm talking about the > release, not the developers' workflow. Jeremy said, "If Dirk is going > to use superbuild to do the release tarballs..."; *that* is what I > think is a bad idea. From what i understood during the release team bof, Dirk is using the scripts in kde-common/release so a repo containing only the CMakeLists.txt file (lie the kde:kdegraphics repo) seems useless to me. Albert > > -- > Nicolas > ___ > 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: Re: Heads-up: kdeutils is moving to git
On Sunday 21 August 2011 05:58:30 Aaron J. Seigo wrote: > On Sunday, August 21, 2011 00:10:07 Nicolas Alvarez wrote: > > Superbuild is unrelated and orthogonal to the code in kdeutils to > > allow building as a single module. > > yes, and that's the challenge here: it takes ~10 seconds to put a bunch of > "add_subdirectory" calls into a CMakeLists.txt file. the issue is having to > manually keep up a bunch of git repositories individually, from cloning to > pulling, ensuring they are in the correct hierarchy initially on disk, etc. > > as such, imho, the kdeutils scratch repo really doesn't help much. Sorry, I'm still trying to understand the goal here: are you thinking of some sort of shell script that creates a kdeutils directory, clones all the git repositories and creates a top-level CMakeLists.txt? ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Heads-up: kdeutils is moving to git
On 8/21/11, Aaron J. Seigo wrote: > On Sunday, August 21, 2011 00:10:07 Nicolas Alvarez wrote: >> Superbuild is unrelated and orthogonal to the code in kdeutils to >> allow building as a single module. > > yes, and that's the challenge here: it takes ~10 seconds to put a bunch of > "add_subdirectory" calls into a CMakeLists.txt file. the issue is having to > manually keep up a bunch of git repositories individually, from cloning to > pulling, ensuring they are in the correct hierarchy initially on disk, etc. Correct, because that's not the problem it's supposed to solve. The CMakeLists.txt with add_subdirectory lines is just if someone wants to make a tarball that works just like the old kdeutils.tar before the split, ie. "recreate the 'whole module' build". For *that* task, I think superbuild is the wrong tool. For example, if Dirk makes a monolithic kdeutils tarball, he should use this instead of superbuild. I see superbuild as a third tool in the same category as kdesrc-build and build-tool, cloning and pulling a bunch of git repositories, ensuring they are in the correct hierarchy on disk, etc. And it's probably a good task for that job. But this is the release-team list, so here I'm talking about the release, not the developers' workflow. Jeremy said, "If Dirk is going to use superbuild to do the release tarballs..."; *that* is what I think is a bad idea. -- Nicolas ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Heads-up: kdeutils is moving to git
On Sunday, August 21, 2011 00:10:07 Nicolas Alvarez wrote: > Superbuild is unrelated and orthogonal to the code in kdeutils to > allow building as a single module. yes, and that's the challenge here: it takes ~10 seconds to put a bunch of "add_subdirectory" calls into a CMakeLists.txt file. the issue is having to manually keep up a bunch of git repositories individually, from cloning to pulling, ensuring they are in the correct hierarchy initially on disk, etc. as such, imho, the kdeutils scratch repo really doesn't help much. -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Heads-up: kdeutils is moving to git
Yury G. Kudryashov wrote: > Thomas Zander wrote: >> What do others think about a solution of that kind? >> And is it applicable to our other (former) modules too? > > There is a "superbuild" script; you can find details in kde-buildsystem > ML. Superbuild is unrelated and orthogonal to the code in kdeutils to allow building as a single module. -- Nicolas ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Heads-up: kdeutils is moving to git
Raphael Kubo da Costa writes: > Hello there, > > kdeutils is currently in the last stages of its migration to git: the > repositories have been created and I will do the initial pushes soon > (but probably not tomorrow, as I'll spend most of the day flying back to > Brazil). > > The applications are all going to have separate repositories, but there > are no dependencies between the applications (ie. there is no > libkdeutils). > > Nicolás Alvarez and I have recently done some changes to the buildsystem > so that it is possible to build kdeutils both as a whole module or each > application individually, so the 4.7 branch workflow does not need to be > changed (I don't know how Dirk is going to create the tarballs, though). > > If there are objections or blocking questions, please post them here > asap, otherwise I think the migration should be finished during the > weekend. kdeutils has finished moving to git; I have done the initial pushes to all repositories and svn only has a MOVED_TO_GIT file. As for the concerns about being able to build everything as a single module, I've created a scratch git repository [1] containing the files that used to be in the top-level kdeutils directory in SVN, including CMakeLists.txt. I am open to where to put these instructions in TechBase or anywhere else you think they are needed. [1] $ git clone kde:scratch/rkcosta/kdeutils-toplevel ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Heads-up: kdeutils is moving to git
I'm looking to migrate kdeaccessibility this weekend also. It's mostly ready, just polishing it a bit in svn first (making each application build on its own or part of kdeaccessibility). I'll backport these changes to the 4.7 branch when it's in git. I'm wondering the same thing, kdeaccessibility has a Mainpage.dox (as did kdeedu before it split) that we are wondering where to keep also, besides the top CMakeLists.txt for the released tarball. I agree a git repo for each module makes sense rather than putting this stuff into superbuild (which I discussed with Allen the other night). So it would be something like this: kdeaccessibility.git (holds CMakeLists.txt, and Mainpage.dox) -- jovie.git --kaccessible.git --kmag.git --kmousetool.git --kmouth.git with similar setups for kdeedu, kdegraphics, etc. On the other hand if Dirk is going to use superbuild to do the release tarballs we could just "dump" this non-superbuild stuff into there Mainpage.dox, any top level README, etc. since we need to have module specific CMakeLists.txt in there anyway for superbuild to work. thoughts? Jeremy On Fri, Aug 19, 2011 at 5:37 AM, Yury G. Kudryashov wrote: > Thomas Zander wrote: > > > What do others think about a solution of that kind? > > And is it applicable to our other (former) modules too? > There is a "superbuild" script; you can find details in kde-buildsystem ML. > -- > Yury G. Kudryashov, > mailto: ur...@mccme.ru > > ___ > 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: Heads-up: kdeutils is moving to git
Thomas Zander wrote: > What do others think about a solution of that kind? > And is it applicable to our other (former) modules too? There is a "superbuild" script; you can find details in kde-buildsystem ML. -- Yury G. Kudryashov, mailto: ur...@mccme.ru ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Heads-up: kdeutils is moving to git
On Thursday 18 August 2011 22.21.46 Raphael Kubo da Costa wrote: > Basically, the current CMakeLists.txt in svn can still be used, but aneven smaller version which just does a series ofmacro_optional_add_subdirectory() calls. Going back to Aaron'smessage, where should I put these instructions? Is there a kdeutils.git repo where this can be put? I fully agree with Aarons message; the amount of time spent tracking down sub- projects and their git checkout line is a big cause of worry for me too. I had had the wish in the past to have a simple repo for a (former) module like kdeutils, and kdegraphics etc and that that module would have at minimum a script to do the checkout of the other repositories. What do others think about a solution of that kind? And is it applicable to our other (former) modules too? ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Heads-up: kdeutils is moving to git
On Thu, Aug 18, 2011 at 5:53 AM, Sebastian Kügler wrote: > We also need this from the release team POV. So if you move, please > > - don't do it too shortly before tagging a patchlevel release I'm planning on doing it this weekend, which is a bit less than 2 weeks than the tagging of 4.7.1. Would that be enough? > - let us know how we can reassemble the tarball for our release > > Please check with Dirk wether it works or not, as to cause as little > disruption to our release process as possible. But you know all that, since > you've taken part in all those discussions =) Basically, the current CMakeLists.txt in svn can still be used, but an even smaller version which just does a series of macro_optional_add_subdirectory() calls. Going back to Aaron's message, where should I put these instructions? Dirk, do you need me to do anything specific for your tarballing needs? ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Heads-up: kdeutils is moving to git
On Thursday, August 18, 2011 07:47:56 Aaron J. Seigo wrote: > On Wednesday, August 17, 2011 19:30:59 Raphael Kubo da Costa wrote: > > The applications are all going to have separate repositories, but there > > are no dependencies between the applications (ie. there is > > nolibkdeutils). > > please document clearly and publicly how to fetch and build the new set of > repositories as one module. > > in the past modules that have split up like this have done so with no > documentation as to how to recreate the "whole module" build easily which > has resulted in the loss of people who previously were regularly buliding > the software. > > "use kdesrcbuild" and similar answers are not good enough, either: we need > simple, straight-forward, copy-and-paste recipes to pass on to those who > follow KDE from sources. > > if there is no such documentation then i'll have to object to the splitting > of this module. we've done enough damage to ourselves with the "split and > worry about it later" approach. > > thanks for your understanding ... We also need this from the release team POV. So if you move, please - don't do it too shortly before tagging a patchlevel release - let us know how we can reassemble the tarball for our release Please check with Dirk wether it works or not, as to cause as little disruption to our release process as possible. But you know all that, since you've taken part in all those discussions =) Cheers, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Heads-up: kdeutils is moving to git
On Wednesday, August 17, 2011 19:30:59 Raphael Kubo da Costa wrote: > The applications are all going to have separate repositories, but there are > no dependencies between the applications (ie. there is nolibkdeutils). please document clearly and publicly how to fetch and build the new set of repositories as one module. in the past modules that have split up like this have done so with no documentation as to how to recreate the "whole module" build easily which has resulted in the loss of people who previously were regularly buliding the software. "use kdesrcbuild" and similar answers are not good enough, either: we need simple, straight-forward, copy-and-paste recipes to pass on to those who follow KDE from sources. if there is no such documentation then i'll have to object to the splitting of this module. we've done enough damage to ourselves with the "split and worry about it later" approach. thanks for your understanding ... -- Aaron J. Seigo humru othro a kohnu se GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE core developer sponsored by Qt Development Frameworks signature.asc Description: This is a digitally signed message part. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Heads-up: kdeutils is moving to git
Hello there, kdeutils is currently in the last stages of its migration to git: the repositories have been created and I will do the initial pushes soon (but probably not tomorrow, as I'll spend most of the day flying back to Brazil). The applications are all going to have separate repositories, but there are no dependencies between the applications (ie. there is no libkdeutils). Nicolás Alvarez and I have recently done some changes to the buildsystem so that it is possible to build kdeutils both as a whole module or each application individually, so the 4.7 branch workflow does not need to be changed (I don't know how Dirk is going to create the tarballs, though). If there are objections or blocking questions, please post them here asap, otherwise I think the migration should be finished during the weekend. ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
