Re: Removing playground from package.cfg files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
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




[Index of Archives]     [Fedora Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Announce]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Linux Apps]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux