Re: ELN SIG First Meeting

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

 



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?

> 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
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

Attachment: signature.asc
Description: PGP signature

_______________________________________________
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux