Le 01/09/2019 à 19:15, Bernd Zeimetz a écrit :
>
>
> On 9/1/19 6:41 PM, Alexis Murzeau wrote:
>> I find both arguments quite valid:
>> - The BTS is more future proof, stuff on it will probably last longer
>> than whatever is on Salsa currently.
>
> Why? There is no real reason to remove MRs or b
On 9/1/19 6:41 PM, Alexis Murzeau wrote:
> I find both arguments quite valid:
> - The BTS is more future proof, stuff on it will probably last longer
> than whatever is on Salsa currently.
Why? There is no real reason to remove MRs or bug reports in salsa after
some time.
> There are bugs in t
Le 01/09/2019 à 11:02, Bernd Zeimetz a écrit :
>
>
> On 8/27/19 5:52 PM, Alf Gaida wrote:
>> Nicer would be "lowest common nominator" but "stone age" describe the
>> process of sending patches via BTS very well. Upps, sorry, not only the
>> process, but the BTS also.
>
> Exactly. Working with t
On 9/1/19 2:52 PM, Sam Hartman wrote:
> Actually, no, people like Sean do care about this.
> They want a record of the discussion.
The record of this discussion is on salsa, not in the BTS.
With the difference that you are actually able to review a merge request
including its changes and discu
> "Bernd" == Bernd Zeimetz writes:
Bernd> On 8/27/19 8:52 PM, Sam Hartman wrote:
>>> "Alf" == Alf Gaida writes:
>>
>>
Alf> There are things i really like about PRs or MRs - they can be
Alf> reviewed, commented, changed without problems and fast.
>>
>> A
On 8/27/19 5:52 PM, Alf Gaida wrote:
> Nicer would be "lowest common nominator" but "stone age" describe the
> process of sending patches via BTS very well. Upps, sorry, not only the
> process, but the BTS also.
Exactly. Working with the BTS is a waste of time compared to github or
gitlab work
On 8/27/19 8:52 PM, Sam Hartman wrote:
>> "Alf" == Alf Gaida writes:
>
>
> Alf> There are things i really like about PRs or MRs - they can be
> Alf> reviewed, commented, changed without problems and fast.
>
> And as Sean pointed out, it's hard to understand the history of the
> chan
On Tue, Aug 27 2019, Antonio Terceiro wrote:
> FWIW, nowadays gitlab keeps track of every push, including rebases, to a
> single merge request. It even adds a "compare to previous version",
> where you can see the diff between the latest, maybe rebased, version of
> the branch, and the previous
Am Mittwoch, den 28.08.2019, 17:57 +0200 schrieb Thomas Goirand:
> However, there's still a way too much web interaction with it, compared
> to what we do with a simple "git review" with gerrit.
Not we - you. Please don't expect that people have the same opinion. I like any
kind of nice interfaces.
On 8/27/19 7:37 PM, Alf Gaida wrote:
> Am Dienstag, den 27.08.2019, 19:18 +0200 schrieb Adam Borowski:
>> New stuff is always better. Go Electron!
>>
> Like it or not - the idea of pull requests (Github) or merge requests (Gitlab)
> isn't exactly new. It might surprise you that people outside of d
On 8/27/19 1:37 PM, Alf Gaida wrote:
> Am Dienstag, den 27.08.2019, 19:18 +0200 schrieb Adam Borowski:
>> New stuff is always better. Go Electron!
>>
> Like it or not - the idea of pull requests (Github) or merge requests (Gitlab)
> isn't exactly new. It might surprise you that people outside of d
On Tue, 27 Aug 2019 15:35:37 -0400
Milan Kupcevic wrote:
> I fully agree with the initial best practices proposal stating that
> merge requests in salsa have to be attended to or otherwise this
> feature has to be disabled as per package maintainer preference.
I only stated that the Debian BTS f
On Tue, Aug 27, 2019 at 02:52:01PM -0400, Sam Hartman wrote:
> > "Alf" == Alf Gaida writes:
>
>
> Alf> There are things i really like about PRs or MRs - they can be
> Alf> reviewed, commented, changed without problems and fast.
>
> And as Sean pointed out, it's hard to understand th
On Tue, 27 Aug 2019 14:52:01 -0400
Sam Hartman wrote:
> And as Sean pointed out, it's hard to understand the history of the
> changes and comments after they hppened. What happens when I'm trying
> to review a MR three years later and the MR was rebased 4 times during
> the lifetime of the MR pr
> "Alf" == Alf Gaida writes:
Alf> There are things i really like about PRs or MRs - they can be
Alf> reviewed, commented, changed without problems and fast.
And as Sean pointed out, it's hard to understand the history of the
changes and comments after they hppened. What happens whe
Am Dienstag, den 27.08.2019, 19:18 +0200 schrieb Adam Borowski:
> New stuff is always better. Go Electron!
>
Like it or not - the idea of pull requests (Github) or merge requests (Gitlab)
isn't exactly new. It might surprise you that people outside of debian are used
to use it a lot. Anyways, it'
On Tue, Aug 27, 2019 at 05:52:02PM +0200, Alf Gaida wrote:
> On Tue, 27 Aug 2019 16:08:59 +0100
> Ian Jackson wrote:
> > Please avoid pejorative language like "stone age".
>
> Nicer would be "lowest common nominator" but "stone age" describe the
> process of sending patches via BTS very well. Upp
On 2019-08-27 17:52:02 +0200 (+0200), Alf Gaida wrote:
> On Tue, 27 Aug 2019 16:08:59 +0100 Ian Jackson wrote:
[...]
> > Please avoid pejorative language like "stone age".
>
> Nicer would be "lowest common nominator" but "stone age" describe
> the process of sending patches via BTS very well. Upps
On Tue, 27 Aug 2019 16:08:59 +0100
Ian Jackson wrote:
> I think Sam's proposed change would be to document in the DR that a
> maintainer should handle change requests (including code
> contributions) sent to the BTS. That would surely just be documenting
> our existing norm. It seems to me that
Bernd Zeimetz :
> On 2019-08-26 23:41, Sam Hartman wrote:
> > I don't think you're part of our consensus.
>
> Yes, that might be very true. But what you describe by
> "our consensus"
I'm not a fan of this phrasing by Sam. But he makes a very good
point: you have not answered any of the substanti
On Tue, Aug 27, 2019 at 11:40:22AM +0100, Ian Jackson wrote:
> Andrej Shadura writes ("Re: Consensus Call: Git Packaging Round 1"):
> > I noticed some people [citation needed] think it is not important to
> > preserve pristine upstream tarballs with the move to Git, and it
Andrej Shadura writes ("Re: Consensus Call: Git Packaging Round 1"):
> 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 pre
> "Andrej" == Andrej Shadura 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.
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 me
24 matches
Mail list logo
