* Slava Zanko <slavaza...@gmail.com> schrieb:


> 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.

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.

"Stable" policy:
    * get in fixes fast and do minor releases for them frequently
      (so that distros don't have to maintain their own fixes)
    * be very careful about adding new features
    * breaks should be prevented as much as possible

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

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 
* suggested sub-projects:

    -> core
    -> vfs
    -> locale
    -> build-/release engineering

> > 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

> National subprojects facilitate communication and reduce the dirt in
> (English) project (diplicates, invalid bugreports, etc).

ACK. For example, user support should look carefully what's really a bug
or just a help request. Only real bugs should go to the devs, help
requests should be handled by the support people.

> > *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 ?

 Enrico Weigelt    ==   metux IT service - http://www.metux.de/
 Please visit the OpenSource QM Taskforce:
 Patches / Fixes for a lot dozens of packages in dozens of versions:
Mc-devel mailing list

Reply via email to