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 -- http://lists.alioth.debian.org/mailman/listinfo/pkg-kde-talk