I've appended some random notes, ...
On Montag, 4. Februar 2008, Will Stephenson wrote:
Agreed, since trust is advisory, one's assessment
of trust would be
helped by having some discrete information on a packager eg:
Individual assertions of trustworthiness
[x] signed guiding principles
[x] signed maintenance agreement
[x] assured identity
Trust Testimonials from others
[x] Novell employee
trusted by Jane Packager (trust: 40)
trusted by Jim Packager (trust: 10)
trusted by Johnny Packager (trust: 1)
Time in project: 3 years 1 month
Packages maintained: 12
Mean package update latency: 10.3 days [*]
Bugs/package: 1.7 [**]
Mean Rpmlint warning score: 20
1. I'd like to see some more things that the packager tells about
the programming languages a packager can fix bugs in the packages.
how familiar is the packager with autotools, cmake, ... to fix build
simple builds, library builds, special things like python packages
desktop integration, ...
oss projects the packager is member in.
2. I'd like to see a place where a packager can write some comments
about each package and why it was build this way.
* Why was it build?
* personal interest
* for the university/company
* because the packager is one of the developers
* because the package is required by another one
* just for fun
* Packaging decisions?
* why was the package not build for new/old distributions
* why was it build this way
* Support for the package?
* will the packager support the package (bug fixing)
* will the package be fixed if it's hard to build or will it be
* How to test the package?
* run make check
* run the application with some example files
3. Splitting the build process into 3 steps could increase the quality
Currently it's hard to test a package in the build service as the build
rpms are published immediatly. I think it would be an improvement to
have an explicit test stage. Then we could create a chain of packaging,
testing and publishing. The tester could be the packager, or another
member of a specific project, or even a user without packaging skills.
* the packager could create the package notify it to the tester
* the tester tests the package and publishes it.
The tester also could take care of publishing a bunch of related
packages in one step.
This could also increase the trust into a package. A tester with a high
trust rate could increase the trust of the packager and vice versa.
BTW: It would be nice to read some stories about how the core
distribution is build and tested.
Member of the science repo
developer in the geda project geda.seul.org
To unsubscribe, e-mail: opensuse-project+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-project+help(a)opensuse.org