Closed bblfish closed 2 years ago
https://github.com/solid/specification/pull/319 is a proposal for the CG as a whole. It takes concerns raised here and elsewhere into account. I suggest that we (i.e., the panel) adopts what's agreed there.
I think we should close this issue in favor of https://github.com/solid/specification/pull/319 since it's more about a general process rather than something AuthZ specific.
The following argument put forward by @acoburn on gitter, October 8, 2021 6:49 PM is that it is easy to revert using.
> git revert <commit>
The same idea has found its way in the discussion on the PR. It is true that git revert is not problematic from the point of view of git, as it undoes a change by applying a new one undoing the previous one. The history of the previous changes therefore always remain available in the history. A URL pointing to the original precise version (the permalink) of the commit will continue to work.
BUT, this is no good for sensitive information that may have found its way into a commit for exactly those reasons. Because git revert
does not remove them from the history and the permalink to the original version will continue to work.
In order to actually remove sensitive information one has to change the history of the branch. There is a whole chapter in the git book on Rewriting History. This states right at the top that it is fine to make changes locally, because nobody is referring to your history, but it is a different story when you go public. Here is a warning about this from the git-rebase.io homepage:
A word of caution: changing the history of public, shared, or stable branches is generally advised against. Editing the history of feature branches and personal forks is fine, and editing commits that you haven't pushed yet is always okay. Use git push -f to force push your changes to a personal fork or feature branch after editing your commits.
If you rebase the main branch any change to the history is going to change the hashes of all commits, leading to potentially a lot of problems to anyone making changes to the branch and wanting to commit with the old history.
On Weekly Meetings
Details
For the whole of 2021 the panel Meeting Notes have been added as a Pull Request on a (temporary) branch, which could then be improved upon before pushing it in the next meeting to the
main
branch after a quick question to the group.@csarven unilaterally changed the process for the 2021-09-29 meeting minutes, giving a number of reasons. I take it that the essential reason is:
On the other hand, committing without review is going against a basic principle of version control: don't commit to
main
(akamaster
) without review. By pushing directly tomain
it may not be clear that the minutes have not been reviewed. It is established W3C policy to 1) automatically publish the minutes to a location that is well understood to be the non-edited, perhaps erroneous, attempt to capture the meeting notes. An example are these LDP IRC logs 2) in the meeting ask if there are any objections to publishing the minutes from the previous meeting, after they have gone through some formatting and other correction. The previous IRC logs show the group engaging in that by approving the minutes from 2015-06-15.These problems can be resolved by having a "draft-minutes" branch, that is never deleted and to which the the new minutes are first pushed. This has the advantages of:
Note: publishing to a "draft-minutes" branch is no more complicated than publishing to
main
, and clicking a "merge" button is something that can easily be done in each meeting.Acceptance criteria