On 12/08/14 08:04 AM, PICCA Frederic-Emmanuel wrote:
I do completely support this idea. I have added autopkgtests for many of "my" packages [1], so you will find there a lot of examples, if you need it.What about creating a dedicated usertag and add bugs for this debci integration. Each maintainer could add this kind of bug if he think that one of his package could beneficiate of the debci integration. Not all packages of debian-science has a unit test available right ? :((. So to help new comers find there way in this not so difficult debci task, would be to references all this kind of bugs in the wiki.
This is an excellent idea. After seeing your suggestion yesterday, I looked through a few packages for what's already included or not included, and felt very overwhelmed. I also saw some of Anton's packages with the tests already enabled, and originally thought he'd written all these tests himself, which was *very* intimidating (thankfully, I thought to use Code Search, and found where the test cases were hiding in the source package).
Is these a mean to generate a web page in the wiki with all bugs tagged ? What is nice in this kind of page is also to see the amount of work already done (the closed bugs). We need to decide of a usertags for this. debian-science-debci (a bit long...) maybe we should discuss with the debci developper if they want a dedicated debci usertag general to debian and not attached to a dedicated team. after all we can filter using the debian-science-maintainers@lists.alioth.debian.org.Also we need to have a look at Debian-science packages, which are not able to migrate to testing for some reasons. There not so much of them, but they need some attention [2].The RC bugs squashing is also an activity interesting with the freeze, but it seems to me that a new comers can be intimidated by this kind of RC fix, which are most of the time not that easy to fix. (If it was easy it would have been already fixed isn't it :p)
After looking at the autopkgtest stuff, this actually feels far LESS intimidating. But that's just me, and that opinion might change. We'll see. :)
Cheers Fred [1] https://qa.debian.org/developer.php?login=gladk@debian.org [2] https://qa.debian.org/developer.php?login=debian-science-maintainers@lists.alioth.debian.org Cheers Anton
I have a couple of questions about package "ownership" in this team. On the Ruby team, the uploader is whoever, and you can just work on any package (pretty much); no one is really in charge of the package. However, based on a couple of comments in this thread, it sounds like there's a more structured concept of ownership. Is that right? And if so, can you think of any people who are listed as uploader but aren't really active anymore, as that would probably be a good place for me to start.
Also, curiosity: why does the DDPO page [1] list all packages in "science", not just those owned by debian-science-maintainers@lists.alioth.debian.org? Seems rather strange. Am I right that the top 3 tables (main, contrib, non-free) and last 2 (pending, backports) are the actual team-maintained packages, and the rest are coming in because they're affiliated with the blend or part of the "science" category?
Thanks, Caitlin[1] https://qa.debian.org/developer.php?login=debian-science-maintainers@lists.alioth.debian.org