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


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

Glad you understood it :)
The folks of many, many other still refuse to - that's why I founded the
OSS-QM project (http://oss-qm.metux.de/) years ago, to have a stable
overlay virtually any distro can base on (I especially needed it for
my embedded projects).

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

ACK. Of course, if we have trivial patches with very high urgence,
we *could* skip that path sometimes, but that should be *really* rare.

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

Actually, I don't like web-forums. Too inconvenient - you always have to
visit (and log into) some webapp to see what's happening. Please let's
stay in this maillist and eventually connect trac with it.
(would be great if patch uploading could be done via a mail robot)

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

ACK. That's the job of the user support team. Actually I'd like to see
more non-coders in the support team, because they have the user's view,
not the coder's.

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

huh, I'm not sure whether mvc fits in here. 
Well, if we say "everything's a file" and the model is the vfs 
(including things like search results represented as filesystem),
we could make some steps in this direction :)

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

Okay. I've sent out all gentoo patches so far, they're not too many.
But for the future it would be cool to have the upload process 
done automatically - with a local command line would be even better.

 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