On Mon, Jul 10, 2006 at 07:30:07PM -0400, Mark Whitis wrote:
> On Sun, 9 Jul 2006, Ron wrote:
> >This is disabled by default (and consensus) upstream, since it accrues
> >additional external dependencies. What do you need it for?
>
> Well, I am writing an application that displays images from a high
> resolution webcam so it may or may not be useful, but without
> a working sample I don't have a way to judge that.
That's a little melodramatic, you have the source and are as close
to having this particular extension enabled as any other user.
Since it seems safe to assume this particular app will not be ready
for stable release by the time etch is frozen, and a fact that no
app in the dist can make use of it, then enabling it prematurely
seems like senseless bloat to me.
I've made it incredibly easy for you to build your own 'flavour'
of debs, and install them concurrently with the distro ones so you
don't have to sacrifice any working apps you have to the dream
undergoing construction.
By the time you are ready to release, you are probably going to want
the 2.6 + 1 release (whatever it may be numbered) in any case, but
laying the foundation on something changing less quickly is wise.
When it's ready to enter the dist, give me a ping and we'll look
at enabling what we need. Until then, let's not burden everyone
else with what I gave you the tools to do painlessly yourself.
> >How I resolve this bug (removing the useless sample, or inflicting
> >a new dep on all users), really depends on what is best for the dist.
>
> Do NOT remove samples. They are part of the package. You can add
> a README.debian to the sample directory or /usr/share/doc with your
> comments.
You seem to miss a couple of points... there are _thousands_ of pages
of wx documentation. Reading them all is going to take quite some time,
and will probably be essential to understanding the _dozens_ of variously
incompatible options that wx can be built with. The -examples package
does NOT profess to be a bunch (let alone a complete bunch) of "working
samples". It is cut-and-paste-documentation, a companion to the other
thousands of pages for people who want an authoritative quick-start guide.
I have been pretty casual toward simply supplying those which exist in
cvs, but Bad Documentation is bad documentation, so if they are causing
confusion, we should nip it out at the bud. One of these, so called,
examples, demonstrates nothing more than an unimaginative memory 'leak',
which the braindead checker will flag for you to 'fix'. If you want fries
with that, the fix in this case (if anything outside that function actually
used the memory allocated by this rigged demo), would be wastefully dumb,
at least if the same bad coding practices were to be imitated. (The fix
'suggested' just shows the example to be totally out-of the real world).
It is perfectly acceptable, even wise, not to delete what the system
will reclaim from you in one fell swoop. There is nothing in any of
these objects that requires shutdown processing except pedantry.
So there is nothing but bad habits to be learned from memcheck.
Beware of blunt tools, they are the antithesis of sharp thinking.
I still think we should put this one away where it can't hurt any
more innocent bystanders.
As to the other, I don't much care. If it is causing confusion since
it won't build with the dist binaries, then its probably best to yank
it from -examples, it will still be in the source package where anyone
who builds a lib to suit can use it...
> The correct way to handle this would be to make inclusion of
> the media class library optional, but the upstream package may need
> some work before you can easily do that.
It should be an entirely separate library, in its own (binary) package.
But all that is pointless busywork if no-one actually needs or uses
it. If you are using it, then you should probably get together with
any others who are and kick this into shape.
We can add the extra package easily enough once the need is real and
the legwork is done...
> >Until now, no one has needed it, nor complained. If that has changed,
> >we can run a straw petition here to see who or what this extra cost
> >for existing users would help...
>
> You have no way of knowing if anyone needed it. You only know if someone
> reported it and that is usually a small percentage of cases.
Which part of : every app in the distro builds with the present config, and
every user can build their own flavour ; seems to leave you in doubt here?
The people who need things and can help themselves, clearly already have
(since I mostly haven't heard from them), while the people who can't,
usually have no trouble connecting my email address in the package
description with someone to pester, politely or otherwise... :-)
So I'm probably about as well informed as the system permits. If you
think you are better informed, I'd be delighted if not wizened, to hear
the salient bits about it.
But without any actual app to use this with, I think I can be pretty sure
that no one is using it for more than something to fill these modern
humongous hard-drives with (to make it look like you really need one;).
So the question remains, is a sample that cannot build with the dist
binaries:
a) useful as documentation,
or
b) confusing to people who might expect it should build?
It's a question that only statistics can answer, I fear there is no
consensus likely on this preference, but if there is a clear answer,
then what we should do about it is likewise clear.
I have no preference, I'll leave this to a poll if anyone else cares
to tip the scales one way or the other. People can vote for memcheck
too if they like, but that will probably just be embarrassing at some
point later in their career... ;-)
hth,
Ron
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
