Re: About your live-build contributions
On Wed, 2020-03-04 at 14:00 +0100, Raphael Hertzog wrote:
> Hi Lyndon,
>
> On Tue, 03 Mar 2020, jnqnfe@gmail.com wrote:
> > I understand. Just to summarise before I expand on things, I
> > contributed a lot of work on LB back around 2015 which never made
> > it
> > into master, and this is a resubmission (partial so far) of that
> > work,
> > because I'd like to see it merged rather than gone to waste. :)
>
> Ok. Still, you should have discussed this beforehand and you should
> have
> submitted stuff gradually as we merge your contributions.
With all due respect, and no desire to fall out whatsoever, I feel a
little defensive about being told what I _should_ or should not do, as
opposed to what you might have appreciated per your preferences, or
what might have been helpful. I don't see that submitting multiple bug
reports or MRs at a time _requires_ a step of discussion first.
My impression from the below is that you're mostly/wholy concerned with
simple common issues in submissions such as lack of "Closed: #XXXXXX"
hints. I'd like to draw attention to the fact that the wiki page [1]
would be the obvious place for such preferences to be documented, and
that page happens to be lacking such in its contributing section.
I'll also just take this opportunity of mentioning that part of that
page to point out that: it mentions "If you would like to be more
involved in the development of Debian Live packages, please join the
Salsa group." With a link to the group page; I looked to see if there
was some way to join out of curiosity, especially when the following
sentence states that "All members of the Salsa group have commit access
to our git repositories", but found none. Perhaps it was written for
people who are already DDs/DMs and needs clarifying...?
[1]: https://wiki.debian.org/DebianLive
anyway...
> I could have told you that:
>
> 1/ I don't need Debian bug numbers for everything
Very well, a bit of a misunderstanding of your preference from a past
comment you'd made I guess. I'd agree that certainly changes not
related to actual bugs should not really make use of bug reports. I
will adjust my approach accordingly with submissions for further work.
> 2/ I don't want Debian bug numbers in commit titles or merge request
> titles
There was only one commit containing a bug number in its title, they
otherwise only contain them at the end of their description blocks. I
have edited that one commit to adjust it accordingly.
I added them to the MR titles to help with referencing between MR and
bug report from the list view of all MRs, but very well, I have just
gone through them and removed them as desired.
> 3/ You need to add "Closes: #XXXX" in the long description to
> actually
> trigger the tagpending hook, get noticed by "gbp dch" and thus
> properly
> handle any Debian bug report.
I actually already had added such lines to commits as part of my
submission process, having picked it up as being good practice some
time ago.
However the format I used was not identical to yours. I'd wrapped it in
parentheses (having seen others do similar in the past), and I'd
mistakenly missed the colon.
I was not familiar with "gbp dch".
Not knowing whether this tool works with such slight variations, I have
edited all submitted commits (minus the two already merged) and force-
pushed updates (also I rebased them) to use exactly the right format.
I also took the opportunity to tweak a few commit titles and add some
presumptive "Gbp-Dch: Short" / "Gbp-Dch: Ignore" hints.
Does this tool in fact work with "(Closes[:] #XXXXXX)" format?
Can multiple bug numbers be given in one go?
FYI, before taking a look at the referenced tool, I was not clear from
your comment whether you actually meant that you wanted such hints to
be present in the MR descriptions for tooling to pick up or in commit
logs, so I updated the MRs accordingly. I later after looking at the
man page for the tool you mentioned understood that it was likely the
commit logs. I'm just mentioning this so that you know why I made such
changes to the MRs.
> 4/ you should leave write access to the live-build committers when
> you
> submit your merge requests so that we can trigger the rebase on our
> side
> and/or append commits on our own
Okay. I tried searching for the group to give it access, but could not
get it to find the group. I successfully added the three group owners
as devs though, so, not being very familiar with this side of things, I
hope that's correct for what you need. :)
It would certainly be better for you to be able to handle this aspect
from your end without needing my involvement.
> I merged the first MR and I'm already stuck because the others are
> obviously not a fast-forward and I can't rebase them from the web
> interface.
> https://salsa.debian.org/live-team/live-build/-/merge_requests/34
hmm. I was not expecting such an issue. hopefully giving you the above
access rights to my salsa copy of the codebase addresses this?
> > I ditched the original plan of just sending one email in part
> > because I
> > recalled one of your reviews of an old 2015 submission asking for
> > individual bug reports for individual bugs if resubmitting a
> > rebased
>
> Well, yes, we need to keep separate stuff separate, but I don't need
> a bug
> and a MR. And refactoring is not a bug and not a feature. That kind
> of
> stuff can be lumped together in a single MR with multiple commits.
to be clear, if I've found a bug and have made a patch, your preference
is for only one or the other not both and it would be an annoyance to
create both?
totally agree on the bts use wrt. refactoring work as mentioned above.
btw, the old 'tmp-jnqnfe' branch of mine on the official repo now that
I look at it again only has a tiny proportion of my old work, some of
which has been merged since its creation, and the rest is obsoleted by
the new submissions, so that entire branch could be removed.
Regards,
Lyndon
Reply to: