On Mon, 2021-02-22 at 07:51 -0500, pmkel...@frontier.com wrote:
> On 2/21/21 16:18, Chris Murphy wrote:
> > On Sun, Feb 21, 2021 at 6:18 AM pmkel...@frontier.com
> > wrote:
> > >
> > >
> > > I'm sitting here thinking about F34 Beta being just two days away and
> > > what I have observed in my te
On 2/21/21 16:18, Chris Murphy wrote:
On Sun, Feb 21, 2021 at 6:18 AM pmkel...@frontier.com
wrote:
I'm sitting here thinking about F34 Beta being just two days away and
what I have observed in my testing. I must admit being more than a
little concerned.
Beta freeze starts Tue 2021-02-23. B
On Sun, Feb 21, 2021 at 6:18 AM pmkel...@frontier.com
wrote:
>
>
> I'm sitting here thinking about F34 Beta being just two days away and
> what I have observed in my testing. I must admit being more than a
> little concerned.
Beta freeze starts Tue 2021-02-23. Beta Release (Preferred Target) is
T
I'm sitting here thinking about F34 Beta being just two days away and
what I have observed in my testing. I must admit being more than a
little concerned.
I have watched the blocker bugs and my concern stems from the fact that
I don't see some troubling ones listed there. Also the
On Mon, Sep 16, 2019 at 5:06 PM Adam Williamson
wrote:
> I still consider automatic blockers to be about obviousness (not
> criticality), but I'm open to different resolutions here anyway, if we
> want to come up with something really clear.
>
For the record, we talked about this yesterday in QA
On Mon, 2019-09-16 at 16:11 +0200, Kamil Paral wrote:
> On Fri, Sep 13, 2019 at 6:44 PM Adam Williamson
> wrote:
>
> > On Fri, 2019-09-13 at 13:53 +0200, Kamil Paral wrote:
> > > As I feel it (and would like to have it), "automatic blockers" imply they
> > > are such core and basic issues that th
On Fri, Sep 13, 2019 at 6:44 PM Adam Williamson
wrote:
> On Fri, 2019-09-13 at 13:53 +0200, Kamil Paral wrote:
> > As I feel it (and would like to have it), "automatic blockers" imply they
> > are such core and basic issues that they are non-questionable and
> > non-waivable (except by FESCo, whi
On Fri, Sep 13, 2019 at 1:10 PM Adam Williamson
wrote:
>
> Let's be clear about what we mean by 'waiving'. Actually I'd like to
> avoid using that word at all (yes I know I did it once, I edited my
> mail to take them out but missed one).
>
> We are *not* 'waiving' the criterion. We are *not* deci
On Fri, 2019-09-13 at 12:34 -0600, Chris Murphy wrote:
> On Fri, Sep 13, 2019 at 10:43 AM Adam Williamson
> wrote:
> > On Fri, 2019-09-13 at 13:53 +0200, Kamil Paral wrote:
> > > As I feel it (and would like to have it), "automatic blockers" imply they
> > > are such core and basic issues that the
On Fri, Sep 13, 2019 at 10:43 AM Adam Williamson
wrote:
>
> On Fri, 2019-09-13 at 13:53 +0200, Kamil Paral wrote:
> > As I feel it (and would like to have it), "automatic blockers" imply they
> > are such core and basic issues that they are non-questionable and
> > non-waivable (except by FESCo, w
On Fri, 2019-09-13 at 13:53 +0200, Kamil Paral wrote:
> As I feel it (and would like to have it), "automatic blockers" imply they
> are such core and basic issues that they are non-questionable and
> non-waivable (except by FESCo, which is itself part of the same policy and
> marked to have godly p
; "Automatic blockers can't un-accepted (waived), with the exception of FESCo."
>
> An alternative option would be to exclude just "last minute blocker bugs"
> exception, but keep "difficult to fix" exception:
> "Automatic blockers can't be sub
e list of automatic blockers
[3], those are broken composes, dead-on-arrival images, incorrect
checksums, broken dependencies, and *oversize images*. I don't think anyone
but FESCo should be able to say "go" in that case, regardless of when the
problem was reported (even minutes before t
lly speaking, any bug that is agreed to be a violation of the
> [[Fedora Release Criteria|release criteria]] should be accepted as a
> blocker bug for the next relevant milestone release. However, bearing
> in mind the [[Fedora_Release_Life_Cycle|Fedora life cycle's]] emphasi
On Wed, Aug 14, 2019 at 4:48 PM Adam Williamson
wrote:
>
> Hmm. Since we've had a proposal for 7 days and a proposal for 3 days,
> why not just split the difference and say 5 days? That would be the
> Saturday before go/no-go: so anything proposed the week before isn't
> covered, but from the week
On Wed, 2019-08-14 at 14:26 -0600, Chris Murphy wrote:
> Another option here, is applying the last minute blocker to the
> Release Target #1 week, and not to the Preferred Target week. Of even,
> if it's a 3 day period apply it to the Preferred Target week; and if 7
> days apply to Target #1 week.
n then!
> >
> Whoops! I was going to say the only bug that's really made me mad in
> the year I've been FPgM is the one that got nominated as a blocker
> within a few mintues of the Go/No-Go meeting starting (I don't recall
> if it was before or after, I just know that i
On Wed, Aug 14, 2019 at 11:26 AM Adam Williamson
wrote:
>
> If we say 3 days, then we're committing to doing all of that for a
> blocker that's proposed the Sunday before the go/no-go - one day before
> the final blocker review meeting. Which, I mean...yeah, we have time to
> do all that. Juuust b
On Wed, Aug 14, 2019 at 3:57 PM Chris Murphy wrote:
>
> On Wed, Aug 14, 2019 at 11:14 AM Ben Cotton wrote:
> >
> > only bug that's really made me mad in the years
>
> Go on then!
>
Whoops! I was going to say the only bug that's really made me mad in
the year I've been FPgM is the one that got nom
On Wed, Aug 14, 2019 at 11:14 AM Ben Cotton wrote:
>
> On Tue, Aug 13, 2019 at 8:46 AM Kamil Paral wrote:
> >
> > I thought about it and 7 days probably sounds OK, considering it also
> > includes the weekend. I think I wouldn't increase it, but consider
> > decreasing it if people think it's t
I have the same doubts about the 7. Well, nobody is sure ;) +1 on my side,
great work Pat & Adam
On August 14, 2019 7:33:03 PM GMT+02:00, Ben Cotton wrote:
>On Wed, Aug 14, 2019 at 1:26 PM Adam Williamson
> wrote:
>>
>> If we say 3 days, then we're committing to doing all of that for a
>> blocke
On Wed, Aug 14, 2019 at 1:26 PM Adam Williamson
wrote:
>
> If we say 3 days, then we're committing to doing all of that for a
> blocker that's proposed the Sunday before the go/no-go - one day before
> the final blocker review meeting. Which, I mean...yeah, we have time to
> do all that. Juuust ba
On Wed, 2019-08-14 at 13:13 -0400, Ben Cotton wrote:
> On Tue, Aug 13, 2019 at 8:46 AM Kamil Paral wrote:
> > I thought about it and 7 days probably sounds OK, considering it also
> > includes the weekend. I think I wouldn't increase it, but consider
> > decreasing it if people think it's the ri
On Tue, Aug 13, 2019 at 8:46 AM Kamil Paral wrote:
>
> I thought about it and 7 days probably sounds OK, considering it also
> includes the weekend. I think I wouldn't increase it, but consider decreasing
> it if people think it's the right way to go.
>
7 is definitely higher than I would have
milestone release. However, bearing
> > > in mind the [[Fedora_Release_Life_Cycle|Fedora life cycle's]] emphasis
> > > on '''both''' time '''and''' quality, in some cases we may make an
> > > ex
On Mon, 2019-08-12 at 16:11 -0600, Chris Murphy wrote:
> On Fri, Aug 9, 2019 at 8:04 PM Adam Williamson
> wrote:
> > # '''Last minute blocker bugs''' - bugs proposed as blockers 7 days or
> > fewer before the scheduled [[Go_No_Go_Meeting]] fo
On Fri, Aug 9, 2019 at 8:04 PM Adam Williamson
wrote:
>
> # '''Last minute blocker bugs''' - bugs proposed as blockers 7 days or
> fewer before the scheduled [[Go_No_Go_Meeting]] for a milestone release
> (Beta or Final) can be considered under this po
both''' time '''and''' quality, in some cases we may make an
> > exception. There are two main categories of bug that may be
> > 'exceptional':
> >
> > # '''Last minute blocker bugs''' - bugs p
t; blocker bug for the next relevant milestone release. However, bearing
> in mind the [[Fedora_Release_Life_Cycle|Fedora life cycle's]] emphasis
> on '''both''' time '''and''' quality, in some cases we may make an
> exception
ugs''' - bugs proposed as blockers 7 days or
fewer before the scheduled [[Go_No_Go_Meeting]] for a milestone release
(Beta or Final) can be considered under this policy, as there are some
circumstances in which we believe it is not sensible to delay an
otherwise-impending release to fix a
in line? It makes it more convenient to read them quickly. For the
record, here is Pat's proposal:
" 3Last Minute Blocker Bugs
3.1 A Last Minute Blocker Bug occurs when a bug is nominated
as a blocker bug seven (7) days or less before a scheduled freeze for
I got feedback from Adam and Ben today; so the following changes have
been made:
I have added a little paragraph at the beginning to say what a last
minute blocker bug is. I used freeze as the time anchor rather than a
meeting since that seems to be the most firm time constraint we work to.
P
I like Pat's proposal, but I don't see that we actually say what a
"last minute blocker bug" is. I am in favor of giving us a little
lattitude to use judgment, but I think we want to set some sort of
guidance for our future selves. We should make it clear that "last
minute" status is based on when
On Mon, 2019-06-17 at 09:20 -0400, pmkel...@frontier.com wrote:
> Proposed additions to the Blocker Bug Procedure to cover Last Minute
> Blocker Bugs (tidied up version). In case we cover this today at the QA
> meeting.
Thanks for this, Pat, and sorry for the late reply. I will put th
Proposed additions to the Blocker Bug Procedure to cover Last Minute
Blocker Bugs (tidied up version). In case we cover this today at the QA
meeting.
Have a Great Day!
Pat (tablepc)
BlockerBugs.odt
Description: application/vnd.oasis.opendocument.text
I like the general idea of the original draft, but I would go for a simpler
route: bugs not nominated as a blocker by the scheduled start of the
Go/No-Go meeting are subject to not being considered for blocking the
release.
This gives us the flexibility to make the best judgment call that we can.
Lukas Ruzicka igorleak hau idatzi zuen (2019 mai. 14,
ar. 14:12):
>
> I am talking about the quorum, if there is a late discovered bug, that
> would normally be considered a blocker, but because
>
> a) it could not be fixed on time, and
> b) it is not as serious as it would prevent people from us
I am talking about the quorum, if there is a late discovered bug, that
would normally be considered a blocker, but because
a) it could not be fixed on time, and
b) it is not as serious as it would prevent people from using Fedora anyway
In this case, I think more people to decide is crucial becau
Lukas Ruzicka igorleak hau idatzi zuen (2019 mai. 14,
ar. 12:55):
> Yeah, you can be right, Julen, however the process, as we are having now,
> would allow discarding Blocker Bugs possibly anytime, even if 3 or 4 people
> would be present on a meeting. And I don't think it is co
Yeah, you can be right, Julen, however the process, as we are having now,
would allow discarding Blocker Bugs possibly anytime, even if 3 or 4 people
would be present on a meeting. And I don't think it is correct to let 4
people decide.
In case of a qorum (and I am not saying it has to
votes could be recorded in all such meetings (blocker bugs meeting,
>go-nogo, ...)
>- votes could be casted in Bugzilla and IRC presence does not need to
>be required.
>
> The most important thing is, the majority agrees, not that we need to
> organize voting every time
I have suggested the quorum, but we can still discuss the exact numbers
(mine were just examples). Besides, the votes do not have to come from
people present in one particular IRC meeting, but
- votes could be recorded in all such meetings (blocker bugs meeting,
go-nogo, ...)
- votes
On both fc29 and fc30 cycles, nor the later blocker review meetings nor the
go/no-go ones did not have 10 participants, so needing a 80% agremeent with
a minimum of 10 votes would directly block on last minute bugs on those
scenarios.
I don't have a clear opinion on this, but for now I would prefe
In the last QA team meeting (04/29/2019) I volunteered to help with
> adding something to the blocker bug process to handle Last Minute
> Blocker Bugs.
>
> I started by reading:
>
> https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/Q46M75GUKRHMI5IMNGB
This is a resend.
In the last QA team meeting (04/29/2019) I volunteered to help with
adding something to the blocker bug process to handle Last Minute
Blocker Bugs.
I started by reading:
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message
In the last QA team meeting (04/29/2019) I volunteered to help with
adding something to the blocker bug process to handle Last Minute
Blocker Bugs.
I started by reading:
https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/message/Q46M75GUKRHMI5IMNGBNL6XHLD5GLLTS
On Tue, 14 Oct 2014 19:20:59 -0500
Michael Catanzaro wrote:
> The blocker bugs app [1] seems to have hardcoded links to outdated
> release criteria. Not sure where to file a bug
>
> [1] https://qa.fedoraproject.org/blockerbugs/propose_bug
Wow, that's been around for a whi
The blocker bugs app [1] seems to have hardcoded links to outdated
release criteria. Not sure where to file a bug
[1] https://qa.fedoraproject.org/blockerbugs/propose_bug
signature.asc
Description: This is a digitally signed message part
--
test mailing list
test@lists.fedoraproject.org
To
On Tue, 2014-08-19 at 10:24 -0600, Chris Murphy wrote:
> On Aug 19, 2014, at 10:07 AM, Tim Flink wrote:
> >
> > I don't see a local account in phab for you, so you'd end up clicking
> > on the "register or login with persona" button on the login page.
> > FedOAuth has persona intergration, so by
On Aug 19, 2014, at 10:07 AM, Tim Flink wrote:
>
> I don't see a local account in phab for you, so you'd end up clicking
> on the "register or login with persona" button on the login page.
> FedOAuth has persona intergration, so by using
> @fedoraproject.org, you will be redirected to FedOAuth f
On Tue, 19 Aug 2014 09:54:01 -0600
Chris Murphy wrote:
>
> On Aug 19, 2014, at 9:22 AM, Tim Flink wrote:
>
> > On Tue, 19 Aug 2014 09:12:24 -0600
> > Chris Murphy wrote:
> >
> >>
> >> On Aug 19, 2014, at 1:18 AM, Christopher Meng
> >> wrote:
> >>
> >>> I don't see the issue here, too.
> >
On Aug 19, 2014, at 9:22 AM, Tim Flink wrote:
> On Tue, 19 Aug 2014 09:12:24 -0600
> Chris Murphy wrote:
>
>>
>> On Aug 19, 2014, at 1:18 AM, Christopher Meng
>> wrote:
>>
>>> I don't see the issue here, too.
>>>
>>> Maybe caused by the special hardware?
>>
>> Well this is just bizarre. T
On Tue, 19 Aug 2014 09:12:24 -0600
Chris Murphy wrote:
>
> On Aug 19, 2014, at 1:18 AM, Christopher Meng
> wrote:
>
> > I don't see the issue here, too.
> >
> > Maybe caused by the special hardware?
>
> Well this is just bizarre. This morning, it's working fine.
> Everything is the same, the
On Aug 19, 2014, at 1:18 AM, Christopher Meng wrote:
> I don't see the issue here, too.
>
> Maybe caused by the special hardware?
Well this is just bizarre. This morning, it's working fine. Everything is the
same, the system hasn't even rebooted. Yesterday I relaunched Chrome, same
problem.
I don't see the issue here, too.
Maybe caused by the special hardware?
--
test mailing list
test@lists.fedoraproject.org
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test
On 08/19/14 06:47, Chris Murphy wrote:
> Any Chrome users seeing missing header text in the blocker bugs page? I'm
> seeing missing text in Chrome on OS X but not Firefox. It also works in
> Firefox on Fedora. I don't have Chrome on Fedora at the moment.
>
> Ticket here,
Hi Chris,
Just checked with Chrome (on fedora 20) and it works well.
Moshe
On Tue, Aug 19, 2014 at 1:47 AM, Chris Murphy
wrote:
> Any Chrome users seeing missing header text in the blocker bugs page? I'm
> seeing missing text in Chrome on OS X but not Firefox. It also works in
&
Any Chrome users seeing missing header text in the blocker bugs page? I'm
seeing missing text in Chrome on OS X but not Firefox. It also works in Firefox
on Fedora. I don't have Chrome on Fedora at the moment.
Ticket here, includes screen shots of what I'm seeing:
https://f
The breakage of the "guided" path install along side Windows has been broken
for a month, apparently:
anaconda damages W7 guests when reclaiming space with 'shrink' using AUTOMATIC
PARTITIONING
https://bugzilla.redhat.com/show_bug.cgi?id=875484
One of the bugs is a dup it seems.
Resize of N
On 2012-12-13 16:20 (GMT-0800) Brian Marshall composed:
On Thu, Dec 13, 2012 at 05:21:03PM -0500, Felix Miata wrote:
Those who follow all the instructions don't have that problem. Those
"unmovable" areas are usually the swap file and/or the hibernation
file. Disable those, reboot, and resize
On Thu, Dec 13, 2012 at 05:21:03PM -0500, Felix Miata wrote:
> On 2012-12-13 17:04 (GMT-0500) Tom Horsley composed:
> >The trouble with that is that the Windows resizer is not very good.
> >I tried to do that, but Windows had this giant partition with supposedly
> >"unmoveable" data structures righ
On 2012-12-13 17:04 (GMT-0500) Tom Horsley composed:
On Thu, 13 Dec 2012 16:52:46 -0500
Felix Miata wrote:
Something should be done to get people to resize Windows Vista+ partitions in
advance using Windows' own resizer, leaving the installer to just use
freespace.
The trouble with that
On Thu, 13 Dec 2012 16:52:46 -0500
Felix Miata wrote:
> Something should be done to get people to resize Windows Vista+ partitions in
> advance using Windows' own resizer, leaving the installer to just use
> freespace.
The trouble with that is that the Windows resizer is not very good.
I tried
On Thu, 2012-12-13 at 14:46 -0700, Chris Murphy wrote:
> Since there are no anaconda logs in 885912 I'm going to post mine and see
> what gets figured out.
There are, they're just compressed. I asked dlehman to look at this this
morning.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw
On 2012-12-13 14:21 (GMT-0700) Chris Murphy composed:
shrinking Windows partition creates an unusable dual-boot setup
https://bugzilla.redhat.com/show_bug.cgi?id=875944
Resize of NTFS partition results in partition smaller than the filesystem,
broken Windows install
https://bugzilla.redhat.com/
On Dec 13, 2012, at 2:21 PM, Chris Murphy wrote:
>
> 2.
> The other is probably a libntfs-3g bug, so I think 885912 should be
> reassigned.
> minimum resize, or if it's just screwing up the resize (or both).
I think I'm wrong. Looks like anaconda is having parted set the partition size
in t
Instead of cluttering the bug reports, since it's unclear what bug is what, if
they are dups, etc. to discuss here.
The gist is that regardless of cause, after installing Fedora, Windows 7 is not
bootable and is not repairable by the Windows automatic startup repair.
shrinking Windows partition
Blocks: (and Depends On:) field of any Fedora bug! Thanks to Matt Tyson
> for doing this at last.
>
> What this means is you no longer need editbugs privileges to be able to
> propose blocker bugs. This was never intended to be the case, it was
> only an unfortunate consequence of the me
this at last.
What this means is you no longer need editbugs privileges to be able to
propose blocker bugs. This was never intended to be the case, it was
only an unfortunate consequence of the mechanism used for nominating
bugs as blockers. Now anyone with a BZ account can follow the
instructions
On Fri, 22 Jun 2012 11:14:56 -0700
Adam Williamson wrote:
> One area that may be more interesting, I guess, would be to look at
> various timing issues. One key one would be 'how long it takes for
> bugs to be a) nominated and b) accepted as blockers, after they are
> reported'. I've come across
thing we're all more or less aware of anyway: I
would expect the majority of blocker bugs to be in anaconda, then in the
other obvious early-boot critical components (kernel, plymouth, systemd,
udev etc), firstboot, preupgrade, and image generation stuff like
livecd-tools. So I'm not sure tha
Look at the time difference between blocker status (first bugzilla'd,
nominated for blocker, and/or confirmed) and the package revision
(culprit created, then fixed.) There might be some relationship
between problem packages and frequency of releases.
--
--
test mailing list
test@lists.fedorapr
One of the items on the Fedora 17 QA retrospective -
https://fedoraproject.org/wiki/Fedora_17_QA_Retrospective - is a
suggestion from Bruno that we could perhaps gain some useful insights by
analyzing the (by now considerable) corpus of blocker bugs from previous
releases, as a way perhaps to
Sender: test-boun...@lists.fedoraproject.org
On-Behalf-Of: awill...@redhat.com
Subject: Review and notification of blocker bugs
Message-Id: <1311889932.1955.67.camel@adam>
Recipient: np...@trinity.edu.test-google-a.com, Forwarded: neal.p...@trinity.edu
--- Begin Message ---
I'm currentl
Sender: test-boun...@lists.fedoraproject.org
On-Behalf-Of: tfl...@redhat.com
Subject: Re: Review and notification of blocker bugs
Message-Id: <20110728162037.07421...@seasicklaptop.tirfa.net>
Recipient: np...@trinity.edu.test-google-a.com, Forwarded: neal.p...@trinity.edu
--- Begin Message
Sender: test-boun...@lists.fedoraproject.org
On-Behalf-Of: awill...@redhat.com
Subject: Re: Review and notification of blocker bugs
Message-Id: <1311893274.1955.84.camel@adam>
Recipient: np...@trinity.edu.test-google-a.com, Forwarded: neal.p...@trinity.edu
--- Begin Message ---
On Thu, 2011
n the schedule is a
bit vague, and can easily be taken to refer more to a process of 'take a
list of blocker bugs and post it to an email list' rather than the more
case-by-case, directly-via-bugzilla approach we've been using lately.
--
Adam Williamson
Fedora QA Community Monkey
IRC:
> F17 and later and forget about it.
>
> "Daily Review & Notification of Open Alpha|Beta|Final Blocker Bugs" is a
> trickier customer. As scheduled, it seems to suggest that for Alpha,
> Beta and Final, we should be 'reviewing and notifying' open blockers for
> an a
it I can see would be the potential to catch big
> issues a couple of days earlier than we otherwise would. I wonder how
> many major issues went undetected in F15 until a blocker review
> meeting.
Really, not many, I don't think. Several of us, at least including James
and myself, make a
On Thu, 28 Jul 2011 14:52:12 -0700
Adam Williamson wrote:
> "Daily Review & Notification of Open Alpha|Beta|Final Blocker Bugs"
> is a trickier customer. As scheduled, it seems to suggest that for
> Alpha, Beta and Final, we should be 'reviewing and notifying'
sted a long time ago by engineering,
but never really happened. It's now pretty much superseded by AutoQA
upgradepath testing, so I think we can delete it from the calendar for
F17 and later and forget about it.
"Daily Review & Notification of Open Alpha|Beta|Final Blocker Bugs&quo
On Wed, 2010-10-13 at 12:49 +0100, mike cloaked wrote:
> On Tue, Oct 12, 2010 at 8:47 PM, Adam Williamson wrote:
>
> > I believe we can't really test the ones in anaconda until images with
> > anaconda 14.19 are available - TC1?
>
> I checked this morning and 14.19 is not yet in the repo for dev
On Wed, Oct 13, 2010 at 9:50 PM, James Laska wrote:
> Sure, very possible. If a yum repo isn't available that has the exact
> mix of packages you desire, you'll need to provide one.
>
> So for anaconda-14.19-1, you could download it and create a local yum
> repo for pungi
>
> # mkdir /tmp
On Wed, 2010-10-13 at 21:39 +0100, mike cloaked wrote:
> On Wed, Oct 13, 2010 at 9:20 PM, James Laska wrote:
>
> > I was attempting just that earlier this week following instructions at
> > https://fedoraproject.org/wiki/How_to_build_a_Rawhide_ISO_image_for_testing
> >
> > I had success creating
On Wed, Oct 13, 2010 at 9:20 PM, James Laska wrote:
> I was attempting just that earlier this week following instructions at
> https://fedoraproject.org/wiki/How_to_build_a_Rawhide_ISO_image_for_testing
>
> I had success creating the ISO files, but they failed to boot due to
> 'unable to find /in
On Wed, 2010-10-13 at 21:14 +0100, mike cloaked wrote:
> On Wed, Oct 13, 2010 at 1:37 PM, James Laska wrote:
> > On Wed, 2010-10-13 at 12:49 +0100, mike cloaked wrote:
> >> On Tue, Oct 12, 2010 at 8:47 PM, Adam Williamson
> >> wrote:
> >>
> >> > I believe we can't really test the ones in anacond
On Wed, Oct 13, 2010 at 9:14 PM, mike cloaked wrote:
>> Still in
>> 'updates-testing'
>> (https://admin.fedoraproject.org/updates/anaconda-14.19-1.fc14) so the
>> install images on mirrors won't yet be using anaconda-14.19. However, the
>> posted TC1 ISO images (CD, DVD or boot.iso) contain t
On Wed, Oct 13, 2010 at 1:37 PM, James Laska wrote:
> On Wed, 2010-10-13 at 12:49 +0100, mike cloaked wrote:
>> On Tue, Oct 12, 2010 at 8:47 PM, Adam Williamson wrote:
>>
>> > I believe we can't really test the ones in anaconda until images with
>> > anaconda 14.19 are available - TC1?
>>
>> I ch
On Wed, 2010-10-13 at 12:49 +0100, mike cloaked wrote:
> On Tue, Oct 12, 2010 at 8:47 PM, Adam Williamson wrote:
>
> > I believe we can't really test the ones in anaconda until images with
> > anaconda 14.19 are available - TC1?
>
> I checked this morning and 14.19 is not yet in the repo for dev
On Tue, Oct 12, 2010 at 8:47 PM, Adam Williamson wrote:
> I believe we can't really test the ones in anaconda until images with
> anaconda 14.19 are available - TC1?
I checked this morning and 14.19 is not yet in the repo for development/14/
Do we know when this will a) hit the mirrors, and b)
On Tue, 2010-10-12 at 12:47 -0700, Adam Williamson wrote:
> On Tue, 2010-10-12 at 12:17 -0400, James Laska wrote:
> > Greetings testers!
> >
> > The bugs listed below are Fedora 14 Blocker bugs that are believed to be
> > fixed. Help is needed to ensure Fedora
On 13/10/10 06:47, Adam Williamson wrote:
> On Tue, 2010-10-12 at 12:17 -0400, James Laska wrote:
>> Greetings testers!
>>
>> The bugs listed below are Fedora 14 Blocker bugs that are believed to be
>> fixed. Help is needed to ensure Fedora 14 ships on time! You can
On Tue, 2010-10-12 at 12:17 -0400, James Laska wrote:
> Greetings testers!
>
> The bugs listed below are Fedora 14 Blocker bugs that are believed to be
> fixed. Help is needed to ensure Fedora 14 ships on time! You can
> follow the list of ON_QA bugs at http://bit.ly/bLdmof
>
Greetings testers!
The bugs listed below are Fedora 14 Blocker bugs that are believed to be
fixed. Help is needed to ensure Fedora 14 ships on time! You can
follow the list of ON_QA bugs at http://bit.ly/bLdmof
To get started, for each bug ...
1. Confirm reported bug is fixed, then change
On 07/10/10 23:08, James Laska wrote:
> On Thu, 2010-10-07 at 11:12 +1100, Steven Haigh wrote:
>> On 10/07/2010 08:53 AM, John Poelstra wrote:
>>> When: Friday, 2010-10-08 @ 16:00 UTC (12 PM EST)
>>> Where: #fedora-bugzappers on irc.freenode.net
>>>
>>> Here are the current bugs listed as blocking
On Thu, 2010-10-07 at 11:12 +1100, Steven Haigh wrote:
> On 10/07/2010 08:53 AM, John Poelstra wrote:
> > When: Friday, 2010-10-08 @ 16:00 UTC (12 PM EST)
> > Where: #fedora-bugzappers on irc.freenode.net
> >
> > Here are the current bugs listed as blocking the final release of Fedora
> > 14. We'll
On 10/07/2010 08:53 AM, John Poelstra wrote:
> When: Friday, 2010-10-08 @ 16:00 UTC (12 PM EST)
> Where: #fedora-bugzappers on irc.freenode.net
>
> Here are the current bugs listed as blocking the final release of Fedora
> 14. We'll be discussing all of these to determine if they meet the
> criteri
When: Friday, 2010-10-08 @ 16:00 UTC (12 PM EST)
Where: #fedora-bugzappers on irc.freenode.net
Here are the current bugs listed as blocking the final release of Fedora
14. We'll be discussing all of these to determine if they meet the
criteria, should stay on the list, and are getting the attent
uot;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
> >&g
).
>>
>> 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.
>
1 - 100 of 103 matches
Mail list logo
