[Libre-soc-dev] Task 980 needs an attention

[Dmitry Selyutin]

Hi folks,

briefly, dropped parts of the context, as this is intended to be a
generic reply, not to particular chunks. I'll drop a sort of summary
of what I think about the overall development. These statements might
appear a bit generic and mostly reflect a modus operandi in SW
development. Indeed, I've been following these for years too, that's
why the recent comments in 980 raised my objections.

My point is, as I work on it as an individual in my free time, I
should have flexibility to a certain degree to develop it when and how
I want. And I commit the code when it's at least somewhat "ready" and
"stable" and "beautiful" according to my personal standards. I
extensively use interactive rebase to make the history readable. When
I find that some branch commit introduced an error, I go back there
and edit it interactively, then force push. This makes the linear
history work when the master is rebased, decreases the chance of the
later bisect and simply avoids the trash like "oh look I fixed a typo"
for the code which just got rebased into the master (unless required).

Obviously this works better in branches or in master if you have force
push rights (and likely develop alone); but it has its own benefits.
Obviously it isn't a silver bullet, but it makes the history way
better, and that's the approach I always follow. And now, despite that
nobody had problems with this before, now we have this discussion.
This is not the first time we have some rules established for which we
lack the explicit requirements. The lack of these is fine as long as
there's a technical rationale. I doubt any real SW project has a
"commit whatever you have" policy. Real SW projects follow "commit
respectively and wisely" policies instead.

Indeed, these statements are vague and reflect my own personal
experience and preferences. But, unless you have a real severe cause
to completely bend someone else's behavior and habits into the way you
like it, I'd prefer to avoid it. You know I don't have massive chunks
of the code with me (I wouldn't even if I had time, what's the
purpose?). But I try to avoid "trash" commits, I try to commit things
which work, and I always worked this way. After all, it's an Open
Source development, not some corporate idiocracy.

As for "we're afraid something might get lost", I'd recommend starting
with the different places to think about. For example, git and CI.
These seem to be much better targets; these are the real points of
failure.

Yes this is subjective; I hope we _all_ are subjects though. "Commit
once you think it's good enough to show to others, it breaks nothing,
there's nothing to be ashamed of, you find it appropriate to publish
at this stage" -- these all look reasonable. The beauty is in the eyes
of the beholder.