Re: Further Midnight Commander development

[Slava Zanko <slavazanko gmail com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Enrico Weigelt wrote:

>> I propose to establish two branches: "stable" and "current" (in git, of
>> course).
>> "Stable" branch will contain all founded patches (Fedora, Debian/Ubuntu,
>> Gentoo,...), new ideas and features.
>> The "stable" branch will provide the solutions that were tested in the
>> "current" tree. The "stable" branch will lag behind in development, but
>> will be secure and stable (for example, good for RHEL/CentOS, SLES, etc).
>> This scheme would not hinder the development of mc, and at the same time
>> will allow a stable release.
>
> ACK. The "stable" branch should be what goes into public release.
> Everyone who's not actively developing on mc (even those who make small,
> eventually distro-specific fixes) should exclusively base on that.

Yes.

> On the other hand "current" is what's been finished and tested by the
> subsystem devs. So everyone who likes to develop on mc can use it
> for testing.

Yes.

> "Stable" policy:
>     * get in fixes fast and do minor releases for them frequently
>       (so that distros don't have to maintain their own fixes)

Absolutly yes. Maintainers of distros should not include any patches of
security in packages that are based on the stable branch. If any patch
of security or stability is included into package (not in repro) - our
work is a bad.

>     * be very careful about adding new features
>     * breaks should be prevented as much as possible

      * Patches of security and stability can be transferred from the
"current" branch to the "stable" branch

> "Current" policy:
>     * get in everything that's tested/discussed by the devs for
>       further testing
>     * prepare approved patches for getting into stable.

      * Each patch, which will be transported in "stable" branch, will
        be discussed in the mailing list... or at the forum if it will
        ever created
>
> Subprojects (eg. translation, vfs, ...) should have their own trees
> and submit patches (either against stable or current) to the list
> for further discussion.

> Now for the role play:
>
> * we need some people resposible for the stable and the current tree,
>   who have full write access - they have to decide (on discussion
>   in the list) what patches to get in and take care of the tree
>   wont be broken
>
> * bug wranglers should be the ones who look over new bugs, eventually
>   give some first-aid, fixup naming and bounce them to the right people

First of all we need to change the attitude towards visitors. Not all
visitors to the professionals in the programming. Not everything could
be properly explain what they want. We must be more open and friendly.
Then the project will evolve.

Because it's not a project (and people) for the developers - the project
(and developers) for people who enjoy mc. IMHO :)

> * suggested sub-projects:
>
>     -> core
         ^^^^ <it CONTROLLER?>
>     -> vfs
      -> vfs (mcvfs-fs, mcvfs-smb, mcvfs-ssh, mcvfs-ftp,
         mcvfs-dav, mcvfs-... ) <it's MODELs>
>     -> locale
>     -> build-/release engineering
      -> mcslang - <it VIEW(s?)>
      -> mcglib? - <it part of LIB?>
      -> mcgettext (may be part of "locale") - <it VIEW(s?)>


>>> As for the Russian issue: we devs should really agree on one well-spoken
>>> language, English. Those who're not yet capable of speaking English,
>>> could be proxied by others. That speaking of *development* - end user
>>> support is an different issue.
>> Between developers one language: English (because Esperanto don't all
>> know... ;) BTW, It would be a good idea that the world learned Esperanto
>> in schools... IMHO :) ).
>
> Maybe we all should start learning Interlac ;-O
:)

>>> *1: I'm currently in the process of reviewing Gentoo's patches and
>>> sending them to the list.
>> It's good. All existing patches are to gather in one place.
>> BTW, look, please, http://www.midnight-commander.org
>> I think that this URL will be the main location for bugreports...
> hmm, should I upload all patches to trac ?
> Is there a more convenient way to do that, instead of all via web ?

Gmm.. answer: 'yes'. Via trac-xmlrpc plugin (don't nkow, Patrick
Winnertz was add this plugin or no) and via using xml-rpc applications
(eclipse-mylyn, for example). But if via web  you will be uncomfortable,
just send patches in maililing list. I will transfer your patches in trac.

WBR, Slavaz



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAklWK7QACgkQb3oGR6aVLpo5CgCfSc53npEOJcoAvWYrCw+meEn/
DEsAnRNe4jumsCL9CNKvTjbbi6EVcrTs
=/ZL/
-----END PGP SIGNATURE-----