[DRAFT for discussion] KDE 4.2 upload to unstable

[Armin Berres]

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