Should I push?

[tramp]

Should I push it now?
From the pov of a developer.

So, work is done, Should I push it now to the public repository, or should I have a rest and check tomorrow if anything is well?
Implementation of the new feature looks good, works good, but, have it any side effect to other, long implemented features?
Will check tomorrow.

So all day testing, haven't found any issue, but, have I checked if a combination of x with y works? Will check tomorrow.

What if I implement it the other way, should be a tad more optimisable by the compiler, let's try. Okay, works, but now I need to check if x with y works, will do tomorrow.

Seems to work all well, will push tomorrow.

So, when I've done this that way I should as well do that this way, Lets try. . .
Tomorrow, let's check tomorrow, and then push it to the public, I swear . . .

EDIT:// Oh, wait, I just found out that those optimisation flags make a huge different in DSP load, let's use them and check if they impact other aspects of the performance, . . maybe tomorrow?

EDIT2:// what's that, is there dust on my guitar? Hmmm

[Audiojunkie]

If it's anything like the company I work for, they push and wait for the response, then call us to clean up the mess!!

Test? QA? That's for sissies!!!

[tramp]

Test? QA? That's for sissies!!!

okay, so:

Code: Select all

~/projecte/guitarix.vst3/guitarix.vst$ git commit . -m "add NAM support"
[main 38758b0] add NAM support
git push

[tavasti]

Test? QA? That's for sissies!!!

Test is it ok for commit: does it compile/build?
Test for customer delivery/release: does it start?

[Audiojunkie]

Test? QA? That's for sissies!!!

okay, so:

Code: Select all

~/projecte/guitarix.vst3/guitarix.vst$ git commit . -m "add NAM support"
[main 38758b0] add NAM support
git push

Cool! We'll help you find the bugs!

That said, I was mostly commenting on the shoddy way my company works. The company I work for functions in a more reactive way than in the preferred proactive way. I'd much prefer proactiveness if possible.

[tseaver]

@tramp

After years of working on F/LOSS projects, I've gradually moved over to a mode where I try to do development on the umpty-many projects I maintain by pretending I need to get another developer to review my work (in other words, I try never to push directly to main/ master):

• I create issues in the Github repository representing the bug or feature to be worked on.
• I then create a branch for each issue, e.g. git branch tseaver-99-add_some-feature, and commit my work on that branch.
• I try to have each commit on a feature / bugfix branch be "coherent", and have it pass whatever lint / testing checks the project requires.
• Once I complete work on the branch, I push it to the upstream repository, make a pull-request, and then either a) wait for whatever CI checks there are to pass; or b) ask for review from other project contributors.
• If there are no developers who might reasonably be expected to review a PR, I will frequently merge as soon as the CI checks pass. The downside here is that I have a non-zero chance of regretting that merge, especially if I am in a hurry.
• If I can reasonably expect review, I wait for N days (based on my experience in that repo) before merging. In this case, I often try to do a "black box" review of the PR myself before merging: even a couple of days' distance from the original burst of activity can reveal problems which would otherwise have eluded my notice.