← Back to team overview

kicad-developers team mailing list archive

Re: Re:Path & execution fixes for Mac OS

 

--0-1575000123-1188194250=:37688 Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

Thank you for responding to my previous message. Since the time that I sent=
that, I have recompiled the source code for Linux and encountered no probl=
ems at the time, and as far as I am aware (after starting each of the appli=
cations), the updated code has not broken anything.

I will recheck the updated source code in the very near future, but at the =
time that I had been looking at it and editing it previously, the changes c=
oncerned only affected Mac builds, and did not have any impact upon either =
the Windows or Linux builds (or at least no significant impact).

And for at least the time being, I will refrain from committing any associa=
ted changes.

Regards,
Geoff Harland.

Dick Hollenbeck wrote:

> I am confused about at least one of these changes, and I share your
> concern that there should be a qualified Mac guy to maintain the MAC
> stuff. Plus it seems the definition of "MAC" is not stable or defined.
>=20
> For example, less than 5 days ago I added a patch for a MAC guy and now
> this guy wants to undo it, see file
> eeschema/plugins/netlist_form_pads-pcb.cpp. That patch removes
> precisely what another guy asked me to add.
>=20
> So they have us going in circles it seems.
>=20
> We could simply add a svn tree directory under trunk, called
> pending_patches, and put stuff there until somebody can go through
> them. This patch effects so many files that one could argue that it
> should be split into separate patches.
>=20
> If we go the pending_patches route, you would have to invent a
> consistent file extension name for these patches. Give it some
> thought. Frankly I would not expect much more feedback than what you
> are getting from me.
>=20
> Frankly I don't care about the MAC specific patches, but I get nervous
> about the part of this huge patch file that does effect the linux and
> windows platforms, so maybe a patch split on that basis would give
> somebody that is a MAC builder the ability to apply a clean MAC specific
> patch at any time in the future, providing it is maintained in the
> trunk/pending_patches directory in the repository. The part of the
> patch effecting everyone could be scrutinized now.
>=20
> This strategy keeps us from running in circles.
>=20
> Dick


_____________________________________________________________________=
_______________
Sick of deleting your inbox? Yahoo!7 Mail has free unlimited storage.
http://au.docs.yahoo.com/mail/unlimitedstorage.html
 --0-1575000123-1188194250=:37688 Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

<html><head><style type=3D"text/css"><!-- DIV {margin:0px;} --></style></he=
ad><body><div style=3D"font-family:times new roman, new york, times, serif;=
font-size:12pt"><DIV>Thank you for responding to my previous message. Since=
the time that I sent that, I have recompiled the source code for Linux and=
encountered no problems at the time, and as far as I am aware (after start=
ing each of the applications), the updated code has not broken anything.</D=
IV>
<DIV>&nbsp;</DIV>
<DIV>I will recheck the updated source code in the very near future, but at=
the time that I had been looking at it and editing it previously, the chan=
ges concerned only affected Mac builds, and did not have any impact upon ei=
ther the Windows or Linux builds (or at least no significant impact).</DIV>
<DIV>&nbsp;</DIV>
<DIV>And for at least the time being, I will refrain from committing any as=
sociated&nbsp;changes.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards,</DIV>
<DIV>Geoff Harland.</DIV>
<DIV>&nbsp;</DIV>
<DIV>&nbsp;</DIV>
<DIV>Dick Hollenbeck wrote:</DIV>
<DIV>&nbsp;</DIV>
<DIV>
<DIV class=3Dmsgarea>&gt; I am confused about at least one of these changes=
, and I share your<BR>&gt; concern that there should be a qualified Mac guy=
to maintain the MAC<BR>&gt; stuff. Plus it seems the definition of "MAC" i=
s not stable or defined.<BR>&gt; <BR>&gt; For example, less than 5 days ago=
I added a patch for a MAC guy and now<BR>&gt; this guy wants to undo it, s=
ee file<BR>&gt; eeschema/plugins/netlist_form_pads-pcb.cpp. That patch remo=
ves<BR>&gt; precisely what another guy asked me to add.<BR>&gt; <BR>&gt; So=
they have us going in circles it seems.<BR>&gt; <BR>&gt; We could simply a=
dd a svn tree directory under trunk, called<BR>&gt; pending_patches, and pu=
t stuff there until somebody can go through<BR>&gt; them. This patch effect=
s so many files that one could argue that it<BR>&gt; should be split into s=
eparate patches.<BR>&gt; <BR>&gt; If we go the pending_patches route, you w=
ould have to invent a<BR>&gt; consistent file extension name for these
patches. Give it some<BR>&gt; thought. Frankly I would not expect much mor=
e feedback than what you<BR>&gt; are getting from me.<BR>&gt; <BR>&gt; Fran=
kly I don't care about the MAC specific patches, but I get nervous<BR>&gt; =
about the part of this huge patch file that does effect the linux and<BR>&g=
t; windows platforms, so maybe a patch split on that basis would give<BR>&g=
t; somebody that is a MAC builder the ability to apply a clean MAC specific=
<BR>&gt; patch at any time in the future, providing it is maintained in the=
<BR>&gt; trunk/pending_patches directory in the repository. The part of the=
<BR>&gt; patch effecting everyone could be scrutinized now.<BR>&gt; <BR>&gt=
; This strategy keeps us from running in circles.<BR>&gt; <BR>&gt; Dick<BR>=
</DIV></DIV></div><br>


<hr size=3D1>
Get the World's number 1 free email service. <a href=3D"http://au.rd.yahoo.=
com/mail/taglines/optusnet/number_one/*http://mail.yahoo.com.au"; target=3D_=
blank>Find out more</a>.
</body></html> --0-1575000123-1188194250=:37688-- 




Follow ups