On Fri, Jan 28, 2022 at 12:01 AM Miro Hrončok <[email protected]> wrote:

> On 28. 01. 22 3:37, Troy Dawson wrote:
> >
> >
> > On Wed, Jan 26, 2022 at 7:54 AM Troy Dawson <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> >
> >
> >     On Wed, Jan 26, 2022 at 7:37 AM Miro Hrončok <[email protected]
> >     <mailto:[email protected]>> 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.

Troy
_______________________________________________
epel-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
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/[email protected]
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Reply via email to