2:15 p.m.
At the Fedora 16 Final Go/No-Go meeting today, the Fedora 16 Final
Release was declared GOLD and ready for release on November 8, 2011.
And to clarify: It is a nice, golden, almost... mustard-like color. :)
Thank you to EVERYONE for your sleepless nights, endless testing, prompt
bug-fixing, and endless patience through 5 release candidates.
A reminder that the Fedora 16 Release Wide Readiness Meeting will take
place Today, pretty much now, at 19:00 UTC (3 PM Eastern/ 12 PM Pacific) at
irc.freenode.net #fedora-meeting-1
https://fedoraproject.org/wiki/Release_Readiness_Meetings
========================================================
#fedora-meeting: F16 Final Go or No Go Meeting Round Two
http://fedoraproject.org/wiki/Go_No_Go_Meeting
========================================================
Meeting started by rbergeron at 18:00:29 UTC. The full logs are
available at
http://meetbot.fedoraproject.org/fedora-meeting/2011-11-03/f16_final_go_o...
Meeting summary
---------------
* Gathering Friends (rbergeron, 18:00:47)
* Why are we here (rbergeron, 18:01:27)
* Purpose of this meeting is to determine if all the Release Criteria
have been met, so we can ship this puppy out the door. (rbergeron,
18:02:17)
* LINK:
https://fedoraproject.org/wiki/Fedora_16_Final_Release_Criteria
(rbergeron, 18:02:36)
* Blocker Bugs (rbergeron, 18:02:53)
* LINK: https://fedoraproject.org/wiki/Current_Release_Blockers
(rbergeron, 18:03:03)
* Look at his beady, majestic eyes. (rbergeron, 18:03:35)
* LINK: https://bugzilla.redhat.com/show_bug.cgi?id=750469 was just
reopened (robatino, 18:03:56)
* LINK:
https://docs.fedoraproject.org/en-US/Fedora/15/html/Installation_Guide/Ma...
(tflink, 18:17:42)
* Test Matrices and etc. (rbergeron, 18:25:30)
* AGREED: 750469 needs to be fixed but does not need to delay f16
release; we can fix by updating l-i-t-d in all extant releases (14,
15) (adamw, 18:25:43)
* absolutely all tests are covered and pass or warn (rbergeron,
18:26:13)
* Release Engineering (rbergeron, 18:29:03)
* LINK: https://fedorahosted.org/rel-eng/ticket/4967#comment:17
(tflink, 18:31:09)
* Anything else before we Set Sail? (rbergeron, 18:35:01)
* To Go, or Not To Go? (rbergeron, 18:36:49)
* F16 is declared GOLD! Ship it. (rbergeron, 18:38:51)
* AGREED: F16 is declared GOLD! Ship it. (rbergeron, 18:39:04)
* Thanks to EVERYONE for your sleepless nights, your hard work, your
bug fixing. (rbergeron, 18:39:34)
* And endless testing, and endless building. (rbergeron, 18:39:45)
* There is a readiness meeting in ~20 minutes here in #fedora-meeting.
(rbergeron, 18:40:04)
* rbergeron will send out a GOLDEN GOLD MAIL to mailing lists.
(rbergeron, 18:40:22)
* in #fedora-meeting-1. (rbergeron, 18:40:39)
* Grats to everyone on shipping yet another INCREDIBLY feature-filled
release. (rbergeron, 18:41:27)
Meeting ended at 18:42:18 UTC.
Action Items
------------
Action Items, by person
-----------------------
* **UNASSIGNED**
* (none)
People Present (lines said)
---------------------------
* rbergeron (88)
* adamw (54)
* thedonvaughn (25)
* nirik (20)
* jsmith (10)
* tflink (9)
* N1tr0g3n (9)
* bcl (8)
* zodbot (5)
* dlehman (5)
* kparal1 (2)
* red_alert (2)
* robatino (1)
* hno_ (1)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
_______________________________________________
test-announce mailing list
test-announce(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/test-announce
2:36 p.m.
On Thu, Nov 3, 2011 at 8:24 PM, Michael Cronenworth <mike(a)cchtml.com> wrote:
On 11/03/2011 02:15 PM, Robyn Bergeron wrote:
> At the Fedora 16 Final Go/No-Go meeting today, the Fedora 16 Final
> Release was declared GOLD and ready for release on November 8, 2011.
Congrats. This is the first release without a slip in a while isn't it?
So 2 slips equal means "without a slip" for you? ;)
2:38 p.m.
On Thu, Nov 3, 2011 at 2:24 PM, Michael Cronenworth <mike(a)cchtml.com> wrote:
On 11/03/2011 02:15 PM, Robyn Bergeron wrote:
> At the Fedora 16 Final Go/No-Go meeting today, the Fedora 16 Final
> Release was declared GOLD and ready for release on November 8, 2011.
Congrats. This is the first release without a slip in a while isn't it?
The alpha release slipped by a week:
https://lists.fedoraproject.org/pipermail/test-announce/2011-August/00026...
--
Jeff Ollie
2:39 p.m.
On Thu, Nov 3, 2011 at 2:38 PM, Jeffrey Ollie <jeff(a)ocjtech.us> wrote:
On Thu, Nov 3, 2011 at 2:24 PM, Michael Cronenworth
<mike(a)cchtml.com> wrote:
> On 11/03/2011 02:15 PM, Robyn Bergeron wrote:
>> At the Fedora 16 Final Go/No-Go meeting today, the Fedora 16 Final
>> Release was declared GOLD and ready for release on November 8, 2011.
>
> Congrats. This is the first release without a slip in a while isn't it?
The alpha release slipped by a week:
https://lists.fedoraproject.org/pipermail/test-announce/2011-August/00026...
The beta release slipped by a week as well:
https://lists.fedoraproject.org/pipermail/test-announce/2011-September/00...
--
Jeff Ollie
5:56 p.m.
On Thu, 2011-11-03 at 12:15 -0700, Robyn Bergeron wrote:
Thank you to EVERYONE for your sleepless nights, endless testing,
prompt
bug-fixing, and endless patience through 5 release candidates.
For the record, Fedora 16 required a total of 20 TC / RC composes.
That's a new record, at least since Fedora 12, which is as far back as
we have a handy record:
Fedora 12: 11 composes
Fedora 13: 17 composes
Fedora 14: 12 composes (F14 final was F14 RC1!)
Fedora 15: 11 composes
Fedora 16: 20 composes
This mostly reflects the fact that F16 makes major changes in very
release sensitive areas, but also I think that we're getting better at
detecting problems and resolving them as blockers and hence driving up
the quality of Fedora releases. (We also effectively 'added' two TCs to
the schedule by moving up the TC date for Beta and Final). Just to
tootle our own horn a little!
I'd certainly second Robyn's thanks to all the awesome folks on the
devel, releng and QA teams who worked so hard to get this thing done and
shiny without slipping any further. We bent process a little to make the
release date but we didn't compromise on quality at all, which is great.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
11:23 p.m.
On Thu, Nov 03, 2011 at 15:56:49 -0700,
Adam Williamson <awilliam(a)redhat.com> wrote:
I'd certainly second Robyn's thanks to all the awesome folks on the
devel, releng and QA teams who worked so hard to get this thing done and
shiny without slipping any further. We bent process a little to make the
release date but we didn't compromise on quality at all, which is great.
Hopefully we'll try to figure out why so much heroic effort was needed
to keep from slipping any further than we did. That kind of thing tends
to burn people out and we don't want it happen regularly.
We also fudged the Go / No-Go meeting twice. We should either accomadate
this in thge process documentation or stop doing it.
1:17 a.m.
On Thu, 2011-11-03 at 23:23 -0500, Bruno Wolff III wrote:
On Thu, Nov 03, 2011 at 15:56:49 -0700,
Adam Williamson <awilliam(a)redhat.com> wrote:
>
> I'd certainly second Robyn's thanks to all the awesome folks on the
> devel, releng and QA teams who worked so hard to get this thing done and
> shiny without slipping any further. We bent process a little to make the
> release date but we didn't compromise on quality at all, which is great.
Hopefully we'll try to figure out why so much heroic effort was needed
to keep from slipping any further than we did. That kind of thing tends
to burn people out and we don't want it happen regularly.
I think it boils down almost entirely to the big behaviour changes in
anaconda in F16, which unfortunately suggests F17 may also be a tricky
cycle, with the UI rewrite (and possible btrfs adoption). anaconda
provides a disproportionately high number of blockers, and the
bootloader and disk label changes in F16 caused change (and hence bugs,
change _always_ means bugs) in lots of paths we've simply not had to
worry about for a long time. All the issues with bootloader installation
on upgrade, BIOS boot partitions and so on are quite simply things we've
never previously had to deal with at all.
This didn't just cause _more_ bugs it caused bugs which were more
difficult to handle and test, because they weren't just 'hey, function X
doesn't work any more' but 'uh, now we're doing A, B and C differently,
our assumptions about D, E and F turn out to be wrong - what the heck do
we do about that?', which is a much more complex issue.
I hope this doesn't offend anyone from the anaconda team, but I do kind
of get the sense that perhaps all the implications of the changes
weren't planned out ahead of time; there seemed to be a lot of making it
up as we went along. The UI rewrite seems to be getting a lot of
pre-planning and whiteboarding and so on, so I'm vaguely hopeful that
they'll catch more of the pitfalls in advance, with that.
It'd be great if we can work with the anaconda team closely to try and
get involved all along the line in the UI rewrite stuff, and see if that
can reduce the pressure around release times - let's put that on the
table for the next meeting. But it might still turn out to be a tough
one. If anyone has any suggestions or ideas at all, please do contribute
them! The more thinking the better.
We also fudged the Go / No-Go meeting twice. We should either
accomadate
this in thge process documentation or stop doing it.
Yeah, agreed. I don't think there's any especial need for the go/no-go
to be an entire day ahead of the release readiness meeting, in all
honesty - it seems to work fine simply to do it earlier the same day. So
do you think it'd be alright to suggest that as a change for the F17 and
beyond scheduling? Every time we've decided the delay the go/no-go
decision, that choice in itself hasn't caused any problems, as far as
I'm aware. It simply gives us more time for validation, which is never a
bad thing...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
1:32 a.m.
On Thu, 2011-11-03 at 23:17 -0700, Adam Williamson wrote:
> Hopefully we'll try to figure out why so much heroic effort
was needed
> to keep from slipping any further than we did. That kind of thing tends
> to burn people out and we don't want it happen regularly.
I think it boils down almost entirely to the big behaviour changes in
anaconda in F16, which unfortunately suggests F17 may also be a tricky
cycle, with the UI rewrite (and possible btrfs adoption). anaconda
provides a disproportionately high number of blockers, and the
bootloader and disk label changes in F16 caused change (and hence bugs,
change _always_ means bugs) in lots of paths we've simply not had to
worry about for a long time. All the issues with bootloader installation
on upgrade, BIOS boot partitions and so on are quite simply things we've
never previously had to deal with at all.
Forgot a couple more factors: I think we're doing more testing and with
higher standards than we have before. The matrices have grown - not
useless growth but we're just covering more things that really ought to
be covered - and use scenarios have gotten more complex over time: quite
a few bugs this time related to the use of DVD / netinst images written
to USB, which we used to consider a pretty minority pursuit but is now
pretty mainstream, for example.
And Red Hat's paid Fedora QA team is two people short of where we ought
to be: jlaska and rhe both moved on, and we didn't hire direct
replacements yet. Both of them certainly contributed a lot to release
testing in the past, obviously, so all that load has had to be spread
out.
So to summarize: we're testing more, to higher standards, on a release
that had extremely disruptive changes, with fewer paid RH staff involved
than before. It was a bit of a perfect storm!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
6:50 a.m.
On 11/04/2011 07:32 AM, Adam Williamson wrote:
So to summarize: we're testing more, to higher standards, on a
release
that had extremely disruptive changes, with fewer paid RH staff involved
than before. It was a bit of a perfect storm!
And the result is something you can all be proud of! Thank you and
everybody involved for your hard work to get F16 done - on time - in
spite of all the big changes and challenges you faced. Truly remarkable.
Regards,
Patrick
9:18 a.m.
On Fri, Nov 04, 2011 at 12:50:43 +0100,
Patrick Lists <fedora-list(a)puzzled.xs4all.nl> wrote:
On 11/04/2011 07:32 AM, Adam Williamson wrote:
> So to summarize: we're testing more, to higher standards, on a release
> that had extremely disruptive changes, with fewer paid RH staff involved
> than before. It was a bit of a perfect storm!
And the result is something you can all be proud of! Thank you and
everybody involved for your hard work to get F16 done - on time - in
spite of all the big changes and challenges you faced. Truly remarkable.
As noted in other threads, the release was really two weeks late. There were
one week slips added at alpha and beta.
I think F16 is clearly better than F15. (Refuseniks might still prefer
F14 for Gnome 2 and/or avoiding systemd.)
F17 is looking to be better still. If I am understanding a message on the
Anaconda list we will probably be able to installs on systems with 256 MB
of ram again. Anaconda is supposed to get a UI improvement. Open source
graphics will support all of OpenGL 3.0. More services will be natively
using systemd. Gnome should be getting another iterative improvement.
1:51 p.m.
On Fri, 2011-11-04 at 09:18 -0500, Bruno Wolff III wrote:
On Fri, Nov 04, 2011 at 12:50:43 +0100,
Patrick Lists <fedora-list(a)puzzled.xs4all.nl> wrote:
> On 11/04/2011 07:32 AM, Adam Williamson wrote:
> > So to summarize: we're testing more, to higher standards, on a release
> > that had extremely disruptive changes, with fewer paid RH staff involved
> > than before. It was a bit of a perfect storm!
>
> And the result is something you can all be proud of! Thank you and
> everybody involved for your hard work to get F16 done - on time - in
> spite of all the big changes and challenges you faced. Truly remarkable.
As noted in other threads, the release was really two weeks late. There were
one week slips added at alpha and beta.
Yep, indeed: we still haven't shipped a release entirely on schedule
yet. Let's do it one day! :) I think two weeks of slip on a release as
complex as F16 isn't bad, though.
I think F16 is clearly better than F15. (Refuseniks might still
prefer
F14 for Gnome 2 and/or avoiding systemd.)
I honestly suspect we're still going to hit some corner cases with the
gpt and grub2 stuff that we've either not found yet or found but not
considered blockers. There's just too much damn hardware out there. We
actually already know about a few boards which will need people to use
the 'nogpt' parameter to get a successful install, for e.g. But I think
the _stuff_ in 16 is great.
F17 is looking to be better still. If I am understanding a message on
the
Anaconda list we will probably be able to installs on systems with 256 MB
of ram again.
Definitely we'll be able to get the RAM requirements back down, which is
awesome. I think for F16 we could really have cut the anaconda hard
limit down to 640MB at least, but things were so busy we never got the
time to just run a few installs and establish a safe floor.
Anaconda is supposed to get a UI improvement. Open source
graphics will support all of OpenGL 3.0. More services will be natively
using systemd. Gnome should be getting another iterative improvement.
And we'll have software 3D Shell, which is awesome. (And makes testing
easier too! :>)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
9:37 a.m.
On Thu, Nov 03, 2011 at 23:17:21 -0700,
Adam Williamson <awilliam(a)redhat.com> wrote:
It'd be great if we can work with the anaconda team closely to try and
get involved all along the line in the UI rewrite stuff, and see if that
can reduce the pressure around release times - let's put that on the
table for the next meeting. But it might still turn out to be a tough
one. If anyone has any suggestions or ideas at all, please do contribute
them! The more thinking the better.
Yeah, I think early testing will be good there. (Unfortunately, that's
not an area I am good at helping with as I mostly do yum upgrades and
run rawhide/branched continuously rather than do lots of test installs.)
It might be useful to run through the test matrices at some other points in
the release cycle to get a heads up on potential blockers with more time
on them. It seemed this release we were in crisis mode for a lot of the
blockers.
Yeah, agreed. I don't think there's any especial need for the
go/no-go
to be an entire day ahead of the release readiness meeting, in all
honesty - it seems to work fine simply to do it earlier the same day. So
do you think it'd be alright to suggest that as a change for the F17 and
beyond scheduling? Every time we've decided the delay the go/no-go
decision, that choice in itself hasn't caused any problems, as far as
I'm aware. It simply gives us more time for validation, which is never a
bad thing...
I am concerned with the process as executed not matching the documentation.
I'd just like to see a change codified that either allows moving the Go /
No-Go meeting when appropriate or just schedule it closer to the
readiness meeting.
12:53 p.m.
On Fri, 4 Nov 2011 09:37:33 -0500
Bruno Wolff III <bruno(a)wolff.to> wrote:
On Thu, Nov 03, 2011 at 23:17:21 -0700,
Adam Williamson <awilliam(a)redhat.com> wrote:
...snip...
> Yeah, agreed. I don't think there's any especial need for the
> go/no-go to be an entire day ahead of the release readiness
> meeting, in all honesty - it seems to work fine simply to do it
> earlier the same day. So do you think it'd be alright to suggest
> that as a change for the F17 and beyond scheduling? Every time
> we've decided the delay the go/no-go decision, that choice in
> itself hasn't caused any problems, as far as I'm aware. It simply
> gives us more time for validation, which is never a bad thing...
I am concerned with the process as executed not matching the
documentation. I'd just like to see a change codified that either
allows moving the Go / No-Go meeting when appropriate or just
schedule it closer to the readiness meeting.
I think moving the go/no-go meetings to thursdays and moving the
readyness meeting to friday is a fine plan. I think our mirroring is in
shape enough to where if we stage things late thursday or friday
morning we should be ok.
If we do this, next cycle we should NOT do any 'two part' go/no-go
meetings.
kevin
1:55 p.m.
On Fri, 2011-11-04 at 11:53 -0600, Kevin Fenzi wrote:
> I am concerned with the process as executed not matching the
> documentation. I'd just like to see a change codified that either
> allows moving the Go / No-Go meeting when appropriate or just
> schedule it closer to the readiness meeting.
I think moving the go/no-go meetings to thursdays and moving the
readyness meeting to friday is a fine plan. I think our mirroring is in
shape enough to where if we stage things late thursday or friday
morning we should be ok.
If we do this, next cycle we should NOT do any 'two part' go/no-go
meetings.
Well, what we were thinking of was moving go/no-go without moving
release readiness: there's no real reason there needs to be a whole day
between them, there's no tasks that must happen *after* go/no-go but
*before* release readiness AFAIK, so that whole day just winds up being
dead time. There's no intrinsic reason they can't simply be 1hr apart,
as we did for 16 Final.
So hey, if Friday's okay, we could do 'em both on Friday...
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
2:06 p.m.
On Fri, 04 Nov 2011 11:55:00 -0700
Adam Williamson <awilliam(a)redhat.com> wrote:
On Fri, 2011-11-04 at 11:53 -0600, Kevin Fenzi wrote:
> > I am concerned with the process as executed not matching the
> > documentation. I'd just like to see a change codified that either
> > allows moving the Go / No-Go meeting when appropriate or just
> > schedule it closer to the readiness meeting.
>
> I think moving the go/no-go meetings to thursdays and moving the
> readyness meeting to friday is a fine plan. I think our mirroring
> is in shape enough to where if we stage things late thursday or
> friday morning we should be ok.
>
> If we do this, next cycle we should NOT do any 'two part' go/no-go
> meetings.
Well, what we were thinking of was moving go/no-go without moving
release readiness: there's no real reason there needs to be a whole
day between them, there's no tasks that must happen *after* go/no-go
but *before* release readiness AFAIK, so that whole day just winds up
being dead time. There's no intrinsic reason they can't simply be 1hr
apart, as we did for 16 Final.
So hey, if Friday's okay, we could do 'em both on Friday...
Well, friday might be cutting it a bit close. I guess we can see how
rapidly mirrors sync up for 16 and use that data to decide.
I think we have a more robust mirror tiering setup now than we had in
the past, so it may not take as long for tier0/1 mirrors to get content
and filter it out to others.
kevin
2:24 p.m.
On 4 November 2011 13:06, Kevin Fenzi <kevin(a)scrye.com> wrote:
On Fri, 04 Nov 2011 11:55:00 -0700
Adam Williamson <awilliam(a)redhat.com> wrote:
> On Fri, 2011-11-04 at 11:53 -0600, Kevin Fenzi wrote:
>
> > > I am concerned with the process as executed not matching the
> > > documentation. I'd just like to see a change codified that either
> > > allows moving the Go / No-Go meeting when appropriate or just
> > > schedule it closer to the readiness meeting.
> >
> > I think moving the go/no-go meetings to thursdays and moving the
> > readyness meeting to friday is a fine plan. I think our mirroring
> > is in shape enough to where if we stage things late thursday or
> > friday morning we should be ok.
> >
> > If we do this, next cycle we should NOT do any 'two part' go/no-go
> > meetings.
>
> Well, what we were thinking of was moving go/no-go without moving
> release readiness: there's no real reason there needs to be a whole
> day between them, there's no tasks that must happen *after* go/no-go
> but *before* release readiness AFAIK, so that whole day just winds up
> being dead time. There's no intrinsic reason they can't simply be 1hr
> apart, as we did for 16 Final.
>
> So hey, if Friday's okay, we could do 'em both on Friday...
Well, friday might be cutting it a bit close. I guess we can see how
rapidly mirrors sync up for 16 and use that data to decide.
I think we have a more robust mirror tiering setup now than we had in
the past, so it may not take as long for tier0/1 mirrors to get content
and filter it out to others.
I believe I have uttered those words before.. they are like saying "I
only have 2 days before retirement" in a movie :). In the past when we
have moved the release time closer we seem to end up with a series of
Tier-1 outages or some other issue where it takes a while to get bits
out. I would like to make sure that there are 100 hours before release
to make sure we have reasonable coverage.
--
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Let us be kind, one to another, for most of us are fighting a hard
battle." -- Ian MacLaren
1:53 p.m.
On Fri, 2011-11-04 at 09:37 -0500, Bruno Wolff III wrote:
On Thu, Nov 03, 2011 at 23:17:21 -0700,
Adam Williamson <awilliam(a)redhat.com> wrote:
>
> It'd be great if we can work with the anaconda team closely to try and
> get involved all along the line in the UI rewrite stuff, and see if that
> can reduce the pressure around release times - let's put that on the
> table for the next meeting. But it might still turn out to be a tough
> one. If anyone has any suggestions or ideas at all, please do contribute
> them! The more thinking the better.
Yeah, I think early testing will be good there. (Unfortunately, that's
not an area I am good at helping with as I mostly do yum upgrades and
run rawhide/branched continuously rather than do lots of test installs.)
It might be useful to run through the test matrices at some other points in
the release cycle to get a heads up on potential blockers with more time
on them. It seemed this release we were in crisis mode for a lot of the
blockers.
We tried to do that to some extent in 16 cycle by moving the TC date one
week up for both Beta and Final, and I think that worked pretty well. I
also noted on the retrospective that we should avoid the trap of
focusing too strongly on the blocker bugs we find _first_, and keep
testing while those are getting fixed to find any others that are
lurking.
> Yeah, agreed. I don't think there's any especial need
for the go/no-go
> to be an entire day ahead of the release readiness meeting, in all
> honesty - it seems to work fine simply to do it earlier the same day. So
> do you think it'd be alright to suggest that as a change for the F17 and
> beyond scheduling? Every time we've decided the delay the go/no-go
> decision, that choice in itself hasn't caused any problems, as far as
> I'm aware. It simply gives us more time for validation, which is never a
> bad thing...
I am concerned with the process as executed not matching the documentation.
I'd just like to see a change codified that either allows moving the Go /
No-Go meeting when appropriate or just schedule it closer to the
readiness meeting.
Yup, indeed, bending process is a bad habit to get into. We can bring it
up at the meeting and if everyone's happy with moving go/no-go back I
can talk to Robyn and have the 17 schedule changed.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
4582
days inactive
4583
days old
18 comments
9 participants
participants (9)
-
Adam Williamson -
Bruno Wolff III -
drago01 -
Jeffrey Ollie -
Kevin Fenzi -
Michael Cronenworth -
Patrick Lists -
Robyn Bergeron -
Stephen John Smoogen