On Wed, 3 Aug 2011 16:26:20 +0000, Alexey Dokuchaev wrote:
On Tue, Aug 02, 2011 at 04:33:14AM +0000, Baptiste Daroussin wrote:
Ah :) I was sure this time that won't be tha easy :)
:-)
I am deprecating them because they are abandon by upstream which
means
and seems unmaintained. they do have modern equivalent.
But if mastersite is still up'n'running, how can we declare that they
are
abandoned by upstream?
No upstream == most of the time no maintainenance, no more patches,
no
more security concern. For us it also mean more things to take care
of,
Maybe that means that the software is stable and "just works". Why
patch
it then? :-)
more infrastructure work, more complicated makefile (in that case
bsd.gnome.mk which already supports gnome2 things and gnome3 will
come
one day).
If you think they are still useful ie have users and people ready
todo
the upstream if needed then feel free to undeprecate (that's the
goal of
the deprecation period: warn users/maintainers that a program will
soon
disappear if no one takes care of it).
First let me state that I think your deprecating work is actually a
good
thing, especially considering how much manual grunt work it requires
to
check that mastersite is indeed gone, project is stalled, etc. I
highly
appreciate this undertaking of yours.
However, I believe that criteria for deprecating should be refined a
bit.
That is, it's fair to deprecate long broken ports with no upstream
availability, or with open security issues. But mere lack of
maintainer
or recent upstream activity is not enough: lots of programs happen to
just
work so no new version is actually that needed, and frankly speaking,
unmaintained ports often get much better care from Kato compared to
plethora
of low quality "maintainer update" PRs that get committed these days.
As
you've probably noticed, I periodically touch some random ports I run
across, and it's really motivating to do something good about it when
I know
there is no one I should be asking for obligatory confirmation for
even
trivial changes. Unfortunately, very few maintainers are top-notch
folks,
and The Project currently has no educational programs to improve this
situation: sadly, many port committers believe in "if it builds on
tindy,
it's fine" mantra. :-(
./danfe
I agree concerning ports maintained by ports@ and how thay are
maintained, however, if you or others feels like I was wrong deprecating
some ports, just undeprecate them.
I am just trying to have a ports tree providing really usable things.
And providing very old, unmaintained by upstream ports which have new
available or equivalent "modern" version is a good thing. To be clear,
in my mind most of the gnome1 (no I don't have xmms or so in mind) ports
has to bite the dust because, who is still using and testing them? It
also has a maintainance cost in the Mk/* files. I am sure we can get rid
of most of those ports (just keeping gtk12 and glib12 or so).
That is why I'm on the mood of deprecating gnome1 related (gtkmm12 in
fact concerning the commit you replied) that are said abandon by their
upstream and (un)maintained by ports@. With a 1 month deprecation period
everyone interested has the time to save them.
Bapt
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "[email protected]"
