Re: Removing playground from package.cfg files

[Troy Dawson <tdawson@xxxxxxxxxx>]

On Fri, Jan 28, 2022 at 7:28 AM Troy Dawson <tdawson@xxxxxxxxxx> wrote:

On Fri, Jan 28, 2022 at 12:01 AM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:

On 28. 01. 22 3:37, Troy Dawson wrote:
>
>
> On Wed, Jan 26, 2022 at 7:54 AM Troy Dawson <tdawson@xxxxxxxxxx
> <mailto:tdawson@xxxxxxxxxx>> wrote:
>
>
>
>     On Wed, Jan 26, 2022 at 7:37 AM Miro Hrončok <mhroncok@xxxxxxxxxx
>     <mailto:mhroncok@xxxxxxxxxx>> wrote:
>
>         On 26. 01. 22 16:30, Troy Dawson wrote:
>          > EPEL 8 Playground is going away.
>          > One of the steps in that process [1] is to clean out playground from
>         all the
>          > various package.cfg files.
>          > I will not be removing the package.cfg files.  I will only remove
>          > epel8-playground entry if it is there.  If you, as a package
>         maintainer, want
>          > to remove the package.cfg file, you are free to do so.
>          > I have seen too many package.cfg files that have been modified, and
>         I do not
>          > feel safe globally removing them.
>          >
>          > Note: I will be checking the epel8, epel9, rawhide and f35 branches for
>          > package.cfg files.
>          >
>          > This will be happening later today.  Let me know if you have any
>         concerns
>          > and/or comments.
>
>         Hey Troy. Could you please share the list for inspection before actually
>         changing anything?
>
>
>     I can, and will.  Good idea.
>     It will be a couple hours before I have that list.
>     Troy
>
>
> That took longer than expected.  Sorry about that.
> I know I said that I was only going to take the epel8-playground out of the
> files, but it turned out that there were so many that only have the default
> package.cfg that we put in, that I feel we should take all those default files out.
> There was three groups.
>
> ** A - Custom package.cfg
> * I will only remove epel8-playground
> argbash (custom) rawhide f35
> nss-mdns (custom) f35
> RBTools (custom) rawhide f35
>
> ** B - Default epel8 package.cfg - in Rawhide and F35
> * I am going to remove the package.cfg from rawhide and f35
> beanstalk-client (default) rawhide f35
> copr-selinux (default) rawhide f35
> czmq (default) rawhide f35
> fctxpd (default) rawhide f35
> gedit-plugin-editorconfig (default) f35
> glances (default) rawhide f35
> gnome-doc-utils (default) rawhide f35
> libwebsockets (default) rawhide f35
> MUMPS (default) f35
> netcdf4-python (default) rawhide f35
> opentrep (default) rawhide f35
> python-astroid (default) rawhide f35
> python-cftime (default) rawhide f35
> python-kubernetes (default) rawhide f35
> python-lazy-object-proxy (default) rawhide f35
> python-multidict (default) rawhide f35
> python-repoze-tm2 (default) rawhide f35
> python-repoze-who (default) rawhide f35
> python-transaction (default) rawhide f35
> R (default) f35
> sagator (default) f35
> TurboGears2 (default) rawhide f35
>
> ...
>
> Let me know if anyone disagrees with my plan.

Thank You!

Looking for example at python-astroid where your plan is to remove it from f35
and rawhide but not from f34.

The f35 and rawhide branches are not in sync but f35 is "reachable" from
rawhide history. Do we really need to diverge f35 just to remove a file that we
are OK keeping on f34?

Looking at python-astroid in Koji:
https://koji.fedoraproject.org/koji/packageinfo?packageID=16809

It doesn't seem this was submitted regularly for many targets. The file has:

   [koji]
   targets = epel8 epel8-playground

Yet when I run `fedpkg build` on rawhide, it only submits a build for rawhide.
Similarly on f35, it only submits a build for f35.

When I run `$ fedpkg --release=epel8 build` it submits 2 builds, so it indeed
does at least something. The dangerousnes of this is... minimal? Considering
the Koji target will be blocked.

Hence I propose to only remove the file from f35 if the branch has the same
HEAD as rawhide, but not to remove it otherwise to avoid git mess.

Similarly, I would also remove it from f34 in such case.

Very good point, and I agree with it.

For "B" packages I will do the following

If Rawhide, f35 and f34 are all in sync

- Remove package in rawhide, sync to f35 and f34

Else If Rawhide and f35 are in sync

- Remove package in rawhide, sync to f35

Else If Rawhide and f35 are NOT in sync

- Remove package in rawhide only

Else If package.cfg in F35 only

- Do nothing, because it is not in sync with rawhide.

For "A" packages, I will follow the above logic,

but instead of "remove package.cfg" I will

"remove epel8-playground from package.cfg"

For "C" packages, I will just "remove package.cfg"

No If's or Else's for the "C" packages.

For the sake of completeness, this is what I did for each package.
Note:  It is possible that I missed some, but I tried to be thorough.
Feel free to clean up your own package.cfg, or if you want, contact me and I'll clean it up.

** "A" Group
argbash - Not in sync - Updated in Rawhide only
nss-mdns - Not in sync - Already updated in Rawhide, do nothing
RBTools - Not in sync - Updated in Rawhide only

** "B" Group
beanstalk-client - Not in sync - Removed from Rawhide only
copr-selinux - Not in sync - Removed from Rawhide only
czmq - Not in sync - Removed from Rawhide only
fctxpd - Not in sync - Removed from Rawhide only
gedit-plugin-editorconfig - Not in sync - Already removed from Rawhide, do nothing
glances - Not in sync - Removed from Rawhide only
gnome-doc-utils - Not in sync - Removed from Rawhide only
libwebsockets - Not in sync - Removed from Rawhide only
MUMPS - Not in sync - Already removed from Rawhide, do nothing
netcdf4-python - Not in sync - Removed from Rawhide only
opentrep - Not in sync - Removed from Rawhide only
python-astroid - Not in sync - Removed from Rawhide only
python-cftime - Not in sync - Already removed from Rawhide, do nothing
python-kubernetes - Not in sync - Removed from Rawhide only
python-lazy-object-proxy - Not in sync - Removed from Rawhide only
python-multidict - Not in sync - Already removed from Rawhide, do nothing
python-repoze-tm2 - Not in sync - Removed from Rawhide only
python-repoze-who - Not in sync - Removed from Rawhide only
python-transaction - Not in sync - Removed from Rawhide only
R - Not in sync - Already removed from Rawhide, do nothing
sagator  - Not in sync - Already removed from Rawhide, do nothing
TurboGears2 - Not in sync - Removed from Rawhide only

** "C" Group

*Removed package.cfg from epel8 branch
adobe-source-han-sans-jp-fonts
ansible-lint
bats
bgpq3
bitlbee-discord
bloaty
bucardo
bullet
cabextract
calamaris
CharLS
cli11
conda
corectrl
dc3dd
dionaea
dist-git
fatresize
fsverity-utils
gnome-shell-extension-historymanager-prefix-search
gnome-shell-extension-topicons-plus
guacamole-server
levmar
libcec
libpri
llvm5.0
llvm6.0
mod_authnz_external
notcurses - also epel8-next and epel9 branches
openvpn-auth-ldap
perl-Carp-Assert
perl-Carp-Assert-More
perl-Data-Stream-Bulk
perl-Email-Valid
perl-Net-OpenSSH
powerman
python-aiomqtt
python-conda-package-handling
python-epson-projector
python-eventlet
python-f5-sdk
python-httpx
python-mongomock
python-pefile
python-QtPy
python-setuptools_scm_git_archive
python-sphinx_ansible_theme
python-wxpython4
Rex
tcl-tclreadline
thunar-archive-plugin
wob
xfce4-dict
xscreensaver
yubico-piv-tool

_______________________________________________
epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to epel-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure