>> 2. Call for volunteers > I volunteer to help the processing the NEW queue. I have a some experience in > inspecting packages, through working on a team that maintains more than a > hundred of them, and through my proposal for a chain reaction of copyright file > peer reviews (http://wiki.debian.org/CopyrightReview), that unfortunately did > not attract followers. You can check at the following page for my accuracy. > http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=one-copyright-review;users=debian-legal@lists.debian.org Thank you for volunteering. We have just discussed it within the team and I have the unfortunate job to tell you that existing members raised the "won't fit" card, ie. while I am sure you could work with the existing members, not all of them could or want with you. As such I currently do not see you joining the team directly, but ... > I also have a strong interest in data.debian.org, but probably more as a user > than a team member. This said, if you need real-life cases for biology, do not > hesitate to contact the Debian Med team. ... data.debian.org sounds good. What about helping out programming, changing our code, to get earlier to it? That way I stand between you and the team and you are helping out with a very valued contribution that leads us to have data.debian.org earlier. :) If so, to get you a basic understanding of the code so we have a base to put our discussions on, could you please git clone https://ftp-master.debian.org/git/dak.git and try getting familiar with it, at least the basic structure and ways we do things? A good learning example to find the way around would be to trace the code path a package of a NEW upload is following in all the various times we run a dak command on it, until the time it is finally removed From the archive. That is, initial processing in the unchecked queue (start with cron.unchecked from config/debian/), placing into NEW, acceptance from there, installation into the archive, possibly moving to a different suite, getting removed from the archive...) -- bye, Joerg <buxy> I wish mrvn stopped supporting 3.0 (quilt), it's a recipe for failure
Attachment:
pgpl5luupc_6G.pgp
Description: PGP signature