Replies: 18 comments
-
|
@torsava @Conan-Kudo @hroncok @gordonmessmer @ignatenkobrain, opened this to avoid further polluting #1195 with this. The topic is not Python specific but the Python bits have an obviously active community around it so it's a good candidate for splitting, feel free to tag others into discussion if/when I missed people. |
Beta Was this translation helpful? Give feedback.
-
|
I think having them in one repository makes more sense to me because of sharing some code, knowledge and so on.... If there would be bunch of separate repos, you'd need to implement CI for each of them and so on. I think the best would be to get interested people aboard and move things like python dep generator, basic ones (metainfo, desktop) into the rpm-extras, define lifecycle, which RPM versions they should support, add all relevant people as maintainers, add some CI (can start with Python) and start doing releases for real. |
Beta Was this translation helpful? Give feedback.
-
|
Having separate CI is a feature I think - different languages will prefer different testing tools etc. |
Beta Was this translation helpful? Give feedback.
-
|
Well, nothing prevents you having extensive testsuite for python, rust and whatnot in one repo. |
Beta Was this translation helpful? Give feedback.
-
Bad maintainability? I think we need to have some sort of distro-wide SIGs that can own things. I will take Python as an example (and we can pyoneer (hehe) this with Python and see what breaks). The following steps need to be taken IMHO:
An as a matter of separate repo or not, I think it can work both ways. GitHub supports code owners and groups. We can make the Python things "owned" by the "RPM Python SIG" in this repo, or we can have a separate repo and make sure the distros know this (trough their "RPM Python SIG" representatives). |
Beta Was this translation helpful? Give feedback.
-
|
I can see some benefits of having some standalone domain-specific repos, like a repo for Python scripts. However, I think Python is one of the special cases, splitting out all the scripts would seem to me an overkill. And if we split only some and leave the rest in rpm, it's more mess than we started with. On the other hand, I don't really see the benefits of using rpm-extras. It has the problems of not being in the rpm repo with no benefits of the standalone repos. So overall, I acknowledge the problems, but to me the proposed cures are worse than the disease (to use a popular turn of phrase). |
Beta Was this translation helpful? Give feedback.
-
|
I know that Miro has expressed concerns about splitting language-specific tools into different repos because it tends to be more difficult to get those tools into broad use if they're separate releases. Perhaps separate git repos and a unified release are not mutually exclusive, though. What is rpm's release process like, today? If language-specific tools were split into separate git repos, could they be gathered into a single "rpm" release, either through the use of git submodules or other mechanism? |
Beta Was this translation helpful? Give feedback.
-
I believe that was Neal. |
Beta Was this translation helpful? Give feedback.
-
That's what I'm been mulling over here. Pulling stuff from multiple places does complicate release-cutting considerably though (which tends to be hard enough as it is), and will mean that bugs will get reported on rpm, but the code will be someplace else, which I suspect would be a frustrating situation for all involved. So I don't think that will work as such, but maybe there's something else in that direction. |
Beta Was this translation helpful? Give feedback.
-
I gotta say I'm sceptical that we'll find a better solution than keeping the scripts in rpm. However, the bugs being reported wrong could be solved by some more capable issue/bug-tracking software. For example a Bugzilla, where a bug can be easily reassigned to a different component (say |
Beta Was this translation helpful? Give feedback.
-
GitHub can do this as well (it's a beta feature). |
Beta Was this translation helpful? Give feedback.
-
|
The ongoing discussion in #1195 points out yet another reason for doing this: people will want to use native language tools for their language-specific scripts. This is perfectly understandable, but impossible from our maintenance point of view. This topic keeps coming up in different forms so much that I'm simply sick of it, which does grave injustice to people wanting to contribute to their interest areas. So after further talks with @ffesti, the decision is this: we can't remove stuff from 4.16 at this point so we'll merge what we must there, but in 4.17 all these language-specific scripts will be pushed out to other repositories. Like @hroncok mentioned, Python will make for an excellent pioneer in this as there's an active and largish community around it, I'd suggest we start with that: we'll make a repo under rpm-software-management umbrella, and put the macros and generators there. We'll be branching off 4.16 by the end of this week, after that we can proceed. And if in a few years time this turns out to be an absolute disaster, we can always just merge things back. |
Beta Was this translation helpful? Give feedback.
-
|
To make these things discoverable, they should have a common naming scheme. I'd suggest rpm-extras-foo with the idea that things that have an active community around them will have their own repositories, and those that don't will go to rpm-extras. And yes this will require finally doing some integration with rpm-extras too. |
Beta Was this translation helpful? Give feedback.
-
|
And are you planning to include the relevant scripts from these different repos into the releases of rpm? |
Beta Was this translation helpful? Give feedback.
-
|
We've yet to figure out the actual logistics of this stuff, but I'd say quite unlikely as it would lead to people reporting issues and rfe's on them back to rpm, which is contrary to the purpose. More likely we'd release tarballs of the different repos on ftp.rpm.org together or closely linked to actual rpm releases. At any rate, the concerns about people not finding these things have been noted, and it's in everybody's best interests to do everything we can that people will find them. |
Beta Was this translation helpful? Give feedback.
-
|
For the sake of cross-referencing, Python is in the progress of being split via #1607 now. |
Beta Was this translation helpful? Give feedback.
-
|
As per the original posting, this actually belongs in discussions. And separate tickets for each split-off piece. |
Beta Was this translation helpful? Give feedback.
-
|
The Perl stuff is being tracked here: #2873 |
Beta Was this translation helpful? Give feedback.
-
The subject has been polluting numerous PR's lately, better to have this discussion separately:
We've been on this road for a long time now, starting from rpm 4.9 introducing the "new" drop-in dependency generator enabling generators to live at the source instead of forcing them into rpm. More recently we removed various perl and python macros from rpm in 4.15. What remains is splitting the remaining language specific generators out of rpm (perl, python, ocaml at least), as we firmly believe that these are better served by respective SIGs rather than rpm maintainers who are not familiar with all these languages. Optimally these would live in repositories of their own with their own stewardships, or lacking sufficient community, rpm-extras.
The concerns around splitting to separate repositories relate mostly to users (distros and otherwise) not discovering said repositories. There must be some things that rpm could do to help with that. Starting with the obvious, documentation and links to known repositories, but other ideas are welcome.
Beta Was this translation helpful? Give feedback.
All reactions