X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Message-ID: <508AF21E.2090400@xs4all.nl>
Date: Fri, 26 Oct 2012 22:27:10 +0200
From: Bert Timmerman <bert DOT timmerman AT xs4all DOT nl>
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] The state of gEDA/gaf
References: <CANqhZFxYH+Y5U1ai7ey-s+4nz6eYDM2vx3aMDb7WuigNXmi4AQ AT mail DOT gmail DOT com>	<50892DC8 DOT 6080308 AT laserlinc DOT com>	<201210251629 DOT q9PGTfes029100 AT envy DOT delorie DOT com>	<50897B77 DOT 1030401 AT laserlinc DOT com>	<201210251859 DOT q9PIxw7n004895 AT envy DOT delorie DOT com>	<F720A597-665F-40D1-B1A4-E02506EE5D09 AT jump-ing DOT de>	<CAGde_xNNrA-QMcXiNQJEkPSfFGeZWLyULAqh0pZfkPAV898NQQ AT mail DOT gmail DOT com>	<8CD82772-DF1C-4C82-852C-B9F6A094CBAA AT jump-ing DOT de>	<CAGde_xNtp8tb82kiggdzbq-3X7zMY5sHu5TS7dLxJooX3K-pFA AT mail DOT gmail DOT com>	<F3B81D9B-82F1-4F13-8DED-93BD106C5414 AT jump-ing DOT de> <CAGde_xM=x5P5yiSMQ0wTGaCATdToY-TcYbcoNTxh1E_m4Ky9tg AT mail DOT gmail DOT com>
In-Reply-To: <CAGde_xM=x5P5yiSMQ0wTGaCATdToY-TcYbcoNTxh1E_m4Ky9tg@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by XS4ALL Virus Scanner
Reply-To: geda-user AT delorie DOT com

Svenn Are Bjerkem wrote:
> On 26 October 2012 16:04, Markus Hitter<mah AT jump-ing DOT de>  wrote:
>    
>> Am 26.10.2012 um 14:16 schrieb Svenn Are Bjerkem:
>>
>>      
>>> and that I do not know what kind of patches or
>>> repositories we are talking about. With "remote repo" I understand
>>> stuff on github or any other place but git.geda-project.org.
>>>        
>>
>> Exactly. Searching at github.com for "geda" finds no less than 160 forks.
>> Some even from people with commit access to geda's own repository. And there
>> are even more fork on other sites.
>>
>> I'm not talking about this in public, these people could feel like I point
>> with my finger towards them and shy away even more.
>>      
> I got curious and headed over to have a look at the misery. It turns
> out that there are 14 projects forked off of geda-gaf in there. Found
> some regulars, yes, but I also found that they just slipped into the
> clone of git.geda-project.org. Most of the forks have their master
> already pushed into git.geda-project.org so I ended up with two forks
> with genuine master data compared to G-P. I do not count genuine
> branches found on the forks as I expect those to have been merged back
> into master in case they were successful. Unfortunately it seems that
> rebasing has been the favourite tool, and that leaves the working
> branches dangling seemingly helpless and forgotten.
>
> Looking at the geda-gaf fork from Peter Brett, I think that's the way
> the whole project should have been run: People without commit access
> make a fork, implement code/bug/fix and push it back to their own
> branch. The interested soul add the fork as a remote and test the
> code/bug/fix in his local work tree. When the work is done, a pull
> request is pushed to the overlords controlling the mainline for audit.
> Good stuff is then put on top of master and the cycle starts again. As
> long as all the forks out there have the same SHA as mother,
> overlaying code is a breeze.
>
> I'm going to have a look at all the other geda forks to see what they
> really try to provide. I think most of the forks are just result of
> the mainline geda development not being up to date with modern chaotic
> development methods.
>
>
>    
Hi Svenn,

ATM I'm doing a Dutch translation of the scheme-api texi documentation 
for geda-gaf, nothing else planned yet.

Last time I did some work on geda-gaf it was done as described above, 
after the last commit a pull request to Peter B's Github fork, and he 
reviewed and pushed to upstream "master".

IMHO the most interesting stuff is most likely to be found in topic 
branches, as the local "master" is almost always lagging behind the 
upstream "master".

In Git branching is too cheap and easy: just "git checkout -b 
<new_branch>" from the CLI.

Another thing in Github is that one may "suffer" from "drive-by" commits 
and single contributions: one or two of them and just when you think you 
have a collaborator .... gone with the wind.

Kind regards,

Bert Timmerman.