[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwin
Subject:    Re: backporting policy?
From:       Martin =?iso-8859-1?q?Gr=E4=DFlin?= <kde () martin-graesslin ! com>
Date:       2010-11-23 18:51:32
Message-ID: 201011231951.40271.kde () martin-graesslin ! com
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday 23 November 2010 18:39:32 Thomas Lübking wrote:
> Hi,
> 
> i've frankly no idea on KDE's backporting policy*, nor where to read (gg
> reported a "draft") about it - also 4.6 isn't faaaar away, so i guess it's
> not that important to backport each and every bit
I think there are no real rules, except only bug fixes and has to be 
regression free (at least distros expect this). My personal rule is trivial 
fixes go to branch directly, everything else the 14 days trunk rule (don't 
think it actually exists) and then only small changes
> 
> Candidates:
> --------------------
> 
> I think it should be ok to backport [1], despite it's theoretically a
> behavioural change. (pre raise fullscreen)
behavioural change should be 4.6
> 
> I guess [2] is just "ok". (dangeling pointer in desktopgrid)
that's ok
> 
> Then there's a request to backport [3] which is a severe bug, but the
> backport would be risky because nobody seems to actually know about the
> sync protocol...
yeah, so it's 4.6
> 
> [4] Is nasty, but has been for years ;-) (modal window behaviour)
would also say 4.6
> 
> [5] Should be ok, but breaks the 14 day rule (slideback freaks up clipping)
should be ok
> 
> I don't care about tabbing, but [6] should be safe as well (clientgroup
> pointer in bridge.cpp)
should be ok
> 
> Also i think we could formally backport [7] & [8], but they're pretty huge
> *shrug* (general glide & sheet implementation pattern)
that's more a rewrite, let's consider "no leaks" as feature ;-) so 4.6
> 
> Sorry for being such a wiener, but just cannot decide this (lacking
> knowledge and resposibility) - so i need a checked list in return or at
> least a reliable "do & do not" list for KDE/kwin backporting that i can
> stick to... Otherwise i'm as well fine with no backporting at all (i'd
> rather just change KDEs release strategy, but that's off topic)
The only piece I found is 
http://techbase.kde.org/Policies/SVN_Commit_Policy#Backport_bugfixes

which is not really a policy. Yeah that is kind of missing and most KDE SC 
modules seem to not backport a lot (or are missing filling out the changelog, 
which is not that much work). Kind of a pity :-( I hope git will change that a 
bit as you can much easier switch branches.

Martin

["signature.asc" (application/pgp-signature)]

_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin


[prev in list] [next in list] [prev in thread] [next in thread]