Liliana Marie Prikler <liliana.prik...@gmail.com> writes:
> Hi, > > Am Sonntag, dem 27.08.2023 um 16:57 +0300 schrieb Saku Laesvuori: >> > > >> > not sure how most people consume their emails nowadays, but for me >> > it's one flat list per thread, in a browser (i.e. it's not a tree). >> >> The point is that the emails contain the information on how to >> construct a tree out of them. It's just that most web clients (which >> most people are unfortunately using nowadays) are so bad that they >> render the tree as a flat list. > Not sure about "most", but Guix folk are definitely biased towards > dedicated mail clients (terminal, graphical, Emacs…), so perhaps my own > perception was a little off in that people will always benefit from > having the tree. Then again, you can share your email between multiple > clients, which isn't that easy to do with code repositories sadly. > > Of course, you can mirror the repo, but your bug trackers aren't that > easily mirrored. > >> >> > and all i'm trying to achieve here is to move the discussion away >> > from email-is-superior-period, to look at what requiremenets we >> > have and what tools satisfy them, if any. >> >> I think that is a good discussion to have, but I think it would be >> better to describe some of the requirements you think we should >> consider instead of just saying email isn't superior. It might not >> be, but it might also be. We should consider what we need and >> evaluate the available tools based on that, and if the result is that >> email is the best then it is. > Not needing to register yet another account for one-off contributions > is an argument that kills all the forges, sadly :) > With Sourcehut you can contribute without an account. There is also https://forgefed.org/ which is for federated forges using activitypub. So you can have one account for all forges that federate. :D MSavoritias >> > > at the ChatGPT-related stuff that has been submitted). There >> > > sadly is no pleasing everyone here and unless these tools are >> > > incredibly simple to maintain, the utilitarian approach of least >> > > misery leads you to plain email. >> > >> > but is a least-misery model appropriate here? how do you even >> > account for the contributions that could have happened in a >> > different environment, but did not happen? >> > >> > similarly, e.g. demanding a dated ChangeLog format for commit >> > messages has a filtering effect on who will contribute, and then >> > who will stick around. most engineers have a hard time jumping >> > through hoops that they find pointless (git automatically encodes >> > that information), and i'd suggest considering what the effect are >> > of such rules on Guix asan emergent order. >> >> I agree on the ChangeLogs being a weird thing to require in commit >> messages. I think of commit messages as the place where you record >> the reasons behind the change in the commit. The ChangeLog seems to >> just record the changes which the diff of the commit already >> automatically records more accurately. > First things first, I disagree with the framing here. Engineers do > pointless things all the time and both code style and commit message > style have near endless potential for bikeshedding (which we are > currently engaged in btw). There are like thirteen competing standards > on how to format C code and similar debates in other languages. In > fact, I'd go so far as to argue that a language ecosystem that has no > such debate is potentially lacking in diversity. > > A proper ChangeLog doesn't simply "record the changes the diff already > records more accurately". It adds semantics. For instance, when > bumping a package, we write the same line twice; once for the header, > once for the ChangeLog. What we don't write is that we also adjusted > the hash along with the version. Doing so would give us no new > information, but the diff includes it anyway, because diffs are stupid. > Humans writing (and reading) ChangeLogs aren't stupid and can rely on > contextual meta-information – however, the ChangeLog should still be > self-contained in the sense that it doesn't rely on other parts of the > message to infer the actual changes made. > >> If someone has use cases for the ChangeLog commits, I'd like to hear >> them. Maybe there is something that can't be achieved with git >> history without ChangeLogs, but I can't think of anything. Someone >> mentioned grepping the git log with them, but I think the same thing >> can be done with git log and git blame regardless of the commit >> message format. > In my humble opinion, you underestimate the benefits of not having to > invoke another command on a commit. For a great number of changes, the > ChangeLog style allows me to imagine the code that was written without > having to see it in a way that a simple diffstat just can't. Of > course, whether you use ChangeLog style commit messages, Emoji commits > or any other formatting guide is a political question between everyone > involved in a project, but there are benefits to having guidelines and > following them. > > It's similar to following generally accepted etiquette in any circle. > People will generally be happy as long as you follow them and can often > tolerate small deviations, but at a certain point it just becomes > uncomfortable, so we kindly ask you to follow the established > practices. > > Cheers
