Default image target size [Was:Re: Summary/Minutes from today's FESCo Meeting (2012-06-18)]

"J├│hann B. Gu├░mundsson" johannbg at
Tue Jun 19 22:47:51 UTC 2012

On 06/19/2012 10:36 PM, Adam Williamson wrote:
> On Tue, 2012-06-19 at 15:31 -0700, Jesse Keating wrote:
>> On 06/19/2012 03:19 PM, Adam Williamson wrote:
>>>> If an manpower to cover anything else then critical path became a
>>>>> concern we should fetch that manpower from the relevant SIG's community.
>>>>> Basically the plan was to reach out for example to the
>>>>> Gnome/KDE/XFCE/LXDE/Sugar community's to ask for assistant to cover
>>>>> their relevant part of required testing if that was the case.
>>>>> If you think about it who are better qualified and more willing to test
>>>>> those components other then the people that are using it on daily bases...
>>> This is fine in theory, but it doesn't hold up terribly well in
>>> practice. Just about every time we roll a TC/RC, I mail the lists for
>>> each desktop - GNOME, KDE, Xfce, LXDE, and Sugar - and ask for help in
>>> filling out the validation matrix. We get help fairly often for GNOME
>>> and KDE, and satellit_ usually covers Sugar, but we very rarely get
>>> anything for Xfce or LXDE.
>> At which point you have to decide "If nobody is willing to test it, can
>> we really call it a blocker?" or you just block the whole release until
>> somebody comes along and tests it (usually yourself).
>> Ultimatums that require people to do work don't often fly here in Fedora
>> land.  Ultimatums that are arranged in "do this, or you lose that
>> status" tend to work better, because the failure case is easier to
>> handle.  They lose $status and life moves on.
> Sure. My concern with the Xfce/LXDE case is that I'm sure it's worth
> going through a 'declare them blockers and expecting testing to come
> from the community, find that testing doesn't happen, declare them not
> blockers any more' cycle if we're 95% sure that's what would happen. I'd
> be happier either just committing QA to finding the time to test them if
> necessary, or not making them blockers at all.

Again anything that gets handed out at various events should be 
considered release blockers since the quality of that product reflects 
back at us as a community thus if an relevant SIG cannot cover it's own 
release testing apart from what we consider core and QA handles ( which 
in essence is what those spins build upon ) it should be removed from 
anything we officially hand out thus no longer be considered release 


More information about the devel mailing list