X-Authentication-Warning:	delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient:	geda-user AT delorie DOT com
Message-ID:	<55D9BBCC.8000904@xs4all.nl>
Date:	Sun, 23 Aug 2015 14:25:48 +0200
From:	"Bert Timmerman (bert DOT timmerman AT xs4all DOT nl) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
User-Agent:	Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.19) Gecko/20110429 Fedora/2.0.14-1.fc13 SeaMonkey/2.0.14
MIME-Version:	1.0
To:	geda-user AT delorie DOT com
Subject:	Re: [geda-user] Antifork
References:	<55D8D8B8 DOT 7050907 AT jump-ing DOT de> <20150822230549 DOT 3750 DOT qmail AT stuge DOT se> <55D9A5AE DOT 9090604 AT jump-ing DOT de>
In-Reply-To:	<55D9A5AE.9090604@jump-ing.de>
Reply-To:	geda-user AT delorie DOT com

Markus Hitter (mah AT jump-ing DOT de) [via geda-user AT delorie DOT com] wrote:
> Am 23.08.2015 um 01:05 schrieb Peter Stuge:
>    
>> Markus Hitter (mah AT jump-ing DOT de) [via geda-user AT delorie DOT com] wrote:
>>      
>>> many talented people happily hack away on the project
>>>        
>> ...
>>      
>>> none of them does so in the official repo
>>>        
>> Would it help if I host git repos and hand out commit access to
>> interested people?
>>      
> I feared this. People see a tool to deal better with forks and feel encouraged to create even more forks.
>
> Forks are the wrong way. As one can easily observe in the public repo, they almost halted official development. Ask Eagle or KiCAD users; they consider gEDA to be mostly dead, because there's no visible development and newer developments also don't get into Linux distributions.
>
> Another reason against forks is lack of collaboration, which I'll try to explain in a minute to Igor2.
>
>
>    
>> I think the branch ignore function should use a combination of
>> one remote URL (NB! git: vs. http: vs. https:) and one branch
>> name, rather than a commit hash, because the commit could be in
>> many branches and only one of them should be ignored.
>>      
> That's how it actually behaves: it doesn't ignore single commits, but only branches, if the last commit on a branch matches the ignored commit hash.
>
> It's the hash, because if a branch in a fork receives additional commits, the branch name is still the same; filtering by branch name whould ignore these new commits. Filtering by hash makes these updated branches appear again, so they get noticed.
>
> Filtering single commits whould be nice, but requires rebasing, making it pretty complicated.
>
>
> Markus
>
>    
Hi Marcus and all,

I think forks with lots of topic branches in themselves are not bad, 
they are the symptom of an underlying issue: lack of communication and 
cooperation.

There are enough explanations/reasons for the above, it's just not 
helping pcb to progress.

I've been collecting and rebasing patches from Launchpad into topic 
branches (on github.com/bert./pcb.git) to allow for "easy" testing and 
merging them into upstream master.

Getting those topic branches is trivial:

     git remote add bert git://github.com/bert./pcb.git
     git pull --all
     git branch -t xyz bert/xyz
     git checkout xyz

I think communication and cooperation can be improved by code-sprints 
like we used to do in the "Good ole days".

We could meet on #geda every last Sunday of the month (depending on time 
zome of course, we could start upcoming August 30th) just for this 
purpose and see what topic branches can be merged and pushed to upstream 
master, and/or closed.

In the mean time I can rebase those topic branches and test for bitrot 
and regression (I'm a bit behind on the latest bug reports and rebasing 
the contributed patches).

If someone is interested in one of these code sprints all you have to do 
is show up on #geda.

Kind regards,

Bert Timmerman.

- Raw text -