Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: splitting language specifics out of rpm core (#1199)
> For example a Bugzilla, where a bug can be easily reassigned to a different > component . GitHub can do this as well (it's a beta feature). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1199#issuecomment-623425055___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: splitting language specifics out of rpm core (#1199)
> 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. 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 `scripts/pythondistdeps`) that is administered by a different group of people. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1199#issuecomment-623424253___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: splitting language specifics out of rpm core (#1199)
> Perhaps separate git repos and a unified release are not mutually exclusive, > though. 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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1199#issuecomment-621078194___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: splitting language specifics out of rpm core (#1199)
> 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. I believe that was Neal. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1199#issuecomment-620766530___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: splitting language specifics out of rpm core (#1199)
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? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1199#issuecomment-620655997___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: splitting language specifics out of rpm core (#1199)
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). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1199#issuecomment-620630859___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: splitting language specifics out of rpm core (#1199)
> Well, nothing prevents you having extensive testsuite for python, rust and > whatnot in one repo. 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: 1. reach out to known distros that use RPM, ask for relevant representatives of their Python RPM ecosystem 2. collect the representatives of interested distros to an informal "RPM Python SIG" 3. have this discussion with them (e.g. currently it is Fedora people talking to Fedora people) -- 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). -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1199#issuecomment-620527744___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: splitting language specifics out of rpm core (#1199)
Well, nothing prevents you having extensive testsuite for python, rust and whatnot in one repo. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1199#issuecomment-620515978___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: splitting language specifics out of rpm core (#1199)
Having separate CI is a feature I think - different languages will prefer different testing tools etc. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1199#issuecomment-620509698___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: splitting language specifics out of rpm core (#1199)
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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1199#issuecomment-620506549___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Discussion: splitting language specifics out of rpm core (#1199)
@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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1199#issuecomment-620500164___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Discussion: splitting language specifics out of rpm core (#1199)
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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1199___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
