[Mono-dev] InterOp problems with 1.2.6pre2

Alan McGovern alan.mcgovern at gmail.com
Sat Dec 1 08:12:33 EST 2007

If you find a bug that affects you that you need fixed, it's up to you to
show that there is a bug. If you paste code in an email, of course people
are going to look at it. If that code is wrong, well, that's not our fault.
You shouldn't paste code which supposedly shows an issue when in fact that
code has nothing to do with the actual issue because the code is incorrect.
Of course no-one would bother looking at SVN because they'd think they
already found the bug.

Your time may be limited, but suppose *everyone* who reported a bug expected
the mono team to go download sources, compile sources, get god knows how
many dependencies so the sources will actually compile, then try and track
down a bug in that code. That'd take forever and nothing would get


If you want something done and want it fast, make it easy for the bug


On Dec 1, 2007 8:01 AM, Prakash Punnoor <prakash at punnoor.de> wrote:

> On the day of Friday 30 November 2007 Andreas Färber hast written:
> > Am 30.11.2007 um 22:10 schrieb Prakash Punnoor:
> > > On the day of Friday 30 November 2007 Robert Jordan hast written:
> > >> The layouts don't match, since declaring a field "private" won't
> > >> magically subtract it from struct layout.
> > >
> > > It would help if you'd look at the svn version as I wrote in my
> > > mail. Reading
> > > helps, really....
> >
> > Careful there: You are writing to the development list of Mono and you
> > seem to want help for a problem you are encountering with some third
> > party library. So first of all, this is actually off-topic for this
> > list in two aspects. To get help non-the-less, file a proper bug
> > report with a self-contained test case, best place would be in
> > Novell's Bugzilla with a link here. Pointing people to some SVN code
> > they have to checkout and configure etc. is definitely not a self-
> > contained test-case. And when you do provide code then it's your
> > responsibility to make sure it's the correct code you're talking of,
> > not Robert's.
> >
> > See: http://www.mono-project.com/Bugs
> My time is limited. I could also simply ignore the bugs I encounter and
> try to
> find work-arounds. It is not my duty to give you test-cases. You the mono
> devs should see it as a courtesy that I report anything. It wouldn't take
> too
> much time to simply reproduce it and with the knowledge mono devs have
> they
> could pinpoint it faster then I have done it by wildly guessing. And in
> fact
> my report was pretty concise. I wrote down everything you need to know to
> reproduce that bug.
> I don't need your help. I report a bug in mono, so I help you to make your
> product better!
> I compare it with Linux kernel mailing list: There the devs respect the
> users
> and at least react to mails. The least I expected was a reaction and
> perhaps
> a hint what the posted error means so I could perhaps provide a small
> testcase within 5 minutes.
> In another post, I tried to contibute a small optimizing patch for
> UInt32.Parse. Did I get any reaction whatsoever? Did I?
> So moral of the story: I won't waste my time anymore on the mono mailing
> list.
> If you want people contributing - be it with code or bug reports - no
> matter
> whether the way of postig fits your taste or not - learn to respect that
> the
> contributers actually sacrifices some time for mono.
> Good luck!
> --
> (°=                 =°)
> //\ Prakash Punnoor /\\
> V_/                 \_V
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20071201/5b9d79e7/attachment.html 

More information about the Mono-devel-list mailing list