Denis Silakov escreveu: > On 05/12/2014 06:51 PM, [email protected] wrote: >> Anyway, from a packager and developer point of view >> I still see significant need to work on our guidance >> for new contributors. So, other than packagers and >> a few extra methods to increase the quality of packages, >> that is, strong rules about checking packages functionality >> as well as having people also actually testing them, we >> also need good writers to document all procedures, suggest >> how to make them easier and/or more standardized, so that >> new people would loose less time searching around on how >> to get things done, or who to ask for help in irc, mailing >> lists, etc. > > Yes, this is one of the things we were discussing at LinuxTag, too. > > Another thing is that it would be nice to have some TODO lists for > people who would like to contribute but don't know what tasks are of > major priority. > > The practice shows that it is not convenient to simply send potential > volunteers to bugzilla or openproject or other complex tools. It would > be nice to have some simple wiki page with TODO items, maybe grouped > according to different criteria (complexity, programming language, > etc.). E.g., even Linux kernel has TODO files in its sources with clear > and explicit tasks.
A brief description of how it works for Fedora is, following https://fedoraproject.org/wiki/Join_the_package_collection_maintainers but slightly simplified would be: 1. Create bugzilla account 2. Create a fedora account 3. Create a rpm package 4. Upload package somewhere 5. Create bug about the package Must use the FE-NEEDSPONSOR tag 6. Announce yourself in fedora-devel mailing list and ask for a sponsor Now it would be our part :-) A packager with sponsor status would choose to help the new packager. The sponsor will talk by whatever means with the person. Review the package in bugzilla. It would be very good to have an automated tool for it, most likely importing fedora-review would be almost all we need, example: ---%<--- $ fedora-review --help usage: fedora-review (-b <bug> | -n <name> | -u <url> | -d | -f | -g | -V | -h) [-B] [-c] [-D <flag>] [-L <rpm directory>] [-m <config>] [--no-report] [--no-build] [-o <mock options>] [--other-bz <bugzilla url>] [-P <plugin>] [-p] [-s <test>] [-r] [-v] [-x "test,..."] [-k {md5,sha1,sha224,sha256,sha384,sha512}] Review a package using Fedora Guidelines Operation mode - one is required: -b <bug>, --bug <bug> Operate on fedora bugzilla using its bug number. -n <name>, --name <name> Use local files <name>.spec and <name>*.src.rpm in current dir or, when using --rpm-spec, use <name> as path to srpm. -u <url>, --url <url> Use another bugzilla, using complete url to bug page. -d, --display-checks List all available checks. -f, --display-flags List all available flags. -g, --display-plugins List all available plugins. -V, --version Display version information and exit. -h, --help Display this help message General options: -B, --no-colors No colors in output -c, --cache Do not redownload files from bugzilla, use the ones in the cache. -D <flag>, --define <flag> Define a flag like --define EPEL5 or -D EPEL5=1 -L <rpm directory>, --local-repo <rpm directory> directory with rpms to install together with reviewed package during build and install phases. -m <config>, --mock-config <config> Configuration to use for the mock build, defaults to 'default' i. e., /etc/mock/default.cfg --no-report Do not print review report. --no-build Do not rebuild or install the srpm, use last built one in mock. Implies --cache -o <mock options>, --mock-options <mock options> Options to specify to mock for the build, defaults to --no-cleanup-after --no-clean --other-bz <bugzilla url> Alternative bugzilla URL -P <plugin>, --plugins <plugin> List of plugins to enable or disable hard e. g., "Java:off,C/C++" -p, --prebuilt When using -n <name>, use prebuilt rpms in current directory. -s <test>, --single <test> Single test to run, as named by --display-checks. -r, --rpm-spec Take spec file from srpm instead of separateurl. -v, --verbose Show more output. -x "test,...", --exclude "test,..." Comma-separated list of tests to exclude. -k {md5,sha1,sha224,sha256,sha384,sha512}, --checksum {md5,sha1,sha224,sha256,sha384,sha512} Algorithm used for checksum ---%<--- After the package is considered good and follow all guidelines it would be approved. Sometimes it can take a lot of time, example of one mine (but a big one..., I only actually made a review request past over 6 months after starting working on it) https://bugzilla.redhat.com/show_bug.cgi?id=877651 New packagers only touch their packages. But on abf we have personal repositories, so, it is quite easy to create private repositories. If a packager thinks he is good enough, the packager can ask for "ProvenPackager" status, and in that case, is allowed to modify almost every package in the distribution. Usually done opening a ticket, that would be discussed by the "technical committee" and then other proven packagers can give feedback and/or + (or -) karma, https://fedoraproject.org/wiki/Fedora_Engineering_Steering_Committee Another special status is "Sponsor", that is a packager that can approve new packagers (anybody is free to review packages from someone else, e.g. to show skills if not yet a proven or sponsor packager, but better not to assign to him/her self in bugzilla if not yet a sponsor :-). > -- > Denis Silakov, ROSA Laboratory. > www.rosalab.ru Thanks, Paulo
