Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Adam Williamson]

On Thu, 2015-01-29 at 23:36 -0500, Bob Lightfoot wrote:
> 

> Have we considered what this will do when used with fedup if 
> anything?
>  Or will the F21 "weak" password be grandfathered in?



It's a change to the installer. It has nothing at all to do with fedup.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #18: Request for content - Debugging evolution

[Fedora QA]

#18: Request for content - Debugging evolution
-+--
  Reporter:  jlaska  |  Owner:  somebody
  Type:  task| Status:  new
  Priority:  minor   |  Milestone:
 Component:  Wiki|Version:
Resolution:  |   Keywords:
Blocked By:  |   Blocking:
-+--

Comment (by mcrha):

 What about a section in User's Manual?
 https://help.gnome.org/users/evolution/stable/index.html.en#tracking-down-
 problems

 At least as an addition to the debugging pages mentioned above.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: DNF kernel-devel: The Final Frontier

[poma]

On 30.01.2015 02:14, Andre Robatino wrote:
> This is https://bugzilla.redhat.com/show_bug.cgi?id=1079906 (originally
> https://bugzilla.redhat.com/show_bug.cgi?id=1062997 ). It partially works
> now in Rawhide, except that it fails to remove the old version of
> kernel-devel (see https://bugzilla.redhat.com/show_bug.cgi?id=1079906#c18
> which is still waiting for someone to respond).
> 

What is new there. ;)


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Bob Lightfoot]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 01/29/2015 11:04 PM, Rejy M Cyriac wrote:
> On 01/30/2015 01:00 AM, David Lehman wrote:
>> On 01/29/2015 06:29 AM, Sudhir Khanger wrote:
>>> On Wednesday, January 28, 2015 08:53:42 AM Brian C. Lane
>>> wrote:
 This Friday's build of Anaconda will no longer allow you to
 use weak passwords and click done twice. In order to promote
 more secureish default systems I have increased the password
 length required to 8 characters and removed allowing weak (as
 defined by libpwquality) passwords.
>>> 
>>> What if security is not a concern for you?
>>> 
>>> What are your suggestions for folks who create a lot of VMs,
>>> use them specific cases, where password protection is merely an
>>> annoyance, and then throw them away?
>> 
>> Pick a single "strong" password that you can remember and use it
>> for all of them. Pretty easy, really.
>> 
> 
> Using a pass-phrase is pretty good in circumstances where the
> password strength should be good, yet the password be easy to
> remember.
> 
> 
Have we considered what this will do when used with fedup if anything?
 Or will the F21 "weak" password be grandfathered in?

Bob Lightfoot

- -- 
Sincerely,
Bob Lightfoot
"As iron sharpens iron, so one man
sharpens another." Proverbs 27:17 {NIV/84}
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBAgAGBQJUywpEAAoJEKqgpLIhfz3X9ZoH/0OVaD1ZBFMD2J6UQb5Y0nX+
fLJSPXsbCZUWYAzlQH2Gaiv0hPiljQNK3o8W36M3mD3Mo2DoGCB8lsGKZ25DhbEi
ao+hHyV3HcLBNoX3AqvquNm/rLDzquoEkW2HCLnyhGj/Uoc1BSGGHSJq6uv7SARs
sCDVLWuk7Ma8XI4ofklErG/Lb5UKfhHr5TpsWGUlouhDgn8iJTul7RA6mWfFQsYJ
D3gbRA40+oTq6crFQ03STSTUDqGriA9I+y8k3iy0ZmWGksM0Vxx6WLPvd0hTWi4m
wleeV7XIX1thxvWkbOtpCH9H3U/SnmO7+kMBS/HaPNr4seyWZlT61eJ6UdtZeKE=
=lYn3
-END PGP SIGNATURE-
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Rejy M Cyriac]

On 01/30/2015 01:00 AM, David Lehman wrote:
> On 01/29/2015 06:29 AM, Sudhir Khanger wrote:
>> On Wednesday, January 28, 2015 08:53:42 AM Brian C. Lane wrote:
>>> This Friday's build of Anaconda will no longer allow you to use weak
>>> passwords and click done twice. In order to promote more secureish
>>> default systems I have increased the password length required to 8
>>> characters and removed allowing weak (as defined by libpwquality)
>>> passwords.
>>
>> What if security is not a concern for you?
>>
>> What are your suggestions for folks who create a lot of VMs, use them
>> specific
>> cases, where password protection is merely an annoyance, and then
>> throw them
>> away?
> 
> Pick a single "strong" password that you can remember and use it for all
> of them. Pretty easy, really.
> 

Using a pass-phrase is pretty good in circumstances where the password
strength should be good, yet the password be easy to remember.


-- 
Regards,

Rejy M Cyriac (rmc)
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Chris Murphy]

On Thu, Jan 29, 2015 at 7:23 PM, Adam Williamson
 wrote:
> And as I said to otherChris, 'without open
> discussion' is just plainly false. There's a ton of 'open discussion',
> spread across three mailing lists.

That's confused. On devel@ the discussion was about the original
change feature. On anaconda-devel@ there was really no meaningful
discussion, because there was no acknowledgement of dissenting
opinions let alone addressing them with exactly why this is necessary
on Fedora and apparently nowhere else. On test@, 100% of the
discussion happened after we were informed of the change, which is in
the very first sentence of the first email in this thread.

Ton no. Modicum perhaps.

>You could also, of course, wait more than
> one lousy day to give the devs a chance to reply before whipping up a
> storm of righteous indignation, but so often that seems too much to
> ask?

You mean like the reply you got after suggesting a secret cmdline
option to make this requirement go away while testing so that you
don't go crazy? That was 13 days ago.


-- 
Chris Murphy
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Felix Miata]

Adam Williamson composed on 2015-01-29 18:23 (UTC-0800):

> You could also, of course, wait more than 
> one lousy day to give the devs a chance to reply before whipping up a 
> storm of righteous indignation, but so often that seems too much to 
> ask? 

I wonder if a point of Brian's OP was to gauge strength and swiftness of
opposition?

I'm surely glad to have gotten a warning.
-- 
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)

 Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Adam Williamson]

On Thu, 2015-01-29 at 19:55 -0600, Chris Adams wrote:
> Once upon a time, Adam Williamson  said:
> > It's not actually something that is part of the Change's scope, 
> > but an alternative way to try and achieve the same goal: the 
> > overall thought process was "well, what the Change proposer really 
> > wants is to reduce the likelihood of compromise via password 
> > access to the root account,
> 
> So, why didn't this change have to go through a proposal?  The 
> original change was rejected (which should show there is 
> disagreement about this), so such a change should not just be pushed 
> without open discussion.

There's no policy (AFAIK) on what is and is not a Change. FESCo has 
the power to effectively declare something to be a Change (and thus 
subject to review and so forth) if it decides to do so, but there's 
nothing beyond that. And as I said to otherChris, 'without open 
discussion' is just plainly false. There's a ton of 'open discussion', 
spread across three mailing lists.

> If there is disagreement about this change, is there no recourse?  
> Or do anaconda devs get to determine system policy now on their own?

Eh, that seems like a pointlessly loaded question. I mean, in a sense, 
sure, they always have. They *write the installer*. That's always 
going to involve some degree of 'determining system policy', if you 
interpret that phrase broadly enough. What do you want, every anaconda 
commit to go through a committee review phase?

And 'recourse' seems like such a weird word that, again, I don't 
really know how to reply to it. You can discuss the decision, in a 
respectful fashion, here or on devel@ or on anaconda-devel-list@. You 
can take it up with FESCo. You could also, of course, wait more than 
one lousy day to give the devs a chance to reply before whipping up a 
storm of righteous indignation, but so often that seems too much to 
ask? 


-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Chris Adams]

Once upon a time, Adam Williamson  said:
> It's not actually something that is part of the Change's scope, but an 
> alternative way to try and achieve the same goal: the overall thought 
> process was "well, what the Change proposer really wants is to reduce 
> the likelihood of compromise via password access to the root account, 

So, why didn't this change have to go through a proposal?  The original
change was rejected (which should show there is disagreement about
this), so such a change should not just be pushed without open
discussion.

If there is disagreement about this change, is there no recourse?  Or do
anaconda devs get to determine system policy now on their own?

-- 
Chris Adams 
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Andre Robatino]

Chris Murphy  colorremedies.com> writes:

> If this is really an improvement in security, which it isn't because
> an 8 character "good" password still has very low entropy, then it

It depends - if the only concern is remote access, and there is a limit on
the number of login attempts (either by number or rate, or both), and the
attacker doesn't know the password hash, even 8 characters is pretty strong.
And if local access is a concern, then anaconda should take other measures
(requiring disk encryption or a bootloader password?) as well, to be
consistent. (Personally I agree with you, as long as the user is informed
that the password is weak, at that point they should be allowed to use it if
they want.)




-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #322: New release criterion: no X libs in the minimal install set

[Fedora QA]

#322: New release criterion: no X libs in the minimal install set
---+
  Reporter:  mattdm|  Owner:
  Type:  enhancement   | Status:  closed
  Priority:  major |  Milestone:
 Component:  Release criteria  |Version:
Resolution:  wontfix   |   Keywords:
Blocked By:|   Blocking:
---+
Changes (by mattdm):

 * resolution:   => wontfix
 * status:  reopened => closed


Comment:

 The Base Design Working Group is really the logical successor to the
 Minimal Core SIG that I proposed -- so, that's good. Additionally, with
 the cloud/server/workstation split, it probably makes more sense to talk
 about this specific criterion in terms of what goes on the cloud image
 (even if I do hope base design continues to care about it).

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: DNF kernel-devel: The Final Frontier

[Andre Robatino]

This is https://bugzilla.redhat.com/show_bug.cgi?id=1079906 (originally
https://bugzilla.redhat.com/show_bug.cgi?id=1062997 ). It partially works
now in Rawhide, except that it fails to remove the old version of
kernel-devel (see https://bugzilla.redhat.com/show_bug.cgi?id=1079906#c18
which is still waiting for someone to respond).

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Self Introduction - David Terrey

[Adam Williamson]

On Mon, 2015-01-26 at 19:47 +1100, Bjorn Njordsson wrote:
> Hi all,

Welcome!

> My name is David Terrey, also known as Bjorn Njordsson.

There just *has* to be a story behind that!

>  I am 31 years old and been an System Administrator and IT Support 
> for just under 8 years.
> I am happy to dedicated as much time as i can to the Fedora Bug 
> Triage Project and to offer my services where possible.

Bug triage is kind of a dormant task at present; the BugZappers group 
is not currently active, and QA isn't strongly focused on it. Of 
course, that doesn't mean you can't do it if you want to! Have you 
checked the other tasks at https://fedoraproject.org/wiki/QA/Join as 
well?


> Thanks.



Thanks for volunteering, and welcome to the group!
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #443: Better format for test compose (TC) and release candidate (RC) requests

[Fedora QA]

#443: Better format for test compose (TC) and release candidate (RC) requests
-+-
  Reporter:  jreznik |  Owner:  adamwill
  Type:  enhancement | Status:  new
  Priority:  major   |  Milestone:  Undetermined Future
 Component:  Blocker/NTH review process  |Version:
Resolution:  |   Keywords:
Blocked By:  |   Blocking:
-+-
Changes (by adamwill):

 * milestone:  Fedora 21 => Undetermined Future


-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #398: Add Secure Boot test case

[Fedora QA]

#398: Add Secure Boot test case
-+-
  Reporter:  adamwill|  Owner:
  Type:  task| Status:  new
  Priority:  major   |  Milestone:  Undetermined Future
 Component:  Test cases  |Version:
Resolution:  |   Keywords:
Blocked By:  |   Blocking:
-+-
Changes (by adamwill):

 * milestone:  Fedora 20 => Undetermined Future


-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #228: SOPs for Everything

[Fedora QA]

#228: SOPs for Everything
---+-
  Reporter:  adamwill  |  Owner:  adamwill
  Type:  task  | Status:  new
  Priority:  major |  Milestone:  Undetermined Future
 Component:  Wiki  |Version:
Resolution:|   Keywords:
Blocked By:|   Blocking:
---+-
Changes (by adamwill):

 * cc: test@… (added)
 * milestone:  Fedora 18 => Undetermined Future


-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #395: Consider how to improve testing of different installer interfaces

[Fedora QA]

#395: Consider how to improve testing of different installer interfaces
---+-
  Reporter:  adamwill  |  Owner:
  Type:  task  | Status:  new
  Priority:  major |  Milestone:  Undetermined Future
 Component:  Wiki  |Version:
Resolution:|   Keywords:
Blocked By:|   Blocking:
---+-
Changes (by adamwill):

 * milestone:  Fedora 20 => Undetermined Future


-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #273: Improve browseability of validation matrix pages

[Fedora QA]

#273: Improve browseability of validation matrix pages
-+-
  Reporter:  adamwill|  Owner:  adamwill
  Type:  enhancement | Status:  new
  Priority:  major   |  Milestone:  Undetermined Future
 Component:  Blocker/NTH review process  |Version:
Resolution:  |   Keywords:
Blocked By:  |   Blocking:
-+-
Changes (by adamwill):

 * milestone:  Fedora 18 => Undetermined Future


-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #454: Proposed Test Day - Server

[Fedora QA]

#454: Proposed Test Day - Server
---+---
  Reporter:  junland   |  Owner:
  Type:  task  | Status:  closed
  Priority:  major |  Milestone:  Fedora 21
 Component:  Test Day  |Version:  2.0
Resolution:  fixed |   Keywords:
Blocked By:|   Blocking:
---+---
Changes (by adamwill):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 This went ahead successfully, closing.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #452: Proposed Test Day - Jenkins

[Fedora QA]

#452: Proposed Test Day - Jenkins
---+---
  Reporter:  msrb  |  Owner:  pschindl
  Type:  task  | Status:  closed
  Priority:  major |  Milestone:  Fedora 21
 Component:  Test Day  |Version:
Resolution:  fixed |   Keywords:
Blocked By:|   Blocking:
---+---
Changes (by adamwill):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 This went ahead successfully:

 https://fedoraproject.org/wiki/Test_Day:2014-09-30_Jenkins

 closing.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #451: Fedora 21 i18n Test Day

[Fedora QA]

#451: Fedora 21 i18n Test Day
---+---
  Reporter:  tagoh |  Owner:
  Type:  task  | Status:  closed
  Priority:  major |  Milestone:  Fedora 21
 Component:  Test Day  |Version:
Resolution:  fixed |   Keywords:
Blocked By:|   Blocking:
---+---
Changes (by adamwill):

 * status:  new => closed
 * resolution:   => fixed


-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #450: Fedora 21 Translation (L10n) Test Day

[Fedora QA]

#450: Fedora 21 Translation (L10n) Test Day
---+---
  Reporter:  anipeter  |  Owner:  pschindl
  Type:  task  | Status:  closed
  Priority:  major |  Milestone:  Fedora 21
 Component:  Test Day  |Version:
Resolution:  wontfix   |   Keywords:
Blocked By:|   Blocking:
---+---
Changes (by adamwill):

 * status:  assigned => closed
 * resolution:   => wontfix


Comment:

 Looks like we only did i18n for F21, but it's past F21 time now; please
 file a new ticket for F22 if desired.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #449: Proposed Test Day - Cockpit

[Fedora QA]

#449: Proposed Test Day - Cockpit
---+---
  Reporter:  stefw |  Owner:  pschindl
  Type:  task  | Status:  closed
  Priority:  major |  Milestone:  Fedora 21
 Component:  Test Day  |Version:
Resolution:  fixed |   Keywords:
Blocked By:|   Blocking:
---+---
Changes (by adamwill):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 This went ahead successfully:

 https://fedoraproject.org/wiki/Test_Day:2014-09-16_Cockpit

 closing.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #448: Proposed Test Day - Virtualization

[Fedora QA]

#448: Proposed Test Day - Virtualization
---+---
  Reporter:  crobinso  |  Owner:
  Type:  task  | Status:  closed
  Priority:  major |  Milestone:  Fedora 21
 Component:  Test Day  |Version:
Resolution:  fixed |   Keywords:
Blocked By:|   Blocking:
---+---
Changes (by adamwill):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 This went ahead successfully:

 https://fedoraproject.org/wiki/Test_Day:2014-09-25_Virtualization

 closing.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #447: Proposed Test Day - ARM

[Fedora QA]

#447: Proposed Test Day - ARM
---+-
  Reporter:  pwhalen   |  Owner:  Paul Whalen
  Type:  task  | Status:  closed
  Priority:  major |  Milestone:  Fedora 21
 Component:  Test Day  |Version:
Resolution:  wontfix   |   Keywords:
Blocked By:|   Blocking:
---+-
Changes (by adamwill):

 * resolution:   => wontfix
 * status:  new => closed


Comment:

 A page was created but it doesn't look like the event really went ahead:

 https://fedoraproject.org/wiki/Test_Day:2014-09-18_ARM

 but it's past F21 time now. Please create a new ticket for F22 if wanted.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #446: Proposed Test Day - NetworkManager

[Fedora QA]

#446: Proposed Test Day - NetworkManager
---+---
  Reporter:  vbenes|  Owner:
  Type:  task  | Status:  closed
  Priority:  major |  Milestone:  Fedora 21
 Component:  Test Day  |Version:
Resolution:  wontfix   |   Keywords:
Blocked By:|   Blocking:
---+---
Changes (by adamwill):

 * resolution:   => wontfix
 * status:  new => closed


Comment:

 Looks like this didn't happen, but the window is gone :) Please file a new
 ticket for F22 if desired.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #444: Proposed Test Day - GNOME-3.14

[Fedora QA]

#444: Proposed Test Day - GNOME-3.14
---+---
  Reporter:  vbenes|  Owner:
  Type:  task  | Status:  closed
  Priority:  major |  Milestone:  Fedora 21
 Component:  Test Day  |Version:
Resolution:  fixed |   Keywords:
Blocked By:|   Blocking:
---+---
Changes (by adamwill):

 * resolution:   => fixed
 * status:  new => closed


Comment:

 The test day was run successfully, closing.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #441: Temporary sysadmin-qa membership to access beaker for desktop qe

[Fedora QA]

#441: Temporary sysadmin-qa membership  to access beaker for desktop qe
--+
  Reporter:  vrutkovs |  Owner:  tflink
  Type:  task | Status:  closed
  Priority:  major|  Milestone:
 Component:  permissions  |Version:
Resolution:  fixed|   Keywords:
Blocked By:   |   Blocking:
--+
Changes (by adamwill):

 * status:  new => closed
 * resolution:   => fixed


-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #429: temporary membership in sysadmin-qa for atodorov so that beaker trial can continue

[Fedora QA]

#429: temporary membership in sysadmin-qa for atodorov so that beaker trial can
continue
--+
  Reporter:  tflink   |  Owner:  tflink
  Type:  task | Status:  new
  Priority:  minor|  Milestone:
 Component:  permissions  |Version:
Resolution:   |   Keywords:
Blocked By:   |   Blocking:
--+

Comment (by adamwill):

 is this still valid?

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #403: Modify initial-setup test case or create new one for ARM (vendor mode)

[Fedora QA]

#403: Modify initial-setup test case or create new one for ARM (vendor mode)
-+---
  Reporter:  adamwill|  Owner:  pwhalen
  Type:  task| Status:  closed
  Priority:  blocker |  Milestone:  Fedora 20
 Component:  Test cases  |Version:
Resolution:  fixed   |   Keywords:  arm
Blocked By:  |   Blocking:
-+---
Changes (by adamwill):

 * resolution:   => fixed
 * status:  new => closed


Comment:

 pwhalen's changes got merged in a while back.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #404: Look through validation matrices and note which tests don't apply to ARM

[Fedora QA]

#404: Look through validation matrices and note which tests don't apply to ARM
---+---
  Reporter:  adamwill  |  Owner:  pwhalen
  Type:  task  | Status:  closed
  Priority:  blocker   |  Milestone:  Fedora 20
 Component:  Wiki  |Version:
Resolution:  fixed |   Keywords:
Blocked By:|   Blocking:
---+---
Changes (by adamwill):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 I think this is pretty much done now, of course corrections will always be
 welcomed.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #397: Create test cases for release criteria that are currently missing them

[Fedora QA]

#397: Create test cases for release criteria that are currently missing them
-+-
  Reporter:  adamwill|  Owner:
  Type:  task| Status:  new
  Priority:  major   |  Milestone:  Undetermined Future
 Component:  Test cases  |Version:
Resolution:  |   Keywords:
Blocked By:  |   Blocking:
-+-
Changes (by adamwill):

 * milestone:  Fedora 20 => Undetermined Future


Comment:

 Current status: all Alpha issues mentioned above fixed.

  *
 
https://fedoraproject.org/wiki/Fedora_22_Beta_Release_Criteria#Scripted_installation
 still the test case doesn't quite match
  *
 
https://fedoraproject.org/wiki/Fedora_22_Beta_Release_Criteria#Unattended_installation
 ditto
  *
 
https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria#Media_consistency_verification
 still same issue
  *
 
https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria#Live_image_persistent_overlays
 still missing
  *
 
https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria#Installation_interfaces
 still missing cmdline
  *
 
https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria#Bootloader_disk_selection
 still missing
  *
 
https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria#Critical_path_translations
 still missing
  * https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria#Pre-
 release_notices still missing (could probably be added into existing test
 cases easily)
  *
 https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria#Kickstarts
 still missing
  *
 https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria#Release_notes
 still missing
  *
 
https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria#Release_identification
 still missing

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #400: Revise 'firstboot' test case

[Fedora QA]

#400: Revise 'firstboot' test case
-+---
  Reporter:  adamwill|  Owner:  adamwill
  Type:  defect  | Status:  closed
  Priority:  major   |  Milestone:  Fedora 20
 Component:  Test cases  |Version:
Resolution:  fixed   |   Keywords:
Blocked By:  |   Blocking:
-+---
Changes (by adamwill):

 * resolution:   => fixed
 * status:  new => closed


Comment:

 This got done.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #396: Revise partitioning test cases to reflect newUI design and cover its intended use cases

[Fedora QA]

#396: Revise partitioning test cases to reflect newUI design and cover its
intended use cases
-+---
  Reporter:  adamwill|  Owner:  pschindl
  Type:  task| Status:  closed
  Priority:  major   |  Milestone:  Fedora 20
 Component:  Test cases  |Version:
Resolution:  fixed   |   Keywords:
Blocked By:  |   Blocking:
-+---
Changes (by adamwill):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 We've improved quite a lot about this - we have a rather different set of
 test cases now, some for guided and some for auto, and they're all updated
 to newUI. Coverage is maybe not 100%, but we can file a new ticket for
 that if needed.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #394: Revise validation process / templates for ARM as primary arch

[Fedora QA]

#394: Revise validation process / templates for ARM as primary arch
---+---
  Reporter:  adamwill  |  Owner:
  Type:  task  | Status:  closed
  Priority:  major |  Milestone:  Fedora 20
 Component:  Wiki  |Version:
Resolution:  fixed |   Keywords:
Blocked By:|   Blocking:
---+---
Changes (by adamwill):

 * status:  new => closed
 * resolution:   => fixed


Comment:

 This all got done.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #393: Revise release criteria for ARM as primary arch

[Fedora QA]

#393: Revise release criteria for ARM as primary arch
---+---
  Reporter:  adamwill  |  Owner:  adamwill
  Type:  task  | Status:  closed
  Priority:  major |  Milestone:  Fedora 20
 Component:  Release criteria  |Version:
Resolution:  duplicate |   Keywords:
Blocked By:|   Blocking:
---+---
Changes (by adamwill):

 * status:  new => closed
 * resolution:   => duplicate


Comment:

 This is basically a dupe of #336 (and various other similar tickets we
 created over the years).

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #363: Require spins to go through smoke testing before being published

[Fedora QA]

#363: Require spins to go through smoke testing before being published
--+-
  Reporter:  adamwill |  Owner:
  Type:  enhancement  | Status:  closed
  Priority:  minor|  Milestone:  Undetermined Future
 Component:  Test cases   |Version:
Resolution:  worksforme   |   Keywords:
Blocked By:   |   Blocking:
--+-
Changes (by adamwill):

 * resolution:   => worksforme
 * status:  new => closed


Comment:

 This has more or less been implemented by releng; releng now drops spins
 that haven't been affirmed to pass smoke testing for a cycle.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #336: ARM as primary arch

[Fedora QA]

#336: ARM as primary arch
---+---
  Reporter:  jdulaney  |  Owner:  jdulaney
  Type:  task  | Status:  closed
  Priority:  major |  Milestone:  Fedora 19
 Component:  Release criteria  |Version:
Resolution:  fixed |   Keywords:
Blocked By:|   Blocking:
---+---
Changes (by adamwill):

 * resolution:   => fixed
 * status:  assigned => closed


Comment:

 This is done.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #327: test cases that require autopart shrink need to be updated

[Fedora QA]

#327: test cases that require autopart shrink need to be updated
-+---
  Reporter:  kparal  |  Owner:
  Type:  defect  | Status:  closed
  Priority:  major   |  Milestone:  Fedora 18
 Component:  Test cases  |Version:
Resolution:  worksforme  |   Keywords:
Blocked By:  |   Blocking:
-+---
Changes (by adamwill):

 * status:  new => closed
 * cc: test@… (added)
 * resolution:   => worksforme


Comment:

 From F19 onwards shrink was back in guided partitioning, so we don't need
 to change anything any more; the relevant test cases have all been poked
 since then anyway, I think.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #322: New release criterion: no X libs in the minimal install set

[Fedora QA]

#322: New release criterion: no X libs in the minimal install set
---+--
  Reporter:  mattdm|  Owner:
  Type:  enhancement   | Status:  reopened
  Priority:  major |  Milestone:
 Component:  Release criteria  |Version:
Resolution:|   Keywords:
Blocked By:|   Blocking:
---+--
Changes (by adamwill):

 * cc: test@… (added)


Comment:

 mattdm: current thoughts? :)

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #307: Add multi-desktop and multi-arch images to validation process

[Fedora QA]

#307: Add multi-desktop and multi-arch images to validation process
-+---
  Reporter:  adamwill|  Owner:  adamwill
  Type:  enhancement | Status:  closed
  Priority:  critical|  Milestone:  Fedora 18
 Component:  Blocker/NTH review process  |Version:
Resolution:  invalid |   Keywords:
Blocked By:  |   Blocking:
-+---
Changes (by adamwill):

 * cc: test@… (added)
 * status:  new => closed
 * resolution:   => invalid


Comment:

 As of F21, neither of these was created any more.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #297: Review release criteria for Fedora 18

[Fedora QA]

#297: Review release criteria for Fedora 18
---+---
  Reporter:  adamwill  |  Owner:  pschindl
  Type:  task  | Status:  closed
  Priority:  major |  Milestone:  Fedora 18
 Component:  Release criteria  |Version:
Resolution:  worksforme|   Keywords:
Blocked By:|   Blocking:
---+---
Changes (by adamwill):

 * resolution:   => worksforme
 * status:  new => closed
 * cc: test@… (added)


Comment:

 Well, this is kinda obsolete. We have tweaked the criteria constantly over
 time, of course they pretty much always need ongoing review.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #277: Add ARM to release criteria / validation process somehow

[Fedora QA]

#277: Add ARM to release criteria / validation process somehow
---+---
  Reporter:  adamwill  |  Owner:  adamwill
  Type:  task  | Status:  closed
  Priority:  critical  |  Milestone:  Fedora 18
 Component:  Wiki  |Version:
Resolution:  fixed |   Keywords:  arm
Blocked By:|   Blocking:
---+---
Changes (by adamwill):

 * resolution:   => fixed
 * status:  new => closed
 * cc: test@… (added)


Comment:

 So yeah, this is pretty much done since ~F19 or so, ARM testing is
 integrated with Intel testing now.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #275: Create test plan for ARM

[Fedora QA]

#275: Create test plan for ARM
-+
  Reporter:  jdulaney|  Owner:
  Type:  task| Status:  closed
  Priority:  major   |  Milestone:
 Component:  Test cases  |Version:
Resolution:  fixed   |   Keywords:
Blocked By:  |   Blocking:
-+
Changes (by adamwill):

 * cc: test@… (added)
 * resolution:   => fixed
 * status:  new => closed


Comment:

 I don't think this is doing anything useful. We pretty much have ARM
 testing in place, with much help from pwhalen.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #273: Improve browseability of validation matrix pages

[Fedora QA]

#273: Improve browseability of validation matrix pages
-+---
  Reporter:  adamwill|  Owner:  adamwill
  Type:  enhancement | Status:  new
  Priority:  major   |  Milestone:  Fedora 18
 Component:  Blocker/NTH review process  |Version:
Resolution:  |   Keywords:
Blocked By:  |   Blocking:
-+---
Changes (by adamwill):

 * cc: test@… (added)


Comment:

 So I guess we still haven't changed much here...relval might be able to
 set up the 'next / previous' links, I guess, I'd have to take a look at
 that.

 We *have* tweaked the categorization in recent releases so that when you
 look at the category pages, result pages of the same type are grouped
 together:

 https://fedoraproject.org/wiki/Category:Fedora_22_Nightly_Test_Results

 which probably helps a bit. sandro, cwickert, what's your current take on
 this?

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #272: Add changelog to TC/RC announce mails

[Fedora QA]

#272: Add changelog to TC/RC announce mails
-+---
  Reporter:  adamwill|  Owner:  robatino
  Type:  enhancement | Status:  closed
  Priority:  major   |  Milestone:  Fedora 17
 Component:  Blocker/NTH review process  |Version:
Resolution:  fixed   |   Keywords:
Blocked By:  |   Blocking:
-+---
Changes (by adamwill):

 * cc: test@… (added)
 * resolution:   => fixed
 * status:  reopened => closed


Comment:

 so we did that, and the announcement mails link to the tickets now. Also,
 'relval nightly --if-needed' (which is what the bot uses) provides the
 information on which of the 'significant packages' it tracks changed since
 the last nominated nightly, if any. I could maybe make it do the same for
 TC/RCs, but haven't really looked at that yet.

 Still, I think we can say this ticket is pretty much addressed.

-- 
Ticket URL: 
Fedora QA 
Fedora Quality Assurance
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Chris Murphy]

On Thu, Jan 29, 2015 at 4:32 PM, Adam Williamson
 wrote:
> On Thu, 2015-01-29 at 16:24 -0700, Chris Murphy wrote:
>>
>> > It's not actually something that is part of the Change's scope,
>> > but an alternative way to try and achieve the same goal: the
>> > overall thought process was "well, what the Change proposer really
>> > wants is to reduce the likelihood of compromise via password
>> > access to the root account, but no-one was particularly keen on
>> > the approach he proposed, so one different way to do it is to
>> > improve the strength of the root
>> > password". As bcl's mail explicitly says:
>> >
>> > https://www.redhat.com/archives/anaconda-devel-list/2015-January/msg00030.html
>>
>> That's not the point at all, which is, is it correct policy to
>> activate a sub-change in a rejected change proposal?
>
> It's *not* a sub-change in a rejected change proposal. It wasn't part
> of the rejected change proposal at all.

That'd seem to make it less appropriate of a change. However, what I'm
drawing on from that proposal is:

Scope
Proposal owners: to communicate with the Fedora maintainers of
packages: Anaconda, OpenSSH, GNOME, etc.
Other developers: packages like Anaconda, GNOME etc. need to update
their workflow to enable compulsory non-root user account creation and
ensure good password strength for it.



>
>> And is it prudent to dig heels in when there's been more negative
>> feedback on that change presented on anaconda-devel@ and test@ than
>> positive? I can't even find positive feedback except from the
>> original change owner.
>
> Um. Take a step back, relax, and look at the timeframe here.
>
> bcl mailed the list *yesterday*. He hasn't posted back to the thread
> since. You should give someone a hell of a lot more than one day
> before you start talking about 'digging heels in'.

Um, you realize that correcthorse is disqualified even though it's
more than 8 characters, right?


>
>> I was thinking of this one
>>
>> http://fedoraproject.org/wiki/Features/Policy/Definitions
>
> that whole thing is obsolete, the Change process replaced the Feature
> process. Nothing with 'Feature' in its URL is current any more.

Is there a bit recycling program?


-- 
Chris Murphy
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Release criterion proposal: "Package sets" (Alpha and Beta)

[Adam Williamson]

On Tue, 2015-01-27 at 13:52 -0800, Adam Williamson wrote:
> On Fri, 2015-01-23 at 09:25 -0700, Mike Ruckman wrote:
> 
> > Just to sum it up for people, the proposal overall is:
> > 
> >  - Reword the alpha criterion [0]
> >  - add a Beta criterion (with the latest extension) [1]
> >  - add a net-install Final criterion [2]
> > 
> > I don't see anything worrisome about any of these changes. Gives 
> > us good, well defined areas we know we want covered.
> 
> So, sigh, we're apparently getting flavor network install images 
> again for F22, along with a generic network install image. So let me 
> refine this *again*:
> 
> Alpha: "When installing with a release-blocking dedicated installer 
> image, the installer must be able to install the default package 
> set." (no change)
> 
> Beta 1: "When installing with a dedicated installer image for a 
> specific Fedora flavor, the default package set must be the correct 
> set for that flavor."
> 
> Beta 2: "When installing with the generic network install image, 
> selecting a package set other than the default must work."
> 
> Final: "When installing with the generic network install image with 
> no update repositories enabled, the installer must be able to 
> install each of the release-blocking desktops, as well as the 
> minimal package set."
> 
> that commits us to a moderate amount of testing, and if we're 
> worried about that we could for e.g. consider limiting the 
> 'guarantee' for the generic netinst image to just minimal.
> 
> Thoughts? Hope I don't have to revise this any further :)

Hum, let me try one more change: if we have official Flavor netinsts, 
we don't really need to *require* the generic one to work for the 
flavors. KDE is kind of a question, but I think to try and reduce the 
workload maybe we should just require the generic netinst to work for 
minimal. So replace the Final proposal above with:

Final: "When installing with the generic network install image with no 
update repositories enabled, the installer must be able to install the
minimal package set."
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Adam Williamson]

On Thu, 2015-01-29 at 16:24 -0700, Chris Murphy wrote:
> 
> > It's not actually something that is part of the Change's scope, 
> > but an alternative way to try and achieve the same goal: the 
> > overall thought process was "well, what the Change proposer really 
> > wants is to reduce the likelihood of compromise via password 
> > access to the root account, but no-one was particularly keen on 
> > the approach he proposed, so one different way to do it is to 
> > improve the strength of the root
> > password". As bcl's mail explicitly says:
> > 
> > https://www.redhat.com/archives/anaconda-devel-list/2015-January/msg00030.html
> 
> That's not the point at all, which is, is it correct policy to 
> activate a sub-change in a rejected change proposal? 

It's *not* a sub-change in a rejected change proposal. It wasn't part 
of the rejected change proposal at all.

> And is it prudent to dig heels in when there's been more negative 
> feedback on that change presented on anaconda-devel@ and test@ than 
> positive? I can't even find positive feedback except from the 
> original change owner.

Um. Take a step back, relax, and look at the timeframe here.

bcl mailed the list *yesterday*. He hasn't posted back to the thread 
since. You should give someone a hell of a lot more than one day 
before you start talking about 'digging heels in'.

> I was thinking of this one 
> 
> http://fedoraproject.org/wiki/Features/Policy/Definitions

that whole thing is obsolete, the Change process replaced the Feature 
process. Nothing with 'Feature' in its URL is current any more.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Chris Murphy]

On Thu, Jan 29, 2015 at 3:18 PM, Adam Williamson
 wrote:
> On Thu, 2015-01-29 at 15:09 -0700, Chris Murphy wrote:
>> On Thu, Jan 29, 2015 at 2:23 PM, Adam Williamson <
>> adamw...@fedoraproject.org> wrote:
>> > Seriously. Stop this. I have already asked people to stop
>> > assigning negative motivations to others without due cause. This
>> > is not being excellent to each other.
>>
>> "Your user password for your computer is arbitrarily unacceptable to
>> the Fedora Project" is not being excellent either.
>
> Come on, that's sophistry. You can't interpret code as a personal
> insult.

Sure I can. Code is copyrightable language owned by the author if not
in property certainly in the consequences, just like any form of
written communication. I don't actually know the motives of the
Anaconda team, I'm only observing patterns that I think have lead and
continue to lead to questionable outcomes.

The last time this happened Anaconda only considered (questionable)
usability aspects without considering security aspects - that's what
the blow up on devel@ entailed; and this time Anaconda considers the
(questionable) security aspects without considering the usability
aspects.

>
> (It's not 'arbitrary', anyway. It's using a well-known and widely-used
> password quality library.)

The decision to enforce is what's arbitrary, not the tool being used
to grade the password. If a password library library that arbitrarily
pass/fails passwords, that would at least be funny.


>> > The anaconda-devel-list discussion couldn't really be clearer
>> > about the relationship to the Change proposal - the whole thread
>> > was kicked off by the Change owner:
>> >
>> > https://www.redhat.com/archives/anaconda-devel-list/2015-January/msg00026.html
>>
>> That change proposal was rejected, so how is it that one of its
>> proposed changes has managed to make it through to the installer
>> barely two weeks later?
>
> It's not actually something that is part of the Change's scope, but an
> alternative way to try and achieve the same goal: the overall thought
> process was "well, what the Change proposer really wants is to reduce
> the likelihood of compromise via password access to the root account,
> but no-one was particularly keen on the approach he proposed, so one
> different way to do it is to improve the strength of the root
> password". As bcl's mail explicitly says:
>
> https://www.redhat.com/archives/anaconda-devel-list/2015-January/msg00030.html

That's not the point at all, which is, is it correct policy to
activate a sub-change in a rejected change proposal? And is it prudent
to dig heels in when there's been more negative feedback on that
change presented on anaconda-devel@ and test@ than positive? I can't
even find positive feedback except from the original change owner.


>
>> The substantive discussion on devel@ was centered on the sshd
>> portion, not changes to the installer enabling password quality
>> enforcement. That happened on anaconda-devel@ which most Fedora
>> users don't even monitor let alone participate. The main notice of
>> this change actually occurring happened for the first time in test@
>> which arguably most users also don't monitor.
>
> If someone's interested in Fedora development, they need to read the
> Fedora development mailing lists. *Any* code change is presumably of
> interest to someone, or it wouldn't be done in the first place; this
> is not a reason for us to go mailing users@ every time someone commits
> to anaconda.

I'm suggesting instead of being presented only on test@, it should
also have been presented on devel@.


> You can argue that the change is significant enough to be a Change, I
> guess, though personally I don't think it really is, unless it affects
> kickstart installs (in which case people would be surprised at their
> kickstarts suddenly not working right any more - but I don't think it
> does). It's a bit hard to argue about, though, since one of the things
> the Change process appears to be missing is an actual definition of
> what should be considered to constitute a 'Change', exactly. It's thus
> impossible to declare conclusively that X or Y *must* be a Change,
> unless FESCo has stated it or something. You can suggest that it
> should be, but it's impossible to make a completely definitive
> declaration since there's literally no basis on which you could do
> that outside of a formal FESCo vote or something.
>
> https://fedoraproject.org/wiki/Changes/Policy

I was thinking of this one
http://fedoraproject.org/wiki/Features/Policy/Definitions and I think
certainly 1, and probably 5 apply, and though ill-conceived 3 could
apply too seeing as thus far it's only Fedora going down this absurd
road of negative efficacy.


-- 
Chris Murphy
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Adam Williamson]

On Thu, 2015-01-29 at 15:09 -0700, Chris Murphy wrote:
> On Thu, Jan 29, 2015 at 2:23 PM, Adam Williamson <
> adamw...@fedoraproject.org> wrote:
> > Seriously. Stop this. I have already asked people to stop 
> > assigning negative motivations to others without due cause. This 
> > is not being excellent to each other.
> 
> "Your user password for your computer is arbitrarily unacceptable to 
> the Fedora Project" is not being excellent either.

Come on, that's sophistry. You can't interpret code as a personal 
insult.

(It's not 'arbitrary', anyway. It's using a well-known and widely-used 
password quality library.)

> 
> > 
> > The anaconda-devel-list discussion couldn't really be clearer 
> > about the relationship to the Change proposal - the whole thread 
> > was kicked off by the Change owner:
> > 
> > https://www.redhat.com/archives/anaconda-devel-list/2015-January/msg00026.html
> 
> That change proposal was rejected, so how is it that one of its 
> proposed changes has managed to make it through to the installer 
> barely two weeks later?

It's not actually something that is part of the Change's scope, but an 
alternative way to try and achieve the same goal: the overall thought 
process was "well, what the Change proposer really wants is to reduce 
the likelihood of compromise via password access to the root account, 
but no-one was particularly keen on the approach he proposed, so one 
different way to do it is to improve the strength of the root 
password". As bcl's mail explicitly says:

https://www.redhat.com/archives/anaconda-devel-list/2015-January/msg00030.html

> The substantive discussion on devel@ was centered on the sshd 
> portion, not changes to the installer enabling password quality 
> enforcement. That happened on anaconda-devel@ which most Fedora 
> users don't even monitor let alone participate. The main notice of 
> this change actually occurring happened for the first time in test@ 
> which arguably most users also don't monitor.

If someone's interested in Fedora development, they need to read the 
Fedora development mailing lists. *Any* code change is presumably of 
interest to someone, or it wouldn't be done in the first place; this 
is not a reason for us to go mailing users@ every time someone commits 
to anaconda.

You can argue that the change is significant enough to be a Change, I 
guess, though personally I don't think it really is, unless it affects 
kickstart installs (in which case people would be surprised at their 
kickstarts suddenly not working right any more - but I don't think it 
does). It's a bit hard to argue about, though, since one of the things 
the Change process appears to be missing is an actual definition of 
what should be considered to constitute a 'Change', exactly. It's thus 
impossible to declare conclusively that X or Y *must* be a Change, 
unless FESCo has stated it or something. You can suggest that it 
should be, but it's impossible to make a completely definitive 
declaration since there's literally no basis on which you could do 
that outside of a formal FESCo vote or something.

https://fedoraproject.org/wiki/Changes/Policy
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Chris Murphy]

On Thu, Jan 29, 2015 at 2:23 PM, Adam Williamson
 wrote:
> Seriously. Stop this. I have already asked people to stop assigning
> negative motivations to others without due cause. This is not being
> excellent to each other.

"Your user password for your computer is arbitrarily unacceptable to
the Fedora Project" is not being excellent either.


>
> The anaconda-devel-list discussion couldn't really be clearer about
> the relationship to the Change proposal - the whole thread was kicked
> off by the Change owner:
>
> https://www.redhat.com/archives/anaconda-devel-list/2015-January/msg00026.html

That change proposal was rejected, so how is it that one of its
proposed changes has managed to make it through to the installer
barely two weeks later?

The substantive discussion on devel@ was centered on the sshd portion,
not changes to the installer enabling password quality enforcement.
That happened on anaconda-devel@ which most Fedora users don't even
monitor let alone participate. The main notice of this change actually
occurring happened for the first time in test@ which arguably most
users also don't monitor.


> It is simply and clearly _false_ to claim that "the Anaconda
> team...tried to enforce a password policy change without consulting
> anyone else about it?", when the change was in fact discussed on two
> high-profile public project mailing lists, both threads which you
> *posted in yourself*.

I was mostly referring to the last time a password change materialized
without conversation, but I accept being 50% inaccurate on this.


-- 
Chris Murphy
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Adam Williamson]

On Thu, 2015-01-29 at 14:01 -0700, Chris Murphy wrote:
> On Wed, Jan 28, 2015 at 5:33 PM, Samuel Sieb  wrote:
> 
> > I just don't understand the reasoning here.  Sure, make it very 
> > clear that
> > the chosen password is weak.  Make me jump through several hoops 
> > before accepting the weak password.  But it's my computer!  Why 
> > can't I make the
> > (informed) choice to use a weak password?
> 
> What was the reasoning from the Anaconda team the last time they 
> tried to enforce a password policy change without consulting anyone 
> else about it? It was conjecture. And they didn't ask any security 
> experts about the idea in advance then either. Calm, rational 
> criticism was met with stubborn condescension from the developers. 
> It took a firestorm on devel@ to get them to change their mind.
> 
> And this time, once again several people have offered calm, rational 
> feedback (on anaconda-devel@) about how this doesn't improve 
> security in any meaningful way, but does inhibit testing in a 
> meaningful way. But this has been ignored and summarily rejected. 
> While consistent with the track record, it's beyond tedious that 
> anaconda devs tend to respond better to vinegar than honey.
> 
> So, I'm not sure why you'd expect any kind of reasoning to be
> presented for yet another installer security mis-feature that's 
> completely orthogonal to the original sshd proposal.

Seriously. Stop this. I have already asked people to stop assigning 
negative motivations to others without due cause. This is not being 
excellent to each other. The next person to do this is going into 
moderation.

I have already explained that the change was made in response to 
extensive discussion of a proposed Fedora 22 Change:

https://fedoraproject.org/wiki/Changes/SSHD_PermitRootLogin_no

it is not hard to follow this discussion. Just go read the devel@ 
archives:

https://lists.fedoraproject.org/pipermail/devel/2015-January/206157.html is the 
start of the 
thread
https://lists.fedoraproject.org/pipermail/devel/2015-January/206513.html is an 
example of someone not at all involved in anaconda development 
proposing password strength enforcement

You were involved in that thread yourself, so you *know* this is not 
just coming from anaconda.

The anaconda-devel-list discussion couldn't really be clearer about 
the relationship to the Change proposal - the whole thread was kicked 
off by the Change owner:

https://www.redhat.com/archives/anaconda-devel-list/2015-January/msg00026.html

It is simply and clearly _false_ to claim that "the Anaconda 
team...tried to enforce a password policy change without consulting 
anyone else about it?", when the change was in fact discussed on two 
high-profile public project mailing lists, both threads which you 
*posted in yourself*.

You may not like the change, I don't like it much either, but it's not 
acceptable to cast entirely insupportable aspersions on the people 
making it.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Chris Murphy]

On Wed, Jan 28, 2015 at 5:33 PM, Samuel Sieb  wrote:

> I just don't understand the reasoning here.  Sure, make it very clear that
> the chosen password is weak.  Make me jump through several hoops before
> accepting the weak password.  But it's my computer!  Why can't I make the
> (informed) choice to use a weak password?

What was the reasoning from the Anaconda team the last time they tried
to enforce a password policy change without consulting anyone else
about it? It was conjecture. And they didn't ask any security experts
about the idea in advance then either. Calm, rational criticism was
met with stubborn condescension from the developers. It took a
firestorm on devel@ to get them to change their mind.

And this time, once again several people have offered calm, rational
feedback (on anaconda-devel@) about how this doesn't improve security
in any meaningful way, but does inhibit testing in a meaningful way.
But this has been ignored and summarily rejected. While consistent
with the track record, it's beyond tedious that anaconda devs tend to
respond better to vinegar than honey.

So, I'm not sure why you'd expect any kind of reasoning to be
presented for yet another installer security mis-feature that's
completely orthogonal to the original sshd proposal.

If this is really an improvement in security, which it isn't because
an 8 character "good" password still has very low entropy, then it
should have to go through the feature process, which it hasn't. Such
enforcement doesn't happen on Ubuntu, openSUSE, Android, iOS, Windows,
or OS X and I think the anaconda developers need to be very clear what
problem they're trying to address. Because right now it's a
faux-solution in search of a problem.

-- 
Chris Murphy
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[David Lehman]

On 01/29/2015 06:29 AM, Sudhir Khanger wrote:

On Wednesday, January 28, 2015 08:53:42 AM Brian C. Lane wrote:

This Friday's build of Anaconda will no longer allow you to use weak
passwords and click done twice. In order to promote more secureish
default systems I have increased the password length required to 8
characters and removed allowing weak (as defined by libpwquality)
passwords.


What if security is not a concern for you?

What are your suggestions for folks who create a lot of VMs, use them specific
cases, where password protection is merely an annoyance, and then throw them
away?


Pick a single "strong" password that you can remember and use it for all 
of them. Pretty easy, really.








--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: criterion update: add "switch user" to Shutdown, reboot, logout

[Rex Dieter]

Kamil Paral wrote:

> I propose this change:
> title: Shutdown, reboot, logout, switch
> Shutting down, rebooting, logging out and user switching must work

(hrm, my prior response missed -test list)

User switching should not be a blocker.

Besides, even if broken, it can be fixed by subsequent updates. 

-- Rex

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: criterion update: add "switch user" to Shutdown, reboot, logout

[Chris Murphy]

On Thu, Jan 29, 2015 at 9:41 AM, Michael Catanzaro  wrote:
> On Thu, Jan 29, 2015 at 4:23 AM, Kamil Paral  wrote:
>
> I agree it's not as important as shutdown, but the question is whether it's
> important enough to be considered "basic functionality" and we block the
> release when it's broken heavily.
>
>
> I'm pretty sure that if user switching doesn't work reliably, users should
> find a better OS to use, so I'd rather block on it
>
> At the same time, our blocker criteria are generally interpreted to apply to
> common bugs. If user switching is broken for one guy with an obscure setup,
> that shouldn't be a blocker.

Is there a particularly strong use case for user switching when booted
from live media? If not, can't this be fixed with an update?


-- 
Chris Murphy
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: DNF kernel-devel: The Final Frontier

[poma]

# dnf --disablerepo=* upgrade *3.18.4-200.fc21.x86_64.rpm
Dependencies resolved.
==
 Package   Arch Version  Repository 
 Size
==
Installing:
 kernelx86_64   3.18.4-200.fc21  
@commandline44 k
 kernel-core   x86_64   3.18.4-200.fc21  
@commandline19 M
  <<==|
 kernel-modules  ||x86_64   3.18.4-200.fc21  
@commandline17 M
 kernel-modules-extra||x86_64   3.18.4-200.fc21  
@commandline   2.2 M
Upgrading:   ||
 kernel-devel >>==|x86_64   3.18.4-200.fc21  
@commandline   9.1 M
 kernel-headersx86_64   3.18.4-200.fc21  
@commandline   957 k
 kernel-tools  x86_64   3.18.4-200.fc21  
@commandline   126 k
 kernel-tools-libs x86_64   3.18.4-200.fc21  
@commandline50 k
 kernel-tools-libs-devel   x86_64   3.18.4-200.fc21  
@commandline47 k
 perf  x86_64   3.18.4-200.fc21  
@commandline   1.0 M
 python-perf   x86_64   3.18.4-200.fc21  
@commandline   140 k

Transaction Summary
==
Install  4 Packages
Upgrade  7 Packages

Total size: 49 M
Is this ok [y/N]: N
Operation aborted.


# yum -q --disablerepo=* upgrade *3.18.4-200.fc21.x86_64.rpm

=
 Package Arch   VersionRepository   
Size
=
Installing:
 kernel  x86_64 3.18.4-200.fc21
/kernel-3.18.4-200.fc21.x86_64  0.0  
 kernel-core x86_64 3.18.4-200.fc21
/kernel-core-3.18.4-200.fc21.x86_64  41 M
 kernel-develx86_64 3.18.4-200.fc21
/kernel-devel-3.18.4-200.fc21.x86_64 34 M
 kernel-modules  x86_64 3.18.4-200.fc21
/kernel-modules-3.18.4-200.fc21.x86_64   17 M
 kernel-modules-extrax86_64 3.18.4-200.fc21
/kernel-modules-extra-3.18.4-200.fc21.x86_642.1 M
Updating:
 kernel-headers  x86_64 3.18.4-200.fc21
/kernel-headers-3.18.4-200.fc21.x86_64  3.3 M
 kernel-toolsx86_64 3.18.4-200.fc21
/kernel-tools-3.18.4-200.fc21.x86_64226 k
 kernel-tools-libs   x86_64 3.18.4-200.fc21
/kernel-tools-libs-3.18.4-200.fc21.x86_6418 k
 kernel-tools-libs-devel x86_64 3.18.4-200.fc21
/kernel-tools-libs-devel-3.18.4-200.fc21.x86_64 5.8 k
 perfx86_64 3.18.4-200.fc21/perf-3.18.4-200.fc21.x86_64 
   2.5 M
 python-perf x86_64 3.18.4-200.fc21
/python-perf-3.18.4-200.fc21.x86_64 348 k

Transaction Summary
=
Install  5 Packages
Upgrade  6 Packages

Is this ok [y/d/N]: y


-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Amita Sharma]

On 01/29/2015 06:30 PM, Scott Robbins wrote:

On Thu, Jan 29, 2015 at 01:37:39PM +0100, Jos Vos wrote:

On Thu, Jan 29, 2015 at 12:56:56AM +, Sérgio Basto wrote:


+1 , I'm against enforce 'good' passwords , it is pretty clear, double
click if you want have an insecure password and system .

+1, enforcing will create lots of frustrations for people often creating
internal test systems, etc.  A very, very bad idea...

OK, I think there's been a great many emails saying this is a bad idea and
none that I've seen, at least, saying it's a good one.  Is there a bug filed, 
or a place to
voice opinion?
This can not be filed as bug, as it is not a faulty behavior. It should 
be filed an RFE.


Thanks,
Amita

  I think this should also be mentioned on Fedora forums so that
the people who actually USE the thing should have a voice


--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Scott Robbins]

On Thu, Jan 29, 2015 at 01:37:39PM +0100, Jos Vos wrote:
> On Thu, Jan 29, 2015 at 12:56:56AM +, Sérgio Basto wrote:
> 
> > +1 , I'm against enforce 'good' passwords , it is pretty clear, double
> > click if you want have an insecure password and system . 
> 
> +1, enforcing will create lots of frustrations for people often creating
> internal test systems, etc.  A very, very bad idea...

OK, I think there's been a great many emails saying this is a bad idea and
none that I've seen, at least, saying it's a good one.  Is there a bug filed, 
or a place to 
voice opinion?  I think this should also be mentioned on Fedora forums so that
the people who actually USE the thing should have a voice
> 

-- 
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6

-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Jos Vos]

On Thu, Jan 29, 2015 at 12:56:56AM +, Sérgio Basto wrote:

> +1 , I'm against enforce 'good' passwords , it is pretty clear, double
> click if you want have an insecure password and system . 

+1, enforcing will create lots of frustrations for people often creating
internal test systems, etc.  A very, very bad idea...

-- 
--Jos Vos 
--X/OS Experts in Open Systems BV   |   Phone: +31 20 6938364
--Amsterdam, The Netherlands| Fax: +31 20 6948204
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Amita Sharma]

On 01/29/2015 05:59 PM, Sudhir Khanger wrote:

On Wednesday, January 28, 2015 08:53:42 AM Brian C. Lane wrote:

This Friday's build of Anaconda will no longer allow you to use weak
passwords and click done twice. In order to promote more secureish
default systems I have increased the password length required to 8
characters and removed allowing weak (as defined by libpwquality)
passwords.

What if security is not a concern for you?
yeah, it will be an issue for people who are doing a lot of testing in 
this way ( creating, testing, tearing off VMs)


- Amita


What are your suggestions for folks who create a lot of VMs, use them specific
cases, where password protection is merely an annoyance, and then throw them
away?





-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Heads up - Anaconda 22.17 will enforce 'good' passwords

[Sudhir Khanger]

On Wednesday, January 28, 2015 08:53:42 AM Brian C. Lane wrote:
> This Friday's build of Anaconda will no longer allow you to use weak
> passwords and click done twice. In order to promote more secureish
> default systems I have increased the password length required to 8
> characters and removed allowing weak (as defined by libpwquality)
> passwords.

What if security is not a concern for you?

What are your suggestions for folks who create a lot of VMs, use them specific 
cases, where password protection is merely an annoyance, and then throw them 
away?

-- 
Regards,
Sudhir Khanger,
sudhirkhanger.com,
github.com/donniezazen,
5577 8CDB A059 085D 1D60  807F 8C00 45D9 F5EF C394.

signature.asc
Description: This is a digitally signed message part.
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

Re: criterion update: add "switch user" to Shutdown, reboot, logout

[Kamil Paral]

> Matthias Clasen wrote:
> I think user switching is much less important than the other things on
> your list (login, shutdown, reboot) 

I agree it's not as important as shutdown, but the question is whether it's 
important enough to be considered "basic functionality" and we block the 
release when it's broken heavily.

For example, by our current standards, gnome-calculator must work or we do not 
ship:
https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria#Default_application_functionality
We also don't ship when we don't have high-contrast icons for all apps, or when 
we miss some artwork.

All of that is probably not as important as shutdown working, but still forms 
some kind of basis which needs to work.

Btw, I just realized that it could be argued that user switching is already 
covered by this criterion:
https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria#Default_panel_functionality
but it's good we're having this discussion, at least we can clarify this.

> if user switching is broken, the
> majority of our users won't even notice because they are on single-user
> systems.

It's hard to make some estimates here, but judging by my surroundings, single 
user systems are very common for us IT geeks, but do not necessarily represent 
Fedora's larger audience. On my home laptop, I have user profiles for me and 
for my girlfriend (my account is mostly logged in when the laptop gets 
suspended), and I need her to be able to use it even when I'm not around to 
manually switch VTs. My dad's laptop has user profiles for him and my mom. And 
even I have a guest account on my work laptop when I need to lend it to someone 
for a minute, I guess that's also a very common use case.

It seems to me that family usage is the most commonly mentioned scenario when I 
see people complaining about this feature being broken.

> 
> Testing it is fine of course, but I don't really think we should block
> on this. 

Do you mean not block on it even for Final, i.e. at all, or Beta?

What I see as a problem is that any serious bugs [1] cut off multi-user usage 
of that system almost completely. I feel that we're losing a really big part of 
our audience this way. And now that we have Fedora Workstation product (and the 
KDE spin) with its more targeted focus on a specific user base, it would be a 
real pity to sacrifice those people.


> Also worth considering: user switching has never worked 100%
> reliably, so increased qa focus may just uncover old heisenbugs, and
> turn them into blocking issues.

It that a bad thing or a good thing? Could this be a worthy goal for F22? It's 
still pretty early in the cycle. 
Or if you think it's too late, does it make sense to target this for F23? Is it 
about technical complexity, or is there no will/manpower to maintain this? 
(Since this is one of my painful issues with GNOME, I can promise you some QA 
time from my side:)).

Thanks,
Kamil

[1] https://bugzilla.gnome.org/show_bug.cgi?id=719418
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test

rawhide report: 20150129 changes

[Fedora Rawhide Report]

Compose started at Thu Jan 29 05:15:02 UTC 2015
Broken deps for i386
--
[Sprog]
Sprog-0.14-27.fc20.noarch requires perl(:MODULE_COMPAT_5.18.0)
[aeskulap]
aeskulap-0.2.2-0.19beta1.fc22.i686 requires libofstd.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.i686 requires liboflog.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg8.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg16.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.i686 requires libijg12.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmnet.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmjpeg.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmimgle.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmimage.so.3.6
aeskulap-0.2.2-0.19beta1.fc22.i686 requires libdcmdata.so.3.6
[barman]
barman-1.3.3-4.fc22.noarch requires python-dateutil < 0:2.0
[boswars]
boswars-2.7-5.fc22.i686 requires libtolua++-5.1.so
[bro]
broccoli-2.3-1.fc22.i686 requires bro-2.3
python-broccoli-2.3-1.fc22.i686 requires bro-2.3
[cab]
cab-0.1.9-12.fc22.i686 requires cabal-dev
[dnssec-check]
dnssec-check-1.14.0.1-4.fc20.i686 requires libval-threads.so.14
dnssec-check-1.14.0.1-4.fc20.i686 requires libsres.so.14
[fawkes]
fawkes-lua-0.5.0-19.fc22.i686 requires libtolua++-5.1.so
fawkes-plugin-katana-0.5.0-19.fc22.i686 requires libtolua++-5.1.so
fawkes-plugin-pantilt-0.5.0-19.fc22.i686 requires libtolua++-5.1.so
fawkes-plugin-roomba-0.5.0-19.fc22.i686 requires libtolua++-5.1.so
fawkes-plugin-skiller-0.5.0-19.fc22.i686 requires libtolua++-5.1.so
[gcc-python-plugin]
gcc-python2-debug-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22
gcc-python2-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22
gcc-python3-debug-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22
gcc-python3-plugin-0.13-2.fc22.i686 requires gcc = 0:4.9.2-1.fc22
[gitg]
gitg-3.14.1-1.fc22.i686 requires libgit2.so.21
gitg-libs-3.14.1-1.fc22.i686 requires libgit2.so.21
[golang-github-goraft-raft]
golang-github-goraft-raft-devel-0-0.5.git73f9c44.fc22.noarch requires 
golang(code.google.com/p/goprotobuf)
[golang-github-influxdb-influxdb]

golang-github-influxdb-influxdb-datastore-0.8.5-0.1.git9485e99.fc22.noarch 
requires golang(code.google.com/p/goprotobuf/proto)
golang-github-influxdb-influxdb-devel-0.8.5-0.1.git9485e99.fc22.noarch 
requires golang(code.google.com/p/goprotobuf/proto)
[libhocr]
libhocr-gtk-0.10.17-18.fc22.i686 requires python-imaging-sane
[nifti2dicom]
nifti2dicom-0.4.9-1.fc22.i686 requires libitksys-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libitkopenjpeg-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libitkdouble-conversion-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libitkNetlibSlatec-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libhdf5_hl.so.8
nifti2dicom-0.4.9-1.fc22.i686 requires libhdf5_cpp.so.8
nifti2dicom-0.4.9-1.fc22.i686 requires libhdf5.so.8
nifti2dicom-0.4.9-1.fc22.i686 requires libITKznz-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKniftiio-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKgiftiio-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKWatersheds-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKVtkGlue-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKVideoIO-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKVideoCore-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKVTK-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKVNLInstantiation-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKStatistics-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKSpatialObjects-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKReview-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKQuadEdgeMesh-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKPolynomials-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKPath-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKOptimizersv4-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKOptimizers-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKNrrdIO-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKMetaIO-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKMesh-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKLabelMap-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKKLMRegionGrowing-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKIOXML-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKIOVTK-4.6.so.1
nifti2dicom-0.4.9-1.fc22.i686 requires libITKIOTransformMatl