On Tue, Aug 5, 2008 at 3:06 PM, Peter TB Brett <[EMAIL PROTECTED]> wrote:
> I still think libgeda should be statically linked into the gEDA apps at
> build time and not installed. :(

libgeda version mismatches certainly make for many user frustrations,
that really shouldn't be necessary.  I'm more of an
anti-static-library kind of person, so I'd rather just de-atomize the
gschem-* binary packages instead.

> [1] Bernd, your opaque objects stuff is pretty cool. But there seems to be
> so much random stuff mixed in with it! I really wish you'd use stgit or
> something so that you could keep your patches in a sane order, and
> immediately submit anything that no-one would dispute belongs on trunk. At
> the moment, if we want to merge your humongous branch, it looks like we're
> just going to have to take your word for it that it doesn't contain any
> changes that are going to come back and bite us in the ass, because I don't
> see how anyone's going to successfully review it.  D-:

I'll read up on stgit (despite not even having quite conquered plain
git - I have a love/hate relationship with it) for its apparently
magical capabilities (I'm willing to suspend my disbelief after
experiencing the DVCS paradigm shift).

I'm just glancing over the log of my opaque objects branch and so far
I've found but one truly "random" patch - the others are all in some
way necessary to allow the desired struct knowledge apostasis.  When
I'm finished (not far off now) I'll distill a list of patches that can
also be applied independently to master.  I do see a few "topics" that
could exist independently but are all necessary to make objects
opaque.

Is there anything in particular that strikes you as particularly
random, besides the interleaving of these "topics"?


_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev

Reply via email to