libftdi Archives

Subject: Re: libftdi-0.20 missed a commit for OSX?

From: "P. Martin" <mrsmiley98@xxxxxxxxx>
To: libftdi@xxxxxxxxxxxxxxxxxxxxxxx
Date: Sun, 25 Mar 2012 21:01:01 +0000 (GMT)
On Mar 23, 2012, Xiaofan Chen <xiaofanc@xxxxxxxxx> wrote: 
> 
> > On Sat, Mar 24, 2012 at 4:05 AM, P. Martin <mrsmiley98@xxxxxxxxx> wrote:
> >
> > Ahh, I didn't notice the two branches.  Now I see what's happened.
> > Thank you for explaining that.  In the case where a fix that exists in
> > head won't be backported to stable, the Homebrew maintainers
> > will wait for a new version that does work.
> 
> What do you mean by that? You can always pick the patch
> and include that with your homebrew formula, right?

If the python bindings are not desirable, then we can drop
all this and let Homebrew just use configure.

But the problem is that you have python bindings, and I'm
under the impression that you want those to work.  Those
only work when I build with cmake, not configure.

I'm also under the impression that the 0.2x branch is the
main one that people use, it's current, and it's good. 

So yes, I could figure out the three patches it takes to fix lib64
in your cmake build scripts, or I could make my own patch.
Five months ago, that is what I did.  I submitted a pull request
to upgrade libftdi from 0.17 to 0.19, switch from configure to
cmake, add python support, fix lib64, and install the docs.  My
request was left open for four months, during which time the
Homebrew admins waited for a new version.
https://github.com/mxcl/homebrew/pull/8351


The new version came out at 0.20, with no fixes.
They decided to go with the current formula that uses
configure and to not use my formula.  Configure can't
compile the python bindings, but at least it's smart enough
not to try to install to lib64.  So what they got was a formula
that builds with no changes to the formula other than the
tarball and sha1.
https://github.com/mxcl/homebrew/pull/10132

But I feel the formula is not correct because configure fails
to build the python bindings.

If I patch the formula to change from configure to cmake
so it can build the python bindings, and patch it to fix lib64,
the request will sit open for another half a year while they
wait to see if someone mentions the fix works or doesn't,
or for a new stable with the patch.  There is very little incentive
for them to accept my pull request in the absence of any
'make check' to prove it works and the absence of proper
hardware to test it themselves.

So what they have is a formula that compiles,
and they have no complaints about python bindings
missing.  It's all me who thinks your software should
work as well as it can because I have a degree in
Physics with A's in Analog Electronics, Digital Electronics,
and Computer Interfacing.  In Homebrew's opinion
my changes are extreme, unproven, and annoying.
Why are they annoying?  It's because my patches have
to be tested on Lion with 2 compilers, Snow Leopard with
three compilers in 64bit or 32bit mode, and Leopard with
three different compilers 32bit mode.  That's a total of 
11 different test phases for each option I put in the
formula.  The formula has an option to brew your
python bindings or not. So that's two options on top
of 11 tests, meaning 22 times this has to be reviewed,
none of which times can we prove to ourselves it works,
all on top of a working formula nobody is complaining
about.  Add to that people could use the system python
or build their own Homebrew python is another two
options.  So now we are at 44 test runs.

So faced with 'it just works and no complaints' versus
44 test phases only to have the patches break in a few
months and have to start this all over again, the admins
will continue to do what they have already done.  Put
my pull request on the bottom of 213 other open ones
that are not in demand, complex, hard to test, or bound
to break in a few months when the patches no longer
apply correctly.

Or libftdi could be fixed in 5 minutes by a few vcs
commands.  Maybe you see why I rewrote this 6 times
over two days where it never comes out well.  It's
enormously complex on Homebrew's end to do what
you think is just apply a patch.  And even if we do, how
does that help other people who don't use Homebrew?
It doesn't. So it's not proper, and it's nearly impossible
to explain that to developers.

 
> If not, please update the Homebrew formula with a HEAD
> option so that git head can be used. Thanks.
> BTW, it seism the 0.20 formula has already been in.
> I just ran "brew update" and fount out that.

Yes indeed.  I should probably take that as a clue to not
try to alter the formula again, seeing as they chose that
over my formula that enhanced libfti.  Now that I think
about it, I'm pretty sure I'm done with this.  Homebrew
doesn't care if I patch 0.2x, and libftdi doesn't care to
either.


--
libftdi - see http://www.intra2net.com/en/developer/libftdi for details.
To unsubscribe send a mail to libftdi+unsubscribe@xxxxxxxxxxxxxxxxxxxxxxx   

Current Thread