[Scummvm-devel] Towards a new release branch model

[Michael Madsen]

> -----Original Message-----
> From: A. Milburn [mailto:fuzzie at users.sourceforge.net]
> Sent: Tuesday, May 31, 2011 6:44 PM
> To: Miguel Bernabeu
> Cc: Max Horn; scummvm-devel.lists.sourceforge.net devel; Marcus Comstedt
> Subject: Re: [Scummvm-devel] Towards a new release branch model
> 
> On Tue, May 31, 2011 at 06:20:11PM +0200, Miguel Bernabeu wrote:
> > not). At the same time we are working in new stuff on "master"
> > _but_not_ bugfixing "master". Now we rebase "stable" changes onto
> > "master", so the quick fix is applied to "master" and a thorough fix
> > can be applied later, without reverting the quick fix, simply a
> modifying commit.
> 
> I worry that this is rather unrealistic given the nature of a lot of the
> quick fixes which get applied to stable branches - they're the *wrong* fix
> and people are going to want to revert them right away. As well as the
> situation with fixes which are irrelevant/wrong for master because other
> code changed and/or was refactored from underneath them.
> 
> But I am generally concerned about the fact that various people have
> obviously been struggling with git since the move, and the possibility
> that
> - even without feature branches etc - mandating a development model like
> this will make people more frustrated with it and less motivated to
> actually fix things. Would be nice to have some feedback from such
> developers, to know if I'm just imagining things or not..

Git is inherently more complicated than SVN, so it's no surprise people have had problems. You have to know more to be able to use Git than to be able to use SVN, and changing the workflow will just require you to know even more, which leads to frustration if you don't understand it. Although I feel Git itself amplifies the problem, this really applies to any DVCS, and I don't think there's a way to avoid that.

IMO, there are two big questions that haven't been answered in this thread:

1) What is the concrete advantage of either of these approaches? No Git terms; explain exactly what they let us do and why *we* would want to do that.
2) What, specifically, is the problem with the current approach?

Right now, it almost seems like these changes are claimed to "obviously" be better for us. That can make it hard for some people to speak up against the changes - especially if they're already having trouble understanding Git.

Also, just to clarify: I'm not taking a stance on either model here; in part because I'm not sure I really understand Git myself, but also because I don't work on ScummVM itself anyway and it sounds like we're only discussing the "main" repository, not the tools.

Michael