Kioslave repos

[Kevin Ottens]

Hello,

On Friday 11 April 2014 01:33:54 Aurélien Gâteau wrote:
> > The problem is manpower, we do not have the manpwoer to maintain half o
> > the things we have in the workspace, most of the things in there are
> > half-cooked or they do not even work (kglobalaccel kcm)

For the record, it works in 4 that particular one, I use it...

> > and instead of
> > taking a breath and decide what we want and what we do not want (like we
> > did in the sprint) we are just blindly moving forward and making things
> > compile that no developers care about. This has to stop. This must stop.
> 
> I agree with your analysis of the problem but not with your solution. If
> it's broken, should not be shipped and is unmaintained then be bold and
> either delete it or move it to our dead code cemetery.

... and that's why I disagree with both the analysis and the solution. Because 
it seems the analysis is very weak in the first place. The fact that from one 
mail to the next we shift in different exhibited examples avoiding general 
rules is telling IMO.

I'm concerned there's no criteria set but feelings (I don't want to maintain 
it because of its ugly face)[*]. That's the best way to create problems like 
our previous major workspace release.

And I agree with what was previously said of not rubbing stuff under the 
carpet. I'm not saying nothing should be moved to the dead code area of 
course. It is justified to move code in such an area if it's broken *and* not 
causing important user regressions on removal. If it's just broken it should 
be repaired and eventually obsoleted responsibly later on.

Regards.

PS: Of course I could be totally wrong and there's been a strong analysis 
where general rules got set and you're in fact following that. Then it's just 
that I see no real evidence of it (which could be worsened by the way we 
structured our wikis).

PPS: And obviously, even if I'm right, the product can turn out OK in the end 
by chance. That would still be taking a huge risk with one of the main 
community assets though, I'm all for reducing this kind of risks.

[*] I admit we had it easier in kdelibs as lxr could help reduce the part of 
feelings and check our criteria... and even there we stumbled and screwed up a 
few times.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140411/66c44b1e/attachment.sig>