Re: mc^2 news (august 2016)

[Andrey Gursky <andrey gursky e-mail ua>]

Hi Yury,

On Thu, 18 Aug 2016 21:00:31 +0200 (CEST)
"Yury V. Zaytsev" <yury shurup com> wrote:

> On Thu, 18 Aug 2016, denisgolovan wrote:

[cut]

> > I mean to structure those 500+ bugs/features ("future" milestone) in 
> > some meaningful way + put some estimates(weeks, dollars)/difficulty for 
> > them and try to pursue people on popular Linux forums for support.
>
> If you are willing to invest some serious effort into pulling out 
> something like that, let me know if there is anything I could reasonably 
> help you with.
>
> In my personal view of the situation, however, then the biggest problem 
> with mc codebase today is the abysmal state of test coverage, which makes 
> maintenance a gamble and demands extreme efforts to review patches.
>
> Before this problem is addressed, I'm not very positive about soliciting 
> massive contributions, which will end up rotting on the Trac waiting for 
> code reviews and rewrites... that might never come.

Once I read the beginning of this last sentence I knew I've heard
something very similar already before. Indeed, it was on the last Chaos
Computer Club meeting [1]. In short: Some developer contributed a nice
feature, it was good but it wasn't good enough for the (now former)
maintainer of libusb. He wanted to get it more stable before he would
release it. The issue was, that the other developer didn't share his
opinion on the not so high quality of the implementation, since it did
just work. The result of this confrontation was pretty sad for that
maintainer.

In my opinion there are at least two kind of open source projects:
private and community ones. While the author is allowed to do what and
how he/she want in the first case, the second case is different. It is
a compromise of how it should be and how it can be really done. (I
personally also don't very like all these compromises, but it really
seems they are unavoidable). While a maintainer can ask to contribute
tests and say that has a 1st priority, this is OK, but to block the
ongoing work to force other to work on that solution (or to force other
to wait until a maintainer himself completes this) is a no go in my
opinion.

Regards,
Andrey


[1] libusb: Maintainer fail
    How I failed to run an open source project
    https://media.ccc.de/v/32c3-7547-libusb_maintainer_fail