[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KDE git docs for dummies ? WAS: Re: splitting up kdebase in git
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2011-01-20 9:31:40
Message-ID: 201101200131.50162.aseigo () kde ! org
[Download RAW message or body]


On Thursday, January 20, 2011, Oswald Buddenhagen wrote:
> On Wed, Jan 19, 2011 at 03:33:30PM -0600, Ian Monroe wrote:
> > There is no push/merge/branching policy for KDE. Different projects
> > will likely do their own thing. For the time being its just the
> > SVN-style development translated to Git.
> 
> words like "unwise", "stupid" and "utterly braindead" come to mind. you

dude, that was so not cool as a response. you can disagree and offer input, 
sure, but try to do it without insult. everyone'll listen closer and walk away 
happier.

> cannot refer to projects' sovereignty in an environment where everybody
> can push everywhere. 

i mostly agree with you; when it's an open-for-all-to-participate playground, 
then having some common guidelines and expectations is highly useful to 
ensuring that accidents don't happen and that people feel confident enough to 
contribute broadly. 

the ballancing issue is that different projects have different needs and even 
variations in how their development community is put together, and that is 
bound to translate to some variation.

there is more than one way to do git, and KDE has more than one team in it 
these days. we can strive to bring commonality to this issue, but i don't 
think we will realistically achieve perfect uniformity.

that said, i've been personally using this as a starting reference:

	http://community.kde.org/Sysadmin/GitKdeOrgManual

the section on personal repositories in particular has some useful points, 
such as how to start with something in your scratch, how to move it to the new 
KDE playground, how to move that to kdereview and then out to a final 
location.

there are some very basic guidelines on things like reviewboard there as well. 
i think it could be a good starting point from which further documentation can 
be built up.

> and before you make excuses about sysadmin only
> implementing and not making decisions: FAIL. at the very least you

i think sysadmin has / had enough on their plate without also taking this on. 
honestly, knowing what resources they have along with the responsibilities 
they've taken on this far and the patience and commitment with which they've 
done so, it's probably ok that they didn't also take this on themselves. :)

> should have facilitated the creation of such a policy, because this very
> much *is* part of "implementing git".

perhaps you could help with this part of implementing git and start crafting 
some mechanisms that we can consider adopting. 

we've been trying to do this for plasma leading up to the migration of libs, 
base and plasma-addons and we've had some success but i'm not sure i'm 100% 
happy yet. :) there's a lot to read about this on the 'net from others who 
have been using git in varoius ways for projects of various sizes, so there's 
a lot to digest.

would you be able / willing to help out with this part of things? it strikes 
me as the kind of thing that you are usually pretty good at, in fact :)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks

["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]