Hi there, 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:
Joe Packager 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) Statistics 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 himself: programming skills: the programming languages a packager can fix bugs in the packages. building skills: how familiar is the packager with autotools, cmake, ... to fix build issues packaging skills, 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 dropped. * 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 * packaging * testing * publishing 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. Regards Werner -- Member of the science repo developer in the geda project geda.seul.org --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-project+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-project+help@opensuse.org