LWN: Comments on "Debian discusses Discourse"

Debian discusses Discourse

nix — Tue, 02 Jun 2020 13:10:49 +0000

It uses branches named after the complete ref of the branch being saved under, e.g. for the branch I'm working on now (named 'oracle/ctf-next'), the working tree's state is saved in a branch named 'refs/wip/wtree/refs/heads/oracle/ctf-next', and the index's state is saved as 'refs/wip/index/refs/heads/oracle/ctf-next'. The names are a bit long, but customizable, and unambiguous. The commit log comments have got more useful since I looked at them last and now say why the wip is happening and what file is being newly preserved.

Every time you commit, the corresponding wip branches are restarted: the old ones are still accessible until the reflog expires (this is clunky, but I can't really see a way around it). You end up with wip branch history like this:

193b21c09b (refs/wip/index/refs/heads/oracle/ctf-next) autosave ld/lexsup.c after stage
9848c17b26 autosave ld/lexsup.c after stage
23ccc37ffb autosave ld/ldlex.h after stage
9ece7ac0f3 autosave ld/ldlang.c after stage
4652ac99a8 autosave ld/ldlang.c after stage
c9a78b787f autosave ld/ld.texi after stage
2e0966c4e8 autosave ld/ld.h after stage
bfd20b8df2 start autosaving index
bfeee83394 fixup! libctf, ld: add --ctf-variables and omit variables from CTF by default
fbcdd02300 libctf: add ctf_link_set_variable_filter
...

(where bfeee83394 is the last commit on the real branch.)

or this, for a working tree:

436a729994 (refs/wip/wtree/refs/heads/oracle/ctf-next) autosave ld/ldlex.h before stage
662a4b4ee5 autosave ld/ldlang.c before stage
1c3b615c7d autosave ld/ld.texi before stage
1dccab233e autosave ld/ld.h before stage
5958b6cd68 autosave ld/lexsup.c after save
22bfa4bcfb autosave ld/lexsup.c after save
c744e6c41f autosave ld/lexsup.c after save
76c6a6e074 autosave ld/lexsup.c after save
caf21622cb autosave ld/lexsup.c after save
f7d813e9f5 autosave ld/lexsup.c after save
a486e6417e start autosaving worktree
bfeee83394 fixup! libctf, ld: add --ctf-variables and omit variables from CTF by default

Manual: https://magit.vc/manual/magit/Wip-Modes.html

Debian discusses Discourse

farnz — Thu, 21 May 2020 13:45:58 +0000

This is one of the things I like about Mercurial's Changeset Evolution feature - I can have a messy pile of commits while I'm working, and then have a clean pile for review that I've fixed up, but that maintains the links to my messy pile so that I can see how I got there.

Debian discusses Discourse

mathstuf — Thu, 21 May 2020 13:33:47 +0000

Using such functionality locally for backup purposes is fine, but I will judge if that branch goes for review :) .

Does it save commit history or is it a series of snapshots all sharing the same parent? Even better would be to reconstruct the history like Vim's (and probably Emacs') history tree too. If it's just a temporal snapshot history, a history viewer where you could collapse the nodes down by a time span would be nice.

Debian discusses Discourse

nix — Thu, 21 May 2020 12:45:49 +0000

The obvious extension is that every in-editor edit should end up as a new commit.

You think it's a joke, but this is what git-wip does, triggering a commit in a not-normally-visible ref on every save via editor hooks. Its only problem (other than an unavoidable complete lack of useful commit log, so you more or less have to do a log -p restricted by date to find stuff you want to recover) is that it's so transparent that I usually forget that it even exists, so I don't use its careful records of every save I did as often as I could. It's part of magit but also a separate project and I think there is a vi-hooking variant around too.

Debian discusses Discourse

jezuch — Wed, 06 May 2020 06:10:22 +0000

My suspicion is that the idea of external identity provider was alien and incomprehensible to managers who direct software teams, until Google and Facebook appeared and said "you can allow users to log in using their credentials on our sites". Then the managers thought "wow, such a great idea!" because they recognize these names and don't realize that the underlying mechanism is exactly the same regardless of the identity provider used.

To clarify, I mean the kind of managers who say that we don't have time for writing tests and refactoring. Which I think is most managers?

Debian discusses Discourse

wookey — Mon, 04 May 2020 17:54:55 +0000

It sucks enormously. How did that happen? OpenID was great, why did it get taken away?

I'm not telling either of those entities which sites I visit so have never used the 'log in with unpleasant entity' button. But the alternative is trusting each and every site (there must be hundreds by now) to take good care of my credentials. They do of course lose them on a regular basis. Quite why I'm not allowed to manage my own identity, I don't know.

Debian discusses Discourse

anselm — Mon, 04 May 2020 11:30:48 +0000

Writing niche software is visibly nothing the author is afraid of. Our community used to encourage that.

SQLite (written by the same person) started out as niche software and is now the most popular SQL implementation on the planet by a few orders of magnitude. A similar argument may be made for the Linux kernel.

Debian discusses Discourse

marcH — Fri, 01 May 2020 08:33:54 +0000

> And I'd argue that only the GitHub/GitLab style of development made rebase so popular.

Github absolutely not:
https://github.com/zephyrproject-rtos/zephyr/pull/14444#i...
https://github.com/isaacs/github/issues/959#issuecomment-...

Gitlab barely:
https://gitlab.com/gitlab-org/gitlab/issues/20339

Debian discusses Discourse

seneca6 — Fri, 01 May 2020 08:26:24 +0000

Fossil is a niche system, and the article in question starts with the line: "Fossil deliberately omits a "rebase" command because the original designer of Fossil (and original author of this article) considers rebase to be an anti-pattern to be avoided. This article attempts to explain that point of view." - this is a design decision for Fossil, why not call it "the author's itch"? He's not pushing code into Git to take away your rebase there.

> What next, removal of the "undo" feature in editors?

Given that the author once said in a podcast that he created an editor just for his own habits, it's possible :-) He also said that the editor would be rather useless for anyone else. Writing niche software is visibly nothing the author is afraid of. Our community used to encourage that. We're free to use it if we like, and not to use it if we don't like it, and still wish them well. Many others already are vocal enough and will never understand why one would want to use Replicant instead of Android, Linux instead of Mac OS, or emacs instead of VS Code. It's funny that this author of niche software happens to have written the most used database in the world.

> Considering millions of git users do and enjoy rewriting history on a daily basis (especially during code reviews but not just)

Well, if someone goes to the extent of creating a new version system, I very much hope it won't be just a clone of git's functionality with a different implementation. That would be just a waste of time.

We don't know when that article was originally written. But Fossil started in 2006, two years before GitHub! Rebase was very controversial back then. And I'd argue that only the GitHub/GitLab style of development made rebase so popular. By now, most Git users have adopted it and have learnt, sometimes with pain, where to use it and where not to use it. If others have kept their non-rebase workflow and are happy with it, why not.

Debian discusses Discourse

rschroev — Thu, 30 Apr 2020 22:46:21 +0000

If D. Richard Hipp, the author of the article and of Fossil (and of SQLite, for which I am very grateful and I respect him a lot) had explained why rebasing doesn't fit his workflow and why it doesn't match his view of version control, that would be no issue at all. A difference in opinion with a lot of people, sure, nothing wrong with that.

But the article uses a very different tone. It categorically states that nobody should use rebasing, ever. The title alone is a hint to that; in the conclusion the author makes it abundantly clear: "Rebasing is an anti-pattern. It is dishonest. It deliberately omits historical information. It causes problems for collaboration. And it has no offsetting benefits."

I think dunlapg's reaction to that is a bit excessive, but I can understand where he comes from. When so many people successfully use rebasing workflows, is it smart of Hipp to think he knows better than all of them and reject their workflow? He's undoubtedly an intelligent man, but so are many of the people who do use rebase.

Debian discusses Discourse

marcH — Thu, 30 Apr 2020 19:12:43 +0000

> > Unfortunately the author doesn't understand review-based workflows;

> Isn't Free Software supposed to be allowed to scratch the author's itch instead of solving all of the world's problems? Especially a niche system, which Fossil certainly is compared to Git, Mercurial, or maybe even SVN.

Fossil's rebaseharm.md stance is absolutely not about a "niche" or just the "author's itch". Did you read it? Focusing on git as the main example, it claims that rewriting version control history is universally bad in any version control system, even rewriting one's own private history! What next, removal of the "undo" feature in editors?

> This sentence, and also the responses, seem needlessly aggressive.

Considering millions of git users do and enjoy rewriting history on a daily basis (especially during code reviews but not just), I find rebaseharm.md's claim pretty... "aggressive" and the responses here fairly civilized compared to the boldness of that claim.

Debian discusses Discourse

seneca6 — Thu, 30 Apr 2020 18:30:25 +0000

> Unfortunately the author doesn't understand review-based workflows;

This sentence, and also the responses, seem needlessly aggressive. I don't use Fossil but I have great respect for its author.

Isn't Free Software supposed to be allowed to scratch the author's itch instead of solving all of the world's problems? Especially a niche system, which Fossil certainly is compared to Git, Mercurial, or maybe even SVN.

Debian discusses Discourse

jezuch — Sun, 26 Apr 2020 07:22:59 +0000

Yeah, from what I can tell, the original vision of OpenID etc. morphed from "you run your identity provider (or use a trusted one) and we'll let you log in using it" to "the only two 'trusted' identity providers in the entire world are Google and Facebook". So instead of a generic button, you see two buttons: "Login with Google/Facebook".

It sucks.

Debian discusses Discourse

pizza — Sat, 25 Apr 2020 13:19:54 +0000

> In any case I'm not entirely sure but I don't have the impression there are many sites that support you using your own OpenID.

Unfortunately, you are correct. Big sites are more than happy to act as an OpenID identity provider; after all it gives them more opportunities to collect data on you and increases lock-in with their services, but very few accept anyone else acting as a provider.

Welcome to the future, I guess.

Debian discusses Discourse

rschroev — Sat, 25 Apr 2020 11:35:31 +0000

Do many sites allow logging in using custom OpenID providers? I used to have a simple personal OpenID, just a PHP script running somewhere IIRC. But IIRC there were not a lot of sites where I could use that. The Stackexchange sites supported it, but I they stopped that some time ago.

In any case I'm not entirely sure but I don't have the impression there are many sites that support you using your own OpenID.

Debian discusses Discourse

pizza — Sat, 25 Apr 2020 04:19:09 +0000

> This true of every account consolidation solution, any better concept?

Sure, run your own single-user OpenID provider on a cheap $5/mo VPS host.

Then your identity is truly *yours*, and can't be taken away from you.

(Yes, I realize this takes a little bit of money, and a little bit of work. So only folks that truly care will bother)

Debian discusses Discourse

marcH — Sat, 25 Apr 2020 01:47:05 +0000

> Yeah, which is awesome way to lose access if Google ever decides it does not like you.

This true of every account consolidation solution, any better concept?

If this comment was specifically about Google, any better OAuth / password manager recommendation? With FIDO 2FA please!

Debian discusses Discourse

karkhaz — Thu, 23 Apr 2020 20:27:26 +0000

Thanks, I noticed this very late in the discussion. The same issues do still apply, but the discussion and range of viewpoints on this thread have been truly fascinating and eye-opening, and I'm learning a lot about what other people value from non-email platforms.

Debian discusses Discourse

nybble41 — Thu, 23 Apr 2020 19:50:29 +0000

> … although any reasonably modern MTA implements SSL, so as long as the mailing list host and your MTA support it, everything is encrypted end-to-end.

End-to-end encryption would mean zero instances of the message in plaintext from the time it leaves the sender's mail client to the time it arrives at the final recipient's mail client. SSL transport for e-mail is not end-to-end. It only encrypts individual links. Every server in the path can see the plaintext, including (at a minimum) your SMTP relay, the mailing list host, and the recipient's MTA.

Debian discusses Discourse

mrshiny — Thu, 23 Apr 2020 16:50:52 +0000

Discourse != Discord. Discourse is open source.

Debian discusses Discourse

mrshiny — Thu, 23 Apr 2020 15:07:57 +0000

I'm over 40 and greatly appreciate the ability to do things like respond to tickets, review code, tag commits, etc, from a web based interface on my phone. It dramatically boosts productivity because I can do it at any time; I don't need to be at a workstation.

Sure, I'm not coding from my phone, but a significant portion of development work is not coding, and having the flexibility to do it from a mobile device is very valuable. YMMV but it's 2020, people are using phones for work.

Discourse Email Integrataion Short of Mailing List

hartmans — Thu, 23 Apr 2020 11:11:28 +0000

I want to make it clear that I'm interested in trying out Discourse, and that there are discussions we had last year that I would rather have had on Discourse. But the idea that if you turned off Discourse's web interface, it would be a reasonably comperable mailing list is simply not up to snuff. Among other things, you cannot:

Reply off-list from the email interface; you don't get the sender's real email address.
Cross post to multiple mailing lists. If you do, you will get split threads on each list and future replies will not cross-post properly.
Use normal email quoting.

These are not criticisms of Discourse: there are good reasons it works that way. But Discourse would make a really crappy mailing list. Its email integration is adequate that a dedicated email user can participate in a forum offline.

Debian discusses Discourse

neilm — Thu, 23 Apr 2020 09:27:51 +0000

> I don't see how this is a good thing. You can block / ignore people on mailing lists without having to resort to a moderator or other authority figure. This allows you to make your own decisions on who you want to interact with instead of making a decision for the whole community.

Just for the record, Discourse allows individual users to mute others (so you never get a notification about a post) or even ignore other users (suppress all posts and notifications from these users.). This doesn't require moderator intervention.

Debian discusses Discourse

Cyberax — Thu, 23 Apr 2020 05:44:03 +0000

> On the other hand, if you (hypothetically) move everything to Discourse, and Civilized Discourse Construction Kit, Inc. is bought e.g. by Baidu, Inc. next year, what can you do?
1. Fork the Discourse (it's OpenSource).
2. Switch to another forum software, leaving the old forum as a read-only archive.
3. Switch to another forum software, importing the data from Discourse.

Debian discusses Discourse

tesarik — Thu, 23 Apr 2020 05:38:54 +0000

You may be right with encryption, although any reasonably modern MTA implements SSL, so as long as the mailing list host and your MTA support it, everything is encrypted end-to-end. If you add a backup MX relay operated by a third party (to allow receiving mail when your MTA host is down/unreachable), then you no longer have full control, indeed. But whether you add such MX (and which provider you choose) is still your own decision.

On the other hand, if you (hypothetically) move everything to Discourse, and Civilized Discourse Construction Kit, Inc. is bought e.g. by Baidu, Inc. next year, what can you do?

Regarding anonymity, I believe that topic is completely separate. FWIW many FOSS communities have never aimed at anonymity of individual contributors. Quite the opposite! They give credit where credit's due and often keep a very long list of all people who have helped. For example, I sent a small patch set to the Wine project many years ago, and my name was added to the AUTHORS file automatically. I did not even expect it to happen, but I was flattered. My name is still there; I have no intention to ask for deletion. Why should I?

Debian discusses Discourse

bferrell — Thu, 23 Apr 2020 05:11:55 +0000

"So MTAs can tamper with email (ad footers), withhold email and it's not like you are in control of your data there either when the MTA inserts your IP and everything is sent in the clear."

For these very reasons, I run my own MTA. I've done so for a long time.

Is it easy? Maybe if I were setting it up from scratch today it would be more tedious now than it was when setting up an MTA was new. And I've had to bolt things on over the years to keep it up to date.

So it's hard. So what. As others here have mentioned, it gives me full control of my mail.

Know what else is hard? Writing code and thinking logically.

It makes my ears bleed and my brains leak sometimes. When I do it, it's a choice I make and I really don't think it's anyone else's responsibility to make it easier for me to execute on that decision. That decision is MY interior landscape.

In my opinion (humble or not), it's rude and obnoxious to try to hold others responsible or accountable in any way for my landscape/my decisions. That opinion is based on years of trying to do exactly that and finding out just how poorly THAT works.

'nuff said.

Debian discusses Discourse

marcH — Wed, 22 Apr 2020 18:56:53 +0000

> I want to see how they _think_, because it's completely unrealistic to expect fresh-outs to be immediately productive with the unique combination of miscellany that makes up our codebase (and technical debt). They're going to be learning on the job for the rest of their career.

There is always plenty of "quality of life" fixes in every project that experienced developers are too busy and too precious to do: small bug fixes, documentation gaps, small validation gaps, basic optimizations and simplifications, etc. These are a great way to ramp-up and learn about a project while being immediately productive and useful.

Tools like githab try hard to lower the barrier to submit these - and doing them lowers the barrier even more for the next project noobs[*]. "Are you with us or not?" mailing-lists and email code reviews keep (by your own admission) that barrier not crazy high but significantly higher. The difference is really that simple.

[*] a "project noob" can be very experienced with other environment and tools and may bring fresh perspectives.

Debian discusses Discourse

mathstuf — Wed, 22 Apr 2020 16:43:02 +0000

I know gmail sucks. I filter what I can, but it is broad brushstrokes because they're so tedious to manage and edit. And yes, the subject is there, but AFAIK, there's no way to say "subject starts with (except "Re:" prefixes)" to match *just* that part of the message. I always ended up with filters labeling things with 2 or 3 labels because the *rest* of the subject had the Magic Words.

Debian discusses Discourse

pizza — Wed, 22 Apr 2020 16:29:36 +0000

> Or everyone reverse engineers headers and hopes they can write rules to filter on them (gmail has no support for header-based filtering outside the 3 or 4 fields they index).

So you have described two problems:

1) the admins of the various discourse boards configured them to not include the name of the boards in the notification emails. (It defaults to being included, btw)

2) Gmail sucks. (and water is wet)

Debian discusses Discourse

mathstuf — Wed, 22 Apr 2020 14:06:48 +0000

> setup filtering rules, priorities, etc.

These two you can. Far better than a mailing list too. For instance, I get only the first message of a thread for most of the areas of our Discourse instances. Some I watch all traffic. Still others I basically ignore and I get no notifications. My split is unlikely to match other folks' preferences. I have no idea how to do that sanely for a mailing list without having a list per Discourse section which sounds like an absolute nightmare. Or everyone reverse engineers headers and hopes they can write rules to filter on them (gmail has no support for header-based filtering outside the 3 or 4 fields they index).

Debian discusses Discourse

gray_-_wolf — Wed, 22 Apr 2020 13:21:00 +0000

> In many cases I can login using my Google account.

Yeah, which is awesome way to lose access if Google ever decides it does not
like you.

Debian discusses Discourse

pizza — Wed, 22 Apr 2020 13:08:41 +0000

> I think this is kind of overselling what the college degree is supposed to represent. For me it was always a certificate issued by a "trusted" entity that I have the skillz to do the job. But I've never been in the position of HR so maybe my interpretation is too narrow ;)

Eh, even back in my undergrad days where we had to fend off dinosaurs on the way to class, it was commonly "joked" that our degrees would be in general crisis management with a minor in our erstwhile field.

In all seriousness, freshly graduated folks are fairly useless when it comes to specific technical skills. I don't say that pejoratively; what I expect instead is a decent understanding of the theory that underpins those technical specifics.

I want to see how they _think_, because it's completely unrealistic to expect fresh-outs to be immediately productive with the unique combination of miscellany that makes up our codebase (and technical debt). They're going to be learning on the job for the rest of their career.

(I should point out that I'm making a distinction between a university/college and a trade school)

> Anyway, like mbunkus said, I hope you're not suggesting that someone should spend 5 years of preparation before they're allowed to contribute to a project...

"be allowed to contribute"? Not at all. But they're not going to be terribly useful starting out, either. It takes time to grok a new codebase, even if you are already very familiar with the problem domain and tooling used.

(And these days, the typical software dev hasn't ever left the confines of client- or server-side javascript. It's quite a steep learning curve from that to reverse-engineering compiled binaries so you can figure out why your bare-metal realtime system is occasionally corrupting the data being read off the SD card...)

Debian discusses Discourse

tao — Wed, 22 Apr 2020 11:05:04 +0000

So, a rather vast variety of different e-mail clients that aren't braindead are "niche software" (all of which you can choose from when you contribute to a project using e-mail for patch submission). But a project using Discourse, for instance, allows you to pick your browser, that's it. You cannot pick your editor, you cannot pick syntax highlighting, setup filtering rules, priorities, etc.

I admit, I haven't used Discourse. I've used various other collaboration tools though; Gerrit, Gitlab, Github, Teams, Sourceforge (back when people actually used that), and Slack.

I really like Slack (but it's non-free), Teams is similar (also non-free), Gerrit is OK as long as nothing is rebased--at which points it turns into a nightmare, Gitlab & Github are OK:ish, Sourceforge was crap back when I used it.

The system I've liked the most though is simply Debian's combination of mailing lists and the BTS. It's certainly not ideal in every aspect, but it's really, really easy to customise to your liking.

The big issue these days with e-mail based interaction is simply that most ISPs actively work against you--they want you to use GMail or their own inferior copy there-of; they don't want you to download your e-mail and read it locally, and they definitely don't want you to send e-mail from your local machine using anything else than a web browser.

Debian discusses Discourse

jezuch — Wed, 22 Apr 2020 05:45:10 +0000

> I find it pretty hilarious that clueless end-users can manage this just fine but this mythical pool of hyper-talented developers that would be all over my code can't.

Autism works in mysterious ways...

Anyway, I was responding to the argument that since the project's subject matter is complex then it's fine if the submission process is also complex - and especially to ascribing an ideology to that. It's way simpler to be honest and just call it a hazing ritual :) It's fine to have reasons you work this way (it's better to try to improve that) but ideologies are bad.

Debian discusses Discourse

jezuch — Wed, 22 Apr 2020 05:29:43 +0000

I think this is kind of overselling what the college degree is supposed to represent. For me it was always a certificate issued by a "trusted" entity that I have the skillz to do the job. But I've never been in the position of HR so maybe my interpretation is too narrow ;)

Anyway, like mbunkus said, I hope you're not suggesting that someone should spend 5 years of preparation before they're allowed to contribute to a project...

Debian discusses Discourse

NYKevin — Wed, 22 Apr 2020 01:21:11 +0000

> How is this phenomenon unique to email or mailing lists?

Because:

- In a forum, a deleted message is gone. In a mailing list, a message deleted from the server has already been delivered to everyone's inbox, and normally cannot be recalled.
- Mailing lists usually lack a one-click report button or link. They *might* have an abuse address, but typing out a message justifying yourself creates a lot more friction than just hitting a button.
- Off-list communication is completely impossible to effectively moderate. Forums need not expose a user's email address, typically require registration, and if necessary can implement IP blocking etc., so that their private messages are a lot harder to abuse.
- Mailing list users, in my experience, tend to be a lot more suspicious of content moderation than forum users, which makes it harder for list moderators to use the limited tools they have.

> Yeah, "make it someone else's problem" is great for an individual until you're on the receiving end of someone deliberately reporting your posts because they don't like what you have to say, and that "someone else" is a three strikes algorithm that perma-bans you before you have a chance to object.

I've never heard of a forum designed that way. Can you provide a specific, real-world example?

> (Or if you're the one having to administer or moderate the forum/mailing list/whatever, and the professional troll you just blocked turns their sights to you and your family instead. Welcome to the jungle.)

Moderators are not new users, so I would characterize this as out of scope. Moderation will always be difficult. But as explained above, a forum does provide the moderator with more powerful tools and a greater shield of pseudonymity, if it comes to that.

Debian discusses Discourse

Jandar — Tue, 21 Apr 2020 22:41:17 +0000

> > As for e-mail vs other forums for discussions and code reviews, etc., I think it actually *does* come down to your e-mail client. I would never ever consider doing serious code reviews in gmail, thunderbird, or *shudder* outlook; sure, sometimes I briefly glance over code and point out obvious flaws, but for any larger amount of code I want access to a proper text client with a proper editor.
> Which basically comes down to "you must use mutt". Which IS a niche software.

Why? I prefer e-mail over any other communication method for non-volatile content like a chat and havn't use neither gmail, thunderbird, nor **violent shudder** outlook and mutt has attracted my attention for the last years my attention but I haven't used it once for now.

Why is mutt the only alternative to embarrassing popular email clients? There is a innumerable multitude of email clients serving every linking but web fora serve mostly only one or a few styles.

E-mail has many shortcomings but most (or all?) can be worked around, but web fora have also shortcomings but there the workarounds are not so plentiful.

For short or clear-cut discussions a forum is nice but for widely ramified discussion e-mail is way better.

The last and most important aspect is the ingrained muscle memory. I can operator my e-mail client with motions of my finger that are cultivated since before the web arouse. This is way faster than any web forum allows me to work.

The last paragraph can be dismissed as "grey-beard dosen't want to learn" (my beard is partly grey :-) but I've seen many fads come and go, a few communication channels come and go and some web services come and go. In the company I work for a quarter of a century I see the debris left behind by the alleged progressive people who propagate "this is the way of the future" and leave after a few years to bequeath some (toxic) legacy to the steady and essential work force. This has shown to me the questionability of the argument "this it is how it is done nowadays". Adapting to the fad of the year (or according to age the fad of the decade) throws away your fine tuned operation to throw it away the next time the next year and so on. Envision a master of his/her craft to turn his/her working on the head because some journeyman/woman has another idea. This doesn't dismiss the notion of a master learning from a journeyman/woman but not only because one of them is younger and therefore at the tip of the advancement. Where I am on the scale of proficiency I can't say for myself, but newer means mostly unseasoned and only rarely better. I have trained a few co-workers over the years and seen many trained by other, those who want to change basic procedures (and are allowed to do so, we are willing to try new things) are the ones that leave after a short time, those that accept the environment and try to learn the given tools are in for the long run and are productive for many years.

Any change you make to the workflow of the main current set of contributing people has to make a substantial improvement for almost all of them. A change to the the detriment of some of them is more pivotal than an improvement to several. Even a slight negative experience overshadows a larger positive one.

Debian discusses Discourse

marcH — Tue, 21 Apr 2020 20:33:06 +0000

> Well, we don't do our work in GitHub so I can't say what capabilities are offered (or not).

A GitHub PR "draft" (if that was the question) is only blocking merges and not connected to force pushes. You could use it as a "volatile SHA1" flag if you want to but that would be merely by convention and I think projects prefer to force push always til the end of the review or never.

> works for us and we don't really feel the need for more "built-in" support.

Fine as long as you don't really care about giving or receiving "drive-by" contributions to/from people with different conventions - same spirit as mailing lists: https://lwn.net/Articles/818238/

Debian discusses Discourse

mathstuf — Tue, 21 Apr 2020 18:01:22 +0000

OK, that sounds reasonable. The way we assume it happens in the workflows I work on is that branches on forks -> draft, branches on the main repo -> immutable. Everyone uses a fork for development (this also avoids the "what are all these branches?" problem when forking).

Debian discusses Discourse

mathstuf — Tue, 21 Apr 2020 17:27:25 +0000

It was more a comment on the lack of CI on most projects that also have 0 external contributors than about availability on any given platform.