Hi, On Apr 26, 2011, at 12:17 PM, Max Horn wrote:
> > 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. Another option would be have some field in the .info file which tells the validator to skip on a particular (set of) tests. E.g. the geant4.x packages could tell the validator to skip the test on /sw. I have no idea how easy it would be to implement, thought. Remi > >> 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 ------------------------------------------------------------------------------ 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
