--nextPart2898142.SxQ8Zn4G2p
Content-Type: Text/Plain;
  charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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.
>=20
> 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,=
=20
sure, but try to do it without insult. everyone'll listen closer and walk a=
way=20
happier.

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

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

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

there is more than one way to do git, and KDE has more than one team in it=
=20
these days. we can strive to bring commonality to this issue, but i don't=20
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,=
=20
such as how to start with something in your scratch, how to move it to the =
new=20
KDE playground, how to move that to kdereview and then out to a final=20
location.

there are some very basic guidelines on things like reviewboard there as we=
ll.=20
i think it could be a good starting point from which further documentation =
can=20
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 o=
n.=20
honestly, knowing what resources they have along with the responsibilities=
=20
they've taken on this far and the patience and commitment with which they'v=
e=20
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 craftin=
g=20
some mechanisms that we can consider adopting.=20

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

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

=2D-=20
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

--nextPart2898142.SxQ8Zn4G2p
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.15 (GNU/Linux)

iEYEABECAAYFAk04AQYACgkQ1rcusafx20MUOQCeOEWcDMDS5IN+BYQy80gZqucl
XOAAni9HHNzu1PAovo2a+XnHCLz91z/D
=pflO
-----END PGP SIGNATURE-----

--nextPart2898142.SxQ8Zn4G2p--