Just tried XFree86, httpd/ssl...

[Rob Myers]

On Thu, 2004-11-18 at 17:05, Gilbert Sebenste wrote:
> On Thu, 18 Nov 2004, Marc Deslauriers wrote:
> 
> > On Thu, 2004-11-18 at 15:34 -0600, Gilbert Sebenste wrote:
> > > Just wanted to throw in my $.02. I have Fedora Core 1, did a yum update 
> > > and got the new XFree86 and httpd/ssl packages. All works fine on a P4 3 
> > > GHZ relatively generic build machine.
> > 
> > Could you please put this in bugzilla so we can count it towards
> > releasing the packages officially.
> > 
> 
> Sure. OK, being a newbie to this kinda thing, how do I do it?

i think bugzilla is currently down.  i think it would be ok to post
clearsigned QAs to the mailing list in the meantime.  (we can put them
in bugzilla whenever it comes back)

from http://www.fedoralegacy.org/wiki/index.php/QaTesting

<snip>

Testing packages for release to updates

     1. Download the binary RPM package from the updates-testing
        channel.
     2. Verify the integrity of the downloaded package (see
        http://www.fedoralegacy.org/about/security.php).
     3. Install the package, and note any installation problems.
     4. Use the package (as appropriate for the package), and note any
        problems found.

After testing a package
Report your test results in the Bugzilla system. QA comments in Bugzilla
should be GnuPG clearsigned. In cases where a QA message would lead to
package approval or publication, the message MUST be GnuPG clearsigned,
and should contain sha1sums of the reviewed source or binary RPM
packages(s). The source RPM sha1sum is mandatory in step 1 of the QA
process in order to be sure that the package to be built is the same as
the reviewed one. GnuPG clearsigned messages that give good advice can
all be traced back to your GnuPG key and accumulate over time. This
process allows new developers to gain trust through technical
correctness and hard work over a period of time, eventually being able
to prove to the community that the developer can be trusted.

If QA comments are submitted listing things within the package that
should be fixed, the original packager should update their SRPM or
respond why they feel suggestions are not valid. Be sure to increment
the release number before building the new SRPMS. Upload the new SRPMS
along with updated clearsigned sha1sums to your web server.

To vote that a package be moved into updates-testing, be sure to use the
tag PUBLISH clearly in the message (e.g. "I vote to PUBLISH"). To vote
that a package be moved from updates-testing to updates, be sure to use
the tag VERIFIED clearly in the message.

<snip>

hope that helps

rob.