Op za 8 sep 2007 15:08 schreef u: > 1) Is kdelibs/kate exempt from the kdelibs freeze on 3 Oct? > [Ed: since the kate application may need to make fixes there]
I agree with Thomas, I don't see an important reason. If there is a critical bug, we should allow it, see below. > 2) Is kdebase/runtime/kstyles exempt from the kdelibs freeze on 3 Oct? > [Ed: since boemann told me that oxygen still needs a couple months] Does he know there hardly isn't a couple of months left? If the Oxygen-style can not make it for 4.0.0, maybe it should be delayed to 4.0.1 or 4.1.0. I mean there is such a hype around Oxygen, I rather wait for a next release and have it perfect, than including it now and it looks bad, that will make bad press. Anyhow, I don't think the style would need to make bic/sic changes, only implementation changes, I think we can allow them a bit longer, but there should be a date where that ends. I would vote to have no exceptions anymore without a date where that exception ends. > 3) Will SC+BC+UC* bugfixes still be allowed after the Total Freezes? > (*UC = Usage Compatible, i.e. non-semantic-changing) > [Ed: I think the real question is how "critical" do the bugs need to be?] After review, yes. Critical bugs are always allowed. We just need to define the word 'critical'. Analog to using the keyword svn_silent in commits, i would define it as 'critical in it's context'. So although a bug in a style is not release critical, it could be critical for that style. Maybe that's to free and that would require the module maintainer's approval. > 4) When is the string freeze? We discussed this before, we could not reach a uniform descision iirc. But I feel a string freeze will force developers to rethink what they are doing. So if I had to decide it would be Oct 3rd. > 5) Should language bindings be part of the development platform? > Richard Dale says "Python and Ruby in good shape by late October, and possibly > C# too." I would follow his plan as he wrote on k-c-d. Toma
_______________________________________________ release-team mailing list [email protected] https://mail.kde.org/mailman/listinfo/release-team
