cvs commit: ports/games/8kingdoms Makefile ports/misc/airoflash Makefile ports/graphics/autopano-sift Makefile ports/x11/avant-window-navigator-xfce4 Makefile ports/lang/boo Makefile ports/x11/cl-clx-sbcl Makefile ports/palm/coldsync ...

[Frederic Culot]

> I have strong opinions against this, at least for ports with an active
> maintainer. I really see these deprecation campaigns as treading on
> somebody's toes.
> 
> I really like linimon's periodic emails "FreeBSD ports that you maintain
> which are currently marked broken", which I see as a reminder that there
> are ports of mine that require action, but going further than that and
> deprecate a port that I maintain without even informing me in an
> official way is not what I consider collaboration.
> 
> Even more so because I don't see any advantage in moving a port from
> BROKEN to DEPRECATED state. If a user has a working version of the port
> installed, he will stick to that, otherwise, installation will be frown
> upon anyway.
> 
> I and bapt have already exchanged opinions on this subject more than
> once, and I would now like to see what other people (other maintainers
> in particular) think about it.
> 
> Can we please stop this?
> 
> -- 
> Pietro Cerutti
> The FreeBSD Project
> gahr at FreeBSD.org
> 
> PGP Public Key:
> http://gahr.ch/pgp


As you inquire people's opinion, I would say that I find this way of proceeding
a bit pushy and I consider it a good example of closed communication as I find
it:

- non-caring: such a commit is a detached and impersonal way to give the
  information to a maintainer that has not unbroken his port for a long time

- dogmatic: it looks like an unwillingness to accept the maintainer's point of
  view or at least to hear about his work on maintaining the port

- superior: deprecating without prior communication with the maintainer stresses
  differences in status between portmgr/committer and maintainers

Hence I am not surprised when you say you feel someone is treading on your toes,
and more generally I fear this does not do any good to maintainer's motivation
and commitment to the project.

On the other hand I also believe those deprecation actions are necessary and I
thank bapt for his work on this.

To conciliate such a necessary action without hurting the feelings of those
maintainers who despite their work could not update the state of their port in a
timely manner, maybe it would be good to be more verbose in the log of such
commits. Inspired by linimon's emails, something like the following could be
added:

"As part of an ongoing effort to reduce the number of problems in the FreeBSD
ports system, we periodically schedule removal of ports that have been marked as
broken for a period of at least six months. As a maintainer of one of those
ports, feel free to remove the deprecate status if you need more time to fix the
breakage and do not hesitate to contact portmgr@ if you need additional
information on this policy."

I hope this brings something to the discussion.

--
Frederic Culot
culot at FreeBSD.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20120410/99684445/attachment-0001.pgp