gEDA-dev: SF.net patch status (5 open)

[Peter TB Brett]

On Monday 16 April 2007 22:23:44 Stuart Brorson wrote:
> On Mon, 16 Apr 2007, Peter TB Brett wrote:
> > Hi folks,
> >
> > The following patches are currently open on SF.net:
> >
> > # [ 1600928 ] Have gnet-spice-sdb handle slotted components.
> >
> >  Status: merged, no reported problems.
> >  Action: I will close if no objections by Sunday.
>
> Please close it.  This was already merged.  The following notes are in
> the spice-sdb source:
>
> ;;  2.10.2007 -- Various bugfixes.  Also incorporated slotted part
> ;;               netlist patch from Jeff Mallatt.  SDB.

Closed.

> > # [ 1661760 ] New refdes numbering tool
> >
> >  Status: refdes-renum now does everything this tool seems to do
> >  Action: FreeDog member(?) to liaise with Rik Wehbring and find out if
> > there are any features not in refdes-renum that he thinks should be
> > added. I will close (rejected) this patch if no objections by Sunday.
>
> Actually, I think this is a new program by the submitter.  Personally,
> I see no reason to reject it.  We can have multiple refdes numbering
> utilities IMO.  We already have at least four ways to number refdeses:
> the Scheme stuff in gschem,
> refdes_renum, grenum, and now this one.  Let's discuss what to do with
> it on Sat instead of just rejecting it.  Why piss off a potential new
> developer?

Agree.  However, there really don't seem to be any major things that this does 
that refdes_renum doesn't.  In fact, I'd be happy to see the refdes 
renumbering tools narrowed down to one "official" command line tool and 
perhaps the one built in to gschem too; surely there's only so many different 
ways to update annotations in a schematic?

> It's like the proliferation of boxsym utilities.....

That's a slightly different business.  I don't mind how many there are, as 
long as the number we distribute with gEDA is kept down to the minimum 
sensible.  If we put everyone's favourite little scripts into gEDA, it would 
end up being gigabytes... ;)

> > # [ 1662285 ] tragesym: different behavior for large symbols
> >
> >  Status: Unknown. Who is the maintainer for tragesym?
>
> I wonder if the requested behavior is already taken care of by
> *boxsym?  (* = dj, and one or two others.  They are on
> gedasymbols.org.)  Otherwise perhaps this is a good project for me
> during the code sprint?  (Although I do have some other plans
> already.....)
>
> If desired, we can converse about these in real time on Sat via IRC.
>

Sounds good.

Cheers,

Peter


-- 
Fisher Society committee                    http://tinyurl.com/o39w2
CUSBC novices, match and league secretary   http://tinyurl.com/mwrc9
CU Spaceflight                              http://tinyurl.com/ognu2

v3sw6YChw7$ln3pr6$ck3ma8u7+Lw3+2m0l7Ci6e4+8t4Gb8en6g6Pa2Xs5Mr4p4
  hackerkey.com                                  peter-b.co.uk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.seul.org/pipermail/geda-dev/attachments/20070416/a673cf83/attachment.pgp