I think it makes sense to treat this similar to other cases, i.e. treating "new" packages as "not actually new" in case of compat packages or package splits etc.

I agree with @decathorpe there.

Agreed, I'm +1 for allowing this. Should we approve this directly and also clarify our guidelines to make explicit that in case of package splits, the new package is also allowed to use deprecated functionalities the old package is eligible for?

There are multiple places where things like this are currently documented ...

• legal docs (for CC0-1.0 "grandfathering" exception for existing packages),
• Package Review Guidelines (for "compat packages or EPEL-only packages don't need to go through package review),
• probably some other places too.

I propose that we add documentation that says something like the following:

Guidelines and Rules that specifically apply to new packages are not intended to cover packages that are "new" only in the sense that the source package name is "new" but the project is already packaged for Fedora, unless explicitly stated otherwise:

• Renaming an existing package.
• Splitting a subcomponent from an existing package into a separate source package.
• Adding a "compat package" for an alternative versions of an existing package.
• Adding an EPEL-only alternative version of an existing package.

Not sure where this should be documented, maybe on Package Review Guidelines?

+1 to allow this for php-pecl-pspell now.

I also agree with the guideline change, but we need to prepare a draft with the changes.

I'm +1 to both also, but as far a location, perhaps this should just be a fesco policy page and have a link to that from the review guidelines?

+1 to both from me.

I'm +1 to both also, but as far a location, perhaps this should just be a fesco policy page and have a link to that from the review guidelines?

FWIW I'm also +1 to the exception here.

If I should draft a Guideline / Docs change for this, where should this live? Currently package review exceptions / exemptions are documented in packaging-guidelines / Package Review Guidelines, so I suggested adding it there. Not sure if this is a fesco-docs thing ...

I'm +1 to both also, but as far a location, perhaps this should just be a fesco policy page and have a link to that from the review guidelines?

FWIW I'm also +1 to the exception here.

If I should draft a Guideline / Docs change for this, where should this live? Currently package review exceptions / exemptions are documented in packaging-guidelines / Package Review Guidelines, so I suggested adding it there. Not sure if this is a fesco-docs thing ...

yeah, want to take it to FPC once there is a PR? Seems to me it should be added to both
https://docs.fedoraproject.org/en-US/packaging-guidelines/deprecating-packages/ and the review guidelines

We can discuss where to document further in the meeting tomorrow - I guess I'm marking this both meeting and also:

APPROVED (+5, 0, -0)

Let's not close this until we document things.

Looks like there is some opportunity to de-duplicate documentation and update it:

• https://docs.fedoraproject.org/en-US/fesco/Package_review_policy/
• https://docs.fedoraproject.org/en-US/packaging-guidelines/ReviewGuidelines/
• https://docs.fedoraproject.org/en-US/package-maintainers/Package_Review_Process/

Will ponder what to update and where.

I opened a PR against the Packaging Guidelines:
https://pagure.io/packaging-committee/pull-request/1458

https://pagure.io/packaging-committee/pull-request/1458 was merged, we can close the ticket.