Am 18.04.2011 um 17:49 schrieb Daniel Macks: > On Mon, 18 Apr 2011 14:50:40 0200, Max Horn wrote: >> Am 18.04.2011 um 14:49 schrieb Max Horn: >>> >>> OK... anybody opposed? To summarize, this are the changes I > propose, each should be trivial to implement: >>> >>> 1) Drop the _warning_ when a package description exceeds 45 > chars, only keep in the 60 chars _error_ >>> 2) Allow package name to be used in description. >>> >>> Alternatively, we could keep these warnings, but make them > non-fatal in maintainer mode. This could be done by making it less > "binary": Instead of $looks_good equal to 0 or 1 (bad or good), we > could distinguish between three levels "perfect", "warnings", "errors". >>> >>> Anyway, I still think we should drop at least the 45 warning > completely. It's just outdated, back from the days when screens were > small ;). > > I won't object to #1 if others feel strongly, even though the standard > xterm and Terminal.app size is still 80-column.
One of the first things I do on any terminal app I need to work with, is to increase this silly old default to something bigger, e.g. 100 or 120. And luckily, at least on Linux, some terminals seem to have begun using larger defaults. > I'm only fine with #2 > for OBSOLETE packages (per previous email, where it helps force > maintainers to be more descriptive, which helps users who don't > already know the jargon or specific keywords, etc.). Fink HEAD has > validator weakened for #2 in this way. > >> PS: An alternative would be to change maintainer mode to invoke the >> validator with pedantic mode turned *off*. That would also make it >> less strict about some other description rules. > > Isn't that pretty much the opposite of the idea of -m mode? Maintainers > need to make sure *their own* packages are squeeky-clean, rather than > putting on blinders to problems that are only seen by others. Agreed. So let's look at the actual problem this idea was meant to address: There are some cases were the validator incorrectly complains about perfectly fine packages. Currently, in such cases, the package maintainer then is forced to either make weird unnatural hacks to fool the validator (YUCK), or has to live without being able to use -m. A concrete example are the geant4.8 and geant4.9 packages, for which the validator complains about them hardcoding /sw. In reality, though, the *upstream* authors hardcoded /sw, and the .info file tries to fix this by replacing /sw with %p. Granted, there are only very few such examples. But it's still annoying that for these, maintainers cannot use maintainer mode, with the useful feedback it provides. So, is there a way to get all the feedback provided by -m mode without using -m mode? If so, IMHO we can leave things as they are, and just tell the few unlucky maintainers to use that as a workaround. If there is no way for that, I think we should contemplate adding one. E.g. by offering separate tools / commands to access them Or by modifying -m mode to be interactive: Instead of aborting when a possible policy violation has been detected, put up a prompt and ask whether to continue anyway. Then, in the end, show a summary of all found issues. Output in big fat letters "THIS PACKAGE PROBABLY VIOLATES THE PACKAGING GUIDELINES" or so. This way, maintainers are still very clearly shown that their package is broken. But maintainer mode becomes useful for some more people. > We have > enough broken messes unstable/ now where things technically pass -m > mode but have "visible to others if one actually tests it" problems, we > don't need don't need to have people contributing more "it passes -m, > why isn't that sufficient?" workload onto -submissions. That is, -m > mode *should* enforce "perfect" in your three-level system, since > maintainers are responsible for their own packages. While I would like us to enforce "perfect", right now I am more concerned about enforcing "at least not obviously broken". As it is, we had / have dozens if not hundreds of package validation warnings and errors in our tree. The validator and maintainer mode are useful tools for battling those, but what we really need is some kind of enforcement of these issues. Like, preventing people from commiting non-validating .info files in the first place. Like, kicking people who have broken package (i.e. validation errors, or errors when doing a "-m --build-as-nobody" mode), and some rules what to do when they don't fix their stuff (e.g. after period X, the package is either removed, or unmaintained; and the latter case ideally should only happen if simultaneously somebody fixes the issues). As it is, I've been chasing folks whose package install stuff outside /sw for half a year; I've now issued a kind of ultimatum. But in the meantime, I am pretty sure some new crap trickled in. So *this* is what I personally am more concerned about than whether a package has an overly long description or not :). And to fix it, we need people to actively watch for these issues. And the more false warnings/errors our tools report, the harder it becomes to concentrate on the truely serious ones... Luckily we have the non-pedenatic mode, too, so I'll be back to prodding maintainers who misspell their package fields, and other stuff. Cheers, Max > > There actually is a special "pedantic" level of warning, that is only > triggered in certain modes (or it's only upgraded to a real warning in > certain modes), things like 45-char. I think one of the situations > where it is kept as a degraded level is when a package is encountered > as a dependency of what one requests (vs actually being passed on > command-line). Again, this makes the explicltly-requested packages > strongly checked (i.e., the one you are testing) but doesn't block on a > dependency that is only broken in style. > > dan > > -- > Daniel Macks > dma...@netspace.org > > > > ------------------------------------------------------------------------------ > Benefiting from Server Virtualization: Beyond Initial Workload > Consolidation -- Increasing the use of server virtualization is a top > priority.Virtualization can reduce costs, simplify management, and improve > application availability and disaster protection. Learn more about boosting > the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev > _______________________________________________ > Fink-devel mailing list > Fink-devel@lists.sourceforge.net > List archive: > http://news.gmane.org/gmane.os.apple.fink.devel > Subscription management: > https://lists.sourceforge.net/lists/listinfo/fink-devel ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
