[DRAFT for discussion] KDE 4.2 upload to unstable

[Ana Guerrero]

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