A while ago I proposed code owners for the packaging files. We tried this but didn't work in our setup. It turns out that those mentioned as owners need permissions on the repository. In our case the packaging team (not individual members) has no permission.
There are 3 options:
1) Remove the file since it doesn't work
2) Create a packaging-core group with the intersection of both groups
3) Give @theforeman/packaging permissions on core
Personally I'd really like us to work together better and think this could reduce our packaging issues but have no preference between 2 or 3.
This could use some opinions. Right now we’re missing a notification system for packagers that these changed. A 4th option is to build some sort of notification system ourselves but I’d like to avoid that.
I’ll put in the obilgatory comment that this is a paid-for commercial service, with a free tier, so factor in considerations of what happens if they decide to remove the free tier later. Also note their terms of service explicitly permit sharing data with third-party organisations. I’m not a fan of that
Ping? If the current situation continues we might as well drop our nightlies since they’re broken and unusable anyway. There needs to be a dialogue between developers and packaging. Code owners may not not be the ideal or even correct solution, but I don’t hear any other suggestions.
Thanks for the warning. In my opinion core should trust the packaging team to do the right thing on the release branches.
If someone in packaging does not have commit access already because they’ve been an usual committer to core, I doubt they would merge anything in core, especially when not related to packaging issues (e.g - Gemfile changes, assets pipeline changes).
Generally I agree about point 2, but in any case my opinion is that much is to be gained by trusting ‘packagers’ to do TheRightThing*tm in core (mostly restricted to what I said in the previous paragraph) and a lot of time is to be lost by putting more barriers to that.
I agree with @dLobatog, and I’d also expect the reverse - that existing maintainers would notice if a packager goes too far, and take action. That could be a simple discussion about why a commit happened, all the way up to reverting the commit if needed. Git is a version control system, after all, we have all the history if we need it
To be honest, I think we’re taking this the wrong way. I think, commit access to foreman core should be justified by helping to maintain the codebase. I don’t want to have a loop-hole. I can only speak for myself, but the way I see it is the following: I have commit access to core, but don’t have commit access to packaging. And I think, that’s totally fine. I haven’t earned that right in foreman-packaging. This is not an issue of not trusting people (I do) or not needing help (we do), but contributors should get a proper review and people need to know the codebase and product well to make a proper review. I think commit permissions should be earned.
When releasing a plugin, one of my release todos is to send PRs to foreman-packaging to update the packages. Can’t we agree, that we only merge core PRs that have a corresponding packaging PR when needed? Ideally, a contributor would file the PR with the core PR. If that’s too much to ask, a maintainer can either help and file the PR or as someone from the packaging team for help. We don’t need any special permissions or loop-holes permissions for that.
Just my 2 cents. I hope, we find an easy solution for our issue. That is broken nightlies.
Thanks for bringing this up. It’s time for a short retrospective.
I had hoped that it would loop us into conversations that changed packaging files. It appears there’s no such granularity and you either follow the entire repository or none of it (modulo those PR’s you’re participating in).
My gut feeling is the that the question we need to answer is “How does a core developer know if something needs packaging changes?”. I believe we all want to do this better, so this isn’t a question of getting better communication, but rather how to know if such changes impact packaging.
Asking all core devs to understanding the packaging probably isn’t realistic - likewise, asking a packaging member to review every core PR isn’t either. Does this come down to more automated tests? Should we be building scratch packages for core PRs? (I know that will take a lot more Jenkins time, but I’m still trying to get us more slaves )