search

SensorsIot / IOTstack

Docker stack for getting started on IOT on the Raspberry PI
GNU General Public License v3.0
1.45k stars 308 forks source link

20220218 PiHole - master branch - PR 1 of 2 #501

Closed Paraphraser closed 2 years ago

Paraphraser commented 2 years ago

Expands/rewrites PiHole documentation. Inspired by Issue 500

Fixes #500

Signed-off-by: Phill Kelley 34226495+Paraphraser@users.noreply.github.com

ukkopahis commented 2 years ago

This is in conflict with #466. Could you close this and submit these changes as a pull request to https://github.com/ukkopahis/IOTstack/tree/doc-improvements ?

You can easily do this directly at: https://github.com/ukkopahis/IOTstack/edit/doc-improvements/docs/Containers/Pi-hole.md

That would make the changes a part of 466.

Paraphraser commented 2 years ago

I'm happy to do the close here but a lot less happy with the idea of a path Paraphraser->ukkopahis->SensorsIot. On balance, I'd rather wait until PR466 is processed and then think about whether I still want to make any changes. As I think I said somewhere else, I was just responding to the password issue, thought the doco was a bit sparse, and decided to take some time to improve it. But it's not the be-all and end-all of my existence.

I still don't understand why this collision wasn't prevented. My starting point is always to make sure my fork is up-to-date with respect to SensorsIot. When I prepared pairs of pull requests which affect the same files (eg Pi-Hole.md on both master and old-menu branches), I commit and push against master, then GitHub prompts me to turn that into a Pull Request. It's exceedingly rare for that to not just sail straight through but it has happened and it has always been because something on SensorsIot has changed between me synchronising my fork and completing the PR loop. Conversely, when I commit and push against old-menu and GitHub prompts to turn that into a PR, it always fails because GitHub defaults to proposing the PR against the master branch where it can see that the second change conflicts with the earlier PR. When I change the popup to say I want to base it on old-menu, the error normally falls away.

ukkopahis commented 2 years ago

I still don't understand why this collision wasn't prevented.

Here's what I wrote to discord about this:

thought one of Git's claims to fame was that it would tell me if something I was about to do would create a conflict.

Nope, only when you try to merge will it tell you if there's a conflict. That's why I tend to merge all current pending pull-requests to my master-branch and check that my new pull-request also merges without conflict.

I thought that was one of Git's design-goals: lots of people could tinker in the same area at the same time and Git would prevent them treading on each other.

Partially true, it was designed to make resolving such problems as easy as possible, not to prevent them.

Git would give me a smack in the head and say "nope".

Exactly the opposite. You must be thinking about some of the "old" centralized corporate version control systems. Git philosophy is to embrace the conflicts and make resolving them easy. Just do enough coordination outside of git to avoid duplicate work. (and large changes on exactly the same parts)

The first is I don't want to send any negative signals of the "before you contribute you need to open a discussion with X". I don't see that pattern anywhere on GitHub

I don't think it would be a bad idea to mention it here on Discord. At least to prevent two persons (mainly you and me) from doing exactly the same work at the same time. I see variations of this all the time. It's either github issues assigned to someone, talk on mailing lists or irc/discord/slack discussions.

ukkopahis commented 2 years ago

I'm happy to do the close here but a lot less happy with the idea of a path Paraphraser->ukkopahis->SensorsIot.

Well, if the shoe was on the other foot, and one of your pull requests were changing files I want to modify further I'd make the improvements as a pull-request to you. But of course first ask for your go-ahead that you think it's a good idea.

Even if you wouldn't accept the pull-request, I can always re-submit it to the main project after your pull-request is accepted.

Paraphraser commented 2 years ago

I suppose the question I ask myself (from my position of acknowledge gitignorance) is how long does the chain-of-forks get to be? That's what bothers me. It might seem natural to you and you might be right about my perspective being coloured by previous experience with centralised approaches. Truth to tell, though, if you submitted a PR to my fork I wouldn't know what to do with it and, unless it was really "in my face" I probably wouldn't even notice it. The next question I'd be asking myself is what it meant in chain-of-responsibility terms? None of the potential answers really appeals to me all that much.

Even more truth to tell, I'm getting heartily sick of being told I'm doing it all wrong. My interest in continuing to be involved is fast approaching zero. If that's what you wanted to achieve - mission accomplished.

ukkopahis commented 2 years ago

Well from my point of view:

  1. You submit multiple PRs that conflict with 466
  2. I ask is your intention to bury it
  3. You say no
  4. I propose solutions
  5. You state I killed you interest in continuing

I don't know where I went wrong. Something must have been miscommunicated. English isn't my first or even second language. I'm just trying to improve the project and the process. I'm the type of guy who just cannot not speak up when I feel something is going awry. I hope you can forgive me.