cvs commit: ports/graphics/metapixel Makefile distinfo

[Gerald Pfeifer]

On Fri, 28 Jan 2011, Mark Linimon wrote:
>> Sometimes this is really frustrating.  Way too many ports are just
>> so, fragile, and the onus to fix up any the breakage then lies with
>> those of us who care about general improvements and infrastructure.
> (I should have responded to this earlier, sorry)

No worries, we are all just volunteers!

> I sympathize with your frustration.  OTOH the only way we make progress 
> is if people like yourself pick up the totally-non-glamorous "dirty 
> work" and just grind through to get it committed.

My point really is that the FreeBSD Ports Collection is hobbled by our 
current set of processes which does not scale to the extent FreeBSD needs, 
both in terms of the sheer number of ports and looking at how fast others 
are moving.

Sure, we can have someone spend what turned out to be a surprising amount
of time caring about unmaintained ports or having to wrestle with ports
he is not familiar with only to get a small, and even obviously correct,
change in.  And there are volunteers like you who engage in mini-projects
like this again and again.  

However, I am sure we are loosing lots of volunteers, energy and overdue 
changes like finally adding -I${LOCALBASE}/include to CFLAGS over these 
policies, making FreeBSD harder to use as a ports developer, more error 
prone as a user, and falling behind in innovation.  Wouldn't you want to
do higher value work that really makes a difference, and wouldn't that be
better for the project overall?

Again, here is my original proposal which I have seen no disagreement
on, but also no indiciation this is something you guys are seriously
considering:

 1  An infrastructure change is submitted.
 2. portmgr (or other maintainers) review.
 3. If the review is positive, a pointyhat run is kicked off and for
    every new failure
    - if the port is maintained, a PR is opened and assigned to the
      port maintainer;
    - if the port is unmaintained, it is marked BROKEN and DEPRECATED
      with a deprecation period of two months.
 4. Unless testing has uncovered a real issue with the infrastructure
    change, it is committed after two months at the latest.

Gerald