I realize I'm jumping in the middle of this conversation, but I would be in favour of someone peer-reviewing the code instead of allowing just anyone to git push code into Freenet. Yes, it may slow down production, but it's important to remember end-user security as well.
Allowing just anyone to push releases is basically asking for saboteurs. The project should enforce some good coding standards, like well commented code requirements. In the event the code is all jumbled up, rejecting the code may be better than allowing it to flow through. Poul-Henning Kamp made this humorous, but informative, presentation in 2014 that covers software "bugs" as well. https://www.youtube.com/watch?v=fwcl17Q0bpk On 03/29/2015 08:29 AM, Bert Massop wrote: > In short: I'm in favor of squashing when done in a sensible and > information-preserving way. > > On 28-03-15 17:13, Arne Babenhauserheide wrote: >> >> I agree with Bombe that it’s not nice to lose the history, but with >> git that’s the best we can do. It’s a limitation of the tool. >> >> […] >> >> ¹: The evolve extension of Mercurial has the concepts of hidden >> changesets with rewrite-markers, so the history which is shown by >> default is clean, but you can always inquire how it came into >> being. > > This is an interesting observation. There appears to be a certain > hierarchy to which history can be considered useful for a particular > purpose. IMHO rewriting / losing history is only a bad thing if the > history actually serves a purpose: this depends on who will be using the > log in the future, and for what purpose. > > I really don't care about anyone's "Oops, fix XYZ" or "Also fix XYZ at > ABC" commits (and nor should any other developer or reviewer) as long as > the relevant code has not yet surfaced. Yes, this provides information > as to how the code was originally created, but it serves no purpose in > understanding, reviewing or maintaining the code. > > I consider this kind of commits *noise* if they end up in the master > tree (or in the initial commit set of a pull request), though they may > be useful in my own branch during development (e.g. I can revert more > granularly, read my work log, etc.). (FYI: I consider myself a noisy > committer, too.) A pull request may require such commits to be added to > the publicly known code, at that point they do add information — up to > the point where the pull request is merged, from then on they no longer > serve a purpose. > > One use case I have in mind that illustrates the above is finding the > *intended purpose* of a single piece of code, e.g. through `git blame': > having to browse through a list of fixup-type commits doesn't help and > can easily be avoided by sensible squashing. I usually don't care if > that line was *changed* (before merge, that is!) to fix something, I > just want to know why that line is there at all. > > In the same way, commits in the initial commit set of a pull request > (and their messages) may be useful during the review process to get a > better understanding of the code. If this is indeed the case, it is > likely that this information will also be relevant to future readers of > the code, and squashing should be done sparingly. > > Squashing entire pull requests into single commits just for the sake of > reducing history verbosity does not make sense — only view merge commits > if you're simply bothered by the verbosity. > > However, squashing and/or reordering a whole lot of (fixup) commits into > one or more semantically correct commits allows the author to > re-describe his development process in a way that actually conveys the > information he intends to convey. This is particularly useful for fixups > after discussion on a pull request: those in particular can easily break > the clarity of the commit log (after merge), although they do add > information during the review process. > > That said, only merge candidate branches should ever be squashed, > obviously before merging, and preferably to yet another branch. > Comparing both branches for equality is trivial, hence existing review > work is not invalidated. > > > So IMHO no, squashing (or history rewriting) is not evil, but it depends > on where, when and how it is applied whether it is good. Developing, > understanding, reviewing and maintaining the code all call for other > commit granularities — squash accoringly. > > -- Bert > > > > _______________________________________________ > Devl mailing list > Devl@freenetproject.org > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
