Stuart Brorson wrote: > Guys, > > It's been some time since gerbv experienced any updates. To this end, > several months ago, Ales and I have agreed to help the original gerbv > developer, Stefan, shoulder the work of maintaining and developing the > program. > > Several patches had accumulated for gerbv over the last 1 1/2 years. > Now, at long last I have applied a couple of the patches (i.e. those > which worked) and committed them into the CVS repo in the > STABLE_1_X_branch. > > Now I'd like to appeal for some help. Specifically, I'd appreciate it > very much if folks could assist me in the follwing ways: > > * I tested the latest gerbv stuff by compiling the program with the > patches and looking at a couple of Gerber files (both mine and some in > the "examples" directory). However, we need more exhaustive testing. > I would appreciate it of some people could grab the latest gerbv out > of CVS, verify that they can build it, and then try looking at a few > of their Gerbers to check that everything still works. > > There are several versions of gerbv in the sourceforge repo. The one > you want is the STABLE_1_X branch. Get it using a command simiar to > this: > > cvs co -v STABLE_1_X_branch gerbv > > As usual, info about dealing with SF is available on this page: > > http://sourceforge.net/projects/gerbv/ > > Please let me know if you experience any problems when testing gerbv. > > * If you have any devilish gerbers which test some arcane Gerber > corner-case feature, and you can share them with the world, please > e-mail them to me and I will include them into the "examples" > directory for use in testing as we move forward. > > * If you had submitted patches to gerbv over the last 1 1/2 years, > and had based your patch on a development branch of gerbv, there is a > good chance I did *not* apply your patch. The reason is that there > are several conflicting branches in the gerbv tree, and the > developement branches are badly broken (i.e. won't compile at all).
Sorry, but thats not the experience I'm having. The trunk is building fine for me. The only thing I had to do was replace 1 call to cosf() with a call to cos() and one call to sinf() to sin(). Can you elaborate on the problems you're having? > Therefore, I'm making the (possibly unpopular) decision to require > that patches be submitted only against the STABLE_1_X_branch as we > move forward. The reason is that none of the maintainers have the > time or global view required to sort out all the conflicts which have > crept into the development branches. Over the course of time I intend > to clean out the many different branches which are currently in the > gerbv tree. yuck!!! You do know that there was a good bit of clean up and work on the main branch this year right? It would be really too bad to toss all that out. There are also new features only found on the trunk and I think there are a handful of fixed bugs on the trunk too that were never fixed on the stable branch. I really think you're throwing the baby out with the bath water here. After all, if this were gattrib or gschem, we wouldn't roll back to last years release just because some patches won't apply to the current code. But if you are set on only letting one branch live then I strongly suggest you make that be the trunk. If you really want to toss out the work thats been done one the trunk, then you can always just replace whats there with whats on the "stable" branch. But really, the intention is to let one of these die, then you should get back to developing on the trunk whether it is based on stable branch code or development branch code. Did you ever hear from the guy who had been hacking on gerbv most recently? -Dan _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
