app-editors/scite: Version Bump to 4.4.3.

[dermoench42]

Actual enhancements and upstream bugfixes. See
http://www.scintilla.org/ScintillaHistory.html

Signed-off-by: Ervin Peters coder@ervnet.de
Package-Manager: Portage-2.3.99, Repoman-2.3.22

[gentoo-bot]

Pull Request assignment

Submitter: @dermoench42
Areas affected: ebuilds
Packages affected: app-editors/scite

app-editors/scite: ervin.peters[at]ervnet.de, @gentoo/proxy-maint

Linked bugs

No bugs to link found. If your pull request references any of the Gentoo bug reports, please add appropriate GLEP 66 tags to the commit message and request reassignment.

If you do not receive any reply to this pull request, please open or link a bug to attract the attention of maintainers.

---

In order to force reassignment and/or bug reference scan, please append [please reassign] to the pull request title.

Docs: Code of Conduct ● Copyright policy (expl.) ● Devmanual ● GitHub PRs ● Proxy-maint guide

[dermoench42]

"gentoo-ci — PR introduced new issues"
Looking at 'Details' I found nothing related to 'app-editors/scite' or '/scite' ... any hints?

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2020-06-13 07:52 UTC
Newest commit scanned: 9859ba8
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/42b8e9803b/output.html

[gentoo-repo-qa-bot]

Pull request CI report

Report generated at: 2020-06-21 16:47 UTC
Newest commit scanned: a5ea7b6
Status: ✅ good

There are existing issues already. Please look into the report to make sure none of them affect the packages in question:
https://qa-reports.gentoo.org/output/gentoo-ci/75b604d4cc/output.html

[juippis]

Can you please split these commits, there is one commit when there should be multiple.

1 for version bump,
1 for removing old versions,
1 for modifying DESCRIPTION on 4.4.3,
1 for those sed modifications,
1 for updating RDEPEND in 4.2.1 note that this requires a revision bump too,

Why are you downgrading https to http?

[dermoench42]

Sometimes I should squash, sometimes not, not really clear. I'll redo the whole, because of a new version bump.

[juippis]

Hi,

sorry for your experience, but in my eyes our policy and standards are pretty clear. You're maybe not that familiar with Git so it can be hard to kind of imagine the git workflow? Please read https://www.gentoo.org/glep/glep-0066.html#splitting-commits

I'll quote and try to explain:
Use atomic commits — one commit per logical change. I listed your logical changes above.
When doing a version bump, it is usually not reasonable to split every necessary logical change into separate commit since the interim commits would correspond to a broken package. This means you can incorporate all of your changes to one commit on a new ebuild file, but when modifying existing ebuilds, the change should be visible and revertable. Talk about reverting a broken a commit, if you made all those changes in a single commit and some part of it proves out to be broken requiring reverting, we would lose all changes instead of the one broken one.

As for opening new PRs, it'd be best for everyone if you just cleared your current git branch and committed the update here. Since now I will get a new e-mail instead of tracking existing e-mail threads, it will take time before I even see the new PR. Although there are many other members in the project, someone else might see it first. Just saying, you don't need to open a new pull request, when you can just use git tools to do the update in this PR.

Just a note, and no offense meant, but perhaps you'd like to read a git tutorial to get over these basic tasks?

I'm sorry you feel like your time is wasted, trust me, I don't feel any better about it either. Yes the main point is to have up-to-date working software in the tree, but I also hope you can see from a technical point of view why this particular GLEP was drafted, and why git history/workflow is important to us.

[dermoench42]

I have to apologize.
I mixed up the two concepts of PR' and 'Commit' in remembering the documentation, and got angry. You're right I'm still climbing the steep ladder to git concepts and knowledge, therefore reading documentation and tutorials. But the git functionality is abstract and must be applied to a semantic frame of the gentoo tree objecs. The lack of the big picture was my problem. For now I decided to see a branch as something like a 'project', merge/pull requests as a set of working changes in an temporal manner like a 'milestone' or a reached goal and commit as an atomic change related to either one 'abstraction level' xor existential changes to keep the cognitive load low.
To reflect this, I'd cleaned up my branches, delete this branch and will use only a branch called app-editors/scite from now on.
Additionally for information I stumbled (again) over nerd-typical optimised minimal communication since social communication uses pictures and is redundant with to weight and clarify.

Thanks for our work together.

further: #17080