Readjusting SRU review process
Hello SRU team, the Tech board recently received a proposal to forego the review of -proposed uploads and directly accept them into -proposed: https://lists.ubuntu.com/archives/technical-board/2013-May/001613.html https://lists.ubuntu.com/archives/technical-board/2013-May/001618.html In today's TB meeting there was unanimous agreement that this is not a flaw in the defined SRU process, but a flaw in its execution. We do not want to give up peer review for what goes into stable releases, and rather want to address the workflow problem in the SRU team. Does that match your feeling as well, or do you feel differently? There are obviously problems with getting timely reviews at the moment: many items in the precise and quantal queue are one to two months old already, and even raring's queue has rather simple SRUs which are already three weeks old. It seems the regular reviewing days got dropped some time ago. How is the reviewing process currently meant to work, and what do you see as the reasons that it doesn't? Would reintroducing regular review days help against them never turning into your focus otherwise, or have they been ineffective as well? Mabye the team is even too big now for anyone to feel sufficient responsibility for doing reviews? Please don't consider this as personal criticism; we just need to figure out a modus that actually works. Thank you! 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
Re: SRU request for custom unity-greeter indicators
Michael Terry [2013-04-30 12:26 -0700]: > Hello! I'd like to request an SRU for unity-greeter that contains a new > feature. Since this is a feature and not a bug fix, the TB was > mentioned as the appropriate place to request an SRU. I already answered, and there have not been any objections from other members in today's TB meeting. So please go ahead, but please ensure that the new D-BUS interface does not cause any regression. 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: Apologies
On Fri, May 10, 2013 at 02:53:39PM -0700, Matt Zimmerman wrote: > I won't be able to make it to the meeting Monday due to another commitment > at work. I'm afraid I won't either; I'm very tired from considerable travel over the weekend and have family-related stress at the moment in conjunction with vUDS coming up, so another evening meeting is rather too much for me right now. -- Colin Watson [cjwat...@ubuntu.com] -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Tech Board catch-up meeting with Community Council scheduled for next Tuesday at 17:00 UTC
This, however, puts it in conflict with vUDS. The CC normally has no meetings on months that have 5 thursdays in them, so that leaves the 30th open if we wish to postpone. Thoughts? -Scott -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
Re: SRU approved without waiting in unapproved
On May 9, 2013 4:15 AM, "Jonathan Riddell" wrote: > > 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? > > Jonathan As another data point the gnome-shell 3.6.3 SRU for 12.10 waited in the unapproved queue for over 2 months. If that kind of excessive wait is typical it will make us lose confidence in the SRU system and be force us to encourage our users to depend on PPAs if they want bugfixes. Thanks, Jeremy -- 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
On 05/10/2013 07:33 AM, Martin Pitt wrote: >> 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. They are two separate changes, but to be useful, the DBus interface depends on the ability to load indicators. Indicators are the only way to get code into the greeter session that can actually call the DBus interface. -mt -- technical-board mailing list technical-board@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/technical-board
