pkg kde talk - Feb 2009 - [DRAFT for discussion] KDE 4.2 upload to unstable

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 least 
pino
>  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 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
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. I
I''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.

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