Policy on `obsolete` ports...

[Vadim-Valdis Yudaev]

Hi,

I thus restored JRuby in 2021 (two years later), which was deleted in 2019. The remote Portfile came in handy for me since I copied the trick for the j prefix from there.

I'm not sure if the port was being built correctly in 2019. But it would be helpful if the ports weren't removed just because they haven't been updated for too long years. I think sometimes even too old projects can be in demand, provided that they can be correctly built.

About the inactive permanent reference archive:

I don't think the maintainers will guess that this port could have existed before. It will be inconvenient to check the archive when creating a new port. I think that checking Trac before creating a new port should be recommended. If the port existed before, the maintainer can find the commit using Trac.

- Vadim-Valdis

> On Nov 20, 2021, at 01:02, Dave Allured - NOAA Affiliate via macports-dev <macports-dev at lists.macports.org> wrote:
> 
> Perry, you said "remove".  I would like to have obsolete ports moved to an inactive permanent reference archive, preferably somewhere in the ports code base, rather than permanently removed.  This would mainly be for possible resurrection at any time in the future.
> 
> I think your proposed rules are fine, except for the premise in #3.  You might never know how far out someone might find a reason to resurrect some old crufty thing.  I would say that a year is sufficient to move something from obsolete to graveyard.
> 
> 
> On Fri, Nov 19, 2021 at 2:05 PM Perry E. Metzger <perry at piermont.com> wrote:
> Howdy! As things stand, we don't explicitly say much in our rules about 
> whether people can remove obsolete ports after a year even without a 
> port maintainer's say-so. We also have circumstances where people leave 
> "maintainer" lines in ports that have been put into `obsolete`.
> 
> I'd like to propose the following rules:
> 
> 1. There must always be a comment in a `PortGroup obsolete` Portfile 
> stating the date on which the port can be removed. (Ideally we'd 
> actually have a keyword for this so tools could find it, but a comment 
> works for now.) In case there isn't a comment, the date of the commit is 
> used.
> 
> 2. Once something is `Portgroup obsolete`, it should no longer be 
> considered to have a maintainer. After all, there's no longer anything 
> being built or maintained. Thus, `maintainer` should be set to 
> `nomaintainer` for such files. If there's still a `maintainer` in an 
> `obsolete` port, that is an accident and can be ignored for purposes of 
> removing the port at the end of the one year timeout.
> 
> 3. Setting a port `obsolete` should be considered automatic consent to 
> remove it in one year's time, and there should be no question that a 
> year is a sufficient chance to think better of it and bring it back in 
> some form.
> 
> 4. If a subport is set `obsolete`, the usual rules about the maintainer 
> needing to consent to touching the Portfile should not apply for 
> removing said subport in a year, as the one year is (again) enough time 
> for them to think better on it.
> 
> Do people think these suggested rules are okay? Are there any objections?
> 
> Perry