Hi folks,
So happily after Lenny is released we will move with KDE 4.2 to unstable. Here
is some drafts plans of how i think we could do it (without breaking too much
stuff)
for starting to discuss about it.
I do not know if it will be 4.2.0 or 4.2.1 but that is not very important
here.
Important things to decide|do before:
- pkg-kde SVN cleanup and re-order (branches/kde4.2 to trunk, current trunk to
branches/lenny/ and maybe move some stuff to attic).
- Decide if keep .kde4 or move to .kde. (already in progress)
- Write documentation of how to package KDE 4 applications. It is nice and
hopefully it will be help to avoid crappy packaging.
- Write pseudo-policy for naming space (plasmoid, artwork, etc). (already in
progress)
- Write some nice guide of how to report KDE bugs for Debian users, with
special emphasis about how upstream bugs are better in the KDE bugzilla.
- Ask the release team what are they plans for transitions-queue post-lenny,
maybe it is a good idea wait to do anything until for example, the glibc
transition is done ... (Hi Marc)
- Mail to d-d-a with proper links with the important info for another
developers/maintainers.
- Something else?
Steps:
- Update b-d (aka krap & friends) in unstable: cmake, eigen, phonon,
soprano,
strigi, akonadi, automoc, ...
- Update the KDE 4.0 development platform in unstable with the KDE 4.2
packages (yes, kde4libs, kdepimlibs and kdebase-runtime). Then:
- Update kde3 apps that have a KDE 4 equivalent ready: amarok, rsibreak,
yakuake, ktorrent, ...[1] Encourage people who are not in any of the KDE
teams to do it it (i.e. kmldonkey, kdiff3, yes [1] and file wish-list bugs).
The stuff that needs more than the development platform will have to wait
a bit.
- File for removal of all the stuff that does not make sense anymore with
KDE 4 as default KDE (like kompose, kdeaddons, kde-i18n, kalgebra...).
Again [1]
- Look at the stuff that is depending / recommending / suggests kde3 parts
that won''t be covered by KDE-legacy. There is for example, packages
that
build depend on kdepim3 libraries... Yes [1]
- Also, in parallel, start some QA-ing for remove qt3 and kde3 stuff from the
archive that is buggy, dead upstream, better new equivalent in KDE 4...
No list to be made here, it will be done little to little through all the
transition, i think.
- Upload KDE-legacy stuff. I would prefer here as new source packages with the
suffix -legacy, at least it is needed for kdebase because there is already a
KDE 4''s kdebase. kdelibs3-legacy and kdebase3-legacy ?
- Upload the rest of KDE 4.2.x (no much later that the previous step, or not
KDE installable in unstable! :D )
- Reintroduce kde 3 apps standalone that we think it is work it (at least pino
wanted to package kregexpeditor). The less here, the better.
- Fix whatever needs to be fixed after replace KDE 3 with KDE-legacy. We can
not really detect this previously and we''ll have mostly to wait for
bug reports
here.
- Profit.
Ideas? Suggestions? A better way of doing it?
I am sorry it is not so elaborated as I would have liked but I will be
networkless the next days and I wanted to send it already.
Ana
[1] A list of packages should be done at some point.
On Wed, 4 Feb 2009 02:38:28 +0100 Ana Guerrero <ana at debian.org> wrote:>- Reintroduce kde 3 apps standalone that we think it is work it (at leastpino> wanted to package kregexpeditor). The less here, the better. >I repackaged kdvi for Kubuntu because of (I think it was) inverse search funtions that a class of users found important and weren''t available with the KDE4 tools in 4.1. Perhaps that has changed, but it''s one to consider. Scott K
On Wednesday 04 February 2009 02:38:28 Ana Guerrero wrote:> Hi folks, > > So happily after Lenny is released we will move with KDE 4.2 to unstable. > Here is some drafts plans of how i think we could do it (without breaking > too much stuff) for starting to discuss about it. > I do not know if it will be 4.2.0 or 4.2.1 but that is not very important > here. > > > Important things to decide|do before: > > - pkg-kde SVN cleanup and re-order (branches/kde4.2 to trunk, current trunkI guess I can try do that next week(end) if it is just a matter of svn mv things around. A good way to celebrate lenny.> - Write documentation of how to package KDE 4 applications. It is nice and > hopefully it will be help to avoid crappy packaging. > - Write pseudo-policy for naming space (plasmoid, artwork, etc). (already > in progress)These two is both in progress as "kde-policy-draft" located at http://alioth.debian.org/~pusling-guest/kde-policy.pdf or in people/sune/doc in your favourite pkg-kde svn. Comments is welcome, but I would prefer people starting a seperate thread on this, and I also prefer for now to recieve comments and patches and to commit myself.> - Write some nice guide of how to report KDE bugs for Debian users, with > special emphasis about how upstream bugs are better in the KDE bugzilla.I don''t think this is a blocker in any way.> - Ask the release team what are they plans for transitions-queue > post-lenny, maybe it is a good idea wait to do anything until for example, > the glibc transition is done ... (Hi Marc)I think we deserve a quite high place in the queue.> - Update the KDE 4.0 development platform in unstable with the KDE 4.2 > packages (yes, kde4libs, kdepimlibs and kdebase-runtime). Then:I would put "upload kde4.2" here and then afterwards sort out third party apps.> - Update kde3 apps that have a KDE 4 equivalent ready: amarok, rsibreak, > yakuake, ktorrent, ...[1] Encourage people who are not in any of the KDE > teams to do it it (i.e. kmldonkey, kdiff3, yes [1] and file wish-list > bugs). The stuff that needs more than the development platform will have to > wait a bit. > - File for removal of all the stuff that does not make sense anymore with > KDE 4 as default KDE (like kompose, kdeaddons, kde-i18n, kalgebra...).adding most (of my) kwin-style* to the list.> Again [1] > - Look at the stuff that is depending / recommending / suggests kde3 > parts that won''t be covered by KDE-legacy. There is for example, packages > that build depend on kdepim3 libraries... Yes [1]There is a set of apps that depend on weird binaries/libraries from weird packages. Most of them is plugins or addons to existing things, for example the basket kontact plugin, so these should just go.> - Also, in parallel, start some QA-ing for remove qt3 and kde3 stuff from > the archive that is buggy, dead upstream, better new equivalent in KDE 4... > No list to be made here, it will be done little to little through all the > transition, i think. > > - Upload KDE-legacy stuff. I would prefer here as new source packages with > the suffix -legacy, at least it is needed for kdebase because there is > already a KDE 4''s kdebase. kdelibs3-legacy and kdebase3-legacy ?This can also wait. people can live without kcontrol for some time. and no need to rename kdelibs source package. (or do you want to rename kde4libs source package ?) I would definately not make it a blocker for any thing.> - Upload the rest of KDE 4.2.x (no much later that the previous step, or > not KDE installable in unstable! :D )> Ideas? Suggestions? A better way of doing it?if I was to plan it, I_would just upload krap/support, wait a day or two, and then slowly upload kde4.2 as we would upload any other kde release. (no one prevents maintainers of 3rd party apps to also do something here, like fixing their own packages) Fix the issues that shows and do aggressive package removal from testing to get kde4.2 into testing. Let those who want to do kde3base packages do it and sponsor if needed. Go over the packages removed from testing and have the maintainer fix them, NMU them or remove them from the archive. We will break some packages no matter what way we do it, and I really don''t think.> I am sorry it is not so elaborated as I would have liked but I will be > networkless the next days and I wanted to send it already.Thanks for making sure to send it out already. If we could get some dates on when we could do it, I expect both to take around a week, I at least would try to clear up big parts of my calendar for that week. /Sune -- Man, how to insert on the device from Office? You cannot cancel a LCD program to digit from the serial firewall of the digital menu to a wordprocessor.
On Wed, Feb 04, 2009 at 09:08:44AM +0100, Sune Vuorela wrote:> On Wednesday 04 February 2009 02:38:28 Ana Guerrero wrote: > > > > Important things to decide|do before: > >... After reading Sune''s reply, I want to mention this was not a list of blockers or "problems" to resolve, just a list of actions we need to do. Agreed about continue discussion about "kde-policy-draft" in another thread. At least I have pending to send a email with my comments about that. About the steps:> > > - Update the KDE 4.0 development platform in unstable with the KDE 4.2 > > packages (yes, kde4libs, kdepimlibs and kdebase-runtime). Then: > > I would put "upload kde4.2" here and then afterwards sort out third party > apps. >I think this can be done with some order, making things easier to everybody who needs to coordinate with us. Specially if that can minimize the number of transitions we can get caught or we can stall.> > - Upload KDE-legacy stuff. I would prefer here as new source packages with > > the suffix -legacy, at least it is needed for kdebase because there is > > already a KDE 4''s kdebase. kdelibs3-legacy and kdebase3-legacy ? > > This can also wait. people can live without kcontrol for some time. and no > need to rename kdelibs source package. (or do you want to rename kde4libs > source package ?) > > I would definately not make it a blocker for any thing. >It is not a blocker, but I do not see why it needs to wait? Actually it could be uploaded in any time if the source package name is different (will need conflcits with current stuff) and people will be able to check their kde3 stuff/packages work with the legacy packages. For sure, this will depend heavily on when people working on it considers it is ready.> > - Upload the rest of KDE 4.2.x (no much later that the previous step, or > > not KDE installable in unstable! :D ) > > > > Ideas? Suggestions? A better way of doing it? > > if I was to plan it, I_would just upload krap/support, wait a day or two, and > then slowly upload kde4.2 as we would upload any other kde release. >That is more or less what i am suggesting, but just with some more delay between libraries and rest of the stuff: - krap/support - 2-3 days - kde4libs/kdepimlibs/-runtime - between 4-6 days - the rest.> (no one prevents maintainers of 3rd party apps to also do something here, like > fixing their own packages) >yeah, sure.> Fix the issues that shows and do aggressive package removal from testing to > get kde4.2 into testing. >I think here is mostly where we differ, i see you approach is more agressive than mine and getting it just done in the less time possible. I believe it can be planned, inform people about plans and get people coordinating/doing their stuff after we provide them the info they need. It might need more time but I think it will make things more smoothy. I do not see any advantage of hurrying stuff here, we have time and usually hurries make you make silly mistakes.> Let those who want to do kde3base packages do it and sponsor if needed. >sure.> Go over the packages removed from testing and have the maintainer fix them, NMU > them or remove them from the archive. >Again, i think if you inform, give time frames etc, no-MIA maintainers will respond and do their stuff.> We will break some packages no matter what way we do it, and I really don''t > think. >you do not think... what? I agree we''ll break stuff, but it can be minimized.> If we could get some dates on when we could do it, I expect both to take > around a week, I at least would try to clear up big parts of my calendar for > that week. >What do you mean here with "both" ? I do not think it will just take a week, but again I am suggesting a much more "quiet" strategy here. Ana
On Wednesday 04 February 2009 10:11:49 Ana Guerrero wrote: [snip kdebase legacy]> It is not a blocker, but I do not see why it needs to wait? Actually it > could be uploaded in any time if the source package name is different (will > need conflcits with current stuff) and people will be able to check their > kde3 stuff/packages work with the legacy packages. > For sure, this will depend heavily on when people working on it considers > it is ready.I just wanted to make sure that we wasn''t planinng on waiting on this step before proceeding with the next step. And I agree it depend on the people working on it, but it can come "at any time", before or after going kde desktop.> > Fix the issues that shows and do aggressive package removal from testing > > to get kde4.2 into testing. > > I think here is mostly where we differ, i see you approach is more > agressive than mine and getting it just done in the less time possible. II''m expecting that we will be blocking quite some testing migration - and the set of packages that needs changes do not differ. Maybe release team (hi marc ;) could tell if they want it fast and more messy or slowly and more quiet. A big chunk of the problematic packages are the ones that uses more of kde than kdelibs (everything that just uses kdelibs kde3 can stay untouched as before) It is a total of around ~50 packages, of these 15 is window decorations and stuff, some have unneded build dependencies on kdebase-dev when they only use kdelibs, some are plugins for kde3 apps and left is only a few apps with their versions in experimental and final, the problematic list: boson tellico taskjuggler (fathi promised to take action, so not that problematic) lurker (wtf?) and a few bugs have been filed already for some other issues. I will send out the full list after a bit of modifications and a bit more research. Or maybe try *urgh* to use a wiki page.> > We will break some packages no matter what way we do it, and I really > > don''t think. > > you do not think... what?heh. funny ;) My kmail was doing tricks on me.> I agree we''ll break stuff, but it can be minimized. > > > If we could get some dates on when we could do it, I expect both to take > > around a week, I at least would try to clear up big parts of my calendar > > for that week. > > What do you mean here with "both" ?"both" as in the way you describe and in the way I describe, at least where it conflicts.> I do not think it will just take a week, but again I am suggesting a much > more "quiet" strategy here.I just see the quiet, slow strategy as the long and painful approach and thus prefer to get it done with immediately. /Sune -- Man, do you know how may I remove a login? You can never send to the e-mail address for overclocking the LCD operating system on the USB BIOS port of a periferic of the shell.
Enrique Matías Sánchez (Quique)
2009-Feb-10 11:08 UTC
[DRAFT for discussion] KDE 4.2 upload to unstable
On Wed, Feb 4, 2009 at 2:38 AM, Ana Guerrero wrote:> - Reintroduce kde 3 apps standalone that we think it is work it (at least pino > wanted to package kregexpeditor). The less here, the better.I''d suggest KBabel here, because Lokalize is not yet on par with it.
On Wed, 04 Feb 09 10:11, Ana Guerrero wrote:> On Wed, Feb 04, 2009 at 09:08:44AM +0100, Sune Vuorela wrote: > > On Wednesday 04 February 2009 02:38:28 Ana Guerrero wrote: > > > > - Upload KDE-legacy stuff. I would prefer here as new source packages with > > > the suffix -legacy, at least it is needed for kdebase because there is > > > already a KDE 4''s kdebase. kdelibs3-legacy and kdebase3-legacy ? > > > > This can also wait. people can live without kcontrol for some time. and no > > need to rename kdelibs source package. (or do you want to rename kde4libs > > source package ?) > > > > I would definately not make it a blocker for any thing.> It is not a blocker, but I do not see why it needs to wait? Actually it could > be uploaded in any time if the source package name is different (will need > conflcits with current stuff) and people will be able to check their kde3 > stuff/packages work with the legacy packages. > For sure, this will depend heavily on when people working on it considers it is > ready.Agreed. Didn''t someone already start to work on this? I remember something...> > > - Upload the rest of KDE 4.2.x (no much later that the previous step, or > > > not KDE installable in unstable! :D ) > > > > > > > Ideas? Suggestions? A better way of doing it? > > > > if I was to plan it, I_would just upload krap/support, wait a day or two, and > > then slowly upload kde4.2 as we would upload any other kde release. > > > That is more or less what i am suggesting, but just with some more delay > between libraries and rest of the stuff: > - krap/support > - 2-3 days > - kde4libs/kdepimlibs/-runtime > - between 4-6 days > - the rest. > > > (no one prevents maintainers of 3rd party apps to also do something here, like > > fixing their own packages) > > > yeah, sure. > > > Fix the issues that shows and do aggressive package removal from testing to > > get kde4.2 into testing. > > > > I think here is mostly where we differ, i see you approach is more agressive than > mine and getting it just done in the less time possible. I believe it can be > planned, inform people about plans and get people coordinating/doing their > stuff after we provide them the info they need. It might need more time but I > think it will make things more smoothy. > I do not see any advantage of hurrying stuff here, we have time and usually > hurries make you make silly mistakes.I''m here with Ana. I guess we will end up with what the release team wants us to do ;-). But uploading all the kdesupport stuff quite soon won''t harm anyone. Greetings, Armin> > > > Let those who want to do kde3base packages do it and sponsor if needed. > > > sure. > > > Go over the packages removed from testing and have the maintainer fix them, NMU > > them or remove them from the archive. > > > > Again, i think if you inform, give time frames etc, no-MIA maintainers will > respond and do their stuff. > > > We will break some packages no matter what way we do it, and I really don''t > > think. > > > you do not think... what? > I agree we''ll break stuff, but it can be minimized. > > > > If we could get some dates on when we could do it, I expect both to take > > around a week, I at least would try to clear up big parts of my calendar for > > that week. > > > > What do you mean here with "both" ? > I do not think it will just take a week, but again I am suggesting a much more > "quiet" strategy here. > > Ana > > -- > http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk