From kde-core-devel Wed Jul 10 15:55:42 2013 From: =?ISO-8859-1?Q?=C0lex?= Fiestas Date: Wed, 10 Jul 2013 15:55:42 +0000 To: kde-core-devel Subject: Re: Releases in 3 months Message-Id: <4911898.5aYaZIXFPL () monsterbad> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=137347187123889 On Tuesday 09 July 2013 16:12:35 Andras Mantia wrote: > Two point I want to mention: > 1) working in a branch for kdepim is quite painful, as you need actually > work on branches of 3 (or sometimes 4) modules: kdepimlibs, kdepim-runtime, > kdepim (and akonadi). Keep them up-to-date, merge them at the right point, > etc. Developing in master is *much* easier. I do this web KDE-Accounts integration, it is more painful but doable, not like the month is ending like it was with svn. > 2) some people don't like branches, we have to understand it. :) There is no > one schedule that will fit all, that's sure. But dismissing once preference > with a way that tells him how he SHOULD do, is not really a good. Developing big features in master is even disrespectful to your fellow developers, countless time things have broken because of this and people have not been able to use master as their work environment. I could understand it for small things, and in the case you are an exceptional developer that does not make mistakes and tests everything before pushing. So maybe we can find a compromise? what about: Features can be developed in master, if they are big or delicate just add compile option to remove them for release. This way we can we could even add something like cmake -DDISABLE_WIP_FEATURES And then leave this up to each module developers to decide whether this way of working is acceptable for them or not. What do you think? > I also find the motivation somewhat contradictory. Yes, you want to provide > new features faster, but by cutting down testing time. *Are you sure?* Testing time by whom? we will be cutting not even a month of user testing (according to 4.11 schedule).