Mail Archives: geda-user/2016/01/16/07:08:49
This is a multi-part message in MIME format.
--------------060108090903010803070909
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
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
>>
>
--------------060108090903010803070909
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 16/01/16 11:46, Milan Prochac (<a class="moz-txt-link-abbreviated" href="mailto:milan AT prochac DOT sk">milan AT prochac DOT sk</a>) [via
<a class="moz-txt-link-abbreviated" href="mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>] wrote:<br>
<blockquote cite="mid:569A2DAC DOT 9070200 AT prochac DOT sk" type="cite">
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<div class="moz-cite-prefix">On 15. 1. 2016 2:51, Britton Kerin (<a
moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:britton DOT kerin AT gmail DOT com">britton DOT kerin AT gmail DOT com</a>)
[via <a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>]
wrote:<br>
</div>
<blockquote
cite="mid:CAC4O8c93jC=qRPAHnzBCrVYONGnyvQ55qv5yQ-vor8es-0_meg AT mail DOT gmail DOT com"
type="cite">
<div dir="ltr"><br>
<div class="gmail_extra">
<div class="gmail_quote">On Thu, Jan 14, 2016 at 2:20 PM,
Milan Prochac (<a moz-do-not-send="true"
href="mailto:milan AT prochac DOT sk">milan AT prochac DOT sk</a>)
[via <a moz-do-not-send="true"
href="mailto:geda-user AT delorie DOT com">geda-user AT delorie DOT com</a>]
<span dir="ltr"><<a moz-do-not-send="true"
href="mailto:geda-user AT delorie DOT com" target="_blank">geda-user AT delorie DOT com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"><span
class="">On 12. 1. 2016 20:23, Britton Kerin (<a
moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="mailto:britton DOT kerin AT gmail DOT com">britton DOT kerin AT gmail DOT com</a>)
[via <a moz-do-not-send="true"
href="mailto:geda-user AT delorie DOT com" target="_blank">geda-user AT delorie DOT com</a>]
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
I'm working on this branch there are some minor
issues. I'll push fixes to LP1532611_fixes<br>
<br>
</blockquote>
<br>
</span> Can you share details about the issues? I guess
I can identify the culprit and prepare fix faster<br>
</blockquote>
<div><br>
</div>
<div style="">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.</div>
<div style=""><br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
The "patch" is not readable/applicable. Can you please provide the
copy without color ANSI sequences?<br>
<br>
<blockquote
cite="mid:CAC4O8c93jC=qRPAHnzBCrVYONGnyvQ55qv5yQ-vor8es-0_meg AT mail DOT gmail DOT com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div style="">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). </div>
<div>Â </div>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote
cite="mid:CAC4O8c93jC=qRPAHnzBCrVYONGnyvQ55qv5yQ-vor8es-0_meg AT mail DOT gmail DOT com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div style="">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.</div>
<div style=""><br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
I will post all fixes to the existing LP as additional patches.
Once patch is published, I will not modify it or recall it.<br>
<br>
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. <br>
<br>
Milan<br>
<br>
<br>
</blockquote>
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:
<a class="moz-txt-link-freetext" href="http://blog.scottlowe.org/2015/01/27/using-fork-branch-git-workflow/">http://blog.scottlowe.org/2015/01/27/using-fork-branch-git-workflow/</a>
. I'm pretty sure this workflow is not unique to Github, it's just
become popular because of it.<br>
Anyone have any better suggestions, going forward?<br>
<br>
MJE<br>
<blockquote cite="mid:569A2DAC DOT 9070200 AT prochac DOT sk" type="cite">
<blockquote
cite="mid:CAC4O8c93jC=qRPAHnzBCrVYONGnyvQ55qv5yQ-vor8es-0_meg AT mail DOT gmail DOT com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div style="">Britton</div>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</blockquote>
<br>
</body>
</html>
--------------060108090903010803070909--
- Raw text -