X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
X-Original-DKIM-Signature:	v=1; a=rsa-sha256; c=simple; d=mail.ud03.udmedia.de; h=
	to:from:subject:message-id:date:mime-version:content-type
	:content-transfer-encoding; s=beta; bh=EF9Y6rXWw0zWzMILqpy1Fipk1
	l1JnF8lDZi9yXZd4lE=; b=mKKF0BNBvBG3Mh+dw+DJ7/olC61oFpRngW72C2bAh
	vo9R4XA0D9lNYR/KJ3QJG76X5gillQLWMPxHeG7x8Glg094EX/eMbkhyt2HJPfH8
	K80jtw7FhaoPxKpIbUVJWULA3iqLe3dlcqHezFKIvEgdSicUndR6TAaG32rEjJK0
	HA=
To:	gEDA User <geda-user AT delorie DOT com>
From:	"Markus Hitter (mah AT jump-ing DOT de) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
Subject:	[geda-user] community repository
Message-ID:	<55E6DBB1.5080704@jump-ing.de>
Date:	Wed, 2 Sep 2015 13:21:21 +0200
User-Agent:	Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
	Thunderbird/38.2.0
MIME-Version:	1.0
Reply-To:	geda-user AT delorie DOT com

Code writers,

the last few days there were discussions about where to contribute. Let me take this opportunity to propose a plan for making the official repo more comfortable for everybody.

Not too surprising, there's a bit a gap between the expectations of those who want to get some feature done quickly and those who care about the long term quality of our tools. That's a natural gap and I hope it's possible to build some bridges.


The first good thing is, gEDA repositories run Git and Git has strong support for topic branches. In detail, branches are cheap, so it's no problem to have dozens or even hundreds of them. Commits on branches can be edited, so no additional commit for each found typo neccessary. It's also possible to rebase them, so one can follow mainline development with some custom feature branch easily. Topic branches are (almost) impossible with earlier CVSs, so don't expect everybody to be comfy with them immediately. More on the topic:

https://github.com/dchelimsky/rspec/wiki/topic-branches
https://blog.mozilla.org/webdev/2011/11/21/git-using-topic-branches-and-interactive-rebasing-effectively/
http://wiki.winehq.org/GitWine#head-20352a9b6bbab91763387de5b12a36a9fecc87b0


The second good thing is, gEDA's repo runs Gitolite, kind of a fine grained access control, including per-branch privileges. Here's what I think of:

- No editing of commits on master. While it might be tempting to 'rebase -i' this silly thing just pushed, this can have unwanted side effects. One can (and should) 'rebase -i' _before_ pushing, of course.

- Bug handling should be done in topic branches, accessible to everybody. Some are there already, Bert Timmermans fork has many more. By rebasing they can follow development on master until they're solved.

- Once a topic branch is done ( = all commits on master) it gets removed. Duplicate commits are pointless.

- A playground for everybody, branches starting with /home/<user>: read/write/rebase/delete access for each user, only read/write for other users. There people can dump anything and yes, I've used a Git repo to exchange screenshots during an ongoing discussion already. Works handily.

- Access to releases only for admins.

Note that there's a delete privilege ('+') in addition to the usual read privilege and write privilege. One can allow writing, but disallow deleting/rebasing.


The above in Gitolite parlance. 

repo pcb
  RW+M                             = @admins
  # enforce name LPxxxxx for bugfix branches
  RW+   LP[0-9]{5,9}(-+[-\w]*)?$   = @devs-pcb @juniors-pcb
  # communicative playground
  RW+   home/USER/                 = @devs-pcb @juniors-pcb
  RW    home/                      = @devs-pcb @juniors-pcb
  # read-write only, no rebasing for master
  RW    master                     = @devs-pcb
  # read-only for releases, etc.
  R                                = @devs-pcb
  R                                = gitweb daemon


With this there should be no longer hesitation to hand out write access. Also no newbie fear to mess up something. Let's make the repository a communications platform! Communicating source code, ideas, developments.

Good plan?


Markus


-- 
- - - - - - - - - - - - - - - - - - -
Dipl. Ing. (FH) Markus Hitter
http://www.jump-ing.de/

- Raw text -