X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Message-ID: <569A6704.2080906@xs4all.nl>
Date: Sat, 16 Jan 2016 16:51:32 +0100
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] LP1532611 (modular fie formats) fixes
References: <CAC4O8c8tTutWKvXFA-nfcmUiUGYbOY1_5171Vf3WDk09Tmx3yw AT mail DOT gmail DOT com> <56982D5A DOT 1020706 AT prochac DOT sk> <CAC4O8c93jC=qRPAHnzBCrVYONGnyvQ55qv5yQ-vor8es-0_meg AT mail DOT gmail DOT com> <569A2DAC DOT 9070200 AT prochac DOT sk> <569A3280 DOT 3030704 AT iee DOT org>
In-Reply-To: <569A3280.3030704@iee.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: geda-user AT delorie DOT com

M. J. Everitt (m DOT j DOT everitt AT iee DOT org) [via geda-user AT delorie DOT com] wrote:
> On 16/01/16 11:46, Milan Prochac (milan AT prochac DOT sk) [via 
> geda-user AT delorie DOT com] wrote:
>> On 15. 1. 2016 2:51, Britton Kerin (britton DOT kerin AT gmail DOT com) [via 
>> geda-user AT delorie DOT com] wrote:
>>>
>>> On Thu, Jan 14, 2016 at 2:20 PM, Milan Prochac (milan AT prochac DOT sk 
>>> <mailto:milan AT prochac DOT sk>) [via geda-user AT delorie DOT com 
>>> <mailto:geda-user AT delorie DOT com>] <geda-user AT delorie DOT com 
>>> <mailto:geda-user AT delorie DOT com>> wrote:
>>>
>>>     On 12. 1. 2016 20:23, Britton Kerin (britton DOT kerin AT gmail DOT com)
>>>     [via geda-user AT delorie DOT com <mailto:geda-user AT delorie DOT com>] wrote:
>>>
>>>
>>>         I'm working on this branch there are some minor issues. 
>>>         I'll push fixes to LP1532611_fixes
>>>
>>>
>>>     Can you share details about the issues? I guess I can identify
>>>     the culprit and prepare fix faster
>>>
>>>
>>> Attached is a patch showing roughly what I've found.  The 
>>> fftemplate.c is entirely in this patch but I didn't change anything 
>>> in it besides including assert.h I think.
>>>
>>
>> The "patch" is not readable/applicable. Can you please provide the 
>> copy without color ANSI sequences?
>>
>>> It comes down to a little more honoring of default format (e.g. 
>>> making sure its in default position in format list in SaveAs, checks 
>>> that only one defualt format is specified, and stuff to take care of 
>>> situation where PCB->Filename is known and PCB->Fileformat not.  
>>> Some or all of that last category of change may be uneeded with the 
>>> patch you propose for invalid file arguments (which I think is the 
>>> right fix for that).
>>
>> I will review my changes and ensure that PCB->Fileformat is valid 
>> when PCB->Filename is known. The assignment of filename from 
>> commandline was missed, but all other situations should be handled 
>> properly.
>>
>> Please note that patch LP1534373 is for PCB without modular file 
>> format. It will require one more line to support modular formats - 
>> set the default format along with filename of non-existing board.
>>
>>> I'd like for you to "own" this code for sure as you can almost 
>>> surely improve it faster and better, but I'd like to start using it 
>>> as well.  If you aren't wanting to use git yet it would be nice to 
>>> get you synced up with a repository version (one way or another, 
>>> either you can sync to home/bert/LP1532611 or we could declare the 
>>> edits in that branch premature and restart it with a new patch from 
>>> you).  You can then send patches to whoever owns the branch so 
>>> people can track it.
>>>
>>
>> I will post all fixes to the existing LP as additional patches. Once 
>> patch is published, I will not modify it or recall it.
>>
>> I am not very comfortable with the proposed development model (spread 
>> patches over various private branches) as I do not see clear way from 
>> bug report (with patch added) to its merging to master branch.
>>
>> Milan
>>
>>
> Yes, I'm not entirely sure why geda/pcb's development workflow is so 
> badly broken. Developers should be working in their own forks of the 
> code, developing features in a private branch of their fork, and then 
> submitting Pull-Requests to the mainstream repo. At the risk of 
> teaching a few people how to suck eggs (Advance apologies!) the 
> following article demonstrates how this normally works, the key final 
> stage being integration into the main repo: 
> http://blog.scottlowe.org/2015/01/27/using-fork-branch-git-workflow/ . 
> I'm pretty sure this workflow is not unique to Github, it's just 
> become popular because of it.
> Anyone have any better suggestions, going forward?
>
> MJE
>>> Britton
>>>
>>
>
Hi M. J. Everitt,

IMHO some of us have already cloned a local copy, are working in topic 
branches and pushing those upstream.

If you want to be able to push your local topic branch(es) upstream, 
please ask DJ for an account and share a key with him.

The only thing that needs streamlined is a "pull request" mechanism, 
Github has made this into a webthingy (button).

For now we have to ask by email, or on #geda, to get branches reviewed 
(second pair of eyes), and this happens from time to time.

Kind regards,

Bert Timmerman.