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=relaxed/relaxed;
	d=gmail.com; s=20120113;
	h=date:from:to:subject:message-id:mail-followup-to:references
	:mime-version:content-type:content-disposition:in-reply-to
	:user-agent;
	bh=a/7XJlTwYed7sfZyN6sI14l1tVrnqd0bCAucduCesyU=;
	b=o+ZXHNS9Nj+3ASPTMmgXCsEaj1KVjy/+m9FIMRcCKwE8vfECalRVPJ3nyXuHa/Veja
	CdXvqDIfvnVBRc8Jy8kQl+p3KezQ6oK7W0BFP9qRZ3pA7C935AIUqNNzvtHt/Cch8J66
	h2wH5C32J3df41he/Lo95ksSfvrrLqM+vRrdW3Vjh9lg+LLmN5o0VnJtxmhEE2u2/KHr
	1IJ2g0wJzn0Wpaj+R7js0pf6nxnVl4KLGTdQ0V/u/6O0Ooo2i2hhUlQELv8JszW7N3rt
	292gQMkk16ZChpG/5DPdgAOEscanmoj44fKzB9o7O/AN6nAAwYLee/H4yBFu99jCXHoq
	ZejA==
X-Received:	by 10.152.37.227 with SMTP id b3mr17615994lak.91.1441230210402;
	Wed, 02 Sep 2015 14:43:30 -0700 (PDT)
Date:	Thu, 3 Sep 2015 00:43:28 +0300
From:	"Vladimir Zhbanov (vzhbanov AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	gEDA User <geda-user AT delorie DOT com>
Subject:	Re: [geda-user] community repository
Message-ID:	<20150902214328.GA14589@localhost.localdomain>
Mail-Followup-To:	gEDA User <geda-user AT delorie DOT com>
References:	<55E6DBB1 DOT 5080704 AT jump-ing DOT de>
MIME-Version:	1.0
In-Reply-To:	<55E6DBB1.5080704@jump-ing.de>
User-Agent:	Mutt/1.5.23 (2014-03-12)
Reply-To:	geda-user AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	geda-user AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Wed, Sep 02, 2015 at 01:21:21PM +0200, Markus Hitter (mah AT jump-ing DOT de) [via geda-user AT delorie DOT com] wrote:
... 
> - Once a topic branch is done ( = all commits on master) it gets removed. Duplicate commits are pointless.
I don't think so. If you use 'git cherry-pick', and it is sometimes
better than merging/rebasing, you'll have duplicate commits in different
branches. Then you can do just 'git merge -s ours ...' to not include
unneeded patches and to have history as is, having at the same time
necessary branches in master and marking branch as fully merged/closed.
(I'm just working on Riccardo Lucchese's patch-set and I believe doing
it this way (and probably using the strategy 'theirs' to continue the
branch) would be the best option.)

...
> 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?

Yes. Mostly agreed.
Just cannot remember what LP is standing for (launchpad? why then?).

And... Why don't you send your proposal to the devel list as well? Some
developers, AFAIR, don't read this list as they just don't want to hear
non-constructive noise here any more :), so they'll not be able to see
your proposals. (I'm starting to think they were right in their
decision.)

Cheers,
  Vladimir

- Raw text -