[PATCH] Third and Final (hopefully)

[John (J5) Palmieri]

On Mon, 2005-11-07 at 19:14 -0500, Havoc Pennington wrote:
> On Tue, 2005-10-25 at 23:34 -0400, Havoc Pennington wrote:
> > Give me a little time to look at this one, I think it's worth reviewing
> > since it's so big. I'd appreciate it if anyone else wants to review it
> > also, my patch-review-fu really isn't that good (Owen for example always
> > finds 10x the bugs on review that I do). Maybe Ross, Alex, Mark, ? or
> > someone could look over the code or at least the proposed new behavior
> > in the spec patch?
> 
> Anyone else have a chance to look at this yet? I'm feeling like a
> loser ;-)
> 
> Havoc

Me ;-) but I can't approve my own patch.  It seems as though most of the
people who have a right to review patches for submission have dropped
off the list or just don't check it.  I was going to blog about people
being able to review patches without having the right to say ok to
commit.  It makes it easier to assess if we should give a person that
right and it lightens the load for all of us.

Anyway, my take on this patch.  I'm not sure of the use cases other than
the text editor one you outlined.  What I am sure of is it is logical,
at least more so than the PROHIBIT_REPLACEMENT version which didn't seem
to follow any strict rules.  The way I see it is we either do it this
way or revert back to only allowing one owner and no queue.  Services
can poll or listen for signals and race for ownership.  I would sulk for
a few seconds if we do revert because it does mean more coding and I had
fun with this particular patch but really it would only be for a few
seconds.

What is clear is we should pick one as the intermediate was inadequate.
Perhaps we should change DO_NOT_QUEUE to ALLOW_QUEUE and have it behave
as a no queue entity by default and keep the added functionality.

In this case it would be harder to add this functionality should we take
it out now.

-- 
John (J5) Palmieri <johnp at redhat.com>