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. 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. 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. 
 
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

Reply via email to