hurd-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

GNU Mach maintenance Re: gnumach patches


From: Marcus Brinkmann
Subject: GNU Mach maintenance Re: gnumach patches
Date: Tue, 08 Nov 2005 17:20:54 +0100
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Fri, 04 Nov 2005 21:51:41 +0100,
Alfred M Szmidt wrote:
> 
> I will commit the following three patches in 4 days to
> gnumach-1-branch.  I will also take over gnumach-1-branch after those
> four days (and apply the same rules as for ams-branch in the Hurd
> repo).  Unless someone screams loudly in my ear...
>
> I only do this since I do not wish to see things die, and Roland is
> busy with other stuff.  But just 'cause he is busy with other stuff
> doesn't mean that patches should be lying around like this and gather
> dust, and in the worst case be forgotten.

Just because the maintainers are busy it doesn't mean you get a
license for a coup d'etat.

My main concern is that you are simply circumventing the GNU
maintainer process.  Instead of stepping up to actually share the
responsibility and burden of maintainership, you want to apply patches
simply because they are around and should not carry dust.  This is a
stupid policy.  Patches should be applied because they improve the
code.  If they don't, they shouldn't be applied.  The time a patch
lingers around provides zero credibility in favor of applying it.

If you can not decide if a patch improves the code or not, based on
its technical merit (and consistently and constructively defend such
decisions), then you can not make a maintainer decision in favor or
against applying the patch.  In this case simply applying the patch
without understanding is no substitute.

Thanks,
Marcus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]