Approval of pull requests

[ghost]

@Eloston I've noticed that even very basic pull requests can take upwards of a week or longer to get accepted at times. I expect this varies with how busy you are with other things.

As it stands these delays can cause delays with deployment of security patches as I often have to wait for this upstream repository to update before I can push out new builds to my PPAs.

I think it would help greatly if we had additional trusted users that could approve relatively minor pull requests such as minor version bumps within the same major series. What do you think of this idea?

[PF4Public]

You may use a commit id from a pull request.

See my ebuild for gentoo for example.

[ghost]

That doesn't really help for updating the official packaging repositories for debian and such though. It requires the commits to already be in this repository AFAIK.

[jstkdng]

I manually patch ungoogled-chromium's tarball with the PR's patches whenever something important comes up. But yeah, ungoogled-chromium suffers from the bus factor, that has to be fixed.

[Eloston]

This is not a bad idea. I think GitHub now has a way to let other users approve PRs and manage issues without having write access.

I also want to grant some people write access at some point in the future, so this might help me figure that out.

EDIT: I will check GitHub to see if what I want is possible, then I'll choose some people based on their contribution history.

[Eloston]

Hmm I think I'll have to move this repo to ungoogled-software to allow people to triage issues. People can already review PRs; in fact I just recalled it's stated in docs/contributing.md

But after re-reading, did you mean you want people to approve and merge small changes? In that case, I think we can setup GitHub Actions to check if the PR is "small", and then perform the merge if it's approved by a trusted set of users (people that I trust based on contribution history).

[ghost]

Yes at the very least it seemed like a good place to start. Maybe eventually some people can have full access like yourself. As for automating detection for small changes how would that be defined? I would think small changes would be things like:

• Any changes to .md files or other files that do not effect any actual code execution
• Any changes to patch files that only change the offset lines and nothing else
• Any changes to the revision number
• Changes to the Chromium revision number that only change the last set of digits
• Any other changes necessary to perform a minor version bump

[Eloston]

As for automating detection for small changes how would that be defined? I would think small changes would be things like:

Yeah that is a bit challenging to define. However, I think what you listed out is pretty comprehensive. To extend a bit more on them:

Any changes to .md files or other files that do not effect any actual code execution Any changes to patch files that only change the offset lines and nothing else

I think we can do better than that:

• For both Markdown and patches, compute a similarity score between the changed lines. If it's too different, then we could abort auto-merging.
  • This algorithm may also be able to check for new or removed lines too. If the sum of total added lines with total removed lines exceeds a threshold, then we can abort auto-merging.
  • I don't know much about similarity metrics out there, but I know there are diffing algorithms in mdoern IDEs and such that can determine changed, added, and removed lines. It's not perfect, but it does a good enough job.
• For patch files, we'd only consider the actual lines added and removed; not context lines, hunk headers, or file headers. But, we should consider comment lines (i.e. all lines that are ignored by GNU patch in the patch file)

Any changes to the revision number

I'm guessing you also want to include minor Chromium updates, not just to ungoogled-chromium's revision number.

We'd also want all CI checks to pass before we auto-merge too. Which means we should re-evaluate the entire PR every time the contributor makes a push.

In addition, we should support this for platform repos as well. Also, with some different restrictions, I think we can support ungoogled-chromium-binaries.

Now if we automatically generated PRs for new Chromium versions... but, one step at a time :)

[ghost]

Eventually being able to dispatch builds in the downstream repositories to a build server would be nice as well. The PPA I setup is mostly a stop gap and unfortunately a service like OBS only really supports the Linux based setups. Incidently though I recall that Linux can cross-compile for Windows but I do not know if Chromium supports being cross-compiled.

[ghost]

Small update. I was given write permissions to the Debian repository so this part is addressed. But there's still other repositories we could use some trusted maintainers for or another solution.

[Eloston]

But there's still other repositories we could use some trusted maintainers for or another solution.

I agree. For anyone reading this: If you've been making contributions to a platform repo and would like to become a maintainer for that repo, let me know.

[PF4Public]

I hope we are in a much better position with respect to pull requests for some time now. Closing this issue for now.