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

[Marcelo Araujo]

2012/4/10 Pietro Cerutti <gahr at freebsd.org>

> On 2012-Apr-10, 11:20, Marcelo Araujo wrote:
> > 2012/4/10 Pietro Cerutti <gahr at freebsd.org>
> > >
> > >
> > > I might agree on that. But how is a DEPRECATED port better than a
> BROKEN
> > > one in this regard?
> > >
> > >
> > In my point of view, no make sense have a bunch of ports that actually
> > doesn't works or because there is a fetch problem or even it is set as
> > BROKEN. Who never was upset when need and find a port but it is BROKEN
> for
> > some reason, In my view, have a port BROKEN or haven't it, is the same.
> Of
> > course, I mean when a port is BROKEN for all plataforms as well as for
> all
> > FreeBSD version.
>
> I agree on that.
>
> >
> > I believe set it as DEPRECATED is a good way to make the maintainer take
> > attention to fix it soon as possible, due he has put effort to insert
> this
> > software on the ports tree in the past.
>
> What about submitting a PR, as we usually do for anything else? If it's
> ok to wait 15 days (maintainer timeout) to commit an update to a port
> that brings in important features, it is even more so to wait to
> deprecate one.
>

That is a very good point, if someone send a PR, nobody need to make it
DEPRECATED, but unfortunately, sometimes it doesn’t happens. And as I can
see, almost all ports that switch from BROKEN to DEPRECATED, is because no
one send a PR.



>
> > In case that has any issue related with the ports framework that make the
> > ports be broken, he can ping any developer to give him more time to fix
> or
> > even rollback the DEPRECATED commit with a proper message on the commit's
> > log.
>
> This is awkward. We're not supposed to spend our time rolling back
> unwanted commits. We're supposed to make sure that a commit made to
> someone else's port is wanted in the first place.
>

I agree with you, maybe there is another better way.


>
> > It also will let us know, what's happen with that port and maybe someone
> > else could give a hand to help the maintainer to fix it.
>
> Well, as I see it, marking a port as DEPRECATED is kind of a final
> decision. I.e., I'll start to look at alternatives and forget about it.
> If you mark a port as DEPRECATED and 12 hours later I back off your
> chance with a comment "I'm working on it", a really unconsistent and
> confused message will pass.
>

Here depends! Usually when I need a port that is set as DEPRECATED, first I
take a look why it is set like this, and then, I start to looking for an
alternative in case I can’t fix that port or it is really obsolete because
the software is dead for some reason.


Best Regards,
-- 
Marcelo Araujo
araujo at FreeBSD.org