Re: [gentoo-dev] Re: euscan GSoC project - requesting feedback
On 29 June 2012 17:32, Duncan <1i5t5.dun...@cox.net> wrote: > > EUSCAN_VERSION=0.71 > > I don't know how difficult that would be for euscan to pickup on, but > since this would have no bearing on actual package behavior, only on > euscan, I'd guess it shouldn't require going thru the formal PMS process, > tho specifying it well enough to know whether it can be a function or > must be a straight variable assignment, etc, as well as whether quotes > are required or not, would be useful, and that's normally part of the PMS > process so at least getting input from them would be useful. > > Alternatively, define some formula that can be placed in the package's > metadata.xml. That's perhaps a better functionality match (we're talking > about metadata, after all), but getting a formula that can deal with all > the corner-cases is likely to be more difficult (and take longer) than > simply specifying a variable to be defined for each ebuild that euscan > can't immediately get correct. The problem is with this approach, some devs will want to set EUSCAN_VERSION automagically using mangling $PV As it is, we *already* have something equivalent to EUSCAN_VERSION for things derived from perl-module.eclass, MODULE_VERSION= Its not 1:1 identical to the intent of EUSCAN_VERSION, MODULE_VERSION is only really required in the generation of SRC_URI , but because of this, there is a loose MODULE_VERSION <-> distfile mapping, and a much looser $PV <-> MODULE_VERSION association. Sure, its fine for MODULE_VERSION to be made by mangling $PV, but the problem is that the *reason* people mangle $PV to make MODULE_VERSION is so they don't have to update MODULE_VERSION manually when bumping the package. Adding a non-bash non-$PV-manglable field EUSCAN_VERSION field will possibly make manually incrementing this value a mandatory thing. Not to mention, if it turns out to be "wrong" on the EUSCAN index, some dev has to drop the change into the repository, do all the manifest updating and commit signing and pushing it to CVS nonsense, when really, its metadata only relevant to euscan, so its really in the wrong place to start with. Having it handled as an exception list on the euscan would be much tidier, and the path from noticing the problem to solving the problem becomes substantially shorter. -- Kent perl -e "print substr( \"edrgmaM SPA NOcomil.ic\\@tfrken\", \$_ * 3, 3 ) for ( 9,8,0,7,1,6,5,4,3,2 );" http://kent-fredric.fox.geek.nz
[gentoo-dev] Re: euscan GSoC project - requesting feedback
Kent Fredric posted on Fri, 29 Jun 2012 14:07:58 +1200 as excerpted: > For the most part it seems to get upstream / portage versioning right, > but occasionally you get miss-matches for some reason. > > It would be nice to allow to provide some mapping mechanism that existed > on the overlay itself to inform euscan how to map upstream versions to > downstream ones, but implementing that would be far too complex I feel. > > Instead, it would be nice to have a mechanism in the interface to set a > "Upstream version is" value for each package if euscan can't tell. > > Ie: > > http://euscan.iksaif.net/package/dev-perl/HTML-TreeBuilder-LibXML/ > > Upstream is 0.71 , portage is ( normalised ) to 0.710.0 , and these are > in fact the same version. So in 0.710.0 , it would be nice to be able to > set the upstream version manually to 0.71 so that euscan no longer > reported it as outdated. What about a simple variable that can be set in the ebuild? Say for the above example something like: EUSCAN_VERSION=0.71 I don't know how difficult that would be for euscan to pickup on, but since this would have no bearing on actual package behavior, only on euscan, I'd guess it shouldn't require going thru the formal PMS process, tho specifying it well enough to know whether it can be a function or must be a straight variable assignment, etc, as well as whether quotes are required or not, would be useful, and that's normally part of the PMS process so at least getting input from them would be useful. Alternatively, define some formula that can be placed in the package's metadata.xml. That's perhaps a better functionality match (we're talking about metadata, after all), but getting a formula that can deal with all the corner-cases is likely to be more difficult (and take longer) than simply specifying a variable to be defined for each ebuild that euscan can't immediately get correct. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
Re: [gentoo-dev] Re: euscan GSoC project - requesting feedback
> I'd like to see the information regarding current tree state updated > more regularly than the full upstream scan. Especially when looking at > the herd view, it can be hard to keep track of which bumps have already > been completed. Good idea- it should be much cheaper to do the tree update than to re-scan upstream... -- Andreas K. Huettel Gentoo Linux developer kde, sci, arm, tex, printing signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: euscan GSoC project - requesting feedback
On 2012-06-27 17:51, Federico "fox" Scrinzi wrote: Hi everybody! I'm working on a GSoC project for enhancing Euscan (http://euscan.iksaif.net/). Euscan allows to check if a given package/ebuild has new upstream versions or not. It uses different heuristic to scan upstream and grab new versions and related urls. Euscan has a web interface for surfing data but for now is only possible to see the scan results per package/category/herd/maintainers/overlay. We're working now on the possibility to register and provide a cool dashboard for maintainers, so that they can easily keep an eye on the upstream versions of the packages they maintain. The main question is: what would you like to have on this dashboard? Currently (in the development version) there's the possibility to login and watch/unwatch packages/categories/herds/... and see the watched stuff in the account dashboard. We're planning on implementing a weekly(?) custom newsletter based on the packages you're watching, which features would you like? The project repo for the GSoC is here: https://github.com/volpino/euscan Thanks! Looking forward to seeing the improvements. :) I'd like to see the information regarding current tree state updated more regularly than the full upstream scan. Especially when looking at the herd view, it can be hard to keep track of which bumps have already been completed.
