[Mono-dev] Arguing for reconsideration of WONTFIX status of 425512

[Stifu]

About taking developer time: point taken. No matter how small the change is,
if there are 50 such demands, things get different quickly. Unless, of
course, the patch is submitted by a 3rd party, in which case the it's only
reviewing time, which in most cases should be negligible.

And although forking is possible and a good point of FOSS, I have to
reiterate that I think it's a bad idea in such a case. Forking a certain
little app to fit your needs or to do new things is usually good, but if
it's a whole framework, it's really a different thing to me. Deployment just
wouldn't work. I can't see myself telling my users "Please install my 100 KB
app, but also my own 400 MB version of the framework"... Assuming the user
is okay with that, that'd be like opening the gates of hell (big download,
possible incompatibilities with other Mono apps, or installing Mono twice,
etc... I can't imagine that).
The only way it could possibly work, I think, is if it was a slimmed down
version of the framework (as is possible easily enough, from what I read),
or a static compilation of the classes I need or something like that... and
then again, updating your own framework as new Mono versions come out may be
an annoyance, and not something you want to do, especially for a tiny change
you wanted on Mono... and your users wouldn't be able to update the Mono
version themselves without breaking your app, and so on. Just not worth it,
no matter how I look at it. I'd rather just do if(IsMono()) { DoThat(); }
and go on with life.


Jérémie LAVAL wrote:
> 
> Take the reverse situation, why would Mono devs care on supporting
> application X because some users would like to run X on Mono ?
> 
> The only difference here is that, in your case, the developer has to take
> care of one platform with minimal change involved where Mono would get ton
> of request preventing them to focus on coding real things.
> 
> Also, all of the applications cited are open-source AND free software
> which
> allow you to patch them freely. Then if the main developer is stubborn
> enough to refuse your patch, just make it available or fork the project,
> that's one of the advantage of FOSS.
> 
> --
> Jérémie Laval
> jeremie.laval at gmail.com
> http://garuma.wordpress.com
> 
> 
> On Thu, Feb 12, 2009 at 3:23 PM, Stifu <stifu at free.fr> wrote:
> 
>>
>> What about developers who don't care about Mono, but some of their users
>> being interested in running their app in Mono?
>> Sure, they could contact the devs to insist on supporting Mono, but then,
>> first, the app must still be under development, which is not obviously
>> the
>> case, and second, the devs must be willing to listen and act... It'd just
>> be
>> much easier and more convenient if it just worked right away, if there is
>> no
>> downside involved.
>>
>>
>> Jérémie LAVAL wrote:
>> >
>> > There is a difference between implementing a public API used by lot of
>> > people and implementing low-level internals that 1/ you aren't supposed
>> to
>> > know in the first place, 2/ are used by 2-3 projects that could fix the
>> > bug
>> > with a two lines change if they cared about Mono.
>> >
>> > --
>> > Jérémie Laval
>> > jeremie.laval at gmail.com
>> > http://garuma.wordpress.com
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Arguing-for-reconsideration-of-WONTFIX-status-of-425512-tp21975511p21977064.html
>> Sent from the Mono - Dev mailing list archive at Nabble.com.
>>
>> _______________________________________________
>> Mono-devel-list mailing list
>> Mono-devel-list at lists.ximian.com
>> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>>
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
> 

-- 
View this message in context: http://www.nabble.com/Arguing-for-reconsideration-of-WONTFIX-status-of-425512-tp21975511p21977704.html
Sent from the Mono - Dev mailing list archive at Nabble.com.