Re: How to handle mgltools in our tasks files
On Thu, 6 Nov 2008, Steffen Möller wrote:
1. Web tasks pages:
Does it makes sense / would it harm the tasks pages if all the
mgltools would be listed there (either in bio or bio-dev task)?
no, it would not, imho. it would be similar to listing all applications
in EMBOSS.
The problem is that mgltools are orginated from different source packages
while in the case of emboss at least one binary package out of the emboss
source is listed. For bugs pages and the QA sectioning the respective
source package is queried while the tasks page shows the description of
the binary package (which is evident because the source package has no
own description and it might also be very reasonable to list different
binary packages there - the description might be quite different).
This is a good point. One should definitely learn about bugs being
assigned to them.
OK, so I just added the packages to the tasks.
3. QA overview[3]:
The packages should be listed really in either bio or bio-dev
section instead under "non-free".
Right.
See above.
I am not sure myself how this should be handled. An option "hide" might
indeed be helpful. It could take "overview", "bugs", "qa" as arguments.
This might be a useful enhancement for the future - but for the moment
I do not really see an urgent need for it.
I'd opt for the listing of the packages in the tasks list and the
introduction of a "hide" attribute.
I'll put that list on my todo list (but not very high) ...
I'll go for an update of that
packages any time soon, btw.
But please take the chance to care for their autobuilding on non-free
quite soon. I see that you have set
XS-Autobuild: yes
but I realised, that
mgltools-bhtree, mgltools-geomutils, mgltools-opengltk, mgltools-pyglf, mgltools-sff
are available only for amd64 which currently hides them for the webtools
as well. The rationale is that the webtools only consider Packages-i386
which works for most practical issues - but not for this one. I just
hesitate to make webtools even slower (by parsing any architectures
Packages file - it is even slow now!) for these non-free corner cases
which rather should be fixed per package. So I just prefer the error
message in the webtools as a means to detect problems for the autobuildes
instead of making the webtools slower.
Are there any autodockers on this list, btw?
Not me ...
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: