Re: SRU approved without waiting in unapproved

[Martin Pitt]

Jonathan Riddell [2013-05-08 14:59 +0100]:
 Discussing ways to make the SRU process smoother with upstream KDE folks we
 wondered if uploads to -proposed could go straight into the archive then be
 approved by ~ubuntu-sru during the 7 days waiting period.  If there's a bug
 which is causing lots of bugs reports upstreams are keen to get updates in
 ASAP and anything which delays it longer means they spend more time
 triaging bugs which they have already fixed. It would just remove one of
 the places this process can be blocked. What does tech board think?

I'm not that keen on this to be honest. Quite a number of developers
and even technical users are running -proposed, and for a stable
update it's always good to have at least two pairs of eyes on a
change. At least in my ubuntu-sru time there have been quite a number
of uploads which had to be rejected due to missing/wrong LP bug links,
a really bad changelog, errors in applying patches, and the like. I
also hit changes which were inappropriate for an SRU in the first
place.

I think it is much better to prod ubuntu-sru members on IRC with
this is urgent, can you please review?, and then sort out potential
fallout on IRC for faster turnaround times.

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

-- 
technical-board mailing list
technical-board@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/technical-board

Re: SRU request for custom unity-greeter indicators

[Martin Pitt]

Hello Michael,

Michael Terry [2013-04-30 12:26 -0700]:
 https://launchpad.net/bugs/1155157
 
 == The rationale ==
 
 A Canonical customer asked for some new features in unity-greeter. 
 Specifically:
 * The ability to add new indicators to the greeter session
 * The ability to change which user is selected in the greeter (done over
 DBus)
 
 These changes are only really useful for administrators.  This customer
 is using them for automatically selecting a user based on an inserted
 smartcard.
 
 Both these features landed in raring.  But for them to be truly useful
 to the customer, they would ideally see the light of day in precise.

This does not change the default behaviour, and happens in an LTS
release, so I'm inclined to agree to this.

 == The details ==
 
 The patch in that bug adds a new gsettings key
 /com/canonical/unity-greeter/indicators which lists indicators to
 load.  Note that this is pulled from the gsettings database under the
 lightdm user, not your everyday desktop user.  So a system
 administrator would likely add a system gsettings override file to
 modify it.  Or call sudo -u lightdm gsettings.

This seems fine.

 It also adds a DBus interface with just one function (SetActiveEntry) to
 set the currently selected user.  This is exposed only on the session
 bus.  Since arbitrary processes cannot be started under the greeter,
 there is currently no real consumers for the interface.  But that's
 where a custom indicator can come into play.  Such an indicator could
 call SetActiveEntry.

I don't really see how this is related to the ability to define which
indicators to load? AFAICS these are really two independent changes,
and thus should be in two separate patches? This second one does
change the default behaviour (the indicator now creating a new D-BUS
connection and exporting an object), so this needs careful testing.

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)


signature.asc
Description: Digital signature
-- 
technical-board mailing list
technical-board@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/technical-board

Apologies

[Matt Zimmerman]

I won't be able to make it to the meeting Monday due to another commitment
at work.

-- 
 - mdz

-- 
technical-board mailing list
technical-board@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/technical-board