how to improve the efficiency [Re: Round-up, 2004-11-28]

[Pekka Savola]

On Mon, 29 Nov 2004, Marc Deslauriers wrote:
> On Mon, 2004-11-29 at 09:02 +0200, Pekka Savola wrote:
>> accounts).  Is there any chance of making the update creation and
>> verification a bit simpler, so that it wouldn't take so damned huge
>> amount of work to get an update out..?
>
> It would be nice to simplify the process so more users can contribute.
> Do you have any suggestions?

OK, let me try to see if I could improve this a bit.

Use of Bugzilla:
  - having to register a fedora.us bugzilla account, it would be better 
to use RH's bugzilla if possible/reasonable.
  - bugzilla being too user-unfriedly; for example, the GUI at
http://bugzilla.fedora.us/query.cgi has _way_ too many options and 
scares people away.  You'll definitely want something simpler, like 
the interface Red Hat is using.

Use of PGP signatures:
  - Is it necessary to use PGP signatures when reporting at bugzilla? 
Bugzilla already provides user authentication, so this only gives 
relatively little additional protection.  It's much simpler if you 
would not need to hassle with PGP at all if you just want to report 
whether a package works or not.  It's (more) OK to require the use of 
PGP for those who submit the actual packages, etc., though.

Documenting the process very clearly and providing tools to help in 
the process:

  - the QA Testing process needs to be much more explicit on what 
_exactly_ should be done at each step of the process:
  1) REQUIRED to do
  2) RECOMMENDED to do

  - For example: updates-testing says:

    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.

These must be more explicit.  What exactly must be verified at "2"? 
How do you report being successful after "4"?

The same applies to the rest.  We'll need a (hopefully short and 
concise) list which we can point people to, and say "follow these 3 
steps and you're done."  If it's a lot of steps (more than, say, 5), 
we'll want to create scripts to help in the process -- e.g., one which 
compares the original SRPM and the updated SRPM and shows the results 
(recursing through tarballs etc.); one that does the same for 
binaries; etc. -- I think these have already circulated on a list half 
a year ago or so.

There should also be more documentation at least on following:
  1) documenting new vulnerabilities (I think Jesse has mostly been 
doing this) -- in bugzilla?

  2) how you proceed if there is new vulnerability in the same package 
which is already in the process but not released to updates yet.

  3) how do you go about from proposing an updated package (in response 
to 1), and how that gets into the build system.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings