[FYI] Why pull requests in this repo aren't processed timely, a case study, was: More help

[jedie]

beside the needed patches from schinckel i add with https://github.com/pfalcon/yaota8266/pull/27/commits/95413b7f2f8173bb780240f3a492d8de567421d1 a small How To into README, for https://github.com/pfalcon/yaota8266/issues/26

And https://github.com/pfalcon/yaota8266/pull/27/commits/95413b7f2f8173bb780240f3a492d8de567421d1 enhanced the idea of: https://github.com/pfalcon/yaota8266/pull/22

And https://github.com/pfalcon/yaota8266/pull/27/commits/df6b5df28ed0f74e51aba49a7669434bcd6faf5f adds a .gitignore

[pfalcon]

Thanks, I appreciate desire to help. Please see https://eli.thegreenplace.net/2019/how-to-send-good-pull-requests-on-github/ for typical guidelines for pull request submission to projects. Hopefully that explains why this and other PRs in this repo can't be processed without noticeable cleanups, so they're waiting for those cleanups.

[jedie]

Yes, this PR is big and must be splitted, I know that, too... I spared the extra effort. Because the other PR aren't merged. And #23 #21 #20 are needed to use this project. These PRs are IMHO ready for merged, but not done, yet and no comment why.

Maybe another needfull patch is: https://github.com/ulno/yaota8266/commit/566a292bb2269747c3475b835d3a84ebc0c3061f But I don't know that for sure.

Because of this and many other open/not commented issued, the project looks unmaintained to me. I therefore come to the conclusion that it would be best if this project was included in micropython repro. In the hope that it will be easier for everyone to use: https://github.com/micropython/micropython/issues/2535#issuecomment-569740745

[pfalcon]

Ok, as I effectively find myself doing the same what you're doing here, @jedie (arguing for revival of another project). So, I feel obliged to respond here either. Actually, I'm a firm believer that one open-source developer can call to another one for answers and get one (and I checked that you @jedie have an open-source participation history, because fairly speaking, communication with random passer-by's is getting unsustainable here on github).

Let's however get the obvious things straight. Not merging pull requests is not good, aka bad. And the reasons for that would be bad themselves, how otherwise? And talking about bad things is unpleasant. And yet you call for answers (in preference of silence), you want to open that Pandora box. Apologies in advance if you find some things not exactly pleasant.

Ok, to give a glimpse of the things we're going to talk about, let's see how us 2 met. You sent me a letter ticket with a title matching following glob pattern "* ?!?". "Hmm", thought I, and promptly replied. You replied with another ticket with title of the same pattern.

Hmm - how to put it more politely - my language and grammar teacher never suggested to title letters to unfamiliar people in such a way. Neither grown-up people with whom I normally communicate write their letters in such a way, unless they want to achieve a peculiar effect. So, if you wanted to achieve one, congrats, it worked.

Don't get me wrong - I'm not trying to teach you how to write, do however you like. But neither you will be able to teach somebody else, and the world in general, how to read. And if you never thought how it works, let's do it together: people open their mail client (or bug tracker, doesn't matter) and see titles of messages. Some descriptive, detailed, and clear, some are "?!!!???!!11". What matters is that there're many of them, e.g. I receive ~50 mail every day (most are notifications of some activity course). In no way I'll be able to read them all - I pick up a few to deal with immediately, and leave the rest for "later", whenever that may come. So, thanks again for helping to prioritize your submissions by giving them suitable title. (E.g., if you want delays with response, please keep up with "Tutorial ?!?", "More help", etc.)

(To be continued.)

[jedie]

Hm. So this is about the subject line, not the content? If the subject line is not well chosen, it goes into trash and fine?

Sorry, i'm not a native English speaker. Even worse, my English is very bad. I guess you can notice that too, right?

Let's not talk about wording. Let's talk about how to improve this project.

When I look at existing issues, it should be clear that not only I wonder how to use it. But it doesn't matter now. I've come further. Can build it halfway now.

[pfalcon]

Ok, status of the project. To understand it, you need to know history of the project. It's all out there, as you found by doing modest amount of searching around. But let me provide condensed summary.

1. There was a kickstarter for MicroPython ESP8266 port, OTA was one of the stretch goals.
2. I did a bunch of iterations of yaota8266, when most of the things already worked. I prepared to do some "realworld" testing. I opened another package from Itead with a bunch of new Sonoff's... Wait, sounds familiar? YYYESSS!!!1, forgive my exclamation marks, 3 years ago I was about to do what you're doing now in https://github.com/jedie/micropython-sonoff-webswitch (kudos for that!)
3. And then - an accident! I was cut off from this hardware and unable to use it for quite some time.
4. Of course, I still worked on MicroPython, just shifted to another things.
5. After some time, the matters deteriorated in MicroPythin side - I felt that my proposals/work (also directly related to ESP8266 kickstarter) are blocked by the project owner and my kickstarter partner.
6. It went only downhill from there. This entire situation changed priorities, and while I'd like to get back to yaota8266, so far, that didn't happen.

Yeah, that's it. And just imagine - if you came some 3 years before, we'd have such a great development party! (Or maybe if I came some 3 years later, but this is my story, and I tell it from my point of view.)

Or maybe we'd not. Because none of my repositories contain commits titled like "needed bugfix from <foobar>" or "fixup!". None commits in my repositories say that they "remove website", and actually start with removing the tests. Please find differences between https://github.com/pfalcon/yaota8266/commits/master and https://github.com/pfalcon/yaota8266/pull/27/commits . And if you don't see them, well, d'oh, it will be hard to explain. Suffice to say that whole of my programming experience (and I'm not exactly young) calls to not do it like in examples outside my humble repo, and do it like I do it inside my repos (and I'm not perfect in any way and there's room for improvement).

So, that's it, the pretty-obvious-to-all-git-users golden rule of thumb: do git log, make your own commits in the way that the only difference is your name in the header. If you work with a project which paints thousands of lines in each commit red and green, throw them even more stuff like that. And never (1) do that to a project with clean, small commits. See a commit messages like "stuff", "fuck it", "booyeah" (2)? Shove them more dirty-mouth. But if you see messages like "ota-client: Set default block size to conservative value of 256.", please kindly note the full stop at the end.

1 There're exceptions to everything. Also, exceptions are exceptions. Don't start with exceptions, that's confusing. 2 Pun intended. As we both take/took fun with Python interpreter implementations, it's fun to see how real PhD's do it (yes, the guy is PhD; please don't alert him away, that repo is golden).

[pfalcon]

Our story is now told. Dry residue:

1. Pull requests here were missed/unprocessed because I was too busy with other stuff.
2. But from a quick look, they don't follow the project code/commit style.
3. So, someone would need to brush them up. That could be original submitter(s). That could be a guys passing outside your/my window. That could be me in the end. I did a lot of that cleanup in MicroPython times, and not fancy spending all of my life doing that. So, from my side, that may need some wait (and I don't consider a few years a long term any longer).
4. Beyond that, not immediately obvious changes would need to be tested by me, but sadly, I don't work on yaota8266 at this time, because of more important projects. (Come join me in them, or you'll miss a few years out again. Just joking.)
5. This is an open-source project, feel free to fork it an maintain it. If you follow the established style of the project, later (if ever) I can merge it back. If you don't follow, then unknown.

Thanks again for the desire to review/help it, and Happy New Year!

[pfalcon]

Hm. So this is about the subject line, not the content? If the subject line is not well chosen, it goes into trash and fine?

But no, as I explained, it stays in the backlog queue. And that's not fine, what if content was important?

Even worse, my English is very bad. I guess you can notice that too, right?

Sorry, I can't ;-). Probably because I'm not native English speaker myself ;-).

[jedie]

I will close this, because i made https://github.com/pfalcon/yaota8266/pull/28 with a better branch name...

[pfalcon]

I would prefer this issue to stay up and be discoverable by interested parties, I won't be able to go thru the exercise of repeating the points above again and again. (It of course applies to many other projects, mine or not.)

[pfalcon]

And - meet another open-source micro-tragedy of the commons du jour: https://github.com/pyinstaller/pyinstaller/issues/4404

Some quotes:

If reasonable funding is not achieved until enf of January 2020, htgoebel will retire as an maintainer. This basically means: Unless somebody else steps in, there will be nobody reviewing any pull-request, there will be not improvement and sooner or later you will not be able to use PyInstaller any more.

None of these is going to pay my rent nor feed my children.

Don't get me wrong - the common thing between this and that (and many other projects) is that they are/will be not actively maintained, and not something else. But the underlying reason why some person maintains something is: a) they personally need that, or b) they have customers for that. There're unfortunately no other foundations for sustainable maintenance otherwise.

Likewise, the way a particular project is maintained is based on: a) customers' requirements/desires, backed by appropriate resources of course; b) maintainers' own rules. In both cases, contributors just need to follow them.

[pfalcon]

Now a good example of well-specified contribution policy: https://github.com/soimort/you-get/blob/develop/CONTRIBUTING.md

If you would like to report a problem you find when using you-get, please open a Pull Request, which should include: A detailed description of the encountered problem; At least one commit, addressing the problem through some unit test(s). Examples of good commits: #2675, #2680, #2685 PRs that fail to meet the above criteria may be closed summarily with no further action.

So, if you want to report an issue, you need to submit a PR. With specific requirement. And it's well specified what happens if you don't.

A good example how projects with almost 30K stars cope with their "success", and what they do to prevent their maintainers' lives turning into complete misery.

[jedie]

The essential thing is that you do not want to maintain the project any further, isn't it?

That's totally okay and understandable. Maintaining a project takes time and we all definitely don't have enough of it ;)

And if you don't use yaota8266 at the moment then it's even more understandable.

The other topic "which pull requests are accepted" is totally irrelevant as long as you do not maintain the project.

[pfalcon]

The essential thing is that you do not want to maintain the project any further, isn't it?

But no, of course no, like clearly explained above (so this is last time I repeat it) - of course I want to maintain it! I also want to climb Himalaya and fly to Mars, don't even ask. I just don't have time and other resources to do that right now. My resources are finite, so I need to plan them carefully, and currently other projects prevail.

The other topic "which pull requests are accepted" is totally irrelevant as long as you do not maintain the project.

It's absolutely relevant, because for projects actively maintained at the specific time, I (or any other maintainers) still have finite resources and again face a choice: either spend time of their lives on cleaning up stuff dropped by other folks, or do something different, perhaps even more exciting, and leave cleanup to the folks who produced that stuff (or maybe some volunteers, or maybe someone will pay maintainers to do that). So, I'm mostly concerned how to make this point clear, unambiguous, and ultimately positive to the project itself and all participants in it.

[jedie]

... of course I want to maintain it! ... I just don't have time and other resources to do that.

So it's de facto currently unmaintained in my eyes. So the work to make pull requests nicer are in vain. I am not talking about my huge pull requests to make this project easier useable. e.g. the small bugfixes without this project can't be used. For example: https://github.com/pfalcon/yaota8266/pull/23 or https://github.com/pfalcon/yaota8266/pull/21

But let's stop discussing it. It's a waste of time that could be better spent implementing code ;)

[pfalcon]

So the work to make pull requests nicer are in vain.

If making things nicer is against your will, then yes. But for some people who never thought that making changes could be beautiful, and that open-source projects need more, not less, quality, that can be insightful.

But let's stop discussing it.

Ack.

[pfalcon]

Another week, another drama. https://github.com/actix/actix-web :

Be a maintainer of large open source project is not a fun task. You alway face with rude and hate, everyone knows better how to build software, nobody wants to do home work and read docs and think a bit and very few provide any help. Seems everyone believes there is large team behind actix with unlimited time and budget.