Re: shall we keep collecting suggestions in the task files?
On Wed, Oct 22, 2014 at 03:48:49PM +0200, Holger Levsen wrote: > (do I need to you cc: you, Andreas?) I'd prefer CCing Debian Edu list (since it is not subscribed to the bug) > On Mittwoch, 22. Oktober 2014, Andreas Tille wrote: > > Try > > debcheckout debian-med > > > > instead. The tasks pages are created from VCS rather than the package > > source. > > I see. And how is the vcs turned into the source package, or why is acacia > mentioned in tasks/bio in VCS but not in the source package? Well, we are developing in VCS, right? It will be part of the next release of the source package. > Where is the > logic for that? And does it have to be that way? I'm sorry, what type of question is this? I admit I'm perplexed. > IOW: how can we get our candidates on our blends pages? Add it to the tasks files in Debian Edu Git. > > The "Ignore" exists for this very purpose and was injected by Petter. > > Why don't you ignore acacia then? Since it is not set to "Ignore"? I also do not understand this question, sorry. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-edu-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141022211256.gb31...@an3as.eu
Re: shall we keep collecting suggestions in the task files?
On Wed, Oct 22, 2014 at 03:21:32PM +0200, Holger Levsen wrote: > Hi, > > On Mittwoch, 22. Oktober 2014, Andreas Tille wrote: > > 1. Add some rudimentary packaging in your packaging VCS containing > > a valid d/changelog, d/control including Homepage and description > > and optionally a DEP5 formatted d/copyright skeleton. There is > > an UDD importer that fetches this data and adds the info to the > > tasks page. > > nope, that doesnt fit here. > > > 2. Add the metadata right into the tasks file. > > > > Both is explained in the Blends documentation[1]. Option 1. is prefered > > since it shows that your interest into the package is somehow "honest". > > The Med Bio task[2] provides an extensive example of all options. > > so the first software there is "Acacia" an "Error-corrector for pyrosequenced > amplicon reads.", how is that in your task file? how is that even part of the > debian-med source package? > > matrix:~/m$ apt-get source debian-med > [...] > matrix:~/m$ cd debian-med-1.13.2/ > matrix:~/m/debian-med-1.13.2$ ls > AUTHORS config COPYING debian debian-med-tasks.desc Makefile menu > README tasks tasks.ctl > matrix:~/m/debian-med-1.13.2$ grep -i Acacia tasks/* > matrix:~/m/debian-med-1.13.2$ rgrep -i Acacia * > > hmmm. Try debcheckout debian-med instead. The tasks pages are created from VCS rather than the package source. > > I personally think that so called "prospective packages" should always > > be accompanied by some metainformation which enables rendering on the > > tasks pages. If you do not mind providing this bit of information I > > doubt that the intent to work on this will be really honest. > > there is no(t neccessarily an) "intend to work on these packages", sometimes > we just want to track them (and use them if someone else packages them). You could at least add a Comment about this ... > > So it is > > really easy to detect "dust": Dependencies that are not in the Debian > > package pool and do not have any metainformation are dust, IMHO. > > yeah, maybe. I've looked at > http://blends.debian.org/blends/ch08.html#edittasksfiles now and "Ignore" > seems to be what we want and which we already use for such packges. The "Ignore" exists for this very purpose and was injected by Petter. > But then I still wonder about the "Acacia" example above! :) You simply need to understand that we try to get the information as current as possible and the source packages are simply static. Any VCS commit to the tasks files will trigger a rerendering of the tasks pages (after 15min cron job). > > > I've checked some of the packages and some of them are indeed provided by > > > alternatives, so I don't think now is there right time to clean this up, > > > but rather after the Jessie release. > > Hmmm, unfortunately this argument was used even two releases before. :-( > > Unfortunatly it's again true. :-( > > No. Blends-dev has a feature to deal with non-existing packages. > > Great. Just that it doesn't seem to be enough / used / used correctly, for > whatever reason(s). ... in Debian Edu. That's correct. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-edu-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141022133307.gd17...@an3as.eu
Re: shall we keep collecting suggestions in the task files?
Hi Holger, On Wed, Oct 22, 2014 at 02:47:45PM +0200, Holger Levsen wrote: > as we keep many suggestions, candidates, Keeping candidates is perfectly supported. However, you can ... and should provide some metadata for candidates. The way you can do this is either 1. Add some rudimentary packaging in your packaging VCS containing a valid d/changelog, d/control including Homepage and description and optionally a DEP5 formatted d/copyright skeleton. There is an UDD importer that fetches this data and adds the info to the tasks page. 2. Add the metadata right into the tasks file. Both is explained in the Blends documentation[1]. Option 1. is prefered since it shows that your interest into the package is somehow "honest". The Med Bio task[2] provides an extensive example of all options. > valid packages which then get > orphaned or renamed, in the tasks files, the task files collect "dust" > and thus it becomes harder to see real issues in the task files. I personally think that so called "prospective packages" should always be accompanied by some metainformation which enables rendering on the tasks pages. If you do not mind providing this bit of information I doubt that the intent to work on this will be really honest. So it is really easy to detect "dust": Dependencies that are not in the Debian package pool and do not have any metainformation are dust, IMHO. > Using the output from the udd importer this is the dust there is > currently, see below. > > I've checked some of the packages and some of them are indeed provided by > alternatives, so I don't think now is there right time to clean this up, > but rather after the Jessie release. Hmmm, unfortunately this argument was used even two releases before. :-( > And I also think this will only be > useful if we change the way we keep track of suggested packages. +1 (see above) > Maybe > have a special task file just for those? I do not think this is a good idea since by nature this is not really a task in the sense we are using tasks. > And then once they become > available, we move them to the "real" tasks? This sounds a bit like a > generally useful feature for blends-dev - what do you think? No. Blends-dev has a feature to deal with non-existing packages. Kind regards Andreas. [1] http://blends.debian.org/blends/ch08.html#edittasksfiles [2] http://blends.debian.org/med/tasks/bio#pkgvcs-debs -- http://fam-tille.de -- To UNSUBSCRIBE, email to debian-edu-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141022130600.gc17...@an3as.eu
