In message <46bc57fc-90af-004e-b722-114869097...@grosbein.net>, Eugene
Grosbein
writes:
> 16.03.2024 17:03, Daniel Engberg wrote:
>
> > A key difference is though that browsers such as Firefox or Chromium are ma
> intained upstream including reporting etc.
>
> It does not stop browsers from being
In message <8212dd5a-bcc2-e214-0373-6dbfddef6...@grosbein.net>, Eugene
Grosbein
writes:
> 15.03.2024 3:37, Daniel Engberg wrote:
> > On 2024-03-12T15:15:49.000+01:00, Eugene Grosbein wrot
> e:
> >> 12.03.2024 3:24, Daniel Engberg пишет:
> >>
> >> [skip]
> >>
> >>
> >>>Another possible optio
Cheers,
Cy Schubert
FreeBSD UNIX: Web: https://FreeBSD.org
NTP: Web: https://nwtime.org
e^(i*pi)+1=0
<20240315072753.46ffa39e1bbb2e0996099...@dec.sakura.ne.jp>
Comments: In-reply-to Eugene Grosbein
message dated "Fri, 15 Mar 2024 14:14:21 +0700."
On Sat, 16 Mar 2024, at 10:28, Michael Gmelin wrote:
> Seriously, the “other” tree would rot in no time, this is not practical
> (it’s also interesting how the discussion moved from ‘ports
> unmaintained upstream’ to ‘ports without a maintainer’).
Look at it another way: how come something like
[Just trying to get Daniel's E-mail address right this time.]
On Mar 16, 2024, at 08:58, Mark Millard wrote:
> Eugene Grosbein wrote on
> Date: Sat, 16 Mar 2024 13:16:21 UTC :
>
>> 16.03.2024 17:03, Daniel Engberg wrote:
>>
>>> A key difference is though that browsers such as Firefox or Chrom
Eugene Grosbein wrote on
Date: Sat, 16 Mar 2024 13:16:21 UTC :
> 16.03.2024 17:03, Daniel Engberg wrote:
>
> > A key difference is though that browsers such as Firefox or Chromium are
> > maintained upstream including reporting etc.
>
> It does not stop browsers from being vulnerable all the t
16.03.2024 17:03, Daniel Engberg wrote:
> A key difference is though that browsers such as Firefox or Chromium are
> maintained upstream including reporting etc.
It does not stop browsers from being vulnerable all the time. All times. So, no
difference in practical point of view.
In theory, the
> On 16. Mar 2024, at 10:45, void wrote:
>
> On Sat, 16 Mar 2024, at 08:28, Miroslav Lachman wrote:
>
>> For vulnerabilities, there is VuXML and pkg audit, not removing
>> vulnerable port from the tree.
>
> I'm talking about *moving* them to a *different* tree, with different
> priorities
On 2024-03-15T08:25:10.000+01:00, Eugene Grosbein wrote:
> 15.03.2024 3:37, Daniel Engberg wrote:
>
> >On 2024-03-12T15:15:49.000+01:00, Eugene Grosbein
> > wrote:
> >
> > > 12.03.2024 3:24, Daniel Engberg пишет:
> > >
> > > [skip]
> > >
> > >
> > >
> > > > Another possible
On Sat, 16 Mar 2024, at 08:28, Miroslav Lachman wrote:
> For vulnerabilities, there is VuXML and pkg audit, not removing
> vulnerable port from the tree.
I'm talking about *moving* them to a *different* tree, with different
priorities, so preserving choice while implicitly informing of risks,
a
Le sam. 16 mars 24 à 9:28:23 +0100, Miroslav Lachman <000.f...@quip.cz>
écrivait :
> If you are asking to remove ports without maintainer, you are asking to
> remove 3458 ports right now, and many others depends on these unmaintained
> ports, so the impact will be much bigger.
Seconded! Ports w
On 16/03/2024 02:48, void wrote:
On Thu, 14 Mar 2024, at 22:59, Daniel Engberg wrote:
Since we've moved to git perhaps another option might be to create a separate
repo (possibly via submodules) with less restricive polices and have
that as an "add-on" for the official tree without the ports te
On Thu, 14 Mar 2024, at 22:59, Daniel Engberg wrote:
> Since we've moved to git perhaps another option might be to create a separate
> repo (possibly via submodules) with less restricive polices and have
> that as an "add-on" for the official tree without the ports team's and
> committers's inv
15.03.2024 3:37, Daniel Engberg wrote:
> On 2024-03-12T15:15:49.000+01:00, Eugene Grosbein wrote:
>> 12.03.2024 3:24, Daniel Engberg пишет:
>>
>> [skip]
>>
>>
>>>Another possible option would be to add something to the port's matedata
>>> that makes pkg aware and easy notiable
>>> like usin
15.03.2024 5:59, Daniel Engberg wrote:
> That may very well be an option possibly with some guidelines to prevent it
> turning into a loophole for being a dumping ground.
> Since we've moved to git perhaps another option might be to create a separate
> repo (possibly via submodules)
> with less
15.03.2024 5:27, Tomoaki AOKI wrote:
> How about setting NO_PACKAGE [1] to force admins to build from ports
> by themselves for such risky but too usful to delete ports?
Tools, not policy. Do not try to force people to do as you wish.
Eugen
> On 14. Mar 2024, at 23:59, Daniel Engberg
> wrote:
> On 2024-03-14T23:27:53.000+01:00, Tomoaki AOKI
> wrote:
>> On Thu, 14 Mar 2024 22:17:39 +0100
>> Daniel Engberg wrote:
>>
>>
>>> On 2024-03-14T21:49:46.000+01:00, Michael Gmelin
>>> wrote:
>On 14. Mar 2024, at 21:38,
On 2024-03-14T23:27:53.000+01:00, Tomoaki AOKI
wrote:
> On Thu, 14 Mar 2024 22:17:39 +0100
> Daniel Engberg wrote:
>
>
> >On 2024-03-14T21:49:46.000+01:00, Michael Gmelin
> > wrote:
> >
> > >
> > >
> > > > On 14. Mar 2024, at 21:38, Daniel Engberg
> > > > wrote:
> > >
On Thu, 14 Mar 2024 22:17:39 +0100
Daniel Engberg wrote:
> On 2024-03-14T21:49:46.000+01:00, Michael Gmelin wrote:
> >
> > >On 14. Mar 2024, at 21:38, Daniel Engberg
> > > wrote:
> > >
> > > On 2024-03-12T15:15:49.000+01:00, Eugene Grosbein
> > > wrote:
> > >
> > > >12.03.2024
Daniel Engberg wrote:
On 2024-03-14T21:49:46.000+01:00, Michael Gmelin wrote:
On 14. Mar 2024, at 21:38, Daniel Engberg
wrote:
Given that we seem to agree on these points in general why should such ports
still be kept in the tree? We don't have such tooling available and it wont
li
On 2024-03-14T21:49:46.000+01:00, Michael Gmelin wrote:
>
> >On 14. Mar 2024, at 21:38, Daniel Engberg
> > wrote:
> >
> > On 2024-03-12T15:15:49.000+01:00, Eugene Grosbein
> > wrote:
> >
> > >12.03.2024 3:24, Daniel Engberg пишет:
> > >
> > > [skip]
> > >
> > >
> > >
> >
> On 14. Mar 2024, at 21:38, Daniel Engberg
> wrote:
>
> On 2024-03-12T15:15:49.000+01:00, Eugene Grosbein wrote:
>> 12.03.2024 3:24, Daniel Engberg пишет:
>>
>> [skip]
>>
>>
>>> Another possible option would be to add something to the port's matedata
>>> that makes pkg aware and easy
On 2024-03-12T15:15:49.000+01:00, Eugene Grosbein wrote:
> 12.03.2024 3:24, Daniel Engberg пишет:
>
> [skip]
>
>
> >Another possible option would be to add something to the port's matedata
> > that makes pkg aware and easy notiable
> > like using a specific color for portname and related
12.03.2024 3:24, Daniel Engberg пишет:
[skip]
> Another possible option would be to add something to the port's matedata that
> makes pkg aware and easy notiable
> like using a specific color for portname and related information to signal
> like if it's red it means abandonware and potentially r
On 2024-03-11T18:22:57.000+01:00, Eugene Grosbein wrote:
> 11.03.2024 4:49, Daniel Engberg wrote:
>
>
> >
> > >
> > > > Ports can be removed immediately if one of the following conditions
> > > > is met:
> > > >
> > > > - Upstream distfile is no longer available from the original
On 2/28/24 11:22, Florian Smeets wrote:
Ports can be removed immediately if one of the following conditions is
met:
- Upstream distfile is no longer available from the original
source/mirror (Our and other distcaches e.g. Debian, Gentoo, etc do
not count as "available")
Such removal can't
11.03.2024 4:49, Daniel Engberg wrote:
>>> Ports can be removed immediately if one of the following conditions is met:
>>>
>>> - Upstream distfile is no longer available from the original source/mirror
>>> (Our and other distcaches e.g. Debian, Gentoo, etc do not count as
>>> "available")
>>
On 2024-03-10 14:49, Daniel Engberg wrote:
On 2024-03-10T21:45:16.000+01:00, Eugene Grosbein
wrote:
29.02.2024 2:22, Florian Smeets wrote:
>This policy should give some guidance on when ports can or should be
removed. In general ports should not be removed without reason but if a port
On 2024-03-10T21:45:16.000+01:00, Eugene Grosbein wrote:
> 29.02.2024 2:22, Florian Smeets wrote:
>
>
> >This policy should give some guidance on when ports can or should be
> > removed. In general ports should not be removed without reason but if a
> > port blocks progress it should be d
29.02.2024 2:22, Florian Smeets wrote:
> This policy should give some guidance on when ports can or should be removed.
> In general ports should not be removed without reason but if a port blocks
> progress it should be deprecated and subsequently removed. In general, if a
> ports blocks progre
Le mer. 28 févr. 24 à 20:22:34 +0100, Florian Smeets
écrivait :
> Dear ports community,
Hello,
> as the removal of ports is a recurring source of friction and dispute we
> would like to add a ports removal and deprecation policy to the porters
> handbook.
Thanks for working on this subject!
Hi,
A few comments on the proposed ports deprecation and removal policy, there will
be some quotes for context by multiple people and adress multiple mails.
I would recommend that we in general set DEPRECATED, EXPIRATION_DATE (2w to 1m
minimum), mark BROKEN if needed before removal to avoid
On 2024-03-02 17:48, Hubert Tournier wrote:
On Thu, 29 Feb 2024 19:26:23 UTC, Xin LI wrote:
For example, one of my port gets marked as DEPRECATED because a dependency
was deprecated and scheduled for removal after 1 month, without any email
telling me so (the port doesn't have a lot of releases
On Thu, 29 Feb 2024 19:26:23 UTC, Xin LI wrote:
For example, one of my port gets marked as DEPRECATED because a dependency
was deprecated and scheduled for removal after 1 month, without any email
telling me so (the port doesn't have a lot of releases and there isn't any
release during that "par
On Thu, 29 Feb 2024 09:43:38 -0800
Cy Schubert wrote:
> In message <864jdrzcov@ltc.des.dev>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?
> = w
> rites:
> > Florian Smeets writes:
> > > Ports can be removed immediately if one of the following conditions is me=
> > t:
> > >
> > > - Upstream distfile i
On 29/02/2024 20:26, Xin LI wrote:
[...]
Could you please explain why upstream WWW would warrant a removal? (I
think removing the WWW= entry if the website is compromised or is no
longer available is perfectly fine, but why remove the port itself?)
- BROKEN for more than 6 months
I th
On Wed, Feb 28, 2024 at 11:22 AM Florian Smeets wrote:
> Dear ports community,
>
> as the removal of ports is a recurring source of friction and dispute we
> would like to add a ports removal and deprecation policy to the porters
> handbook.
>
> We tried to find a sensible middle ground between t
In message <864jdrzcov@ltc.des.dev>, =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?
= w
rites:
> Florian Smeets writes:
> > Ports can be removed immediately if one of the following conditions is me=
> t:
> >
> > - Upstream distfile is no longer available from the original
> > source/mirror (Our and oth
Florian Smeets writes:
> Ports can be removed immediately if one of the following conditions is met:
>
> - Upstream distfile is no longer available from the original
> source/mirror (Our and other distcaches e.g. Debian, Gentoo, etc do
> not count as "available")
Strong disagree, give the mai
On Wed, Feb 28, 2024 at 2:31 PM Aryeh Friedman wrote:
>
> On Wed, Feb 28, 2024 at 2:22 PM Florian Smeets wrote:
> > - The port does not adapt to infrastructure changes (i.e. USE_STAGE,
> > MANPREFIX, compiler updates, etc.) within 6 months. Ports should be set
> > to DEPRECATED after 3 months and
On 2/28/24 14:38, Chris wrote:
On 2024-02-28 12:13, Florian Smeets wrote:
On 28.02.24 21:00, Miroslav Lachman wrote:
On 28/02/2024 20:22, Florian Smeets wrote:
Ports can be removed immediately if one of the following conditions
is met:
- Upstream distfile is no longer available from the ori
On 2/28/24 12:22, Florian Smeets wrote:
Dear ports community,
as the removal of ports is a recurring source of friction and dispute we
would like to add a ports removal and deprecation policy to the porters
handbook.
If it is clear that guidelines could be interrupted/altered as
discussio
Florian Smeets wrote:
On 28.02.24 22:09, Charlie Li wrote:
Florian Smeets wrote:
This policy should give some guidance on when ports can or should be
removed. In general ports should not be removed without reason but if
a port blocks progress it should be deprecated and subsequently
removed.
On 2/28/24 12:22, Florian Smeets wrote:
Dear ports community,
as the removal of ports is a recurring source of friction and dispute we
would like to add a ports removal and deprecation policy to the porters
handbook.
We tried to find a sensible middle ground between too fast removal and
kee
On 28.02.24 22:18, Michael Gmelin wrote:
On 28. Feb 2024, at 20:22, Florian Smeets wrote:
Hi Flo,
Thanks for the effort, it’s a delicate topic for many.
It is, we're tying our best and put some thought into it in the last
coupe of weeks.
Ports can be removed immediately if one of t
On 2024-02-28 12:13, Florian Smeets wrote:
On 28.02.24 21:00, Miroslav Lachman wrote:
On 28/02/2024 20:22, Florian Smeets wrote:
Ports can be removed immediately if one of the following conditions is
met:
- Upstream distfile is no longer available from the original source/mirror
(Our and ot
On 2024-02-28 11:22, Florian Smeets wrote:
Dear ports community,
as the removal of ports is a recurring source of friction and dispute we
would
like to add a ports removal and deprecation policy to the porters handbook.
We tried to find a sensible middle ground between too fast removal and
k
On 28.02.24 22:09, Charlie Li wrote:
Florian Smeets wrote:
This policy should give some guidance on when ports can or should be
removed. In general ports should not be removed without reason but if
a port blocks progress it should be deprecated and subsequently
removed. In general, if a ports
> On 28. Feb 2024, at 20:22, Florian Smeets wrote:
>
> Dear ports community,
>
> as the removal of ports is a recurring source of friction and dispute we
> would like to add a ports removal and deprecation policy to the porters
> handbook.
>
> We tried to find a sensible middle ground bet
Florian Smeets wrote:
This policy should give some guidance on when ports can or should be
removed. In general ports should not be removed without reason but if a
port blocks progress it should be deprecated and subsequently removed.
In general, if a ports blocks progress for some time it will
On 28.02.24 21:00, Miroslav Lachman wrote:
On 28/02/2024 20:22, Florian Smeets wrote:
Ports can be removed immediately if one of the following conditions is
met:
- Upstream distfile is no longer available from the original
source/mirror (Our and other distcaches e.g. Debian, Gentoo, etc do
On 28/02/2024 20:22, Florian Smeets wrote:
Ports can be removed immediately if one of the following conditions is met:
- Upstream distfile is no longer available from the original
source/mirror (Our and other distcaches e.g. Debian, Gentoo, etc do not
count as "available")
I miss some sort
On Wed, Feb 28, 2024 at 2:22 PM Florian Smeets wrote:
> - The port does not adapt to infrastructure changes (i.e. USE_STAGE,
> MANPREFIX, compiler updates, etc.) within 6 months. Ports should be set
> to DEPRECATED after 3 months and can be removed after 6
Does this include special cases such as
Dear ports community,
as the removal of ports is a recurring source of friction and dispute we
would like to add a ports removal and deprecation policy to the porters
handbook.
We tried to find a sensible middle ground between too fast removal and
keeping unmaintained and abandoned upstream
54 matches
Mail list logo
