lets do a release! (was: Re: [PATCH] Third and Final (hopefully))

[John (J5) Palmieri]

On Sat, 2005-11-12 at 00:00 -0500, Havoc Pennington wrote:

> Hmm. We should probably map this out. For a text editor, we want:
>  - you can only run one Emacs or one GEdit, but you can run 
>    both apps at once; let's call Emacs and GEdit two 'brands'
>    of text editor
>  - if either is running you have the generic TextEditor service,
>    regardless of order of start/exit
> 
> So for this you want "queue" but "don't replace"
> 
> I'm not sure this is right; I think it might be possible that if I set
> Emacs as my default text editor, it should always own the generic
> TextEditor service and no other editor should ever even try to own it.
> In that case the queuing behavior just doesn't make any difference.
> 
> For a screensaver it's a bit different, you want:
> 
>  - only have one screensaver running, regardless of brand; 
>    so you don't want both xscreensaver and kscreensaver or something
> 
> Here queue works if all screensavers exit when they aren't the primary
> owner, but !queue is more natural. You don't want to allow replacement.
> (I think we all agree that allowing replacement won't be a common case,
> since apps have to be ready to deal with it)
> 
> Blah. This is why I'm very uncomfortable going 1.0 without real desktop
> application usage.

Why don't we get this stuff in and do a release.  It is obvious we
aren't going to get feedback here without there being a release.  I can
always do a 0.60 release if we don't want to commit to a freeze just
yet.  Letting this linger is just stalling the process.  We can debate
to worlds end on the theoretical but until it shows up in distros most
people don't really care much and the ones that do (us ;-) are too busy
elsewhere.  It is a pain if we change again but everything is going to
be a pain at this point until we get to 1.0.

> In fact I *believe* the original reason I implemented the queue feature
> was so apps would not have to sit there and monitor the bus to see when
> the current owner exited. i.e. the point of the queue is that you don't
> have to do anything if you just want to say "I'll provide this service
> whenever nobody else is providing it"
> 
> The other thing about the queue feature is that it removes a certain
> kind of race condition by leaving no time gap between the old owner
> leaving and the new owner taking the name.
>
> 2) If you want to exit if you don't get the service right away, can't
> you do:
>   if (reply != REPLY_PRIMARY_OWNER)
>     exit(0);
> which works regardless of the flags? It seems to me that 
>   if (reply != REPLY_EXISTS) 
>     exit(0);
> is just wrong.

This all sounds good.  Really I think the argument was that if we felt
that queuing might not be right it might be safer to just make it act
like it wasn't a queue but if apps found the queuing useful they could
turn it on.  If we feel that queuing is right then I have no problem
leaving the patch as is with the DO_NOT_QUEUE flag.

> I think the right thing is to behave in the most likely to be right way,
> or the way that requires less *application* code to handle correctly. We
> can talk about what that way is.
> 
> >  b) commit this patch along with my bus name releasing stuff
> >  c) merge J5's outstanding API breaks
> >  d) release 0.60 (not to be too hasty... :D) to the ISVs who I know are
> > waiting for it
> 
> That probably makes sense, but we do need to be sure to get *all* the
> planned ABI breaks ... a few more small ones might trickle in but we
> should try to avoid any blatant oversights.

So can I check in all my patches? We can then look things over to see if
we need to do more ABI breaks and only do a release after we are sure
there are no more big ABI changes.

--