Re: salsa.debian.org: merge requests and such

[Ian Jackson]

Guido Günther writes ("Re: salsa.debian.org: merge requests and such"):
> On Fri, Nov 09, 2018 at 07:42:13PM +, Holger Levsen wrote:
> > - git wise, I think, I reverted these commits, pushed my changes and
> >   merged the reverted commits again. No big deal, except a bit of messy
> >   history. There are several strategies to deal with, I choose the
> >   quickest path.
> 
> Maybe even simpler: Create the tag for your upload (e.g. gbp tag). 'git
> push' that tag. 'git pull' the changes (which uses the merge machinery
> in case of overlapping changes).

If you are using dgit then the git tag was of course done already for
you.  So all you need to do is:
  git pull salsa master   # makes the merge
  git push salsa master

> You then have a tag with the released package (it's not pointing to a
> commit on master but nobody says it has to) and all the changes
> integrated into master and the contributors changes will end up in the
> next release without any "messy" history due to reverts.

Precisely.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: salsa.debian.org: merge requests and such

[Guido Günther]

Hi,
On Fri, Nov 09, 2018 at 07:42:13PM +, Holger Levsen wrote:
> On Fri, Nov 09, 2018 at 05:41:53PM +, Matthew Vernon wrote:
> > The particular commit was fine (and had it come as a MR or bug report or
> > whatever I'd have had no problem with it at all).
>  
> I'm not sure why you are so bothered by it.
> 
> Granted, when I first experienced a git push not working after I
> uploaded some package, I was also puzzled and a bit annoyed that someone
> pushed into the master branch of 'my' package, but upon reflection I
> decided:
> 
> - this is great. someone contributed to make *many* Debian packages
>   better.
> - git wise, I think, I reverted these commits, pushed my changes and
>   merged the reverted commits again. No big deal, except a bit of messy
>   history. There are several strategies to deal with, I choose the
>   quickest path.

Maybe even simpler: Create the tag for your upload (e.g. gbp tag). 'git
push' that tag. 'git pull' the changes (which uses the merge machinery
in case of overlapping changes).

You then have a tag with the released package (it's not pointing to a
commit on master but nobody says it has to) and all the changes
integrated into master and the contributors changes will end up in the
next release without any "messy" history due to reverts.
Cheers,
 -- Guido

> - I also learned to first do 'git fetch' before uploading. Maybe someone
>   put another present into git?
> 
> So, yes, at first I was surprised too, now I'm gladly looking forward to
> more of these contributions.
> 
> That said, there is one exception, src:piuparts, where I'll dislike
> drive-by commits to master. Why is explained in the CONTRIBUTING document
> in the source code. Here I will most likely again just revert the
> commits in the master branch, merge them in the develop branch and tell
> the commiter.
> 
> And surely, if you don't like other people contributing to 'your' stuff
> directly, you are absolutly free to not have your packages in the debian
> namespace. I do however think that having packages there by default is a
> very good idea.
> 
> 
> -- 
> cheers,
>   Holger
> 
> ---
>holger@(debian|reproducible-builds|layer-acht).org
>PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Re: salsa.debian.org: merge requests and such

[Herbert Fortes]

On 12/11/2018 13:02, Ian Jackson wrote:

Colin Watson writes ("Re: salsa.debian.org: merge requests and such"):

Honestly, I think it's better for Debian as a whole that people should
be able to do that kind of bulk cleanup with absolutely minimal
friction,


I absolutely agree.

The disruption from this kind of thing is minimal, and clearly IMO
outweighs the benfit.

Ultimately whether to allow this is a matter for the maintainer but I
think maintainers shoudl be encouraged to allow it - even, to
encourage it.

And there should be clear guidance for other DDs on when and how to
exercise this authority.  That should include the level of confidence
that a DD should have before making such a commit; whether there
should be a `mass commit' d-devel review process; and whether such
changes should be accompanied by a changelog entry.



When I run 'gbp dch' everything goes to debian/changelog anyway.

But no problem. I am OK to 'Debian as a whole'.



Regards,
Herbert

Re: salsa.debian.org: merge requests and such

[Ian Jackson]

Colin Watson writes ("Re: salsa.debian.org: merge requests and such"):
> Honestly, I think it's better for Debian as a whole that people should
> be able to do that kind of bulk cleanup with absolutely minimal
> friction,

I absolutely agree.

The disruption from this kind of thing is minimal, and clearly IMO
outweighs the benfit.

Ultimately whether to allow this is a matter for the maintainer but I
think maintainers shoudl be encouraged to allow it - even, to
encourage it.

And there should be clear guidance for other DDs on when and how to
exercise this authority.  That should include the level of confidence
that a DD should have before making such a commit; whether there
should be a `mass commit' d-devel review process; and whether such
changes should be accompanied by a changelog entry.

Ian.

Re: salsa.debian.org: merge requests and such

[Colin Watson]

On Sat, Nov 10, 2018 at 10:36:53AM -0200, Herbert Fortes wrote:
> But why the new debian/changelog? It is a honest question.

Seems perfectly reasonable to me (and indeed I'd have thought it was
best practice): make a change, add a changelog entry to go with it.  If
the maintainer wants to do something different when uploading the
package then they can always adjust it themselves.

-- 
Colin Watson   [cjwat...@debian.org]

Re: salsa.debian.org: merge requests and such

[James McCoy]

On Sun, Nov 11, 2018 at 01:51:56PM +, Jonathan Dowland wrote:
> On Fri, Nov 09, 2018 at 04:57:51PM +, Matthew Vernon wrote:
> > That's what Vcs-Git et al are for, isn't it?
> 
> I'm sorry I don't understand what you're saying.

That was in response to the visibility aspect of your email.  In terms
of visibility, it doesn't matter where the repo is hosted or whether
it's in Salsa's debian org or one's own namespace -- Vcs-Git clearly
tells people where to find it.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Re: salsa.debian.org: merge requests and such

[Jonathan Dowland]

On Fri, Nov 09, 2018 at 04:57:51PM +, Matthew Vernon wrote:

That's what Vcs-Git et al are for, isn't it?


I'm sorry I don't understand what you're saying.

Right now, the only way that someone can indicate that a package is
collaboratively maintained via the control file is to have their Vcs-Git
pointing at salsa.../debian/*. (contrast this to the alioth arrangement,
where the Maintainer: field was also set to indicate this)

Therefore, the salsa "Debian" project is carrying a lot more meaning
than any other salsa project, or other potential VCS URI.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: salsa.debian.org: merge requests and such

[Marc Haber]

On Tue, 6 Nov 2018 15:43:41 + (UTC), Felipe Sateler
 wrote:
>But for example, about a month ago Ond?ej Nový 
>changed the Format: url of d/copyright to use https on one of my packages 
>(and I assume a lot more), and didn't notify me. I don't think it is 
>reasonable to ask for coordination for this type of changes, and I would 
>agree that even notifying is too much effort if this was done salsa-wide. 
>Some fixes are better just done than talked about :).

If that would happen to one of my packages, it would be work for me to
verify that the changed links would still work. A commit comment like
"(URLs verified working on $DATESTAMP)" would save me that work since
I'd _know_ that somebody else already did it, and it fits well into
the workflow.

>BTW, thanks Ond?ej Nový for those "editorial" fixes!

+1.

>Additionally, if one is doing an NMU, I think that should be pushed to 
>salsa if the permissions allow it.

To master, or to an NMU branch?

Greetings
Marc, big fan of branches
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: salsa.debian.org: merge requests and such

[Herbert Fortes]

On 10/11/2018 17:18, Phil Morrell wrote:

On Sat, Nov 10, 2018 at 10:36:53AM -0200, Herbert Fortes wrote:

On 09/11/2018 20:26, Colin Watson wrote:

I guessed that the particular commit was
https://salsa.debian.org/debian/pcre2/commit/6c14b51ddfc45604fd805bcadc810d437f09a30f.
(The same developer has also been doing a number of other minor cleanups
in many other packages along the same lines.)


The fix is good.

But why the new debian/changelog? It is a honest question.


It's just an alternative personal style. 


I have the same opinion.

I also think that if a package has a maintainer the maintainer's
personal style should be respected. That is the social thing
said before.

Do a fix is collab maint. Set my personal style in many other
packages that I am not directly responsible for is not.

I understand a minor cleanup that is done directly in the repository.
But doing a patch you pay attention to the fix.

Re: salsa.debian.org: merge requests and such

[Phil Morrell]

On Sat, Nov 10, 2018 at 10:36:53AM -0200, Herbert Fortes wrote:
> On 09/11/2018 20:26, Colin Watson wrote:
> > I guessed that the particular commit was
> > https://salsa.debian.org/debian/pcre2/commit/6c14b51ddfc45604fd805bcadc810d437f09a30f.
> > (The same developer has also been doing a number of other minor cleanups
> > in many other packages along the same lines.)
> 
> The fix is good.
> 
> But why the new debian/changelog? It is a honest question.

It's just an alternative personal style. Some people like to hand curate
the changelog in a standalone commit, especially if not every commit is
worth mentioning, or the version number needs changing. Other people
want there to be some record of work in progress, showing up on e.g.
tracker.debian.org or qa.


signature.asc
Description: PGP signature

Re: salsa.debian.org: merge requests and such

[Herbert Fortes]

On 09/11/2018 20:26, Colin Watson wrote:

On Fri, Nov 09, 2018 at 05:41:53PM +, Matthew Vernon wrote:

Ian Jackson  writes:

Matthew Vernon writes ("Re: salsa.debian.org: merge requests and such"):

Colin Watson  writes:

This seems like a little bit of an overreaction to somebody removing a
single redundant line from a control file, though.  Is moving it really
worth the added friction?


It's more a reaction to the "if you didn't want random commits onto
master, you shouldn't have put it under debian/" policy. I don't, so I
shouldn't have.


We're not talking about "random" commits, though, are we ?  We're
talking about a commit that a DD thought was very likely a good idea.
Were they wrong ?  It would be nice to have a proper reference.


The particular commit was fine (and had it come as a MR or bug report or
whatever I'd have had no problem with it at all).


I guessed that the particular commit was
https://salsa.debian.org/debian/pcre2/commit/6c14b51ddfc45604fd805bcadc810d437f09a30f.
(The same developer has also been doing a number of other minor cleanups
in many other packages along the same lines.)


The fix is good.

But why the new debian/changelog? It is a honest question.



Regards,
Herbert

Re: salsa.debian.org: merge requests and such

[Colin Watson]

On Fri, Nov 09, 2018 at 07:42:13PM +, Holger Levsen wrote:
> Granted, when I first experienced a git push not working after I
> uploaded some package, I was also puzzled and a bit annoyed that someone
> pushed into the master branch of 'my' package, but upon reflection I
> decided:
> 
> - this is great. someone contributed to make *many* Debian packages
>   better.
> - git wise, I think, I reverted these commits, pushed my changes and
>   merged the reverted commits again. No big deal, except a bit of messy
>   history. There are several strategies to deal with, I choose the
>   quickest path.
> - I also learned to first do 'git fetch' before uploading. Maybe someone
>   put another present into git?

For the record, I think the strategy I took was even quicker:

 * "git push --follow-tags" *before* uploading (this has been my
   invariable habit for years)
 * oh, push failed.  "git pull --rebase" and resolve conflicts
 * check new commits
 * build source package again, test, push, upload

-- 
Colin Watson   [cjwat...@debian.org]

Re: salsa.debian.org: merge requests and such

[Colin Watson]

On Fri, Nov 09, 2018 at 05:41:53PM +, Matthew Vernon wrote:
> Ian Jackson  writes:
> > Matthew Vernon writes ("Re: salsa.debian.org: merge requests and such"):
> >> Colin Watson  writes:
> >> > This seems like a little bit of an overreaction to somebody removing a
> >> > single redundant line from a control file, though.  Is moving it really
> >> > worth the added friction?
> >> 
> >> It's more a reaction to the "if you didn't want random commits onto
> >> master, you shouldn't have put it under debian/" policy. I don't, so I
> >> shouldn't have.
> >
> > We're not talking about "random" commits, though, are we ?  We're
> > talking about a commit that a DD thought was very likely a good idea.
> > Were they wrong ?  It would be nice to have a proper reference.
> 
> The particular commit was fine (and had it come as a MR or bug report or
> whatever I'd have had no problem with it at all).

I guessed that the particular commit was
https://salsa.debian.org/debian/pcre2/commit/6c14b51ddfc45604fd805bcadc810d437f09a30f.
(The same developer has also been doing a number of other minor cleanups
in many other packages along the same lines.)

Honestly, I think it's better for Debian as a whole that people should
be able to do that kind of bulk cleanup with absolutely minimal
friction, rather than the "open 2000 bugs, wait a year, find that 500 of
them are still open" dance that I'm sure many of us are familiar with;
it's one thing when it requires non-trivial thought or testing or when
the substance might in some way be controversial, but when the commits
are this simple it's hard to see a cost-benefit analysis working out
favourably for filing a large number of bugs or even MRs, either for the
developer doing the original work or the maintainers receiving the
patches.

(I do have a few of the packages I maintain in slightly more restrictive
namespaces, admittedly, in cases where my opinion is that working on
them requires an unusual amount of care, but they're still team
namespaces; and I could be convinced that I should open them up further.
I mostly use the "debian" namespace, though, and am happy not to have to
put more than the absolute bare minimum of effort into dealing with the
sort of "chore" commits being done directly here as a result.)

-- 
Colin Watson   [cjwat...@debian.org]

Re: salsa.debian.org: merge requests and such

[Holger Levsen]

On Fri, Nov 09, 2018 at 05:41:53PM +, Matthew Vernon wrote:
> The particular commit was fine (and had it come as a MR or bug report or
> whatever I'd have had no problem with it at all).
 
I'm not sure why you are so bothered by it.

Granted, when I first experienced a git push not working after I
uploaded some package, I was also puzzled and a bit annoyed that someone
pushed into the master branch of 'my' package, but upon reflection I
decided:

- this is great. someone contributed to make *many* Debian packages
  better.
- git wise, I think, I reverted these commits, pushed my changes and
  merged the reverted commits again. No big deal, except a bit of messy
  history. There are several strategies to deal with, I choose the
  quickest path.
- I also learned to first do 'git fetch' before uploading. Maybe someone
  put another present into git?

So, yes, at first I was surprised too, now I'm gladly looking forward to
more of these contributions.

That said, there is one exception, src:piuparts, where I'll dislike
drive-by commits to master. Why is explained in the CONTRIBUTING document
in the source code. Here I will most likely again just revert the
commits in the master branch, merge them in the develop branch and tell
the commiter.

And surely, if you don't like other people contributing to 'your' stuff
directly, you are absolutly free to not have your packages in the debian
namespace. I do however think that having packages there by default is a
very good idea.


-- 
cheers,
Holger

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


signature.asc
Description: PGP signature

Re: salsa.debian.org: merge requests and such

[Matthew Vernon]

Ian Jackson  writes:

> Matthew Vernon writes ("Re: salsa.debian.org: merge requests and such"):
>> Colin Watson  writes:
>> > This seems like a little bit of an overreaction to somebody removing a
>> > single redundant line from a control file, though.  Is moving it really
>> > worth the added friction?
>> 
>> It's more a reaction to the "if you didn't want random commits onto
>> master, you shouldn't have put it under debian/" policy. I don't, so I
>> shouldn't have.
>
> We're not talking about "random" commits, though, are we ?  We're
> talking about a commit that a DD thought was very likely a good idea.
> Were they wrong ?  It would be nice to have a proper reference.

The particular commit was fine (and had it come as a MR or bug report or
whatever I'd have had no problem with it at all).

Regards,

Matthew

-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org

Re: salsa.debian.org: merge requests and such

[Ian Jackson]

Matthew Vernon writes ("Re: salsa.debian.org: merge requests and such"):
> Colin Watson  writes:
> > This seems like a little bit of an overreaction to somebody removing a
> > single redundant line from a control file, though.  Is moving it really
> > worth the added friction?
> 
> It's more a reaction to the "if you didn't want random commits onto
> master, you shouldn't have put it under debian/" policy. I don't, so I
> shouldn't have.

We're not talking about "random" commits, though, are we ?  We're
talking about a commit that a DD thought was very likely a good idea.
Were they wrong ?  It would be nice to have a proper reference.

It might be nice to have clearer guidance about exactly what level of
certainty a DD ought to have before making such a commit.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: salsa.debian.org: merge requests and such

[Matthew Vernon]

Jonathan Dowland  writes:

> On Fri, Nov 09, 2018 at 11:54:50AM +, Matthew Vernon wrote:
>>Putting it under a personal namespace doesn't make it much less visible,
>>and folk can still open MRs...
>
> Oh I beg to differ, there's a huge difference of visibility between the
> "main" Debian project, to which we are all members, and personal
> namespaces. Not least the lack of any implied rules of behaviour.

That's what Vcs-Git et al are for, isn't it?

Regards,

Matthew

-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org

Re: salsa.debian.org: merge requests and such

[Matthew Vernon]

Colin Watson  writes:

> On Fri, Nov 09, 2018 at 11:54:50AM +, Matthew Vernon wrote:
>> Jonathan Dowland  writes:
>> > On Tue, Nov 06, 2018 at 03:42:01PM +, Matthew Vernon wrote:
>> >>Hm, I had not quite appreciated that was the expected behaviour. Ah
>> >>well, I can move it :)
>> >
>> > Please re-consider whether this trade-off (other people pushing to
>> > master) is a small price to pay for the advantages to you and/or the
>> > project of your package sources in the Debian project (more eyes, bus
>> > factor…)
>> 
>> Putting it under a personal namespace doesn't make it much less visible,
>> and folk can still open MRs...
>
> This seems like a little bit of an overreaction to somebody removing a
> single redundant line from a control file, though.  Is moving it really
> worth the added friction?

It's more a reaction to the "if you didn't want random commits onto
master, you shouldn't have put it under debian/" policy. I don't, so I
shouldn't have.

Regards,

Matthew

-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org

Re: salsa.debian.org: merge requests and such

[Jonathan Dowland]

(Please do not CC me, I am subscribed to the list and have set MFT
accordingly, or at least think I have.)

On Fri, Nov 09, 2018 at 11:54:50AM +, Matthew Vernon wrote:

Putting it under a personal namespace doesn't make it much less visible,
and folk can still open MRs...


Oh I beg to differ, there's a huge difference of visibility between the
"main" Debian project, to which we are all members, and personal
namespaces. Not least the lack of any implied rules of behaviour.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: salsa.debian.org: merge requests and such

[Colin Watson]

On Fri, Nov 09, 2018 at 11:54:50AM +, Matthew Vernon wrote:
> Jonathan Dowland  writes:
> > On Tue, Nov 06, 2018 at 03:42:01PM +, Matthew Vernon wrote:
> >>Hm, I had not quite appreciated that was the expected behaviour. Ah
> >>well, I can move it :)
> >
> > Please re-consider whether this trade-off (other people pushing to
> > master) is a small price to pay for the advantages to you and/or the
> > project of your package sources in the Debian project (more eyes, bus
> > factor…)
> 
> Putting it under a personal namespace doesn't make it much less visible,
> and folk can still open MRs...

This seems like a little bit of an overreaction to somebody removing a
single redundant line from a control file, though.  Is moving it really
worth the added friction?

-- 
Colin Watson   [cjwat...@debian.org]

Re: salsa.debian.org: merge requests and such

[Matthew Vernon]

Jonathan Dowland  writes:

> On Tue, Nov 06, 2018 at 03:42:01PM +, Matthew Vernon wrote:
>>Hm, I had not quite appreciated that was the expected behaviour. Ah
>>well, I can move it :)
>
> Please re-consider whether this trade-off (other people pushing to
> master) is a small price to pay for the advantages to you and/or the
> project of your package sources in the Debian project (more eyes, bus
> factor…)

Putting it under a personal namespace doesn't make it much less visible,
and folk can still open MRs...

Regards,

Matthew

-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org

Re: salsa.debian.org: merge requests and such

[Alex Muntada]

Hi Jacob,

> Ideally we’d change the default notification settings in Salsa
> to always send emails but that won’t work because then all DDs
> would get emails about all the merge requests in the Debian
> group.

I was wondering whether the following setup could work to have
notifications enabled by default but inside the debian group:

1. maintainers get notifications by default for all projects
2. maintainers in debian group do not get notifications by default
3. members in debian group projects should enable notifications
   for their interests one by one

I think this would solve most of the notification issues raised
in this thread for most of the projects. I haven't tried it
myself, but anyone that has a gitlab instance running could check
if it works as I suspect.

Hope this helps,
Alex

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer - log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature

Re: salsa.debian.org: merge requests and such

[Alex Muntada]

Hi Matthew,

> Relatedly, what's the etiquette about commits to master? I
> recently discovered that someone else had pushed a commit to
> the tip of master of one of the packages I maintain (and not
> notified me); when I complained I was told that emailing would
> be too much effort. Am I wrong to feel that at least a MR is
> something I should have expected as a package maintainer, not
> just commits to master?

That's where protected branches come to the rescue: you can
protect the master branch so people have to send a merge
request. Usually the rules don't apply to debian group because
all DD are maintainers in the group and maintainers can write
to master. But the repo settings can be set so nobody can write.
OTOH, protected branches may be a burden for maintainers making
mass commits to fix URLs, etc.

Ah, and make sure you're watching the project if you want to
receive notifications.

Cheers,
Alex

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer - log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature

Re: salsa.debian.org: merge requests and such

[Guido Günther]

Hi,
On Tue, Nov 06, 2018 at 04:32:29PM +0100, Guillem Jover wrote:
> Hi!
> 
> On Tue, 2018-11-06 at 15:00:03 +, Matthew Vernon wrote:
> > Jacob Adams  writes:
> > > The consensus seems to be that people should enable email
> > > notifications in salsa and open a bug when filing a merge request. 
> > >
> > > https://lists.debian.org/debian-devel/2018/08/msg00235.html
> > >
> > > https://lists.debian.org/debian-devel/2018/08/msg00259.html
> > 
> > Relatedly, what's the etiquette about commits to master? I recently
> > discovered that someone else had pushed a commit to the tip of master of
> > one of the packages I maintain (and not notified me); when I complained
> > I was told that emailing would be too much effort. Am I wrong to feel
> > that at least a MR is something I should have expected as a package
> > maintainer, not just commits to master?
> 
> Assuming that packages is under the Salsa Debian namespace, then I
> think that's what you (perhaps unknowingly :) signed up for when
> adding a repo there. See the Collab-maint sections in:
> 
>   
> 
> and
> 
>   
> 
> 
> Because, I'm not sure what's the point of hosting a git repo, on a
> platform like gitlab with its trivial forking facilities, on a group
> with wide write permissions, if you don't want others to directly
> write to it? :)

Code review. Even if you can write directly it makes sense to allow
others (e.g. people uploading a package a lot) to have a look at the
changes first.

Cheers,
 -- Guido

Re: salsa.debian.org: merge requests and such

[Andreas Metzler]

Jonathan Dowland  wrote:
> On Tue, Nov 06, 2018 at 08:06:38PM +0100, Andreas Metzler wrote:
>> Could we document this a little bit better in the wiki? This is
>> completely different than on alioth, where collab-maint was suggested
>> for basically everything that did not need a mailinglist.
>> .

> The rules were basically the same for collab-maint as they are for
> Salsa's Debian group, it even says so on that very page you linked:
> "Thanks to ACL, all Debian developers have write access on those
> repositories."

Hello,

alioth's collab-maint was a zero-admin way to have a Debian hosted GIT
repository, without implying a specific commit-policy. e.g.:
| If a maintainer wants to maintain his/her package within a VCS, (s)he
| can use the collab-maint repository even if the package is not (yet)
| collaboratively maintained. This is always useful since contributors
| are more likely to propose patch if they can be sure that the work has
| not yet been done.

i.e. e.g. for this use case patch-submitting instead of direct
committing was expected.

And this was the way it was used, although DD had commit-rights, they
would not do uncoordinated commits to master. There was no technical
barrier but a social one. Similar to package uploading. Technically
every DD has upload rights for everything, but we have a common ground
what is accepted there. The technical barriers are the same on salsa
as they were on alioth, the implicit barriers obviously have changed,
probably because forking and merge request for private projects is
easy now.

[...]
> But of course, the wiki docs can be improved, including by you :-)

I have updated the wiki, I am little bit more awake than yesterday.
;-)

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: salsa.debian.org: merge requests and such

[Jonathan Dowland]

On Tue, Nov 06, 2018 at 08:06:38PM +0100, Andreas Metzler wrote:

Could we document this a little bit better in the wiki? This is
completely different than on alioth, where collab-maint was suggested
for basically everything that did not need a mailinglist.
.


The rules were basically the same for collab-maint as they are for
Salsa's Debian group, it even says so on that very page you linked:
"Thanks to ACL, all Debian developers have write access on those
repositories."

Instead of retreating in horror, please consider that the sky did not
fall and perhaps there are many advantages to this arrangement.

But of course, the wiki docs can be improved, including by you :-)

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: salsa.debian.org: merge requests and such

[Jonathan Dowland]

On Tue, Nov 06, 2018 at 03:42:01PM +, Matthew Vernon wrote:

Hm, I had not quite appreciated that was the expected behaviour. Ah
well, I can move it :)


Please re-consider whether this trade-off (other people pushing to
master) is a small price to pay for the advantages to you and/or the
project of your package sources in the Debian project (more eyes, bus
factor…)

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.

Re: salsa.debian.org: merge requests and such

[Ondrej Novy]

Hi,

út 6. 11. 2018 v 16:46 odesílatel Felipe Sateler 
napsal:

> > That seems completely reasonable.  Making the repository accessible to
> > others is a courtesy that should not be abused.  Pushing directly to the
> > master branch of a package for which one is not an active maintainer or
> > contributor is at a minimum impolite.
>
> I disagree when it comes to the debian namespace, and the documentation
> agrees with me[1].
>

+1. If someone wants private repo, he/she can use private/user namespace
for it. We created "debian" (original collab-maint) group with RW
permissions for DD with intention. So we have place where any DD can commit
and collaborate together on one project.


> ... I don't think it is
> reasonable to ask for coordination for this type of changes, and I would
> agree that even notifying is too much effort if this was done salsa-wide.
>

any owner of repository can enable email notifications for changes inside
own repo. But sending emails "hey i commited something, please git pull" is
just crazy. Maybe we should don't use git at all just use email for sending
patches, right? :)

BTW, thanks Ondřej Nový for those "editorial" fixes!
>

yw :)

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

Re: salsa.debian.org: merge requests and such

[Joseph Herlant]

Hi,

On Tue, Nov 6, 2018 at 11:07 AM Andreas Metzler  wrote:
>
> Guillem Jover  wrote:
> > On Tue, 2018-11-06 at 15:00:03 +, Matthew Vernon wrote:
> [...]
>
> >> that at least a MR is something I should have expected as a package
> >> maintainer, not just commits to master?
> cu And- plan for the weekend: move everything except qa away from
> Debian/group - reas

Not sure exactly what the commit was but:
* maybe that person spent time trying to help or trying to fix
something that wasn't clean. Maybe the better way to go is to be
thankful for people trying to help your package being better, even if
expressed not exactly the way you wanted.
* in a community, people trying to help may result in commits that you
will have to revert but I'm not sure why all this fuss. Honestly, I've
made a bunch of MR, some worked fine, some were totally ignored or
just made people angry (for reasons I don't really get), not sure if
it would have changed anything if I would have pushed to master
directly.
* in an even broader sense, it's always a best practice to pull your
repo before working on it and not to keep local changes (at least in
case you are not awake enough and you do `rm -f ~/`+ bad copy/paste
resulting in a wipe of your homedir!)

Maybe we should have kept collab-maint as group name as it says on the
package "Collaborative maintenance"? We can't really change that now!
:)
But anyway, I'm still convinced that playing as a global team is
better than doing something separately and be mad when someone is
trying to help.

Joseph

Re: salsa.debian.org: merge requests and such

[Andreas Metzler]

Guillem Jover  wrote:
> On Tue, 2018-11-06 at 15:00:03 +, Matthew Vernon wrote:
[...]
>> that at least a MR is something I should have expected as a package
>> maintainer, not just commits to master?

> Assuming that packages is under the Salsa Debian namespace, then I
> think that's what you (perhaps unknowingly :) signed up for when
> adding a repo there. See the Collab-maint sections in:

>   

> and

>   
> 
[...]

Hello,

Could we document this a little bit better in the wiki? This is
completely different than on alioth, where collab-maint was suggested
for basically everything that did not need a mailinglist.
.

The dda-mail made this difference pretty clear:
| If you create a project within the Debian group, you are implicitly
| welcoming all DDs to contribute directly to the project.
But the wording cannot be copied over directly to the wiki, the
style's off. And I am too stupid right now to convert it. ;-)

cu And- plan for the weekend: move everything except qa away from
Debian/group - reas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: salsa.debian.org: merge requests and such

[Roberto C . Sánchez]

On Tue, Nov 06, 2018 at 03:43:41PM +, Felipe Sateler wrote:
> 
> I disagree when it comes to the debian namespace, and the documentation 
> agrees with me[1].
> 
Interesting.  I was not aware of that.  Thanks for sharing.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: salsa.debian.org: merge requests and such

[Felipe Sateler]

On Tue, 06 Nov 2018 10:17:01 -0500, Roberto C. Sánchez wrote:

> On Tue, Nov 06, 2018 at 03:00:03PM +, Matthew Vernon wrote:
>> 
>> Relatedly, what's the etiquette about commits to master? I recently
>> discovered that someone else had pushed a commit to the tip of master
>> of one of the packages I maintain (and not notified me); when I
>> complained I was told that emailing would be too much effort. Am I
>> wrong to feel that at least a MR is something I should have expected as
>> a package maintainer, not just commits to master?
>> 
>> [I don't really mean to have a go at the person concerned; I'd just
>> like to know what to expect in future...]
>> 
> That seems completely reasonable.  Making the repository accessible to
> others is a courtesy that should not be abused.  Pushing directly to the
> master branch of a package for which one is not an active maintainer or
> contributor is at a minimum impolite.

I disagree when it comes to the debian namespace, and the documentation 
agrees with me[1].

I agree that one should exercise judgement: I wouldn't commit an 
intrusive patch without discussing first. But there are many changes that 
do not need discussion. But for example, about a month ago Ondřej Nový 
changed the Format: url of d/copyright to use https on one of my packages 
(and I assume a lot more), and didn't notify me. I don't think it is 
reasonable to ask for coordination for this type of changes, and I would 
agree that even notifying is too much effort if this was done salsa-wide. 
Some fixes are better just done than talked about :).

BTW, thanks Ondřej Nový for those "editorial" fixes!

Additionally, if one is doing an NMU, I think that should be pushed to 
salsa if the permissions allow it.


[1] https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.
22Debian.22_group



-- 
Saludos,
Felipe Sateler

Re: salsa.debian.org: merge requests and such

[Matthew Vernon]

On 06/11/2018 15:32, Guillem Jover wrote:

> Because, I'm not sure what's the point of hosting a git repo, on a
> platform like gitlab with its trivial forking facilities, on a group
> with wide write permissions, if you don't want others to directly
> write to it? :)

Hm, I had not quite appreciated that was the expected behaviour. Ah
well, I can move it :)

Regards,

Matthew

Re: salsa.debian.org: merge requests and such

[Guillem Jover]

Hi!

On Tue, 2018-11-06 at 15:00:03 +, Matthew Vernon wrote:
> Jacob Adams  writes:
> > The consensus seems to be that people should enable email
> > notifications in salsa and open a bug when filing a merge request. 
> >
> > https://lists.debian.org/debian-devel/2018/08/msg00235.html
> >
> > https://lists.debian.org/debian-devel/2018/08/msg00259.html
> 
> Relatedly, what's the etiquette about commits to master? I recently
> discovered that someone else had pushed a commit to the tip of master of
> one of the packages I maintain (and not notified me); when I complained
> I was told that emailing would be too much effort. Am I wrong to feel
> that at least a MR is something I should have expected as a package
> maintainer, not just commits to master?

Assuming that packages is under the Salsa Debian namespace, then I
think that's what you (perhaps unknowingly :) signed up for when
adding a repo there. See the Collab-maint sections in:

  

and

  


Because, I'm not sure what's the point of hosting a git repo, on a
platform like gitlab with its trivial forking facilities, on a group
with wide write permissions, if you don't want others to directly
write to it? :)

Thanks,
Guillem

Re: salsa.debian.org: merge requests and such

[Roberto C . Sánchez]

On Tue, Nov 06, 2018 at 03:00:03PM +, Matthew Vernon wrote:
> 
> Relatedly, what's the etiquette about commits to master? I recently
> discovered that someone else had pushed a commit to the tip of master of
> one of the packages I maintain (and not notified me); when I complained
> I was told that emailing would be too much effort. Am I wrong to feel
> that at least a MR is something I should have expected as a package
> maintainer, not just commits to master?
> 
> [I don't really mean to have a go at the person concerned; I'd just like
> to know what to expect in future...]
> 
That seems completely reasonable.  Making the repository accessible to
others is a courtesy that should not be abused.  Pushing directly to the
master branch of a package for which one is not an active maintainer or
contributor is at a minimum impolite.

Regards,

-Roberto

-- 
Roberto C. Sánchez

Re: salsa.debian.org: merge requests and such

[Matthew Vernon]

Jacob Adams  writes:

> The consensus seems to be that people should enable email
> notifications in salsa and open a bug when filing a merge request. 
>
> https://lists.debian.org/debian-devel/2018/08/msg00235.html
>
> https://lists.debian.org/debian-devel/2018/08/msg00259.html

Relatedly, what's the etiquette about commits to master? I recently
discovered that someone else had pushed a commit to the tip of master of
one of the packages I maintain (and not notified me); when I complained
I was told that emailing would be too much effort. Am I wrong to feel
that at least a MR is something I should have expected as a package
maintainer, not just commits to master?

[I don't really mean to have a go at the person concerned; I'd just like
to know what to expect in future...]

Regards,

Matthew

-- 
"At least you know where you are with Microsoft."
"True. I just wish I'd brought a paddle."
http://www.debian.org

Re: salsa.debian.org: merge requests and such

[Joseph Herlant]

Hi Ian,

On Mon, Oct 29, 2018 at 3:51 AM Ian Jackson
 wrote:
> If people don't like the emails it generates, this should be "fixed"
> by disabling MRs rather than by disabling the email bridge.
>
> Do you know how to write such a thing ?  Where would it be
> configured ?  (Eg, what if I want to add a configurable feature to
> automatically turn an MR into a series of patchbomb emails rather than
> one email?)

If you would go for the solution I described, you'd enable a webhook
in settings > integration of your project (you'd first need to write
such integration and serve it somewhere as an endpoint).
Note that this would only be if you need to send to a specific team.
If it's for individual emails, you really should go with the built-in
"watch" on the repository as described earlier in the thread.

Joseph

Re: salsa.debian.org: merge requests and such

[Ian Jackson]

Joseph Herlant writes ("Re: salsa.debian.org: merge requests and such"):
> I wonder if we should have a custom integration enabled like we do for
> setting the tags pending. It would send an email to the maintainer
> when a MR or an issue would be created.
> I don't expect Salsa to be aware of the Maintainer and Uploader fields
> of a package, so a custom integration would make sense to me.
> This change could be scripted globally and also added to the
> salsa-scripts for when you create a repo.
> Does that sound like a reasonable solution?

Yes.  I think it will have to be enabled by default.

If people don't like the emails it generates, this should be "fixed"
by disabling MRs rather than by disabling the email bridge.

Do you know how to write such a thing ?  Where would it be
configured ?  (Eg, what if I want to add a configurable feature to
automatically turn an MR into a series of patchbomb emails rather than
one email?)

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: salsa.debian.org: merge requests and such

[Joseph Herlant]

> “My concern is that newcomers will have their merge requests ignored when 
> maintainers are not emailed. I see no workable solution as yet, so I’ll have 
> to look more into this and come back to this thread when I find one.”

I wonder if we should have a custom integration enabled like we do for
setting the tags pending. It would send an email to the maintainer
when a MR or an issue would be created.
I don't expect Salsa to be aware of the Maintainer and Uploader fields
of a package, so a custom integration would make sense to me.
This change could be scripted globally and also added to the
salsa-scripts for when you create a repo.
Does that sound like a reasonable solution?

Joseph

Re: salsa.debian.org: merge requests and such

[Steve McIntyre]

David Bremner wrote:
>
>I'm not especially proud of it, but I mostly won't see things that don't
>arrive in my mailbox. Polling web pages just isn't going to happen for
>me. I understand other people have different ways of working, but I
>suspect I'm not alone on relying on problems being reported (typically
>by the BTS).

Nod - that's exactly my workflow too.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
 whether they're being malicious or incompetent. Capital letters are forecast."
 Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html

Re: salsa.debian.org: merge requests and such

[Jacob Adams]

> On Oct 28, 2018, at 09:44, Jacob Adams  wrote:
> 
> 
>> On Oct 28, 2018, at 08:11, Adam Borowski  wrote:
>> 
>> On Sat, Oct 27, 2018 at 12:46:00PM -0400, Jacob Adams wrote:
 On Oct 27, 2018, at 09:20, Holger Wansing  wrote:
 
 It looks to me, that many merge requests are lying around on Salsa, but the
 responsible package maintainers / teams are not aware of them.
>>> 
>>> The consensus seems to be that people should enable email notifications in
>>> salsa and open a bug when filing a merge request.
>> 
>> Except doing that manually just doesn't work:
>> * new maintainers don't know this bit of tribal knowledge
>> * it's obscure even for the oldies
>> * you're 99% likely to forget it when adding a new repo
>> 
>> Case in point: despite me having read the previous thread, and having set my
>> repos accordingly (I don't even remember how to do that anymore!), there's
>> a request rotting on a recent package:
>> https://salsa.debian.org/debian/boohu
>> https://salsa.debian.org/debian/boohu/merge_requests
>> 
>> I did make an unrelated upload of that package, but of course didn't notice
>> the request -- you typically don't touch salsa anymore if you use git's
>> command-line interface, and by default there's no notification whatsoever. 
>> So the fixes sit there, the contributor feels ignored, and improvements grow
>> conflicts with new upstream code.  Not cool.
>> 
>> So no, neither the maintainer nor the requester remember to do such extra
>> steps (they're not needed eg. on GitHub).  They must either be done
>> automatically or the GitLab functionality disabled or at least adorned with
>> in-your-face warnings.
> 
> I completely agree with you. The above is simply the best solution currently. 
> To quote from my last message in the previous thread:
> “My concern is that newcomers will have their merge requests ignored when 
> maintainers are not emailed. I see no workable solution as yet, so I’ll have 
> to look more into this and come back to this thread when I find one.”
> 
> I haven’t yet

Apologies, sent before completing my thought. 

I haven’t yet found a workable solution. Ideally we’d change the default 
notification settings in Salsa to always send emails but that won’t work 
because then all DDs would get emails about all the merge requests in the 
Debian group. 

Jacob 

Re: salsa.debian.org: merge requests and such

[Jacob Adams]

> On Oct 28, 2018, at 08:11, Adam Borowski  wrote:
> 
> On Sat, Oct 27, 2018 at 12:46:00PM -0400, Jacob Adams wrote:
>>> On Oct 27, 2018, at 09:20, Holger Wansing  wrote:
>>> 
>>> It looks to me, that many merge requests are lying around on Salsa, but the
>>> responsible package maintainers / teams are not aware of them.
>> 
>> The consensus seems to be that people should enable email notifications in
>> salsa and open a bug when filing a merge request.
> 
> Except doing that manually just doesn't work:
> * new maintainers don't know this bit of tribal knowledge
> * it's obscure even for the oldies
> * you're 99% likely to forget it when adding a new repo
> 
> Case in point: despite me having read the previous thread, and having set my
> repos accordingly (I don't even remember how to do that anymore!), there's
> a request rotting on a recent package:
> https://salsa.debian.org/debian/boohu
> https://salsa.debian.org/debian/boohu/merge_requests
> 
> I did make an unrelated upload of that package, but of course didn't notice
> the request -- you typically don't touch salsa anymore if you use git's
> command-line interface, and by default there's no notification whatsoever. 
> So the fixes sit there, the contributor feels ignored, and improvements grow
> conflicts with new upstream code.  Not cool.
> 
> So no, neither the maintainer nor the requester remember to do such extra
> steps (they're not needed eg. on GitHub).  They must either be done
> automatically or the GitLab functionality disabled or at least adorned with
> in-your-face warnings.

I completely agree with you. The above is simply the best solution currently. 
To quote from my last message in the previous thread:
“My concern is that newcomers will have their merge requests ignored when 
maintainers are not emailed. I see no workable solution as yet, so I’ll have to 
look more into this and come back to this thread when I find one.”

I haven’t yet 

Re: salsa.debian.org: merge requests and such

[Adam Borowski]

On Sun, Oct 28, 2018 at 01:14:29PM +0100, Mattia Rizzolo wrote:
> On Sun, Oct 28, 2018 at 01:11:28PM +0100, Adam Borowski wrote:
> > Case in point: despite me having read the previous thread, and having set my
> > repos accordingly (I don't even remember how to do that anymore!), there's
> > a request rotting on a recent package:
> > 
> > I did make an unrelated upload of that package, but of course didn't notice
> > the request -- you typically don't touch salsa anymore if you use git's
> 
> At least now DDPO shows such things in the VCS column.  I think the "!1"
> is way too small and very easy to miss, but that can be improved if
> anybody has a shed of ability with UIx/CSS… (which I don't)

Which is exactly the way I managed to notice the request.  Big thanks for
whoever added the !1 -- otherwise it'd wait there ad calendas graecas.

But as you say, it's not enough, and even people who look at DDPO frequently
are going to miss that bit.  Making the !1 stand out is probably not a good
idea, though -- just like bugs tagged +patch, making pull requests sit there
forever (with an ongoing discussion or not), is not that bad.  It's only the
initial notification that's vital.  And for that, the DDPO page is a poor
fit -- it's great for a status overview at a glance, not for timely
notifications.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Have you heard of the Amber Road?  For thousands of years, the
⣾⠁⢰⠒⠀⣿⡁ Romans and co valued amber, hauled through the Europe over the
⢿⡄⠘⠷⠚⠋⠀ mountains and along the Vistula, from Gdańsk.  To where it came
⠈⠳⣄ together with silk (judging by today's amber stalls).

Re: salsa.debian.org: merge requests and such

[David Bremner]

Mattia Rizzolo  writes:

> At least now DDPO shows such things in the VCS column.  I think the "!1"
> is way too small and very easy to miss, but that can be improved if
> anybody has a shed of ability with UIx/CSS… (which I don't)

I'm not especially proud of it, but I mostly won't see things that don't
arrive in my mailbox. Polling web pages just isn't going to happen for
me. I understand other people have different ways of working, but I
suspect I'm not alone on relying on problems being reported (typically
by the BTS).

d

Re: salsa.debian.org: merge requests and such

[Mattia Rizzolo]

On Sun, Oct 28, 2018 at 01:11:28PM +0100, Adam Borowski wrote:
> Case in point: despite me having read the previous thread, and having set my
> repos accordingly (I don't even remember how to do that anymore!), there's
> a request rotting on a recent package:
> https://salsa.debian.org/debian/boohu
> https://salsa.debian.org/debian/boohu/merge_requests
> 
> I did make an unrelated upload of that package, but of course didn't notice
> the request -- you typically don't touch salsa anymore if you use git's
> command-line interface, and by default there's no notification whatsoever. 
> So the fixes sit there, the contributor feels ignored, and improvements grow
> conflicts with new upstream code.  Not cool.

At least now DDPO shows such things in the VCS column.  I think the "!1"
is way too small and very easy to miss, but that can be improved if
anybody has a shed of ability with UIx/CSS… (which I don't)

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: salsa.debian.org: merge requests and such

[Adam Borowski]

On Sat, Oct 27, 2018 at 12:46:00PM -0400, Jacob Adams wrote:
> > On Oct 27, 2018, at 09:20, Holger Wansing  wrote:
> > 
> > It looks to me, that many merge requests are lying around on Salsa, but the
> > responsible package maintainers / teams are not aware of them.
> 
> The consensus seems to be that people should enable email notifications in
> salsa and open a bug when filing a merge request.

Except doing that manually just doesn't work:
* new maintainers don't know this bit of tribal knowledge
* it's obscure even for the oldies
* you're 99% likely to forget it when adding a new repo

Case in point: despite me having read the previous thread, and having set my
repos accordingly (I don't even remember how to do that anymore!), there's
a request rotting on a recent package:
https://salsa.debian.org/debian/boohu
https://salsa.debian.org/debian/boohu/merge_requests

I did make an unrelated upload of that package, but of course didn't notice
the request -- you typically don't touch salsa anymore if you use git's
command-line interface, and by default there's no notification whatsoever. 
So the fixes sit there, the contributor feels ignored, and improvements grow
conflicts with new upstream code.  Not cool.

So no, neither the maintainer nor the requester remember to do such extra
steps (they're not needed eg. on GitHub).  They must either be done
automatically or the GitLab functionality disabled or at least adorned with
in-your-face warnings.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Have you heard of the Amber Road?  For thousands of years, the
⣾⠁⢰⠒⠀⣿⡁ Romans and co valued amber, hauled through the Europe over the
⢿⡄⠘⠷⠚⠋⠀ mountains and along the Vistula, from Gdańsk.  To where it came
⠈⠳⣄ together with silk (judging by today's amber stalls).

Re: salsa.debian.org: merge requests and such

[Holger Wansing]

Hi,

Joseph Herlant  wrote:
> Hi,
> 
> > The consensus seems to be that people should enable email notifications in 
> > salsa and open a bug when filing a merge request.
> 
> That's indeed the best way to make the bridge between the BTS and the
> merge requests on Salsa.

Unsure, if this is an acceptable solution:
- since filing such bugreports is a manual step 
- and most Debian volunteers are short on time
this is most likely to not happen very often IMO.
At least there is still a high chance for that merge requests, to rott on 
Salsa for a long time.

Also, that would lead to two different places, where discussions on the
topic might be running, with different audience, which are not aware of
the other site.

And: for small things, that might be not worth a bugreport, one could think
that a merge request at salsa is a suitable way, but if package maintainers
are not aware of it, ...

In summary, this sounds like a semi-optimal solution to me.


Holger


-- 
Holger Wansing 
PGP-Finterprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: salsa.debian.org: merge requests and such

[Joseph Herlant]

Hi,

> The consensus seems to be that people should enable email notifications in 
> salsa and open a bug when filing a merge request.

That's indeed the best way to make the bridge between the BTS and the
merge requests on Salsa.

Note that you can enable the notification programmatically globally,
at the team level or at the repo level using the API [1].
If you do end up writing a script for that, you could probably add it
with the other nice salsa-related tools in the salsa-scripts repo [2].

Lately I've been wondering if it wouldn't be nice to see the open
MR/issues on the DMD [3] or on tracker.d.o (haven't looked further but
it might also be interesting to see it there).

[1] https://docs.gitlab.com/ee/api/notification_settings.html
[2]  https://salsa.debian.org/mehdi/salsa-scripts
[3] https://udd.debian.org/dmd/

Joseph

Re: salsa.debian.org: merge requests and such

[Jacob Adams]

> On Oct 27, 2018, at 09:20, Holger Wansing  wrote:
> 
> Hi all,
> 
> how is the new Salsa collaborative concept supposed to work with the "old"
> workflow in Debian?
> 
> Means: it seems to me, that with Salsa there is a second parallel world is
> getting evolved (in parallel to the old world: BTS, mailinglists ...), 
> containing things like patches in form of merge requests, which do not 
> interact 
> well with the old world (BTS, mailinglists).
> It looks to me, that many merge requests are lying around on Salsa, but the
> responsible package maintainers / teams are not aware of them.

I started a thread about this a while back:

https://lists.debian.org/debian-devel/2018/08/msg00231.html

The consensus seems to be that people should enable email notifications in 
salsa and open a bug when filing a merge request. 

https://lists.debian.org/debian-devel/2018/08/msg00235.html

https://lists.debian.org/debian-devel/2018/08/msg00259.html

Jacob