Hi, I'm woming into the discussion late, I've taken this as a "proper" request for BOF space, and have assigned some in the schedule. If you only need half an hour, or if you haven't decided whether to ask for space yet, let me know.
In any case, it's a big site, and the principle of BOFs is "grab the people you need/want, and sit down informally together" - scheduled space isn't a requirement, I think. Cheers, Dave. 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. > > On Fri, Sep 4, 2009 at 1:57 PM, David Greaves<da...@dgreaves.com> wrote: >> I personally thing think that as a development community with git on garage >> and >> gitorious.org we should be making efforts to understand how best to use DVCS >> processes to collaborate. > > 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. > >> 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 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) > >> 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? > > > >> So why now? >> >> 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?. To me divide and conquerer doesn't mean every body > gets' it's own branch. For this specific problem (debian stuff) I > would suggest using whatever packager use to solve this problem and I > don't think it's put everything in a git. > >> 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 > >> 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. > >> 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 > >> Which means if you're a member of multiple teams you might find they each >> have >> different approaches - "whoo hoo!" - not! >> >> So anyway... I thought a talk would be a good idea. >> >> Now at the time no-one had volunteered so I did - some of you may have >> noticed >> my name at the bottom of >> >> http://www.kernel.org/pub/software/scm/git/docs/git.html >> >> Now you may think that qualifies me to offer this talk - you'd be wrong ;) >> >> I was hanging around the kernel lists at the time, got interested and acted >> as >> an 'editor' pulling together words of wisdom. Since then I've used git a >> little >> but it wasn't until we started to need it in Mer that I reviewed the >> state-of-play and tried to pull in other people's good ideas - so that's what >> I'd use as a base. >> >> However we also have Johan Sørensen (cc'd as I don't think he's on-list) who >> wrote Gitorious.org - I think having him speak on using git and gitorious >> would >> be an opportunity that we shouldn't miss. > > That does sound good, on something like FOSDEM I would certainly go > >> Equally there must be developers in Nokia/Trolltech who could say "we know >> this >> stuff and this is how we think you might want to do it." > > Indeed interested to hear how they want to solve their problems > >> So... speak now... >> >> David >> >> PS If anyone fancies collaborating and doing a multi-person presentation then >> I'm up for it. > Here is where I try to say something more positive but fail. > > Greetings and see you soon > _______________________________________________ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > -- maemo.org docsmaster Email: dne...@maemo.org Jabber: bo...@jabber.org _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
