TechBase git policies, infrastructure documentation, please
neundorf at kde.org
Sun Apr 29 19:15:59 BST 2012
On Sunday 29 April 2012, John Layt wrote:
> For the actual repo layout and building KDE step-by-step that can be found
> under http://techbase.kde.org/Getting_Started especially under
> http://techbase.kde.org/Getting_Started/Sources, and for individual modules
> in their pages under http://techbase.kde.org/Getting_Started/Build
> The http://community.kde.org/Sysadmin/GitKdeOrgManual page is really only
> the SysAdmin manual, it shouldn't be referred to by us mere mortals :-)
> If there's anything that needs to move to TechBase from there please do
I think at least the "personal clones" and "personal scratch" repositories
should be mentioned in some way in our not yet existing workflow description
(since there must be a reason that we have them).
> I did make a start on drafting a replacement policy at
> http://techbase.kde.org/Policies/Draft/Commit_Policy but didn't get far as
> I was waiting for things to settle down and a "One True Workflow" to
> emerge. There are various proposed workflows on community such as
> http://community.kde.org/Frameworks/Git_Workflow, but it has always been a
> source of contention so it's hard to finalise a policy.
Yes, I know this page, and I know it's not finished, because the issue is
still not settled.
We are using git now for more than a year, and we still haven't decided on how
we want to use it.
One of the things we wanted to keep an eye on is avoiding fragmentation caused
by the splitting into multiple repositories.
To do that, we need a standard how to work with the repositories, otherwise
there is actually fragmentation happening right now.
E.g. for me, instead of just committing somewhere, I now prefer to let other
people commit it, because I don't know what git worklfow should be used in
some repository. If "just commit and push to master" is fine by default, then
let's document that.
If we decide to decide on this, can we do this please on k-c-d ?
I see no reason why such a discussion should not be as public as possible.
More information about the kde-core-devel