[Fedora-livecd-list] [PATCH 5/6] Optionally prevent killing application

[Jeremy Katz]

On Mon, 2007-08-06 at 23:50 +0200, Jeroen van Meeuwen wrote:
> Jeremy Katz wrote:
> > On Sun, 2007-08-05 at 20:37 +0200, Jeroen van Meeuwen wrote:
> >> A patch to prevent livecd-creator from also killing the application that
> >> is build on top of livecd-tools, while not changing the default behaviour.
> > 
> > Better would be a patch to use the YumBase.close() method in yum >=
> > 3.1.7.  And then perhaps fallback to the current behavior for older yum
> > (although I'm not against just requiring yum 3.2.x at this point I don't
> > think)
>
> Hey, this just works for us. 

It may "just work", but it's not the best approach and when I come back
in six months or a year or whenever and try to figure out what the
reasoning was, it's not going to be very obvious as to why there's an
option here and who calls with the option and why they needed it.  At
which point either the code lives on, rotting and potentially unused and
adding to the learning curve, or I remove it and hope it doesn't break
someone.  

> I'm not the maintainer of livecd-tools nor
> do I have commit access. Make me have one of these things before you
> tell me what is better, while /and/ not applying the better change you
> suggest yourself, /and/ not applying the patch I sent you.

As I tried to convey yesterday on IRC, that's not the way that open
source development works.  Iteration of submitted patches based on
feedback from the maintainer to get to the best solution is a part of
how things get accepted.  In the long-term, this sort of peer review
leads to better code in the project being discussed and is also a part
of the pedagogical process.

Commit access to a project is a result of sending patches that the
maintainer is comfortable with to the point that it's easier to just let
them be committed.  Or, in some projects, commit access only ever rests
with the maintainer (cf: the kernel which only Linus directly commits
to).  Granted, I don't want to go to that extreme as I think that
multiple committers is generally a better way to do things.  But not as
a carrot for rewriting patches.

Jeremy