sysutils/cfs

[Julian H. Stacey]

Matthias Andree wrote:
> Am 07.09.2011 17:53, schrieb Mikhail T.:
> 
> > The policy -- up until fairly recently -- was to remove ports, that
> > *fail to build* for a while. This made sense -- if the port remains
> > unbuildable long enough, then, certainly, it is no longer in use.
> > 
> > The /new/ policy of removing ports for much lighter offenses, such as
> > having vulnerabilities, has already caused so many objections, that it
> > is time to abolish it.
> 
> I don't see ports being killed the first day they are vulnerable.  They
> are killed if they're dead

If long term dead, fine, but if a port is deleted between releases,
without prior warning variables set in Makefile at last release
tag, then we deny release users any warning & any code to fix, ...

Unless user hurdles the extra un-necessarily premature obstacle of
CVS Attic; & as FreeBSD will have just irresponsibly annoyed user,
it's a bad time to expect user to waste extra time learning FreeBSD
web or CLI interface to CVS for Attic, additional to fixing a broken
port and filing a send-pr.

Some users may react:
"Time for another BSD or Linux with more mature code management."

Broken ports should first be marked BROKEN= through a release cycle
so more users have time to consider a fix via send-pr.


> and vulnerable though, and that's good.

No. "Vulnerable" depend on user context you, & as others have already
explained,it would be cheeky of FreeBSD to dictate policy to others,
when we don't know their circumstances, there are Makefile variables,
as others have already explained, to help the User decide, not us.


> > A "maintainer timeout" will allow another developer to perform a fix. To
> > completely remove the port (if that has to happen at all), a much longer
> > warning is warranted.
> 
> Which can certainly be negotiated (and an EXPIRATION_DATE shifted) if
> and only if the fix is really going to happen.

No. Wooly thinking, that would require commiters making judgements,
& changing variables, make it easy & automatic. We've already read
a better proposal for some time/ release/ macro var. Read back on
the thread.


> A case like "I'll fix it
> after vacation" might be workable.  However if you make empty promises
> repeatedly noone will care.

You'r assuming some rush crusade to delete, backed by time consuming
analogue humans making value judgements. Not good, better leave it
to the state machine of send-pr & automatic non short term var
macros for expire.

> 
> > Yes, the matter is exactly that: your wanting to remove something, that
> > continues to build and remains in use. You followed, what you think is
> > "an old" policy, and are getting flack from people like myself, who
> > object to the (new) policy. Nothing personal...
> 
> End users are not obliged to delete ports we've removed from the ports,

Neither would you be obliged to delete eg your gcc if src/ unbundled
it, but you'd find it pretty annoying after no warning, to suddenly
need to look for a backup in the Attic.


> so I wonder what the heck the difficulty is with "we no longer care".

"We no longer care ... to be responsible, we removed it without warning."
Or 
"We no longer care ... to give this without warning,
 so we added some BROKEN= / DEPRECATED= /  FORBIDDEN=
 so users can make their Own decision in light of their circumstances."


> We're not enforcing port removals on end user's computers.  We're not
> Google removing applications from your Android phone.  We're not Apple
> doing the same to your iOS phone.
> 
> So can this discussion be ended?

When the ill considered ports/ killing campaign is ceased.


> If the port was in active use and
> maintained, we would not be deprecating it.

Not true.  Example: Procmail too was proposed for the ports killing
crusade.  ( A FreeBSD developer who doesnt have time for ports@ was
shocked when he heard that today.)


> > Again. This is not about a particular port -- Julian, myself, and other
> > objectors can fix /any/ port, but we can not fix them /all/, so blaming
> > us for not submitting patches is wrong.
> 
> Rather than waste your time discussing that you could go maintain and/or
> fix the ports you feel should not be deprecated.

Wrong. Re-Read  Mikhail above "Again. This is not ..."


> > We object to the new policy, because we believe, only those ports, that
> > fail to build, ought to be removed. Problematic ports ought to remain in
> > the tree (as long as they build) -- to make it easier for people to
> > continue using them and/or offer to maintain them. If there remains a
> > vulnerability, then, of course, a loud warning (with a link to the
> > advisory(ies)) is in order, but the users ought to make their own
> > choices and evaluations.
> 
> They do even after port removal.

Wrong. They will find the port they were going to look at has been
irresponsibly removed without warning, no code left there to fix.


  If a port is known broken and there is
> no prospect of a fix, it must go.

"no prospect of a fix" is a value judgement not easily made in a rush.
(& some value judgement in the ports crusade have been wrong recently).
Better FreeBSD should revert largely to the pre port killing crusade way,
allow release users some warning.

See definition of eg BROKEN in ports/Mk/bsd.port.mk

If a port is found to be broken it is Not just tossed, it is marked
"BROKEN=" (hopefully for a good while, eg at least a release cycle)
so release users have time to see & fix.

Cheers,
Julian
-- 
Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com
 Reply below, not above;  Indent with "> ";  Cumulative like a play script.
 Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable.
 http://www.softwarefreedomday.org 17th Sept,  http://berklix.org/sfd/ Oct.