[maemo-developers] [Qt4Maemo-devel] The Summit: Git/Gitorious - Untracked talks: consider adding them...

[From: David Greaves]

Kees Jongenburger wrote:
> Hi David,
> 
> I assume you want to present to also have some discussion. so let's
> start with that. This is all IMHO.
Sure.

> I don't believe that version control system is what is keeping us back
> from collaborating. I do use git myself
> when I feel like it to "grab" projects and start hacking on it but
> this is not what you are talking about.
It's part of it but not what I was interested in.

When you have even 2 or 3 people working on a project you begin to *need* a
process to handle submitting changes to manage bugs and new features.

There are obviously lots of social issues - but I'm not planning on discussing
that side of it.

>> Maybe it's just me but I see a lot of devs who are new to DVCS and very few
>> community guidelines on how to use DVCS. Qt uses it but, as we've recently been
>> discussing, it could be going better.
> 
> One can solve many problems in many ways. it's very hard to find a
> common way of doing things but this is apparently the design goals of
> the git system 
I wouldn't say that. There are lots of ways to use git - and *that* is actually
one of the problems.

> and it's very hard to learn from other just because
> it's distributed(you can't look over somebody's shoulder). Even for
> developers git is a huge learning curve. While it's not bad to learn
> at first sight I don't think it solves and problems we have(it
> probably even make us have more problems because we have more choice)
So yes it does bring choices - and it needs some getting used to.

I am sure that git is not "the best" DVCS for everyone, all the time. I am
equally sure that it is a perfectly good solution for most OSS people, most of
the time.

>> Frankly I don't care which 'good practice' I use - I can go out and find lots of
>> them. But it strikes me that as a community we should at least say "hey, quite a
>> few of us are using this approach - if you don't have any strong preferences
>> then you can use it too"
> 
> This is not clear to me. what people what problem,project are you
> thinking about? what is your target audience?

Any maemo C/C++/python devs. Most non-trival projects.

The problem is how you handle having a release branch that allows bugs to be
fixed; another allowing features to be added and how a team interact around them.

Here are some diagrams I use in Mer:
  http://wiki.maemo.org/Mer/Build/UsingGitorious

That's not ready for a presentation but I'd hope to discuss lots of the concepts.

eg:
>> Well, real soon now (I hope) we're going to have 3 different versions to support.
>>
>>    * Fremantle
>>    * Diablo
>>    * Mer
>> So how do we (you) manage the build-variations (ie debian/* may well vary for
>> each of them. Maybe ./configure too)? Do we use branches? How?

> I hope not, I know git is good a branches but how confusing will this
> be for others?.
Well, if there's some commonality in terms and approaches then "less confusing".

> To me divide and conquerer doesn't mean every body
> gets' it's own branch.
No, it doesn't - not even close.
But with git everybody gets their own copy of a repository and can, eg, ask a
core team to review a change and consider merging it back into a master repo.

> For this specific problem (debian stuff) I
> would suggest using whatever packager use to solve this problem
It's not a packaging issue - it's mainly a development/QA issue with minor
packaging details.

> and I
> don't think it's put everything in a git.
No. However the debian vcs-pkg group have been discussing this - as have others.
git is an answer (a popular one) but the principles are DVCS agnostic.

>> Now how do we manage adding features and back-porting simple bug fixes to the
>> stable release whilst you work on that big new feature set.
> 
> This is a typical problem of people working with closed source. In
> open-source you release once and might do some minor update
> for "real" big problems but overall should not have to maintain a
> release branch to to long as everybody wants the Latest & Greatest.
> "Release often" mantra
Heh - no.

A huge number of debian/ubuntu packages are 'release-branch' based. Just look at
the version numbers anything that ends in -n is 'release branched'

However - you do describe the naive approach taken by a large number of OSS
applications.
And with a little support it is perfectly possible to provide these solid
sw-engineering principles to even the smallest package with almost no overhead.


>> How are contributions and teams handled?
>>
>> It sounds horrendous - and it can be!
> 
> Indeed it sound overcomplicated. first make it easy to contribute and
> if it gets out of hand start using tools. Try to keep
> working with as many people as possible on the same branch to force
> yourself to think about other people's problems.
I think we're talking at cross-purposes here.
I'm talking about organising a dvcs to provide consistent code releases.

I expect to suggest some techniques (as per that link above) and discuss
shortcomings.

>> But actually this is all fairly simple stuff with DVCS once you have it
>> explained and once you grok it - but it's bloody hard to figure out from scratch
>> and it's also very unlikely that you'll arrive at the same solution as another team.
> 
> Indeed. this is actually where a tend to like bzr (for simplicity) and
> the very nice launchpad as it removes
> part of this thinking process. bzr is also a distributed versioning
> system so not completely fair
Yep, bzr is similar.
I'm not familiar with it but you should be able to adapt anything gittish I say
 to bzr.

David

-- 
"Don't worry, you'll be fine; I saw it work in a cartoon once..."