My name is Dustin and joining this project is long overdue. Short story is
that I'm a Math/CS college grad that learned on Debian and KDE back in the
early 2ks. Eventually saw the light and gravitated toward the Red Hat
family once I went into the professional world a few years later.
Currently, I serve as the Network Manager for a company based out of the
midwest and manage a coast-to-coast network of ~70 sites and a team of 2
Net Engineers and 2 Net Admins. My skills are heavily based in layers 1-4
but I really love testing different distros as well as writing code.
Python is obviously a big time suck for me (this includes web frameworks
such as django and flask) but I've got a very well-rounded background in
systems-admin as well (MS server flavors specifically). Recently, I've
finally talked the powers-that-be at my job to let my laptop refresh come
bare metal and I've placed Fedora on it. Life is good minus a few caveats
but I'll definitely stick with the shift and hopefully convince a few
others to hop on as well. In the spirit of FOSS I'd like to start giving
back. The easy fit for me is in QA but really that can and probably should
propagate into other areas such as a package maintainer, tech writer, Fed
Magazine or whatever else is needed by the project. Suffice it to say, I'm
really looking forward to this and I'm anxious to help give back to a
community that I've used personally and professionally for so long now. I
look forward to working with you all! Cheers!
Hi Fedora testers,
I am very excited to join you guys on the Fedora Quality Assurance team.
I have been long time user of Fedora Linux for personal use
and redhat linux for server use.
I have worked with many system administration programs and
systems. I use containers on a day-to-day basis at work.
I have been studying C development. I am trying to learn more
about driver and kernel development.
I am Ryan Kosta, I live in San Diego, California and intern at
an education startup. In my freetime I work with linux mostly
in userspace (both administration and light development) but
I plan to do more in kernelspace as I learn more about that
Thankyou to those of you at the Fedora-Project for taking time
to work with me
Ryan P Kosta <ryanpkosta(a)gmail.com>
Since time began (Fedora 7), all fedora bugs in bugzilla have had their
"QA Contact" field set to: extras-qa(a)fedoraproject.org.
Bugzilla describes "QA Contact" as:
"The person responsible for confirming this bug if it is unconfirmed,
and for verifying the fix once the bug has been resolved."
However, also since at least 2007-04-20 emails to that address go to
/dev/null. (Before that they went to a linux.duke.edu address, so I am
not sure where they went).
I'd like to propose dropping this from all Fedora bugs.
It's a useless extra email that bugzilla has to generate, network has to
send and deliver and we have to drop in the bitbucket.
But, perhaps there's some secret clever use for it I am not aware of?
If you can think of some reason to keep it, speak up. ;)
On Tue, Sep 29, 2020 at 07:03:29PM +0200, Pierre-Yves Chibon wrote:
> On Tue, Sep 29, 2020 at 09:30:45AM -0700, Kevin Fenzi wrote:
> > Since time began (Fedora 7), all fedora bugs in bugzilla have had their
> > "QA Contact" field set to: extras-qa(a)fedoraproject.org.
> > Bugzilla describes "QA Contact" as:
> > "The person responsible for confirming this bug if it is unconfirmed,
> > and for verifying the fix once the bug has been resolved."
> > However, also since at least 2007-04-20 emails to that address go to
> > /dev/null. (Before that they went to a linux.duke.edu address, so I am
> > not sure where they went).
> > I'd like to propose dropping this from all Fedora bugs.
> > It's a useless extra email that bugzilla has to generate, network has to
> > send and deliver and we have to drop in the bitbucket.
> > But, perhaps there's some secret clever use for it I am not aware of?
> > If you can think of some reason to keep it, speak up. ;)
> +1 for me. Just to be sure, bugzilla doesn't require such contact to be set?
I tested that on partner-bugzilla and it didn't care if it was unset.
I guess the quiet way to do this is just modify the sync script so it
drops it from all packages for new bugs, then if we want later go back
and remove it from existing bugs if we want to.