On Fri, 2010-02-19 at 19:05 -0500, Dan McMahill wrote:
> Peter Clifton wrote:
> > On Fri, 2010-02-19 at 09:53 -0500, Julian wrote:
> >> Hello all,
> >>     The list has been fairly quit, so I thought I'd see if anyone was
> >> game to push out a new release.  I haven't added any new features, but
> >> we've had a steady stream of bug fixes in the past 8 months or so, so
> >> it would be nice to get them out to everyone.  I can potentially roll
> >> up a release too, but have never done it before so it might be less
> >> trouble for someone else.  Let me know your thoughts--
> >>
> >> Julian
> > 
> > If there have been no new "features", then release 2.3.1, and we can
> > look at getting a freeze-exception for including it in Ubuntu Lucid.
> > Ubuntu Lucid will be a long-term-supported release, so is likely to see
> > more users (over a longer time period) when compared to a normal Ubuntu
> > release.
> > 
> > Best wishes,
> > 
> > Peter C.
> 
> I would need help in figuring out how to pull up all the changes then to 
> the gerbv-2-3 branch.  I don't want to release 2.3.1 starting from 
> somewhere besides the 2-3 branch.

Either cherry-pick each individual fix, or merge. cherry-pick would seem
more appropriate, just in case any non-bug-fix commits crept in.

Another work-flow (which I used for translations in gEDA), is to commit
fixes onto the stable-?? branch, then merge back into master.

Looks pretty simple to me though..

This commit might not be considered a bug fix by some upstreams if they
looked closely though:

committer: Julian Lamb <[email protected]>  2009-09-23 04:16:51
Parent: 2492bc7c35501a99223419687cffdc385350b760 (Fix FAST mode translation 
rendering error in Y direction (bug 2858102))
Child:  bb2a0b8664a2be1fb6fa43ec4d93a06d0a83b7b7 (* fix regression in FAST mode 
rendering with flashed apertures)
Branches: master, remotes/origin/master
Follows: gerbv-2-3-base
Precedes: 

    Modify our parsing behavior for RS-274D files
    
    Try to parse files we suspect as RS-274D because of missing apertures/etc
    (fixes bug 2864667), and create dummy apertures to roughly visualize the 
file
    if it is actually a RS-274D file (fixes feature request 566142).


Still - commit log says it fixes a bug ;)

Author: Julian Lamb <[email protected]>  2009-11-05 13:49:52
Committer: Julian Lamb <[email protected]>  2009-11-05 13:49:52
Parent: bb2a0b8664a2be1fb6fa43ec4d93a06d0a83b7b7 (* fix regression in FAST mode 
rendering with flashed apertures)
Child:  00d772b56aafdc7aa5e30555d620fd33c1a9a7ad (Fix sidebar bug where small 
scale and translations in X did not display a marker (bug and fix by mland, bug 
#2901881()
Branches: master, remotes/origin/master
Follows: gerbv-2-3-base
Precedes: 

    apply patch from Uwe Bonnes to display the total aperture uses in the 
anaylsis tool (patch #2892537)


This is not a bug fix.



Anyway... I don't think either would cause too much problem.


>From my checkout, it seems that you don't actually have a stable branch
- just some tags (CVS legacy?) You could create the stable-2.3 branch
from git HEAD, then do your release engineering on it, or you could
"pretend", go back and create a branch from the gerbv-2-3-RELEASE tag.

git checkout -b for-stable-2.3 gerbv-2-3-RELEASE
git push {REMOTE_NAME_PERHAPS_origin_?} for-stable-2.3:stable-2.3

You'd probably want to merge / cherry pick all of what is in master onto
that branch..

A further thought - is that you could be evil - and re-write some
history here.. if we pretend that all which is git HEAD "master" is
actually the stable-2.3 branch (Just create a branch of master, then
push),

then force-update master to match the start of that supposed branch -
e.g. gerbv-2-3-MASTER, you could then merge the stable-2.3 branch (which
was up until just now "master"), into the new "master" branch - as if
they were all stable updates made on the stable branch.

Slightly naughty in terms of people who might be working on top of the
master branch, but it ought not to be insurmountable.

Thoughts?

I've CC'd Peter Brett, for a second opinion on the git evilness I've
suggested above ;)

Best regards

Peter C.



> -Dan
> 
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Gerbv-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/gerbv-devel



------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Gerbv-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gerbv-devel

Reply via email to