Hello, Frédéric!
On Sun, 1 Apr 2001, [iso-8859-1] Frédéric L. W. Meunier wrote:
> Hi. I see GNOME released 4.5.52 2 weeks ago (March 18), but CVS
> still uses 4.5.51 in configure.in. Is 4.5.52 from CVS, with all
> changes before this date ?
It's great! Thanks for informing us!
Unless anybody protests, I'm going to upgrade the version number on CVS to
4.5.52a to avoid any confusion. Many projects use letters to indicate that
it's a CVS version.
> BTW, I hope you can now remove gmc :)
I hope too, but only if Miguel approves it. Until then I'll do everything
to prevent breaking the GNOME frontend by the new changes.
I have a mixed feeling about removing the GMC support. It will clearly
make the life easier for those who want to contribute to MC but don't want
to install and learn GNOME.
On the other hand, the removal of GMC will be admitting our weakness.
Given enough qualified manpower, MC could have become a modular project,
with an UI-independent core, shared libVFS with loadable modules for every
virtual filesystem and separate frontends targetting different users and
not sharing any code with each other.
This didn't happend for several reasons.
The first and foremost, user interface projects don't usually attract
attention of the developers with a sufficient expertize to thoughtfully
_design_ the project. An exception is a when the project has a high
visibility, which is the case for GNOME, but not for Midnight Commander.
Most contributions to the user interface projects are (unsurprisingly)
concerned with the user interface. People submit small improvement to fix
things, but, due to a wrong design, an improvement for one frontend can
break another one, and a patch for the manual can make in out of sync with
its obsure "source" that can only be processed with a historic software
with an additional patch.
Secondly, unlike MC, maintainers of most projects are usually their
principal developers. They can commit an incomplete patch if they know
that the release is not going to happen soon and they know that they will
be able to fix the broken parts eventually. This allows for a greater
flexibility for the developers and makes it possible to redesign the
project step by step.
In the case of GNU Midnight Commanger, most commits between 4.5.51 and
4.5.52 were made by people who not only have no control over the release
process, but were not even informed about the release.
Whether GMC will be removed or not, I'll have a sad feeling that we could
have done it better. In the meantime I'm going to apply some patches that
don't cause regression for any edition.
Regards,
Pavel Roskin
