Lessons for PA3

Stefan Werden stefan.werden at open-slx.de
Sat Dec 17 17:35:34 UTC 2011


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 at kde.org
> https://mail.kde.org/mailman/listinfo/active



More information about the Active mailing list