Working on two versions in parallel

Mark Kretschmann kretschmann at kde.org
Wed Dec 9 20:36:17 CET 2009


On Wed, Dec 9, 2009 at 5:00 PM, Leo Franchi <lfranchi at kde.org> wrote:
> On Wed, Dec 9, 2009 at 6:15 AM, Mark Kretschmann <kretschmann at kde.org>
> wrote:
>>
>> On Wed, Dec 9, 2009 at 11:53 AM, Nikolaj Hald Nielsen
>> <nhnfreespirit at gmail.com> wrote:
>> >> One of our problems with 2.2.2 currently is that we're in string (and
>> >> feature) freeze, so many patches, ideas, and Merge Requests are on
>> >> hold. What if we created a 2.2.3 branch, and started to work on two
>> >> versions in parallel, before 2.2.2 is actually tagged?
>> >
>> > I don't think this is a good idea for a couple of reasons.
>> >
>> > What would happen is the same that always happens when we have a
>> > stable branch and a "fun" feature branch. We are all suckers for cool
>> > new features, so the feature branch is what everyone will end up
>> > running, meaning that there is less focus on fixing bugs in the stable
>> > branch and less overall testing of it.
>>
>> Well, I see your point, and I agree that there is a risk of losing
>> focus on what is important (getting the current release done).
>>
>> But let me give you a practical example:
>>
>> In the Collection settings, we have this button "Import Collection". I
>> think we had discussed this before, and the problem with it is that
>> it's a bit of a misnomer (doesn't import the collection, but rather
>> the statistics). So I quickly wanted to add a tooltip for it, or
>> rename the button. Not possible because of string freeze.
>>
>> Now, I have two options: 1) Put it on my already loooooong TODO list.
>> 2) Put it in some feature branch that I often forget about.
>>
>>
>> Having an official branch for 2.2.3 could solve these issues elegantly, I
>> think.
>
> Or you could have your own "string changes" branch that you push any string
> change commits to, and then merge it in as soon as 2.2.3 opens up again. As
> long as you tell people if you merge a request there so it's not merged
> twice, that should be fine.

That is basically my "Plan B".

If my proposal (which I still find a good idea) is getting rejected,
I'll do the same thing, just not in mainline, but in a clone. I could
give everyone else commit access to that, so in effect, I'd reach the
same result, but through the backdoor :p

-- 
Mark Kretschmann
Amarok Developer
Fellow of the Free Software Foundation Europe
www.kde.org - amarok.kde.org - www.fsfe.org


More information about the Amarok-devel mailing list