From kde-active Sat Dec 17 17:35:34 2011 From: Stefan Werden Date: Sat, 17 Dec 2011 17:35:34 +0000 To: kde-active Subject: RE: Lessons for PA3 Message-Id: <83405d230a3ebde95d5b65685229fd35 () open-slx ! com> X-MARC-Message: https://marc.info/?l=kde-active&m=132414345219516 On Fri, 16 Dec 2011 14:57:12 +0100, Thomas Pfeiffer wrote: >> I'm actually thinking of something like a week between code freeze >> and >> release. With a longer cycle (7 instead of 2 months), that's >> relatively >> bearable, I tend to think -- and really, having everything ready two > days in >> advance doesn't really hurt anyone, or does it?) > > What about betas and RCs? As PA grows, I don't think we can rely on > ourselves to do > all the testing, so why not do it like most FOSS projects I know do? So currently it was not possible to do any RC-Image. Most of the changes were done in the last weeks. RC implying milestones that could be used to create images. So no problem, but this probably hurts upstream development. Most of the important test will be done by the integrators. The advantage of the public RC is, that we can hope to catch much more use cases. But this no automtism. For example on Linux distri most of the testing stuff is focused on installation and this was done by integrators anyway. So we need to carefully look at the feedback. Of cause public RCs would be nice to have > I know those cost extra time, but I'd still prefer to do them. We > don't > need to > start shipping the first beta months before release, but maybe a few > weeks > of public > testing could already help? If we have the right processes of bugfixing it will definitly help. > > Plus there is another thing we should definitely do with PA3: Proper > upgrade tests. > Things like https://bugs.kde.org/show_bug.cgi?id=289103 , could be > avoided > if there was enough time to do a as-realistic-as-possible upgrade > test > before release. Upgrade needs special expertise. I'm not sure if PA-Team can handle this topic on PA3 or may be every. The progress on PA is still very high and we all need to be open to optimize architectural improvements or API changes. Guaranty an upgrade in such situation is very difficult and time consumption. > > Apart from that, I agree with all points brought up so far. I'd > prefer > waiting > longer until the next release if the quality is better and even as a > non-developer I > feel awkward about doing many patches to kdelibs and kde workspace, > so > synching with KDE SC sounds like a good idea to me as well. I fell PA should continue with its own speed and should not build up constraints. kdelibs are redesigned in a different project to get them smaller. So such a binding does not make sense for me. But I could be wrong. > > Regards, > Thomas > > _______________________________________________ > Active mailing list > Active@kde.org > https://mail.kde.org/mailman/listinfo/active _______________________________________________ Active mailing list Active@kde.org https://mail.kde.org/mailman/listinfo/active