geda-developers team mailing list archive

[Peter TB Brett <peter@xxxxxxxxxxxxx>]

On Wednesday 14 November 2012 17:27:37 Gareth Edwards wrote:
> On 14 November 2012 10:20, Peter TB Brett <peter@xxxxxxxxxxxxx> wrote:
> > Mmm.  Not sure.  I would be inclined to say that when a deprecated
> > function can be replaced by an equivalent in a very straight forward
> > and obvious way, then we should go ahead and do it in the stable
> > branch. WDYT?
> 
> I think that I should probably just cherry pick everything in HEAD
> that looks like a valid "non-feature" change and we re-stabilise the
> stable-1.8 branch from that point - treat it as a bit of a fresh
> start.

That sounds fairly reasonable. I've done the translations import now, 
and pushed the patches; after you pick the patches across I'll merge 
them into 'master' too.  I've got a list here that I threw together this 
morning:

- libgeda: only include top level glib header
- libgeda: fix dereference after NULL check
- gschem: Remove dead code
- gschem: fix unsafe use of strncpy
- gnetlist: cleanly discard unused power tag in s_netattrib.c
- gschem: suppress compiler warning in line type dialog code
- gschem: replace deprecated call to g_strcasecmp () in gschem-version 
Guile function.
- gnetlist: remove unused pointer value from s_traverse_component()
- libgeda: Remove redundant checks against NULL in s_encoding.c
- Add TAGS files produced after make tags to .gitignore
- gschem: remove unused pointer values in multiattrib code
- gschem: replace deprecated calls to g_strcasecmp ()

Anything I've missed?

I don't know if you use stgit, but if you do, I would suggest using `stg 
pick -x` so that the original commit ID gets added to the log message. 
(I have a TODO to fix stg so that it adds some newlines between the 
existing log message and the extra text it adds, but haven't got round 
to it).

> I've also been a bit fast and loose with marking the Launchpad bugs
> for release 1.8 so I will need to go back and see if I have any in the
> wrong bucket.

Thanks, that would be good.  It's handy to know what releases a bug 
applies to.

                     Peter

-- 
Peter Brett <peter@xxxxxxxxxxxxx>
Remote Sensing Research Group
Surrey Space Centre

Attachment: signature.asc
Description: This is a digitally signed message part.