Re: About your live-build contributions
Hi,
On Thu, 05 Mar 2020, jnqnfe@gmail.com wrote:
> > 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.
It's not required, and it's not required for me to look at your bug
reports and MR. Still, we want to respect each other and we make efforts.
Submitting so many bugs and MR at the same time is unusual and some
coordination before going ahead would have been nice. You would have
avoided double work and I would have not been surprised.
> 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
To be clear, I don't feel like being the Debian Live maintainer (even
though in practice, I'm doing some of that job with a few others DD), I'm
an active user as part of my work in Kali, thus I'm trying to help
along... but I'm not documenting much, I'm not reviewing old bugs on a
regular basis, etc.
Feel free to step in and update the wiki page, etc.
> Does this tool in fact work with "(Closes[:] #XXXXXX)" format?
> Can multiple bug numbers be given in one go?
I guess so but I have not double checked. It's usually best to fix a
single bug in a single commit.
> 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.
Given that we merge fast-forward branches without adding any merge commit,
the bug closure needs to be in the commit themselves, not in the merge
request.
Maybe we should revisit that decision of using only fast-forward merges, I
don't use it on my other projects.
> > 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. :)
Yeah, I can trigger the rebase now. Though I was referring to this
feature when you submit the MR:
https://salsa.debian.org/help/user/project/merge_requests/allow_collaboration.md
> > 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?
Yes, it does.
> 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?
It's a minor annoyance for me and a huge pain for you to properly
cross-reference both of them. A bug report can be useful if you want
to discuss something before creating a patch. If you're ready to submit a
patch, then the MR is sufficient to discuss your patch.
> 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.
Dropped.
Cheers,
--
⢀⣴⠾⠻⢶⣦⠀ Raphaël Hertzog <hertzog@debian.org>
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋ The Debian Handbook: https://debian-handbook.info/get/
⠈⠳⣄⠀⠀⠀⠀ Debian Long Term Support: https://deb.li/LTS
Reply to: