Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.python > #12114 > unrolled thread

Merge Requests

Back to article view | Back to linux.debian.maint.python

Contents

  Merge Requests Jonathan Carter <jcc@debian.org> - 2019-12-06 10:40 +0100
    Re: Merge Requests Scott Kitterman <debian@kitterman.com> - 2019-12-06 12:30 +0100
    Re: Merge Requests Louis-Philippe Véronneau <pollo@debian.org> - 2019-12-06 20:50 +0100
      Re: Merge Requests Raphael Hertzog <hertzog@debian.org> - 2019-12-06 21:50 +0100

#12114 — Merge Requests

Hey debian python team

We currently have a few merge requests open:

== tools ==

Count: 6

https://salsa.debian.org/groups/python-team/tools/-/merge_requests

== papt ==

Count: 8

https://salsa.debian.org/groups/python-team/applications/-/merge_requests

== dpmt ==

Count: 31

https://salsa.debian.org/groups/python-team/modules/-/merge_requests


I merged a bunch of trivial ones yesterday, but even then it seems like
we have some problems which might need some update in our policy in
dealing with merge requests.

I noticed that one MR fixed some typos but did it in the upstream source
directly, which isn't all that useful to us.

For other MRs, I noticed that many small changes in the packaging didn't
have an associated changelog entry with it, so I had to dch to add a
changelog entry. I think for small changes I'd prefer the person who
submits the MR to add them. For larger ones it probably makes sense not
to do that since it might take longer.

Any suggestions? How about we draft some MR policy in gobby and get it
added to the PAPT/DPMT policies?

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) <jcc>
  ⣾⠁⢠⠒⠀⣿⡁  Debian Developer - https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄⠀⠀⠀⠀  Be Bold. Be brave. Debian has got your back.

[toc] | [next] | [standalone]

#12115

It looks like a lot of this is lintian-brush generated and of questionable value, IMO.  As an example, bumping compat to 12 is trivial to do.  

The hard part is checking if it affects the package content, so the bot has produced a proposed change that will take far longer to verify than it would to produce.  If I had time to do the checking, I don't need a merge request for the trivial bit of changing one number.

I'd caution against just accepting such changes without careful review.

Scott K

On December 6, 2019 9:34:59 AM UTC, Jonathan Carter <jcc@debian.org> wrote:
>Hey debian python team
>
>We currently have a few merge requests open:
>
>== tools ==
>
>Count: 6
>
>https://salsa.debian.org/groups/python-team/tools/-/merge_requests
>
>== papt ==
>
>Count: 8
>
>https://salsa.debian.org/groups/python-team/applications/-/merge_requests
>
>== dpmt ==
>
>Count: 31
>
>https://salsa.debian.org/groups/python-team/modules/-/merge_requests
>
>
>I merged a bunch of trivial ones yesterday, but even then it seems like
>we have some problems which might need some update in our policy in
>dealing with merge requests.
>
>I noticed that one MR fixed some typos but did it in the upstream
>source
>directly, which isn't all that useful to us.
>
>For other MRs, I noticed that many small changes in the packaging
>didn't
>have an associated changelog entry with it, so I had to dch to add a
>changelog entry. I think for small changes I'd prefer the person who
>submits the MR to add them. For larger ones it probably makes sense not
>to do that since it might take longer.
>
>Any suggestions? How about we draft some MR policy in gobby and get it
>added to the PAPT/DPMT policies?
>
>-Jonathan

[toc] | [prev] | [next] | [standalone]

#12116

[Multipart message — attachments visible in raw view] — view raw

On 19-12-06 04 h 34, Jonathan Carter wrote:
> For other MRs, I noticed that many small changes in the packaging didn't
> have an associated changelog entry with it, so I had to dch to add a
> changelog entry. I think for small changes I'd prefer the person who
> submits the MR to add them. For larger ones it probably makes sense not
> to do that since it might take longer.

I rarely add a changelog entry when creating MRs, as I feel it often is
a burden for the maintainers if the MR isn't immediately merged and new
releases are made (creates merge conflicts, etc.).

-- 
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Louis-Philippe Véronneau
  ⢿⡄⠘⠷⠚⠋   pollo@debian.org / veronneau.org
  ⠈⠳⣄

[toc] | [prev] | [next] | [standalone]

#12117

[Multipart message — attachments visible in raw view] — view raw

On Fri, 06 Dec 2019, Louis-Philippe Véronneau wrote:
> On 19-12-06 04 h 34, Jonathan Carter wrote:
> > For other MRs, I noticed that many small changes in the packaging didn't
> > have an associated changelog entry with it, so I had to dch to add a
> > changelog entry. I think for small changes I'd prefer the person who
> > submits the MR to add them. For larger ones it probably makes sense not
> > to do that since it might take longer.
> 
> I rarely add a changelog entry when creating MRs, as I feel it often is
> a burden for the maintainers if the MR isn't immediately merged and new
> releases are made (creates merge conflicts, etc.).

And it's also painful when you use "gbp dch", having a commit in the
middle introduce a changelog entry means that the next "gbp dch" run
might miss some commits that need to be documented.

Not everybody is sold to the idea of using "gbp dch" but it's definitely
cleaner IMO. Commits that do not modify debian/changelog are also easier
to cherry-pick between different branches, etc.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog <hertzog@debian.org>
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋    The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄⠀⠀⠀⠀   Debian Long Term Support: https://deb.li/LTS

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.python

csiph-web