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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Quoting Pekka Savola <pekkas@xxxxxxxxxx>:

> OK, let me try to see if I could improve this a bit.
> Use of Bugzilla:
>   - having to register a bugzilla account, it would be better
> to use RH's bugzilla if possible/reasonable.
>   - bugzilla being too user-unfriedly; for example, the GUI at
> has _way_ too many options and
> scares people away.  You'll definitely want something simpler, like
> the interface Red Hat is using.

This has been brought up many times, and most users tend to agree, but
the powers that be in FL seem to be resistent to change to the bugzilla

Due to the overwhelming support for changes to Bugzilla, I really think
this needs to be looked into.  Maybe an ad-hoc committee to look into it?
> 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.

See the security page.  Digital signatures are critical to the project.
No other way can one establish trust, and the project depends on a trust
model to succeed.
> Documenting the process very clearly and providing tools to help in
> the process:

It's a wiki.  If you don't like it, change it.  If you don't know how
to wiki, but want to change it, ask.  If you don't know how to wiki,
don't want to learn how to, then simply post a patch or update to the
mailing list.  It is a community project; be part of the community!

>   - 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
>     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"?

Well, you refer to the link given, which tells you how and what to verify.

> How do you report being successful after "4"?

You see the next section of the page, IIRC.

> The same applies to the rest. 

I don't see your point.  I think you simply failed to follow the links,
or read the rest of the page.  But that doesn't matter.  It is a wiki
page.  You are free to modify it to make it better.  You are free
to suggest additions and changes to it.  Please participate!

> 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."

There is no such thing.  First, above is a 4 step list.  You don't like
it.  So it won't work.  Second, each package is different.  How you verify
a package depends on the package.  Different packages need different 
verification processes.  Third, each tester's machine is different.  One
may install with YUM, one with APT, one with RPM of the binary RPM, one
by rebuilding the source SRPM, etc.  Some will be missing dependencies.
Others will have conflicting packages, or newer versions installed, etc.
Some will use lilo, others grub, etc.  We can't provide a simple three
step process that addresses all the possible situations and variations.

> 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.

Yes.  I wish the people with these scripts would put them up in the wiki
with instructions on how to use them, etc.  So far, no one has taken up
my challange to do that, AFAIK.
> There should also be more documentation at least on following:
>   1) documenting new vulnerabilities (I think Jesse has mostly been
> doing this) -- in bugzilla?

What isn't covered about this?  If you tell me what is missing, I'll
add it.  If the problem is you don't know where to look, let me know
and we'll try to make some cross-links to make things easier to find,
or menu changes to make it easier.  But you need to tell us what the
problem is.

>   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.

This is a policy decision we're struggling with, and hence a policy needs
to be established.  This isn't a documentation issue at this time, as
there is no set policy yet.

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

This is addressed, as far as I'm concerned, in the docs.  If you disagree,
we need to talk out why.

I think the biggest things right now are bugzilla complaints/changes, and
the policy on what to do with updates that have additional changes before
they are released.  These are real problems, and policy problems.

As for docs, I've asked many, many times for people to participate.  Only
about 3 people have ever taken up the call.   We need more paritipation.
We need more discussion, more ideas.  Please help!

Yes, I'm being rather obtuse about the documentation changes recommended
above, but it is mostly due to the lack of content in the suggestions.
Please address each point separately, and we'll hash them out and get
them resolved as best as possible.  I'm not against changes or better
docs.  I just have only so much time to devote to it, and so much talent
to go into it, and only one perspective when looking at the docs.  I need
help to improve them, and the only way, and best way, to get that help
is via the participation of as many people as possible in discussion about
the current docs or lack thereof.

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

Eric Rostetter



[Fedora Development]     [Fedora Announce]     [Fedora Legacy Announce]     [Fedora Config]     [PAM]     [Fedora General Discussion]     [Big List of Linux Books]     [Gimp]     [Free Internet Dating]     [Yosemite Questions]

Powered by Linux