Oopsie in sysvinit-2.92

[Dmitry Bogatov]

No personal offence is intended. Purely technical concerns.

> [ Benda Xu ]
> While I agree with your commits on points for KatolaZ to improve, I
> would like to remind that the git workflow is ultimately a personal
> preference, not black-or-white, right-or-wrong.

Surely it personal preference. But sticking to workflow, implied by
well-recognized tool, and already implemented in repository is nice
thing to do.

> [ KatolaZ ]
> I am sorry for that but I am the only one who has been using wip
> branches so far, while have seen that you just push to master "no
> matter what".

Well, actually not. I use wip/ or bug-/ namespace too. Note, that
I pushed the controvesial reversion of your commits as `wip/master'.

> > [ Dmitry Bogatov ]
> > you can not amend `master' branch once you pushed to it, no matter
> > what!
> [ KatolaZ ]
> It does not look like reverting commits is master has been forbidden.

There is nothing wrong with reverting, as is `git-revert'. But you could
not alter published branch is sense of `git-rebase'. History with
many reverts looks untidy and complicates `git-blame'.

[ KatolaZ ]
> I am sorry if my work caused any problem.

Happens, nothing serious.

> > [ Dmitry Bogatov ]
> >  * New upstream release should be incorporate as merge with `upstream-release'
> >    branch. Use `gbp import-orig --uscan'.
> [ KatolaZ ]
> There is not just one way of doing that, AFAICT. We could decide to
> agree on one particular way or another, and I might be happy
> considering to adhere with that. But please, just be clear about what
> and why.

Yes, there is multiple workflows. But as you can see, sysvinit is
currently using workflow, default to `git-buildpackage'. See `Importing
a new upstream version' in manual [^1].

By the way, you will get repository with this workflow if you recover
package history with `gbp import-dscs --debsnap foo'.

> > [ Dmitry Bogatov ]
> >  * Your commit messages and changelog entries could be improved. The
> >    `gitlint' tool may provide some suggestions.
> >
> [ KatolaZ ]
> I don't know whether gitlint is the preferred, suggested, or mandated
> way of checking commit messages for Debian packages.

Nothing that official. It is not even mentioned in
`developers-reference'. It was just my suggestion...

> [ KatolaZ ]
> If it is, I have probably missed it by reading the variety of
> documentation available on the git workflow in Debian, and I am sorry
> for that.

... for a tool, that checks for well-estabilished guidelines about git
commit messages. [^2][^3]

> [ KatolaZ ]
> If it is not, I would appreciate concrete comments instead. Anything
> can be improved in many different ways, and if you are not told what
> is wrong, any "improvement" might just be bad without you realising
> it.

Correct. Let me elaborate (see links above):

 * Subject of commit message should be capitalized and in present tense.
     'amended changelog' -> 'Amend changelog'
     'incorporated'      -> 'incorporate'
     'applied'           -> 'apply'

 * There is quite wide-spread convention, that changelog entry for new
   release is 'New upstream release' or 'New upstream version'.

> > [ Dmitry Bogatov ]
> >  * You do not add [ J. Random hacker ] into changelog as long you are
> >    the only person making changes.
> >
> [ KatolaZ ]
> Sorry for that. I thought that would have spared time and effort to
> the other who would have added to the changelog later.
> This is what has happened so far, so the mistake is due to the effort
> of being kind to other fellow maintainers.

I never doubted your good faith. But `debchange -a' insert proper
attribution automatically.

> [...]
> I don't understand why you decided to revert the commits (could you
> please explain what was wrong with them, exactly?
>
> It was basically the same version of upstream, plus one patch which
> could have been removed...), but I am fine with that.

Commit message of revert commit (0a6d64):

    This commit reverts set of commits, that includes improper import of
    upstream release. Import of upstream release should be done as merge
    with upstream branch (`upstream' by default, `upstream-release' as
    configured in `debian/gbp.conf').

I wrote about it above.

    There is nothing wrong with patch to fix behavior of `pidof', but since
    upstream release 2.93 is already released, that contains that fix, it is
    simplier to just package and upload sysvinit-2.93.

Here, as you see, I do not object aganist your commit 5b14.

It would be perfectly fine to leave it as-is, and instead remove that
patch at commit, introducing upstream release 2.93. This patch will not
be mentioned in `debian/changelog', since it was never uploaded. I am
okay with doing it that way.

You are welcome to propose improvements to my wording.

> [ KatolaZ ]
> I am used to maintain packages with a group of people, and normally
> there is not only one master of the rings, as long as stuff is kept
> tidy and in order.

I do not claim to be the master of the rings. I just try to make sure
that we have clear, well-written git history. [^4]

> [ KatolaZ ]
> I think it would be good if we could please be clear about maintenance
> workflow.

I agree. Does anyone aware of already existing documents describing team
maintainence workflow?

 [^1] /usr/share/doc/git-buildpackage/manual-html/index.html
 [^2] https://chris.beams.io/posts/git-commit/
 [^3] https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project
 [^4] https://xkcd.com/1296