Git Packaging Round 1: Hopefully Easy Stuff

classic Classic list List threaded Threaded
46 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Git Packaging Round 1: Hopefully Easy Stuff

Sam Hartman-3


Hi.

In my latest bits from the DPL, I said that I was going to start a
couple of consensus-forming discussions on debian-devel surrounding Git
and packaging.  These will run similarly to the Debhelper/Dh discussion.
The issues are more complicated, and so I want to spread things out a
bit.

In this message I want to cover a few things that I think are
non-controversial.

If you disagree with any of the following, please reply.

BTS for Patches
===============

Regardless of anything they are doing with Git, maintainers of a package
are expected to process patches sent to the BTS.  You cannot respond to
a patch telling someone they need to file a merge request to have it
considered.
Today, the BTS is still very much an appropriate way to propose changes
to a Debian package.

Unmonitored Merge Requests Harmful
==================================

If you're going to set up a repository for Debian packaging on Salsa,
you need to either:

1) turn off merge requests

or

2) Monitor them and process them.

I don't want to get into how frequently you look at merge requests just
as I don't want to get into how responsive you need to be to the BTS.
But I hope we can agree that if you're going to have merge requests
enabled that they cannot go into a black hole.

I think the question of whether people should use merge requests is more
complex.  Sean pointed out some reasons why we might prefer the BTS.
And yet it's clear that many people do find merge requests useful.


VCS Packaging Info
==================

If you have a public repo then you should use vcs-git and vcs-browser.
I'm reasonably sure this is even already well documented.



Thanks for your consideration,

--Sam

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 1: Hopefully Easy Stuff

Jonathan Carter (highvoltage)-2
On 2019/08/14 20:02, Sam Hartman wrote:
> If you're going to set up a repository for Debian packaging on Salsa,
> you need to either:
>
> 1) turn off merge requests

That would be quite horrible IMHO, this is the de facto method that
young (let's say under 35 years old) developers use to submit
improvements to other projects. We have all the infrastructure and tools
conveniently in place to accommodate this, it seems suboptimal to treat
MRs as a second class citizen.

> 2) Monitor them and process them.
>
> I don't want to get into how frequently you look at merge requests just
> as I don't want to get into how responsive you need to be to the BTS.
> But I hope we can agree that if you're going to have merge requests
> enabled that they cannot go into a black hole.
>
> I think the question of whether people should use merge requests is more
> complex.  Sean pointed out some reasons why we might prefer the BTS.
> And yet it's clear that many people do find merge requests useful.

The Debian QA DDPO pages will show you whether you have MRs on the same
page where you see how many open bugs, RC bugs, lintian errors, etc you
have. This makes it super easy to notice MRs when doing routine checks
of your general package health overview.

-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.

Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 1: Hopefully Easy Stuff

Sam Hartman-3
>>>>> "Jonathan" == Jonathan Carter <[hidden email]> writes:

    Jonathan> On 2019/08/14 20:02, Sam Hartman wrote:
    >> If you're going to set up a repository for Debian packaging on
    >> Salsa, you need to either:
    >>
    >> 1) turn off merge requests

    Jonathan> That would be quite horrible IMHO, this is the de facto
    Jonathan> method that young (let's say under 35 years old)
    Jonathan> developers use to submit improvements to other
    Jonathan> projects. We have all the infrastructure and tools
    Jonathan> conveniently in place to accommodate this, it seems
    Jonathan> suboptimal to treat MRs as a second class citizen.
And yet, consider the following cases:

* You are simply mirroring from somewhere else to Salsa

* You buy Sean's argument that MRs aren't stable enough to capture
  discussion long-term and/or we're unlikely to port forward the
  database of merge requests if we move away from Gitlab.

I think that merge requests are quite valuable, but I'm quite certain
we're not going to get to "you must enable merge requests."

Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 1: Hopefully Easy Stuff

Jonas Smedegaard-2
In reply to this post by Jonathan Carter (highvoltage)-2
Quoting Jonathan Carter (2019-08-14 20:25:05)

> On 2019/08/14 20:02, Sam Hartman wrote:
> > If you're going to set up a repository for Debian packaging on Salsa,
> > you need to either:
> >
> > 1) turn off merge requests
>
> That would be quite horrible IMHO, this is the de facto method that
> young (let's say under 35 years old) developers use to submit
> improvements to other projects. We have all the infrastructure and tools
> conveniently in place to accommodate this, it seems suboptimal to treat
> MRs as a second class citizen.
Interesting!

I systematically turn off Gitlab MR support for projects I am involved
in, because I am not confortable and efficient using it myself, it is
additional work for me to tune into (there is more to it than getting
notification about MRs pending!), and I already have a workflow that
works well for me and the teams I work with.

This is similar to my turning off Gitlab issue tracking.  And not using
webforums and Matrix and Jabber and Diaspora and and and all the places
where potential helpers may be waiting for me to reach out to them.

I do want to collaborate.  Sincerely!  I would have wanted that Debian
reached out to me on Jabber when many years ago - they didn't and I had
to do more work to get a text-chat experience with my peers.

I try hard to turn off any and all features except core git hosting.  
Did same for Alioth, and am disappointed that features are enabled by
default putting pressure on me to change working habits.


 - Jonas

--
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 1: Hopefully Easy Stuff

Jonathan Carter-6
In reply to this post by Sam Hartman-3
On 2019/08/14 20:36, Sam Hartman wrote:
> And yet, consider the following cases:
>
> * You are simply mirroring from somewhere else to Salsa
>
> * You buy Sean's argument that MRs aren't stable enough to capture
>   discussion long-term and/or we're unlikely to port forward the
>   database of merge requests if we move away from Gitlab.

Ah yes, good points.

-Jonathan

Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 1: Hopefully Easy Stuff

Holger Levsen-2
In reply to this post by Jonas Smedegaard-2
On Wed, Aug 14, 2019 at 09:08:44PM +0200, Jonas Smedegaard wrote:
> I systematically turn off Gitlab MR support for projects I am involved
> in, because I am not confortable and efficient using it myself, it is

what helps me is having a note with this line:

git config alias.mr '!sh -c "git fetch $1 merge-requests/$2/head:mr-$1-$2 && git checkout mr-$1-$2" -'

which I copy & paste into a shell running inside the directory of a git
repo, and after that "git mr origin 2" will checkout the merge request #2.

Thanks to Raphael Hertzog for pointing this out some time ago.


--
cheers,
        Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Dance like no one's watching. Encrypt like everyone is.

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 1: Hopefully Easy Stuff

Philip Hands
In reply to this post by Jonathan Carter (highvoltage)-2
Jonathan Carter <[hidden email]> writes:

> On 2019/08/14 20:02, Sam Hartman wrote:
>> If you're going to set up a repository for Debian packaging on Salsa,
>> you need to either:
>>
>> 1) turn off merge requests
>
> That would be quite horrible IMHO, this is the de facto method that
> young (let's say under 35 years old) developers use to submit
> improvements to other projects. We have all the infrastructure and tools
> conveniently in place to accommodate this, it seems suboptimal to treat
> MRs as a second class citizen.
Would it not be possible to have a webhook (or similar) that could
receive notifications of MRs, and automatically create a bug report
containing the current state of the MR as a patch?

Of course, if people then fiddle with their MR, the patch may well be
useless, which is likely to force one to actually deal with the MR
within gitlab anyway (or to bugs in the BTS with streams of mostly
useless generated patches ... but at least one would have captured the
history that way).

If the generated bug report included links to guide the maintainer
straight to the diff as it currently exists that would minimise the pain
for non-MR-happy maintainers ... along with a link to a wiki page where
we could collect tips like the one just mentioned by Holger.

The webhook could also add a comment to the MR linking to the new bug in
the BTS.

That way, people that intend to mostly ignore MRs could still allow
people to make contributions in their preferred style, while gently
guiding them towards interacting via the BTS, simply by adding the
relevant webhook to the project's Integrations settings.

That seems rather more welcoming than simply turning MRs off, which is
likely to make some people go and find something more enjoyable to do
with their time than contributing to that project.

Cheers, Phil.
--
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 1: Hopefully Easy Stuff

Sam Hartman-3
>>>>> "Philip" == Philip Hands <[hidden email]> writes:

    Philip> Jonathan Carter <[hidden email]> writes:
    >> On 2019/08/14 20:02, Sam Hartman wrote:
    >>> If you're going to set up a repository for Debian packaging on
    >>> Salsa, you need to either:
    >>>
    >>> 1) turn off merge requests
    >>
    >> That would be quite horrible IMHO, this is the de facto method
    >> that young (let's say under 35 years old) developers use to
    >> submit improvements to other projects. We have all the
    >> infrastructure and tools conveniently in place to accommodate
    >> this, it seems suboptimal to treat MRs as a second class citizen.

    Philip> Would it not be possible to have a webhook (or similar) that
    Philip> could receive notifications of MRs, and automatically create
    Philip> a bug report containing the current state of the MR as a
    Philip> patch?


It would be possible to have many things.
I think it's great that you're coming up with these ideas, and I hope
that you or someone capture them somewhere.

If such a web hook existed, it would be a great way to make merge
requests available for a certain class of maintainers.

I don't think they fit well into a discussion I'm facilitating about
what our current best practices should be.

While we do sometimes defer choosing a best practice because something
else might be possible, I think that decision to defer articulating what
we have today is rarely in and of itself a best practice:-)

Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 1: Hopefully Easy Stuff

Adam Borowski-3
In reply to this post by Holger Levsen-2
On Wed, Aug 14, 2019 at 10:32:29PM +0000, Holger Levsen wrote:

> On Wed, Aug 14, 2019 at 09:08:44PM +0200, Jonas Smedegaard wrote:
> > I systematically turn off Gitlab MR support for projects I am involved
> > in, because I am not confortable and efficient using it myself, it is
>
> what helps me is having a note with this line:
>
> git config alias.mr '!sh -c "git fetch $1 merge-requests/$2/head:mr-$1-$2 && git checkout mr-$1-$2" -'
>
> which I copy & paste into a shell running inside the directory of a git
> repo, and after that "git mr origin 2" will checkout the merge request #2.

Thanks!

You do want --global for the alias, though -- that removes the need to
repeat the config for every machine:checkout pair, requiring it just once
per machine.


Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Debian is one big family.  Including that weird uncle
⢿⡄⠘⠷⠚⠋⠀ and ultra-religious in-laws.
⠈⠳⣄⠀⠀⠀⠀

Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 1: Hopefully Easy Stuff

Holger Levsen-2
On Thu, Aug 15, 2019 at 07:02:37PM +0200, Adam Borowski wrote:
> You do want --global for the alias, though -- that removes the need to
> repeat the config for every machine:checkout pair, requiring it just once
> per machine.

thanks for this as well! :)


--
cheers,
        Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 1: Hopefully Easy Stuff

Vincent Bernat-3
In reply to this post by Holger Levsen-2
 ❦ 14 août 2019 22:32 +00, Holger Levsen <[hidden email]>:

>> I systematically turn off Gitlab MR support for projects I am involved
>> in, because I am not confortable and efficient using it myself, it is
>
> what helps me is having a note with this line:
>
> git config alias.mr '!sh -c "git fetch $1
> merge-requests/$2/head:mr-$1-$2 && git checkout mr-$1-$2" -'

If you prefer, you can avoid to create a local branch with:

git fetch $1 merge-requests/$2/head && git checkout FETCH_HEAD
--
"... all the modern inconveniences ..."
                -- Mark Twain

signature.asc (847 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 1: Hopefully Easy Stuff

gregor herrmann-3
In reply to this post by Jonathan Carter (highvoltage)-2
On Wed, 14 Aug 2019 20:25:05 +0200, Jonathan Carter wrote:

> On 2019/08/14 20:02, Sam Hartman wrote:
> > If you're going to set up a repository for Debian packaging on Salsa,
> > you need to either:
> > 1) turn off merge requests
> That would be quite horrible IMHO, this is the de facto method that
> young (let's say under 35 years old) developers use to submit
> improvements to other projects. We have all the infrastructure and tools
> conveniently in place to accommodate this, it seems suboptimal to treat
> MRs as a second class citizen.

<rant type="unscientifc">
Most MRs I've seen so far on salsa lead to packages not building
anymore.
</rant>

And I dispute that we have "the infrastructure and tools". Because
gitlab is targetted at single projects of single persons; for a team
you don't know who gets mails about MRs / who has enabled those
notifications. -- Whereas bug reports arrive at the maintainer
mailing list.

(And the poor support for teams in gitlab is a general issue IMO.
But that's another discussion.)
 

> > 2) Monitor them and process them.
> >
> > I don't want to get into how frequently you look at merge requests just
> > as I don't want to get into how responsive you need to be to the BTS.
> > But I hope we can agree that if you're going to have merge requests
> > enabled that they cannot go into a black hole.
> >
> > I think the question of whether people should use merge requests is more
> > complex.  Sean pointed out some reasons why we might prefer the BTS.
> > And yet it's clear that many people do find merge requests useful.
>
> The Debian QA DDPO pages will show you whether you have MRs on the same
> page where you see how many open bugs, RC bugs, lintian errors, etc you
> have. This makes it super easy to notice MRs when doing routine checks
> of your general package health overview.
DDPO is not a useful tool for maintainers with lots of packages and
for teams. (And I don't see any MRs there but that might be
correlated. If you have lots of time, grab a $beverage and load
https://qa.debian.org/developer.php?login=pkg-perl-maintainers@...
)


Personally I am monitoring MRs and I'm acting on them. But my
enthusiasm about them is quite limited so far. So I think Sam's
attempt in wording ("turn them off or monitor and process them") is
quiter accurate.


Cheers,
gregor

--
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Flying Pickets: Road To Nowhere

signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 1: Hopefully Easy Stuff

Russ Allbery-2
In reply to this post by Jonathan Carter (highvoltage)-2
Jonathan Carter <[hidden email]> writes:

> The Debian QA DDPO pages will show you whether you have MRs on the same
> page where you see how many open bugs, RC bugs, lintian errors, etc you
> have. This makes it super easy to notice MRs when doing routine checks
> of your general package health overview.

Is there some way for me to get email when there's a new MR, the way that
GitHub does?

Unless there's a push notification, I'm probably not going to remember to
go check something when I'm busy, so I'll probably turn off MRs, even
though I generally agree with you that they're the way a lot of people
prefer to contribute and it's kind of a shame.  But having to poll some
external system is not really viable for me.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 1: Hopefully Easy Stuff

David Prévot-2
In reply to this post by gregor herrmann-3
Hi,

Le 15/08/2019 à 16:38, gregor herrmann a écrit :
> On Wed, 14 Aug 2019 20:25:05 +0200, Jonathan Carter wrote:

>> The Debian QA DDPO pages will show you whether you have MRs
[…]
> I don't see any MRs there

You need to look for (or grep) the exclamation marks (yay, discrete).

> https://qa.debian.org/developer.php?login=pkg-perl-maintainers@...

There are 5 repositories as I’m writing these lines, one of them with 2
MR (noted as « Git !2 »).

Regards

David


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 1: Hopefully Easy Stuff

Raphael Hertzog-3
In reply to this post by Russ Allbery-2
On Thu, 15 Aug 2019, Russ Allbery wrote:
> Jonathan Carter <[hidden email]> writes:
>
> > The Debian QA DDPO pages will show you whether you have MRs on the same
> > page where you see how many open bugs, RC bugs, lintian errors, etc you
> > have. This makes it super easy to notice MRs when doing routine checks
> > of your general package health overview.
>
> Is there some way for me to get email when there's a new MR, the way that
> GitHub does?

Sure, you just need to configure your notification level for the group or
the project that you want to get notifications. The default is "Global"
(which equates to the global default setting which usually is
"Participate") and you want to change it to "Watch".

https://docs.gitlab.com/ce/workflow/notifications.html#project-settings

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 1: Hopefully Easy Stuff

Raphael Hertzog-3
In reply to this post by Sam Hartman-3
On Wed, 14 Aug 2019, Sam Hartman wrote:
> Regardless of anything they are doing with Git, maintainers of a package
> are expected to process patches sent to the BTS.

Yes.

> You cannot respond to a patch telling someone they need to file a merge
> request to have it considered.

I would not hesitate to suggest it however... it would give me immediate
feedback on whether the package still compiles, on whether the testsuite still
passes, etc.

That in turn means that I'm more likely to process said patch in a timely
manner...

> Unmonitored Merge Requests Harmful
> ==================================

Ack.

> VCS Packaging Info
> ==================
>
> If you have a public repo then you should use vcs-git and vcs-browser.
> I'm reasonably sure this is even already well documented.

Ack.

Cheers,
--
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

signature.asc (535 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Consensus Call: Git Packaging Round 1

Sam Hartman-3
In reply to this post by Sam Hartman-3
Hi.
I'm going slower than I did for the dh discussion mostly because
non-Debian aspects of my life are taking up a fair bit of time at the
moment.


My take is that I mostly got things right:

1) Maintainers need to respond to packages in the BTS.

2) I think I got the emphasis wrong on handling merge requests.  We
should emphasize the recommendation to handle merge requests rather than
leading off with the option of turning them off.  If you are going to
handle merge requests, setting your notification level to "watch" rather
than "global" will give you email notifications of merge requests.

However it's far preferable to turn off merge requests than to leave
them on and not monitor them.

3) We seem to be good on recommending vcs-* in packages that use Git.

Next steps:

Obviously if the above doesn't seem right please reply.
I'm going to go on with the next round of questions.
At the end I'm imagining all this gets folded up into a wishlist bug on
developers-reference.
Volunteers who would be willing to help turn such a bug into a proposed
patch would be welcome.  I don't plan on doing that work myself.

Reply | Threaded
Open this post in threaded view
|

Re: Consensus Call: Git Packaging Round 1

Andrej Shadura-2
Hi,

Not replying to your email at all, but it has reminded me of something
I wanted to state, which, while tangentially related to the topic, is
connected to other Git-related work currently happening in Debian.

I noticed some people [citation needed] think it is not important to
preserve pristine upstream tarballs with the move to Git, and it’s
okay to regenerate them from a Git branch without trying to preserve
checksums of the tarballs upstream has somehow generated.

I disagree with that point of view, and I think it is important to
keep them, not only for Debian, but even more so for Debian’s
downstreams.

I understand that’s not everyone’s opinion, and I’m open to
well-versed and technically sound attempts to convince me it’s
something we don’t necessarily want to do.

I just had an impression this is not being considered and sort of
assumed a consensus that we won’t keep them in Git when we move to
git-debpush workflows. Let’s discuss it instead of have people
assuming things potentially incorrect :)

--
Cheers,
  Andrej

Reply | Threaded
Open this post in threaded view
|

Re: Consensus Call: Git Packaging Round 1

Sam Hartman-3
>>>>> "Andrej" == Andrej Shadura <[hidden email]> writes:

    Andrej> important to preserve pristine upstream tarballs with the
    Andrej> move to Git, and it’s okay to regenerate them from a Git
    Andrej> branch without trying to preserve checksums of the tarballs
    Andrej> upstream has somehow generated.

    Andrej> I disagree with that point of view, and I think it is
    Andrej> important to keep them, not only for Debian, but even more
    Andrej> so for Debian’s downstreams.

That's on my list for discussion in round 3.
I'd ask you to have your argument about why this is important ready to
present in a couple of weeks.

I think that people value upstream integrity.
The interesting question will be why tarball integrity is better or
worse than git tag integrity.

--Sam

Reply | Threaded
Open this post in threaded view
|

Re: Git Packaging Round 1: Hopefully Easy Stuff

Bernd Zeimetz
In reply to this post by Sam Hartman-3
Hi Sam,

> BTS for Patches
> ===============
>
> Regardless of anything they are doing with Git, maintainers of a package
> are expected to process patches sent to the BTS.  You cannot respond to
> a patch telling someone they need to file a merge request to have it
> considered.
> Today, the BTS is still very much an appropriate way to propose changes
> to a Debian package.

I agree with that, although I think that we should tell bug reporters
that - if the package is maintained on salsa (or maybe github, gitlab,
...), then we prefer merge/pull requests.


> Unmonitored Merge Requests Harmful
> ==================================
> [...]

Thats why I would suggest

3. If a package is maintained on salsa, maintainers have to process
merge requests. Please note that I did not write "accept". Denying
requests is very valid of course.

>
> VCS Packaging Info
> ==================
>
> If you have a public repo then you should use vcs-git and vcs-browser.
> I'm reasonably sure this is even already well documented.
Definitely. If that is not yet in policy, it should go in there asap.


Bernd

--
 Bernd Zeimetz                            Debian GNU/Linux Developer
 http://bzed.de                                http://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F


signature.asc (849 bytes) Download Attachment
123