[Mono-dev] Unit Testing process: Community Contributions
Alex J Lennon
ajlennon at dynamicdevices.co.uk
Tue Oct 21 14:29:57 UTC 2014
On 21/10/2014 16:18, Miguel de Icaza wrote:
> Unfortunately there were issues, most obviously with an exception
> to show a textbox.
> So I read up on how to file a bug report
> did so, with a test case that shows the problem in a
> straightforward manner.
> Glad you did this. A good bug report with good information will give
> the person that will look into the bug many more clues as to what is
> The bug report was filed in May and is here:
> So, I don't know, maybe I went about this wrongly, but I tried to
> the procedures laid down for raising this as I understood it.
> Let me set some expectations here.
> Windows.Forms is not actively developed or maintained. If you want
> support for Windows.Forms your best bet is to hire a contractor to fix
> Windows.Forms for you.
> The Mono team stopped full time development of that stack sometime
> around 2009 (give or take a year). While I would like to remove it,
> there are certain dependencies that require it, so we keep it around.
Thanks Miguel - the background helps me to understand the situation.
> I also made it clear that I was happy to put some time on and work on
> this but could do with some support to get going, so I'm not trying to
> freload on others doing the work here.
> Yet there was absolutely no response at all. Not "redo the report for
> this reason", "you need to look here", "we're looking at this" or even
> "we have no intention of fixing this".
> I can see that this can be frustrating, but filing a bug does not mean
> someone is going to look at it.
> You might have gotten a *little bit* more engagement if you post to
> the mailing list, as opposed to waiting for the rare case of someone
> accidentally strolling into the bug. It is a long shot, but worth a try.
I did try that a few times, as I recall, when there was no response :)
> This is not different than any other open source project. If you
> want to keep a particular port of Linux alive, you have to do the
> work. You want to maintain some drivers? You have to do the work.
> People do not respond to your issues? You must reach out. There
> is no community around a particular feature you need? Rally the troops.
I am happy to do the work, where I can, and where I cannot I do not
expect others to do the work unless I happen to be paying them for their
What I'm trying to suggest is that for the idea of "community" to work
it helps if there's engagement with those who wish to become involved.
It's a pipeline. I believe engagement is a win-win as time spent
fostering no-nothing newbies like myself will (one would hope) result in
a small percentage of those no-nothing newbies turning into useful
contributors, for the betterment of the project.
And that's impossible without some level of time-investment in
engagement - such as having somebody respond to bug reports even if this
is to say "sorry this is unmaintained - your problem"
> It's really discouraging when you put in the time and try to
> follow the
> procedures laid down but there is absolutely no engagement. I mean
> - why
> bother again if there's no point?
> I agree, do not bother with unmaintained code. Instead use stacks
> that are actively maintained, like Gtk#.
If only life was that simple :) To reiterate though, I'd have tried to
fix this if I knew where to begin looking, as I have applications here
that need System.Windows.Forms and which I can't simply abandon or rewrite.
Presumably Microsoft still views as System.Windows.Forms as maintained?
Or have they abandoned it too?
Is there a place where I can see a matrix of what components the Mono
project views as unmaintained and therefore what kind of .NET
applications may no longer run under the current release of Mono?
Thanks for the feedback,
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mono-devel-list