On Thu, 4 Mar 2021 at 16:21, Kevin Fenzi <kevin@xxxxxxxxx> wrote:
On Thu, Mar 04, 2021 at 06:56:24AM -0500, Stephen John Smoogen wrote:
> I think we are all using different short hand definitions of what we want
> to happen and are seeing each other skip steps because of that. I am very
> guilty of this when saying what could happen in this scenario. The
> following is more detailed but still skips steps
>
> 1. Get a list of all packages which are branched for past EPEL releases.
> 2. Get a list of all 'active' packages in the latest Fedora active release
> (aka F33 if I were doing this today) versus prerelease where packages may
> still get orphaned dropped before final.
> 3. Compare the lists and filter out the ones remaining
So this list would be the overlap of 'was in past EPEL' and 'is in
current Fedora'? But that still doesn't cover all the cases. Take
'Terminal' (The Xfce terminal back in the day). It finally got renamed
'xfce4-terminal' upstream. This wouldn't show up in these lists. It
would take someone who knew that it was renamed/replaced to add it, no?
I think you kind of ate what was my context for writing all this which was Petr's going from a shorter list and thinking that the forks would need to be from the already EL8 packages. It would actually need to be a much larger list and I wanted to cover all the steps I could think of to see what would be needed. [Whether or not mass-branching makes sense.]
> 4. Fork all those packages to a 'project' space so we don't pollute
> mainline.
> 5. Use a script on all the spec files to see what buildrequires/requires
> are needed on those packages.
> 6. Compare to existing pool of packages in ELN+already forked packages
> 7. Add forks of all the extra packages.
> 8. I would then probably rebuild all these in Copr or private system to get
> build order and find yet more 'missing' packages.
> 9. Put in fixes to spec files into the forks to make it work.
> 10. Put in a list for packages to be branched for 'ELN'
> 11. Keep up with 'active' package so your fork work is kept in line.
> 12. Do proper branch requests for the packages for 'ELN'
> 13. Merge Request Madness time
> 14. Start building in the real build system and find/fix problems missed in
> COPR private builds.
> 15. ...
> 16. Profit
You are describing... package maintainers. :)
In any case, I'm not convinced mass branching is ever going to work for
epel. Although I suppose as more packages have the epel packager sig
After looking at the steps above, I agree. There are already too few active maintainers in Fedora who are having to handle way too many packages just for rawhide, F-N+1, F-N, and F-N-1. Adding in a burden of reports/messages/failed-builds to active maintainers for branches they don't care about will likely make the number of active maintainers 'less'.
group on them, that group could work on faster adding piles of packages.
Perhaps we should try and identify all the 'please branch for epel'
requests in bugzilla and have some way for the epel packager sig to step
in and get those added?
kevin
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 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/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
--
Stephen J Smoogen.
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to 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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
