Well, this getting to a pretty useless discussion. You set out to prove that you find it all very simple, and I am sure you find it simple.

You don't have to rebut everything I say point by point to prove whatever you think you are proving because the point is this: you find it simple, others don't. What you have to do is accept is this: others don't. The rest of the world is fine with accepting that you think it's simple, that's not the point of the discussion.

So, yes, you cannot write a git-for-dummies manual, for that we need a genius like David Revoy. Just get this: you hope everyone has met a DVCS. I regularly meet people for whom git is a magic way of getting new features, and who have _no_ idea at all about what version control is, or what source code is. And many of them turn out to be awesome contributors, and some even, after a year or two, help with git bisecting a particular bug.

So all I want to make sure here is that participation in KDE is as accessible as possible to the great majority of the world that doesn't want to play the 'serious software engineer', qt-project.org-style.

That is why I've given the link to what non-engineers active in #krita think about KDE's infrastructure, and that's why I've tried to show you how intimidating something you find very simple actually is, how many steps that you know are optional, or necessary, you actually forgot to mention in your little list.

 On Mon, 5 Jan 2015, Albert Astals Cid wrote:

El Dilluns, 5 de gener de 2015, a les 22:22:19, Boudewijn Rempt va escriure:
On Mon, 5 Jan 2015, Albert Astals Cid wrote:
I think this is due to the fact that it's quite simple
git clone kde:repo

This requires:

* setting up gitconfig with the kde: alias. That requires finding the
right info on techbase, as well as the awareness that techbase exists.
You can always just use the full url.

* figuring out the reponame for a particular project (and that isn't as
easy as just downloading the entire trunk of kde's svn repo -- even if I
never did that myself)
Sure, if you don't know the repo name you're out of luck, not that downloading
the whole trunk would help you much more (you can still grep but it may take
ages)


do coding
git commit

* using the commit template
You don't really need a commit template (though it's nice if you use it)

* with the relevant keywords
You don't really need to use the keywrods (though it's nice if you use it)

* having a grasp of what a git commit is, especially that a commit isn't
visbile to anyone else
Any modern (i.e. DVCS) has that concept, sure it's complicated for cvs/svn
people, i'd like to think most of us has worked with a DVCS at the moment.

git push

But not before you have

* realized that you need to push, i.e. what local and remote is
Same as above, it's DCVS.

* figured out what branches are for, and how different projects handle
those
Right, that's hardly documentable though (and will get old soon most probably)

* got your kde indenity
Every system needs it's own identity system, we use ours.

* posted it on the right reviewboard
Reviewboard is not mandatory (though it's nice)

* to the right reviewers
Yes, you either have to pick the reviewers or let a robot do your job.

That said, i'm not saying contributing is easy, i'm just saying the "pure git"
part is not that hard, it's all the "project overhead" (branches, review,
account, etc) that really makes it harder (in my opinion).

Cheers,
 Albert


Reply via email to