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 trunk

I 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 

>   - 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 

> 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.

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.


Reply via email to