Github Working Group

This wiki page has all the pointers you'll need to participate in the Github working group. This working group has two main tasks (but many minor ones related)

  1. To improve scripting around pull requests
    1. Make them easier to land
    2. Make them easier to verify
    3. Make them easier to test
  2. Improved github experience
    1. Provide as much automated feedback as possible
    2. Templates for pull requests to get more information
    3. Actions and other means to provide feedback on the pull request itself
    4. Actions or other means to improve "state tracking" of the pull request

Where to Find Us

We'll be using the freebsd-git mailing list for announcements and longer, more in-depth discussions. We'll be using the #github-hacking channel on the project's Discord Server to deal with the day to day stuff.

Identified Tasks

Bugzilla Tooling

BZ Landing Script

It would be nice if there was a one-stop-shop command to use to land bugzilla items with patches.

One problem in doing this, however, is that there's several different patch formats. Ideal format is git format-patch, which just works with git am. However, there's also the simple git diff patch, which will have a commit message and author, but git am won't work on them (but git apply will if you strip off the status information from bugz attachment that's bogusly going to stdout instead of stderr). Then there's the raw diffs, and there's no hope there, except to try to harvest author information from the account submitting the bug.

So that's one problem.

Next problem is that even if you have good author data, etc, there's no 'Trailers' added for "PR: 1234" or "Reviewed by: $FreeBSD_User_Name". Those should either be added, or we have a separate script that copes.

So the task is either to create a new bz src_commit to apply the patch, regardless of type, create a good commit message as best one can, add the right author and/or trailers.

BZ Reflection to Github

One idea, to make the patches more accessible and easier to review, would be to create a FreeBSD fork (not the default one) that people could pull from. This fork would be populated with all (?) the PRs that apply to the main branch. Then developers (and CI automation) could pull the branches for review and testing. This is similar to the prior item, and likely can share a lot of the tooling, but need not be as refined. For example, if the patch isn't a git format-patch format, then we could just commit the bug description as the commit message, using the reporter as the 'author'. This isn't perfect, but having due diligence steps in the 'landing' process could make it suffice.

We could re-run the script weekly to make sure things still apply.

It would also be nice if there were ways to say "This applied cleanly and is in $URL" or "This has stopped applying cleanly as of $HASH" (and don't try anymore, but also don't delete the branch, since a rebase may do the trick). Even better would be "This successfully did a make tinderbox" after the first application. Etc. There's much that can be done here.

Github Action Tooling

Commit message checker

We should create something that checks the commit message for faults. Currently, checkstyle9.pl does this, but it's super imperfect.

Having an action that would check the commit messages to make sure they have a title, have not-too-long lines, etc would be a huge win.

Pull Request Landing Automation Scripts

We have a rag-tag collection of partial scripts that make things tolerable. However, it would be nice if we can batch the pull requests, if we could do some testing and if we could make the whole thing less tedious and error prone. We can stage commits, and push them. We can't see what PRs are stage, easily de-stage one, recover from not having permission to push to the github repo, merge conflicts, etc. It's up and limping and barely adequate for a power user to get things done, let alone an occasional user.

Code!

Coming soon: github repo for all our code

Next Meeting

TBD. Join us on discord to help us figure out when to meet and how.

Warner's BSDCan 2024 talk

Just slides are available right now.


CategoryProject

WorkingGroup/Github (last edited 2024-09-22T03:47:03+0000 by MarkLinimon)