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

On Wednesday, January 19, 2011, Alexander Neundorf wrote:
> http://community.kde.org/Sysadmin/GitKdeOrgManual looks quite ok for
> somebody who knows how to use git for KDE, but not for me.
> Can somebody please add a simple step-by-step howto, what I have to do wi=
th
> identity.kde.org, projects.kde.org and git.kde.org, how the git
> push/merge/branching policy is for KDE, etc. If there are existing blog

this is, at least to me, two related but separate topics:

a) how do i get myself hooked up with all the tools?
b) what is the development workflow once i have those tools?

as i understand it:

identity.k.o, projects.k.o, reviewboard.k.o, etc. are things you set up onc=
e=20
and mostly forget about afterwards. they are the new replacements to the "h=
ow=20
do i get an svn account?", "how do get a new svn module?" and "what is the=
=20
lifecycle of a kde app?"

this is mostly about re-working existing documentation, such as:

	http://techbase.kde.org/Policies/SVN_Guidelines

and it's probably a really good opportunity to try and put it into an order=
=20
that's even more accessible than what we have right now. a "KDE contributor=
's=20
primer" on techbase, which is what you seem to be looking for (and somethin=
g=20
i'd find useful myself as i learn all the new answers, too :)

one thing that complicates this is that these tools are to some extent stil=
l=20
in development. as needs are discovered and defined, sysadmin is adding=20
capabilities to cover them. the recent addition of=20
http://projects.kde.org/kde_projects.xml is a good example. so the "it's no=
t=20
finished yet, but it's already usable" status does mean it's a little more=
=20
tricky.

the other half of the question is development workflow. and that's even les=
s=20
well defined, as Ian noted. it would be very good, as Ossi noted, to have=20
something that can create some consistency between KDE projects. personally=
, i=20
think we'll end up with something like this:

	http://techbase.kde.org/Policies/Kdelibs_Coding_Style

but for git workflow in kdelibs. hopefully then we can encourage as many of=
=20
KDE projects to adopt it outright or as the core of their own workflow.=20
kdelibs just hasn't had this done for it yet. it's part of the struggle wit=
h=20
kdelibs given how distributed and loosely knit the group of people who work=
=20
kdelibs are.

in kde-workspace (and for the parts of kde-runtime we also maintain) we've=
=20
been discussing how to do things. i love that you shared what CMake has don=
e=20
here as it's a great reference point. thanks for that :) so far, the workfl=
ow=20
we've sketched together looks a -lot- like this:

	http://public.kitware.com/Wiki/Git/Workflow/Topic

i'm fairly tempted to just steal .. er .. borrow, yeah, that's it .. borrow=
!=20
that from cmake for our needs. perhaps we could even use it as a starting=20
point for the kdelibs workflow as well.

one of the things we haven't worked out yet is how to publish the status of=
=20
topic/feature branches, which is what this seems to address for CMake:

	http://public.kitware.com/Wiki/Git/Workflow/Stage

?

our documents should also probably cover how reviewboard and friends can wo=
rk=20
into that workflow as well. i'm also personally somewhat conflicted over ho=
w=20
to handle bug fixes without getting too complex....

this is all separate from the tools (identity.k.o, etc.) though, and imho=20
should probably be a second set of documents on techbase. the git.kde.org=20
manual is a decent starting pont for source material for the tools, but we'=
ll=20
be starting from scratch for the workflow bits. which makes borrowing pre-
existing work that fits closely with what we need tempting ;)

i'm not sure i have the energy right now to do this (too many other things=
=20
tugging at my sleeves right now), and i am doubly unsure i have enough git=
=20
knowledge to really do a great job of it. i could probably help with the to=
ols=20
intro, though; and i wouldn't mind participating, though certainly not taki=
ng=20
lead on, the workflow bits.

it would be great if we could have a working document (as in: something we =
are=20
actually using, or at least trying to use) for workflow by the time the=20
Platform 11 sprint rolls around at the start of June where we could probabl=
y=20
do some high-bandwidth hammering out of any remaining details, if any. in t=
he=20
meantime, as Ian notes, it's likely that kdelibs will start out on day 0 in=
 a=20
sort of "what we've always done with svn/cvs, only using git" workflow unti=
l=20
we have something like this put together.

> Sorry if such documentation already exists and I just didn't find it.

i don't think it does yet .... or at least, i haven't found it either ;)

> For CMake, which moved to git last spring, such a wiki page exists:
> http://www.cmake.org/Wiki/CMake/Git , which was mostly good enough for git

again, thanks for sharing this link ... another bit of useful git-ology add=
ed=20
to my reading ...

=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

--nextPart1884941.LlcxrpKqaO
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)

iEYEABECAAYFAk04CNIACgkQ1rcusafx20P6yQCcDap8rgv76CWz3VZYEXszwnhb
FwEAniZed75BHATLv9/e8i/GP535Siom
=ZJQo
-----END PGP SIGNATURE-----

--nextPart1884941.LlcxrpKqaO--