Re: flash player 64bit?

[Ankur Sinha]

On Wed, 2010-07-07 at 01:44 -0400, Chris Kloiber wrote:
> On 07/06/2010 11:16 PM, Ankur Sinha wrote:
> 
> > hey,
> >
> > There's an alpha release of 64bit flash that works well enough(like poc
> > said, this one has as many problems as usual flash)
> >
> > you can look at the fedoraproject.org wiki page on flash. It has the
> > required info.
> >
> > regards,
> > Ankur
> 
> Not anymore. Adobe yanked it.
> 

Drat.. I hadn't noticed.. 

/me goes to remove the 64 bit and use the 32 bit wrapped version.

Thanks !!

regards,
Ankur

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

Re: flash player 64bit?

[Chris Kloiber]

On 07/06/2010 11:16 PM, Ankur Sinha wrote:


hey,

There's an alpha release of 64bit flash that works well enough(like poc
said, this one has as many problems as usual flash)

you can look at the fedoraproject.org wiki page on flash. It has the
required info.

regards,
Ankur


Not anymore. Adobe yanked it.

--
Chris Kloiber



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Interactive white boards and Fedora Xorg setup

[Rodd Clarkson]

On Wed, 2010-07-07 at 11:01 +1000, Peter Hutterer wrote:
> [faked-up reply, I'm not on the list, ajax pointed it out to me on the
> archives. please make sure you CC me for any replies]

Thanks for the reply, and it's nice to know that ajax noticed this (as
it appears ajax has much to do with Xorg on fedora (and I'm guessing
elsewhere)).

> > Unlike a mouse, these pointer devices move the mouse pointer to where
> > you touch the screen.  For example, if the IWB is to the right of my
> > laptop screen and I touch the right edge of the screen then the mouse
> > pointer appears on the right side of my laptop screen, and not where
> > I've touched the screen.
> > 
> > The pointer device included with the IWB needs to be able to be
> > configured to do two things:
> 
> > 1.  Only work as a device for the IWB screen.  The mouse shouldn't be
> > able to be moved off the screen, only around it.
> > 2.  Calibrate the pointer so that you can declare the
> > top/bottom/left/right of the screen (as where the image falls on the
> > pointer device isn't usually at the extremes of the device.)
> >
> > Is this possible?
> 
> The 1.9 X server that's already in rawhide has an coordinate transformation
> matrix to restrict absolute devices to essentially any rectangle on the
> screen. The matrix is a property on each device and can be modified with the
> xinput commandline tool (no GUI tools yet).
> 
> For example, I've got a 1440x900 and a 1920x1200 display. To restrict my
> tablet to the right (larger) screen:
> $> xinput --set-prop "Wacom Intuos4 6x9" "Coordinate Transformation Matrix"
> 0.58 0 0.42 0 1 0 0 0 1  
> 
> The matrix thus looks like this:
> | 0.58 0 0.42 |
> | 01 0|
> | 00 1|
> 
> giving us a scale into 58% of the screen range with an offset of 42%. Your
> numbers will likely vary but that should fix the issue for you.

This looks like a great start, but I'm guessing it only works in 1.9 at
this stage. Will this also work in 1.8?

Obviously a nice GUI tool for this where you can specify the pointer and
the region visually would be the finishing touches (as this will vary
for me from IWB to IWB and I'm a Relief Teacher that sees a lot of
different IWBs.)   Presumably this would be easy enough to implement in
the Monitor Preferences (System > Preferences > Monitor) by including
options to limit pointer devices to a particular display.

The other bit of the problem is defining the mouse region for the
pointer device.  Unlike your wacom device (and similar devices) where
the top left point of the device is quite easier to assume as the top
left corner of the display, IWBs aren't so simple.

IWBs have the image projected onto the screen which is also the pointer
device, but it's very unlikely that the top left corner of the projected
image is also at the same place as the top left corner of the screen.
Since the mouse pointer moves to where you place you finger on the
screen, it's important that this maps precisely so you can click buttons
and drag items without a level of hit and miss (and incorrectly buttons
pressed).  I've even seen IWBs where the image isn't even square on the
IWB, and I guess this needs to be addressed too.

Any suggestions for this?


Rodd



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

Re: [Fedora QA] #103: proventester mentor request: fenris02

[Fedora QA]

#103: proventester mentor request: fenris02
--+-
  Reporter:  fenris02 |   Owner:  maxamillion
  Type:  proventester request |  Status:  assigned   
  Priority:  major|   Milestone: 
 Component:  Proventester Mentor Request  | Version: 
Resolution:   |Keywords: 
--+-
Comment (by fenris02):

 I have read both, and know how to use bodhi/f-e-k and how to use the
 updates-testing repo.  Thank you for sponsoring.  I hope proventesters
 helps ensure a better end-user experience.

-- 
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] #70: proventesters request - tomspur

[Fedora QA]

#70: proventesters request - tomspur
--+-
  Reporter:  tomspur  |   Owner:  jlaska
  Type:  proventester request |  Status:  closed
  Priority:  major|   Milestone:
 Component:  Proventester Mentor Request  | Version:
Resolution:  fixed|Keywords:
--+-
Comment (by lmacken):

 Replying to [comment:4 jlaska]:
 > Thanks Thomas.  Great question, I believe the Fedora updates system
 (bodhi) is setup to require proventester feedback for critpath packages in
 all releases.  However, I'm confirming with lmacken to be sure.

 Yes, bodhi currently requires proventester feedback for critical path
 updates across all releases in bodhi.

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

gnome/fc14/x86_64

[Rob Healey]

Greetings:

I have been using rawhide for a very long time now, and I have been having
problems with gnome for a few days now...

It seems like there are several issues right now:
an accessibility problem...
a bonobo issue
nautilus
gedit
nouveau driver
gramps

All of these are issues that are stopping me from being able to do my work
effectively and efficiently...

I having been a user and lover of fedora for a very long time now, and I am
just curious if there are some package updates that can fix or eliminate
these issues?  Nautilus and Gedit have been going on for the longest without
any package updates for a while now...

I am also wondering if I am the only one having these issues

Sincerely yours,
Rob G. Healey
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: flash player 64bit?

[Ankur Sinha]

On Tue, 2010-07-06 at 20:53 -0430, Patrick O'Callaghan wrote:
> On Tue, 2010-07-06 at 16:38 -0700, Rob Healey wrote:
> > Greetings:
> > 
> > Is there anything that can be used as a substitute for the flash
> > player since Adobe refuses and alienates 64bit users?
> > 
> > They either expect us to use i386 software for my 64bit!
> 
> Not sure what that sentence means, but I'm using the 32-bit plugin on
> 64-bit Fedora with no problems (at least no more than usual with Flash).
> 
> poc
> 

hey,

There's an alpha release of 64bit flash that works well enough(like poc
said, this one has as many problems as usual flash)

you can look at the fedoraproject.org wiki page on flash. It has the
required info.

regards,
Ankur

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

Re: flash player 64bit?

[Patrick O'Callaghan]

On Tue, 2010-07-06 at 16:38 -0700, Rob Healey wrote:
> Greetings:
> 
> Is there anything that can be used as a substitute for the flash
> player since Adobe refuses and alienates 64bit users?
> 
> They either expect us to use i386 software for my 64bit!

Not sure what that sentence means, but I'm using the 32-bit plugin on
64-bit Fedora with no problems (at least no more than usual with Flash).

poc

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

flash player 64bit?

[Rob Healey]

Greetings:

Is there anything that can be used as a substitute for the flash player
since Adobe refuses and alienates 64bit users?

They either expect us to use i386 software for my 64bit!

Sincerely yours,
Rob G. Healey
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: Broken dependencies with Fedora 13 + updates-testing - 2010-07-02

[Adam Williamson]

On Mon, 2010-07-05 at 21:29 -0400, Josh Boyer wrote:
> On Mon, Jul 05, 2010 at 12:50:23PM -0700, Adam Williamson wrote:
> >On Fri, 2010-07-02 at 10:03 +, Michael Schwendt wrote:
> >> ==
> >> The results in this summary consider Test Updates!
> >> ==
> >> 
> >> Summary of broken packages (by src.rpm name):
> >
> >> tasks
> >
> >> tasks-0.16-2.fc12.x86_64  requires  libedataserver-1.2.so.11()(64bit)
> >
> >Just to note that the maintainer did actually submit an update for this,
> >but it doesn't seem to have been pushed yet, for no apparent reason.
> >I've asked releng about this.
> 
> Reason:  I started the push last Friday.  If failed, for the same reason it
> failed Thursday, which is due to a bug in bodhi that allows obsoleted critpath
> updates to get pushed to stable.  I told the bodhi owner about it.  Then, I
> left for the weekend due to the major holiday in the United States.

Thanks.

> Is that apparent enough for you?

Now it is, yes. An apparent reason is one that can be found. Prior to
the sending of this mail, the reason was not listed anywhere and hence
was, indeed, not apparent. =)

It always seems a bit unfortunate when lots of stuff shuts down whenever
it's a public holiday in the U.S. It's a bit of a dead giveaway that a
lot of stuff is still performed only by Red Hat staff working in the
U.S. Obviously that's not your problem, just an observation. I'd love it
if there were a community member in Indonesia, or something, pushing
updates when it's 4am on a long weekend in the U.S. (I have not checked
if the timezones in my wild-ass conjecture actually work out :>). It'd
just give me warm community fuzzies.

(Before anyone yells, I know that this applies to quite a bit of QA
stuff too, sadly.)
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

Re: Proven tester wiki love

[Adam Williamson]

On Mon, 2010-07-05 at 19:33 -0500, Aaron Faanes wrote:
> I went to work a bit on jdulaney's fork of the proven tester page to
> make the mentorship-merging stuff fit a little more smoothly, and I
> sort of got carried away. I'd normally just add this as a new revision
> for Proven_testers, but it's pretty substantially revised. It probably
> needs to get re-reviewed:
> 
> https://fedoraproject.org/wiki/User:Dafrito/Proven_tester
> 
> I can write up a summary of the major differences, but I figure I
> should only toss out one wall-of-text at a time. ;) Basically, I took
> the current one, and tried to expand on places that were shallow (like
> testing criteria) and made other sections flow a lot better (like the
> old Feedback section).
> 
> I feel the need to mention I refer to critpath packages as just
> critical packages and critical updates, instead of critical path
> packages and critical path updates. This is purely a stylistic change:
> when I was reading it out loud, I trip over the alliteration of "path
> packages" a lot. Let me know if this (or anything else) is a mortal
> sin.

I understand - I've had the same feeling - but I think we may want to
stick with the 'critical path' naming, as it's what's used elsewhere in
Fedora-land.

I'm not absolutely in love with the 'stable update' concept introduced
here, to be honest. Personally I'd prefer to stick with the concept of
critical path functionality, and whether or not the update violates it.
I'll try and submit a proposed revision for this soon.

I quite like the overall layout of the page. But it's a lot wordier than
the existing version, and reads less like a clear set of instructions on
how to actually perform the proven tester function and more like an
abstract discussion of concepts that requires some work and
interpretation to actually put into practice. I'm not convinced that, if
I were a brand new proven tester applicant, I'd actually feel
particularly confident about exactly what it is I should be doing after
reading that page. In technical language terms, it switches voices quite
a lot. Using the passive voice tends to make sentences longer and harder
to interpret; I'd want to avoid stuff like:

"Neutral karma should be left in cases of an untestable or
insufficiently tested update." It just feels...squiggly, as someone
reading the page for instructions on what to do. I really like the short
sentences, active voice and use of 'you' that we have in the current
version of the page. It makes things a lot more direct.

Honestly, I have to say, I still prefer the current version of the page
over this proposed re-draft.

Do any of the current / recent proven tester applicants have a
preference?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

Re: Fedora 14 test release blocker bugs

[Adam Williamson]

On Tue, 2010-07-06 at 17:10 -0700, John Poelstra wrote:
> Hard to believe, but Fedora QA starts its "Pre-Alpha Rawhide Acceptance 
> Test Plan" testing this Thursday (2010-07-08).
> 
> We've run out of time and run way to implement a new means of tracking 
> blocker bugs for Fedora--previously discussed in the context of using 
> flags in Bugzilla.  We'll continue to use the same process we've used 
> for past releases.

Erm, really? We could throw the existing proposal in in an afternoon if
we wanted to. I was fine with it. Jesse, what was your plan here?
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

Fedora 14 test release blocker bugs

[John Poelstra]

Hard to believe, but Fedora QA starts its "Pre-Alpha Rawhide Acceptance 
Test Plan" testing this Thursday (2010-07-08).

We've run out of time and run way to implement a new means of tracking 
blocker bugs for Fedora--previously discussed in the context of using 
flags in Bugzilla.  We'll continue to use the same process we've used 
for past releases.

I've created tracker bugs for the Fedora 14 Alpha and Beta releases:

Fedora 14 Alpha = F14Alpha = 
https://bugzilla.redhat.com/show_bug.cgi?id=611990

Fedora 14 Beta = F14Beta = 
https://bugzilla.redhat.com/show_bug.cgi?id=611990

Other tracker bugs for Fedora 14 are at: 
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers#Fedora_14

The criteria for considering a bug a release blocker is at:
Alpha--http://fedoraproject.org/wiki/Fedora_14_Alpha_Release_Criteria#Alpha_Blocker_Bugs

Beta--http://fedoraproject.org/wiki/Fedora_14_Beta_Release_Criteria#Beta_Blocker_Bugs

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

RE: ProvenTesters Sponsorship

[John Dulaney]

I'd say only those interested in being mentors.
Dulaney

> Subject: Re: ProvenTesters Sponsorship
> From: awill...@redhat.com
> To: test@lists.fedoraproject.org
> Date: Tue, 6 Jul 2010 15:16:56 -0700
> 
> On Tue, 2010-07-06 at 16:47 -0500, Adam Miller wrote:
> > Hello testers!
> > 
> > I wanted to open a conversation on the list about how we want to as a
> > group handle sponsorship. I wanted to propose two ideas I had and
> > leave the floor open for other suggestions.
> > 
> > 1) Allow the sponsors/mentors to individually decide upon new
> > proventesters FAS group menbers when they feel the person they are
> > mentoring is "ready"
> > 2) Have a vote process such that when a proventester-to-be (i.e.-
> > currently being mentored) is considered familiar enough with the
> > processes by their mentor and has shown a track record of good testing
> > practices that they are to present their formal request to the current
> > proventesters at a QA meeting and then a vote is given?
> > 
> > The way it is currently outlined in the wiki[0] leans more the
> > direction of option 2 but I wanted to bring it up as I think each
> > option has some benefits. I like option 1 because the mentor is going
> > to be the one who ultimately has (or should have) the closest working
> > relationship with the person they are mentoring and therefore would be
> > the best judge upon when they are "ready." I however also like option
> > 2 because it feels like a more formal process and allows for some more
> > uniformity on how decisions are made, allows for the group as a
> > community to constructively critique their peers as well as offers a
> > little more oversight in the process.
> > 
> > I also wanted to point out concerns I have with each. Option 1 I feel
> > could spawn some feeling of chaos where people are getting added
> > "willy nilly" (cheesy saying, I know ... ) and I worry that Option 2
> > could run us into the situation where we could be preventing testers
> > from joining in with their critpath contributions (example: request
> > comes in on a Tuesday, we have to cancel the meeting the following
> > Monday for some reason  2 weeks go by for sponsorship in FAS).
> > 
> > Just my thoughts, please reply with questions, comments, and if need
> > be ... snide remarks ;)
> 
> Most definitely Option 1, Option 2 is way too much bureaucracy. This
> ain't the Order of the Bath.
> 
> I am perfectly happy for people to be added willy-nilly, it's really not
> a problem in my opinion. The reason the group exists is simply to give
> us a control mechanism so that we can take people *out* of it if
> necessary. I don't view it as a terrible disaster if we let someone into
> the group who turns out to either a) suck or b) be be evil, because the
> whole point is that we can then quite easily take them out again. The
> application process and the FAS group are really just there to ensure
> that we have that escape valve, and to provide a little hoop for people
> to jump through so we know they care at least a little bit. That's all.
> 
> For me, the only question to settle is if we make every proventester
> member able to sponsor new members, or just ones who express an interest
> in being mentors.
> -- 
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
> http://www.happyassassin.net
> 
> -- 
> test mailing list
> test@lists.fedoraproject.org
> To unsubscribe: 
> https://admin.fedoraproject.org/mailman/listinfo/test
  
_
Hotmail has tools for the New Busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_1-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: ProvenTesters Sponsorship

[Adam Williamson]

On Tue, 2010-07-06 at 16:47 -0500, Adam Miller wrote:
> Hello testers!
> 
> I wanted to open a conversation on the list about how we want to as a
> group handle sponsorship. I wanted to propose two ideas I had and
> leave the floor open for other suggestions.
> 
> 1) Allow the sponsors/mentors to individually decide upon new
> proventesters FAS group menbers when they feel the person they are
> mentoring is "ready"
> 2) Have a vote process such that when a proventester-to-be (i.e.-
> currently being mentored) is considered familiar enough with the
> processes by their mentor and has shown a track record of good testing
> practices that they are to present their formal request to the current
> proventesters at a QA meeting and then a vote is given?
> 
> The way it is currently outlined in the wiki[0] leans more the
> direction of option 2 but I wanted to bring it up as I think each
> option has some benefits. I like option 1 because the mentor is going
> to be the one who ultimately has (or should have) the closest working
> relationship with the person they are mentoring and therefore would be
> the best judge upon when they are "ready." I however also like option
> 2 because it feels like a more formal process and allows for some more
> uniformity on how decisions are made, allows for the group as a
> community to constructively critique their peers as well as offers a
> little more oversight in the process.
> 
> I also wanted to point out concerns I have with each. Option 1 I feel
> could spawn some feeling of chaos where people are getting added
> "willy nilly" (cheesy saying, I know ... ) and I worry that Option 2
> could run us into the situation where we could be preventing testers
> from joining in with their critpath contributions (example: request
> comes in on a Tuesday, we have to cancel the meeting the following
> Monday for some reason  2 weeks go by for sponsorship in FAS).
> 
> Just my thoughts, please reply with questions, comments, and if need
> be ... snide remarks ;)

Most definitely Option 1, Option 2 is way too much bureaucracy. This
ain't the Order of the Bath.

I am perfectly happy for people to be added willy-nilly, it's really not
a problem in my opinion. The reason the group exists is simply to give
us a control mechanism so that we can take people *out* of it if
necessary. I don't view it as a terrible disaster if we let someone into
the group who turns out to either a) suck or b) be be evil, because the
whole point is that we can then quite easily take them out again. The
application process and the FAS group are really just there to ensure
that we have that escape valve, and to provide a little hoop for people
to jump through so we know they care at least a little bit. That's all.

For me, the only question to settle is if we make every proventester
member able to sponsor new members, or just ones who express an interest
in being mentors.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

RE: ProvenTesters Sponsorship

[John Dulaney]

All: My only comment is that it seems that #2 would certainly lengthen meeting 
times.  I myself don't object to this as I do not currently have a job, but one 
of these days that may impede my ability to make said meetings.

> Date: Tue, 6 Jul 2010 16:47:21 -0500
> Subject: ProvenTesters Sponsorship
> From: maxamill...@fedoraproject.org
> To: test@lists.fedoraproject.org
> 
> Hello testers!
> 
> I wanted to open a conversation on the list about how we want to as a
> group handle sponsorship. I wanted to propose two ideas I had and
> leave the floor open for other suggestions.
> 
> 1) Allow the sponsors/mentors to individually decide upon new
> proventesters FAS group menbers when they feel the person they are
> mentoring is "ready"
> 2) Have a vote process such that when a proventester-to-be (i.e.-
> currently being mentored) is considered familiar enough with the
> processes by their mentor and has shown a track record of good testing
> practices that they are to present their formal request to the current
> proventesters at a QA meeting and then a vote is given?
> 
> The way it is currently outlined in the wiki[0] leans more the
> direction of option 2 but I wanted to bring it up as I think each
> option has some benefits. I like option 1 because the mentor is going
> to be the one who ultimately has (or should have) the closest working
> relationship with the person they are mentoring and therefore would be
> the best judge upon when they are "ready." I however also like option
> 2 because it feels like a more formal process and allows for some more
> uniformity on how decisions are made, allows for the group as a
> community to constructively critique their peers as well as offers a
> little more oversight in the process.
> 
> I also wanted to point out concerns I have with each. Option 1 I feel
> could spawn some feeling of chaos where people are getting added
> "willy nilly" (cheesy saying, I know ... ) and I worry that Option 2
> could run us into the situation where we could be preventing testers
> from joining in with their critpath contributions (example: request
> comes in on a Tuesday, we have to cancel the meeting the following
> Monday for some reason  2 weeks go by for sponsorship in FAS).
> 
> Just my thoughts, please reply with questions, comments, and if need
> be ... snide remarks ;)
> 
> -AdamM
> 
> [0] - http://fedoraproject.org/wiki/QA/JoinProvenTesters
> 
> -- 
> http://maxamillion.googlepages.com
> -
> ()  ascii ribbon campaign - against html e-mail
> /\  www.asciiribbon.org   - against proprietary attachments
> -- 
> test mailing list
> test@lists.fedoraproject.org
> To unsubscribe: 
> https://admin.fedoraproject.org/mailman/listinfo/test
  
_
Hotmail is redefining busy with tools for the New Busy. Get more from your 
inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

ProvenTesters Sponsorship

[Adam Miller]

Hello testers!

I wanted to open a conversation on the list about how we want to as a
group handle sponsorship. I wanted to propose two ideas I had and
leave the floor open for other suggestions.

1) Allow the sponsors/mentors to individually decide upon new
proventesters FAS group menbers when they feel the person they are
mentoring is "ready"
2) Have a vote process such that when a proventester-to-be (i.e.-
currently being mentored) is considered familiar enough with the
processes by their mentor and has shown a track record of good testing
practices that they are to present their formal request to the current
proventesters at a QA meeting and then a vote is given?

The way it is currently outlined in the wiki[0] leans more the
direction of option 2 but I wanted to bring it up as I think each
option has some benefits. I like option 1 because the mentor is going
to be the one who ultimately has (or should have) the closest working
relationship with the person they are mentoring and therefore would be
the best judge upon when they are "ready." I however also like option
2 because it feels like a more formal process and allows for some more
uniformity on how decisions are made, allows for the group as a
community to constructively critique their peers as well as offers a
little more oversight in the process.

I also wanted to point out concerns I have with each. Option 1 I feel
could spawn some feeling of chaos where people are getting added
"willy nilly" (cheesy saying, I know ... ) and I worry that Option 2
could run us into the situation where we could be preventing testers
from joining in with their critpath contributions (example: request
comes in on a Tuesday, we have to cancel the meeting the following
Monday for some reason  2 weeks go by for sponsorship in FAS).

Just my thoughts, please reply with questions, comments, and if need
be ... snide remarks ;)

-AdamM

[0] - http://fedoraproject.org/wiki/QA/JoinProvenTesters

-- 
http://maxamillion.googlepages.com
-
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #103: proventester mentor request: fenris02

[Fedora QA]

#103: proventester mentor request: fenris02
--+-
  Reporter:  fenris02 |   Owner:  maxamillion
  Type:  proventester request |  Status:  assigned   
  Priority:  major|   Milestone: 
 Component:  Proventester Mentor Request  | Version: 
Resolution:   |Keywords: 
--+-
Changes (by maxamillion):

  * owner:  => maxamillion
  * status:  new => assigned

Comment:

 We are now accepting proven testers candidates. Can you please read the
 proven tester instructions at:

 https://fedoraproject.org/wiki/Proven_tester

 and confirm that you've read and understand them and will do your testing
 in accordance with those? Also that you know how to enable the updates-
 testing repository, and use the Bodhi web interface -
 http://bodhi.fedoraproject.org/ - or the fedora-easy-karma utility to
 provide feedback? If you have any questions or problems with the process,
 please ask and I'll help out, that's what mentors are for! Once you're
 clear on the process, I'll sponsor you into the proventesters group.
 Thanks a lot for volunteering.

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

RE: Proven tester wiki love

[James Laska]

On Mon, 2010-07-05 at 21:12 -0400, John Dulaney wrote:
> I like it
> 
> 
> J. H. Dulaney
> 
> > From: dafr...@gmail.com
> > Date: Mon, 5 Jul 2010 19:33:35 -0500
> > Subject: Proven tester wiki love
> > To: test@lists.fedoraproject.org
> > 
> > I went to work a bit on jdulaney's fork of the proven tester page to
> > make the mentorship-merging stuff fit a little more smoothly, and I
> > sort of got carried away. I'd normally just add this as a new
> revision
> > for Proven_testers, but it's pretty substantially revised. It
> probably
> > needs to get re-reviewed:
> > 
> > https://fedoraproject.org/wiki/User:Dafrito/Proven_tester
> > 
> > I can write up a summary of the major differences, but I figure I
> > should only toss out one wall-of-text at a time. ;) Basically, I
> took
> > the current one, and tried to expand on places that were shallow
> (like
> > testing criteria) and made other sections flow a lot better (like
> the
> > old Feedback section).
> > 
> > I feel the need to mention I refer to critpath packages as just
> > critical packages and critical updates, instead of critical path
> > packages and critical path updates. This is purely a stylistic
> change:
> > when I was reading it out loud, I trip over the alliteration of
> "path
> > packages" a lot. Let me know if this (or anything else) is a mortal
> > sin.

Thanks for drafting.  

I agree with John.  I like the updates draft.  I made a few *minor* wiki
changes, feel free to revert if desired.  This new draft feels less like
two distinct pages, and more like something that developed on its own.
This might be more reflective of my reading style, but I'm trying to
think of ways to organize the "Providing feedback" content in a way that
is easy to scan/reference content.  

I was thinking about organizing your existing "Providing feedback"
content into 3 sub-sections:

== Providing feedback ==
...
=== Negative karma ===
...
=== Neutral karma ===
...
=== Positive karma ===
...

You have some good examples for the appropriate type of feedback.  It
might seem obvious to some, but it's not always clear what type of
feedback to give.  Does this clutter your draft too much?  You are more
adept at organizing wiki content, so I trust your instincts.

Thanks,
James


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: Bodhi 0.7.5 release

[Adam Williamson]

On Sun, 2010-07-04 at 17:27 +0200, Michel Alexandre Salim wrote:
> On Sun, Jul 4, 2010 at 1:27 PM, Till Maas  wrote:
> > On Sun, Jul 04, 2010 at 12:34:59PM +0200, Michel Alexandre Salim wrote:
> >> On Sun, Jul 4, 2010 at 10:34 AM, Till Maas  wrote:
> >> > On Sun, Jul 04, 2010 at 01:32:16AM +0200, Michel Alexandre Salim wrote:
> >> >
> >> >> Could a flag be added to only output the package names, so that I can
> >> >> pipe the output directly to yum? Or even better, have that flag
> >> >> automatically cause the bodhi client to invoke yum with
> >> >> --enable-repo=updates-testing with the packages required.
> >> >
> >> > You can just install all critpath updates using:
> >> >
> >> > yum groupinstall --enable-repo=\*-testing critical-path\* core
> >> >
> >> > and then use f-e-k from git with --critpath-only to get only asked for
> >> > the unapproved ones.
> >> Ah! Would be great if this is listed on the QA page.
> >
> > If you know on which page it fits, just add it. I did not find a
> > matching page when I swept through the QA pages.
> >
> I don't -- Adam Williamson probably knows better. Adam?

We have a page with general instructions for testing stuff in
updates-testing:

https://fedoraproject.org/wiki/QA/Updates_Testing

and also a page of instructions for proven testers:

https://fedoraproject.org/wiki/Proven_tester

This is info that's probably useful for both, really. I certainly
intended to extend the proven_tester page with instructions on the new
functionality in f-e-k, as soon as it's available in a released f-e-k
version (I really don't want to be bothering proventesters with
suggestions to check their f-e-k out of git, so it'd be nice to have a
new version pushed with the new features). We could certainly add the
info on using yum to *install* only critpath updates too.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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

Re: [Fedora QA] #69: Proventester mentor request

[Fedora QA]

#69: Proventester mentor request
--+-
  Reporter:  mcloaked |   Owner:  jlaska  
  Type:  proventester request |  Status:  assigned
  Priority:  major|   Milestone:  
 Component:  Proventester Mentor Request  | Version:  
Resolution:   |Keywords:  
--+-
Comment (by mcloaked):

 Replying to [comment:2 jlaska]:
 > Greetings Mike,
 >
 > I'll be happy to sponsor you into the proventesters group.  Please take
 a moment to read through the [https://fedoraproject.org/wiki/Proven_tester
 proventester instructions].  As a proventester, our job isn't to
 exhaustively find all defects in a software update.  The focus is to
 determine whether the proposed software update negatively impacts core
 system functionality.  Pay particular attention to the documented feedback
 procedures.
 >
 > Once you have read the instructions, please confirm that you ...
 >  1. have read and understand the instructions, and intend to follow the
 instructions when testing Fedora critical path updates
 >  2. understand how to enable the update-testing repository
 >  3. are familiar with providing test feedback using either the
 [http://bodhi.fedoraproject.org/ Bodhi web interface], or the
 [https://fedoraproject.org/wiki/Fedora_Easy_Karma fedora-easy-karma
 utility]
 >
 > Please let me know if you have any questions or concerns.  Once I hear
 back, I'll sponsor your membership in the proventesters group.

 Dear James

 Thank you for the offer to sponsor me. I have read and understood the
 prove_tester instructions at the Fedora Wiki, and have been using the
 updates-testing repo enabled for a significant number of tests of pre-
 release packages since the earliest days of Fedora (since FC1). I am also
 familiar with the process to add karma and comments to tested packages via
 bodhi, though I have not explicitely used the fedora-easy-karma facility
 yet.

 I have been following the debate on establishing the proventester group
 with interest, and am happy with the process. I look forward to helping in
 the QA effort with Fedora package testing including critpath packages, and
 at present have Fedora 12 and 13 running on several machines.

 Mike

-- 
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] #76: Use two methods to specify install source

[Fedora QA]

#76: Use two methods to specify install source
--+-
  Reporter:  rhe  |   Owner:  rhe  
  Type:  enhancement  |  Status:  new  
  Priority:  major|   Milestone:  Fedora 14
 Component:  Wiki | Version:   
Resolution:   |Keywords:   
--+-
Comment (by jlaska):

 Replying to [comment:18 rhe]:
 > Currently the "stage2=" kernel parameter is not executable and supported
 (Liam reported a bug regarding it), so it's not very useful to separate
 install.img tests from install source. Therefore, my suggestion is to keep
 the old install source tests (askmethod=), and modify the Additional repo
 tests to make it use either repo= or manual repo adding method.  [[BR]]
 >
 > Please refer to [https://fedoraproject.org/wiki/User:Rhe/Draft2 draft
 template] for details. Thanks.

 Good suggestion, I like this idea.

 The only addition I'd offer is including a repository test in each install
 usage scenario (boot.iso, pxe, cd, DVD, live).  This test would confirm
 that the default repository method works for each install usage scenario.
 I've also added a network-based repository test to the CD and DVD usage
 scenarios, since enabling the network on physical media installs is often
 problematic.

 I've updated [https://fedoraproject.org/wiki/User:Jlaska/Draft my draft to
 provide an example].  I'm not sure I have the default repository correct
 for the boot.iso (repo=http) and pxeboot (repo=mirrorlist) cases, but
 hopefully it conveys the idea.

-- 
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] #69: Proventester mentor request

[Fedora QA]

#69: Proventester mentor request
--+-
  Reporter:  mcloaked |   Owner:  jlaska  
  Type:  proventester request |  Status:  assigned
  Priority:  major|   Milestone:  
 Component:  Proventester Mentor Request  | Version:  
Resolution:   |Keywords:  
--+-
Changes (by jlaska):

  * owner:  => jlaska
  * status:  new => assigned

Comment:

 Greetings Mike,

 I'll be happy to sponsor you into the proventesters group.  Please take a
 moment to read through the [https://fedoraproject.org/wiki/Proven_tester
 proventester instructions].  As a proventester, our job isn't to
 exhaustively find all defects in a software update.  The focus is to
 determine whether the proposed software update negatively impacts core
 system functionality.  Pay particular attention to the documented feedback
 procedures.

 Once you have read the instructions, please confirm that you ...
  1. have read and understand the instructions, and intend to follow the
 instructions when testing Fedora critical path updates
  2. understand how to enable the update-testing repository
  3. are familiar with providing test feedback using either the
 [http://bodhi.fedoraproject.org/ Bodhi web interface], or the
 [https://fedoraproject.org/wiki/Fedora_Easy_Karma fedora-easy-karma
 utility]

 Please let me know if you have any questions or concerns.  Once I hear
 back, I'll sponsor your membership in the proventesters group.

-- 
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] #70: proventesters request - tomspur

[Fedora QA]

#70: proventesters request - tomspur
--+-
  Reporter:  tomspur  |   Owner:  jlaska
  Type:  proventester request |  Status:  closed
  Priority:  major|   Milestone:
 Component:  Proventester Mentor Request  | Version:
Resolution:  fixed|Keywords:
--+-
Changes (by jlaska):

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

Comment:

 Replying to [comment:4 jlaska]:
 > Please apply to the 'proventesters' group in FAS. I will then sponsor
 your membership. Thanks!

 I see you have already applied.  I have sponsored your request.  Welcome
 to proventesters.  Happy testing!

-- 
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] #71: Proventester request

[Fedora QA]

#71: Proventester request
--+-
  Reporter:  kevin|   Owner:  jlaska
  Type:  proventester request |  Status:  closed
  Priority:  major|   Milestone:
 Component:  Proventester Mentor Request  | Version:
Resolution:  fixed|Keywords:
--+-
Changes (by jlaska):

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

Comment:

 Replying to [comment:6 kevin]:
 > applied.

 Sponsored, thanks Kevin.  Happy testing!

-- 
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] #71: Proventester request

[Fedora QA]

#71: Proventester request
--+-
  Reporter:  kevin|   Owner:  jlaska  
  Type:  proventester request |  Status:  assigned
  Priority:  major|   Milestone:  
 Component:  Proventester Mentor Request  | Version:  
Resolution:   |Keywords:  
--+-
Comment (by kevin):

 applied.

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

Fedora 14 Schedule Reminder

[John Poelstra]

Start   End Name
Thu 08-Jul  Fri 16-Jul  Pre-Alpha Rawhide Acceptance Test Plan #1
Tue 13-Jul  Tue 13-Jul  Feature Submission Deadline
Thu 15-Jul  Thu 22-Jul  Pre-Alpha Rawhide Acceptance Test Plan #2
Fri 16-Jul  Fri 16-Jul  Alpha Blocker Meeting (f14alpha) #1
-- 
test mailing list
test@lists.fedoraproject.org
To unsubscribe: 
https://admin.fedoraproject.org/mailman/listinfo/test

Re: [Fedora QA] #70: proventesters request - tomspur

[Fedora QA]

#70: proventesters request - tomspur
--+-
  Reporter:  tomspur  |   Owner:  jlaska  
  Type:  proventester request |  Status:  assigned
  Priority:  major|   Milestone:  
 Component:  Proventester Mentor Request  | Version:  
Resolution:   |Keywords:  
--+-
Comment (by jlaska):

 Replying to [comment:3 tomspur]:
 > My only question for now is, for how many releases will the critpath be
 enabled?
 > Are there enought testers for more than one release?
 > (I'll be mostly testing F-13 right now.)

 Thanks Thomas.  Great question, I believe the Fedora updates system
 (bodhi) is setup to require proventester feedback for critpath packages in
 all releases.  However, I'm confirming with lmacken to be sure.

 Please apply to the 'proventesters' group in FAS. I will then sponsor your
 membership. Thanks!

-- 
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] #71: Proventester request

[Fedora QA]

#71: Proventester request
--+-
  Reporter:  kevin|   Owner:  jlaska  
  Type:  proventester request |  Status:  assigned
  Priority:  major|   Milestone:  
 Component:  Proventester Mentor Request  | Version:  
Resolution:   |Keywords:  
--+-
Comment (by jlaska):

 Replying to [comment:4 kevin]:
 > Yes, I can confirm 1, 2 and 3. I have several machines with updates-
 testing enabled, and use fedora-easy-karma as often as I can remember to.
 ;)
 >

 Thanks Kevin, please apply to the 'proventesters' group in
 [https://admin.fedoraproject.org/accounts/group/view/proventesters FAS].
 I will then sponsor your membership.  Thanks!

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

rawhide report: 20100706 changes

[Rawhide Report]

Compose started at Tue Jul  6 08:15:06 UTC 2010

Broken deps for i386
--
BackupPC-3.1.0-14.fc14.noarch requires perl-suidperl
1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9
1:anjuta-2.30.0.0-2.fc14.i686 requires libwebkit-1.0.so.2
claws-mail-plugins-geolocation-3.7.6-3.fc14.i686 requires 
libchamplain-gtk-0.4.so.0
claws-mail-plugins-geolocation-3.7.6-3.fc14.i686 requires 
libchamplain-0.4.so.0
dates-0.4.11-3.fc14.i686 requires libedataserver-1.2.so.11
deskbar-applet-2.30.0-1.1.fc14.i686 requires libedataserver-1.2.so.12
eclipse-checkstyle-4.0.1-14.fc12.noarch requires checkstyle-optional = 
0:4.1
eclipse-checkstyle-4.0.1-14.fc12.noarch requires checkstyle = 0:4.1
emerillon-0.1.1-2.fc13.i686 requires libchamplain-0.4.so.0
emerillon-0.1.1-2.fc13.i686 requires libchamplain-gtk-0.4.so.0
emerillon-devel-0.1.1-2.fc13.i686 requires pkgconfig(champlain-0.4)
empathy-2.31.3-3.fc14.i686 requires libchamplain-gtk-0.4.so.0
empathy-2.31.3-3.fc14.i686 requires libchamplain-0.4.so.0
eog-plugins-2.30.0-1.fc14.i686 requires libchamplain-0.4.so.0
eog-plugins-2.30.0-1.fc14.i686 requires libchamplain-gtk-0.4.so.0
epiphany-2.31.3-1.fc14.i686 requires libwebkit-1.0.so.2
evolution-rss-0.1.9-7.20100525git.fc14.i686 requires libwebkit-1.0.so.2
gmpc-0.19.1-3.fc14.i686 requires libwebkit-1.0.so.2
gnome-phone-manager-0.65-6.fc14.i686 requires libgnome-bluetooth.so.7
gnucash-2.3.13-1.fc14.i686 requires libwebkit-1.0.so.2
gpx-viewer-0.1.2-2.fc14.i686 requires libchamplain-0.4.so.0
gpx-viewer-0.1.2-2.fc14.i686 requires libchamplain-gtk-0.4.so.0
7:kdenetwork-4.4.90-1.fc14.i686 requires libmsn.so.0.1
kst-fits-1.8.0-7.fc14.i686 requires cfitsio = 0:3.240
lekhonee-gnome-0.11-2.fc14.i686 requires libwebkit-1.0.so.2
libpeas-0.5.1-1.fc14.i686 requires libgdk_pixbuf-3.0.so.0
libpeas-devel-0.5.1-1.fc14.i686 requires libgdk_pixbuf-3.0.so.0
1:liferea-1.6.3-1.fc14.i686 requires libwebkit-1.0.so.2
maven2-plugin-checkstyle-2.0.8-3.fc12.noarch requires 
checkstyle-optional >= 0:4.1
merkaartor-0.16.1-1.fc13.i686 requires libexiv2.so.6
midori-0.2.6-1.fc14.i686 requires libwebkit-1.0.so.2
mingw32-OpenSceneGraph-2.8.2-4.fc14.noarch requires 
mingw32(libpng-3.dll)
moblin-panel-status-0.1.21-3.fc14.i686 requires libchamplain-0.4.so.0
perl-DBI-Dumper-2.01-8.fc12.i686 requires perl(:MODULE_COMPAT_5.10.0)
perl-Data-Alias-1.07-6.fc13.i686 requires perl(:MODULE_COMPAT_5.10.1)
perl-Pugs-Compiler-Rule-0.37-4.fc13.noarch requires 
perl(:MODULE_COMPAT_5.10.1)
perl-Test-AutoBuild-1.2.2-9.fc12.i686 requires 
perl(:MODULE_COMPAT_5.10.0)

plexus-containers-component-annotations-javadoc-1.0-0.1.a34.7.fc12.noarch 
requires jakarta-commons-logging-javadoc
python3-beaker-1.5.3-4.fc14.noarch requires python3-paste
pywebkitgtk-1.1.6-3.fc14.i686 requires libwebkit-1.0.so.2
qtgpsc-0.2.3-6.fc12.i686 requires libgps.so.18
seed-2.31.1-1.fc14.i686 requires libwebkit-1.0.so.2
shotwell-0.5.2-1.fc14.i686 requires libwebkit-1.0.so.2
skyviewer-1.0.0-4.fc14.i686 requires libQGLViewer.so.2.3.5
spacewalk-certs-tools-1.1.1-1.fc14.noarch requires 
spacewalk-backend-libs >= 0:0.8.28
themonospot-gui-qt-0.1.3-6.fc14.i686 requires mono(qt-dotnet) = 
0:4.5.0.0
themonospot-gui-qt-0.1.3-6.fc14.i686 requires libqyotoshared.so.1
vfrnav-0.4-1.fc13.i686 requires libgps.so.18
viking-0.9.91-3.fc13.i686 requires libgps.so.18
xcf-pixbuf-loader-0.0.1-3.8af913d1.fc14.i686 requires 
/usr/lib/gtk-2.0/2.10.0/loaders
xenner-0.48-1.fc14.i386 requires libxenguest.so.3.4



Broken deps for x86_64
--
BackupPC-3.1.0-14.fc14.noarch requires perl-suidperl
1:anjuta-2.30.0.0-2.fc14.i686 requires libgladeui-1.so.9
1:anjuta-2.30.0.0-2.fc14.i686 requires libwebkit-1.0.so.2
1:anjuta-2.30.0.0-2.fc14.x86_64 requires libgladeui-1.so.9()(64bit)
1:anjuta-2.30.0.0-2.fc14.x86_64 requires libwebkit-1.0.so.2()(64bit)
claws-mail-plugins-geolocation-3.7.6-3.fc14.x86_64 requires 
libchamplain-gtk-0.4.so.0()(64bit)
claws-mail-plugins-geolocation-3.7.6-3.fc14.x86_64 requires 
libchamplain-0.4.so.0()(64bit)
dates-0.4.11-3.fc14.x86_64 requires libedataserver-1.2.so.11()(64bit)
deskbar-applet-2.30.0-1.1.fc14.x86_64 requires 
libedataserver-1.2.so.12()(64bit)
eclipse-checkstyle-4.0.1-14.fc12.noarch requires checkstyle-optional = 
0:4.1
eclipse-checkstyle-4.0.1-14.fc12.noarch requires checkstyle = 0:4.1
emerillon-0.1.1-2.fc13.x86_64 requires 
libchamplain-gtk-0.4.so.0()(64bit)
emerillon-0.1.1-2.fc13.x86_64 requires

Re: [Fedora QA] #76: Use two methods to specify install source

[Fedora QA]

#76: Use two methods to specify install source
--+-
  Reporter:  rhe  |   Owner:  rhe  
  Type:  enhancement  |  Status:  new  
  Priority:  major|   Milestone:  Fedora 14
 Component:  Wiki | Version:   
Resolution:   |Keywords:   
--+-
Comment (by rhe):

 Back to the topic, after this new grouping method, I find it's hard to
 define installation source tests. [[BR]]

 First, install source generally contains two parts: 1. Install.img
 (stage2=) 2. package repository (repo=). So far we have no specific tests
 focusing on each of them, but we have: 1. Install source tests (askmethod
 to specify one source for both install.img and package repo) 2. Additional
 repository (add another package repo： http, nfs, CD/DVD and
 mirrorlist).[[BR]]

 Initially I planed to create new install.img source tests(stage2=) and
 modify existing install source tests to package repository tests(repo=).
 But then I don't know how to name the "askmethod=" tests. Besides, there
 are already 9 install source tests(askmethod), so I don't think it's nice
 and realistic to add 9 install.img source tests and 9 package repository
 tests based on these. [[BR]]

 Currently the "stage2=" kernel parameter is not executable and supported
 (Liam reported a bug regarding it), so it's not very useful to separate
 install.img tests from install source. Therefore, my suggestion is to keep
 the old install source tests (askmethod=), and modify the Additional repo
 tests to make it use either repo= or manual repo adding method.  [[BR]]

 Please refer to [https://fedoraproject.org/wiki/User:Rhe/Draft2 draft
 template] for details. Thanks.

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

[Test-Announce] Bugzappers Meeting Agenda for 2010-07-06

[Adam Williamson]

Event: Fedora Bug Triage Meeting
Date: 2010-07-06
Time: 15:00 UTC
Location: #fedora-meeting on irc.freenode.net

Agenda Items:
https://fedoraproject.org/wiki/BugZappers:meeting-agenda-list

If anyone has an additional topic they would like discussed, please
reply to this email.

= Agenda =

* triage metrics update
https://fedoraproject.org/wiki/User:Jraber

* open floor
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

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