I think we have enough confirmations to move forward.
There are a couple. of last call comments/question that need answers,
and then as facilitator, I'll write up a d-d-a post.
I'd like to see a round 3 focusing on branch format and stuff.
Before proposing a timeline for that, I recommend that we
Hi,
I confirm the summary seems fair and reasonable with one
question/proposal (see below in line).
Sam Hartman writes:
> * Exploring what current social conventions are around pushing to other
> people's repositories in the debian group on salsa and documenting
> them. This is more about
Hello,
On Wed 06 Nov 2019 at 11:10AM -05, Sam Hartman wrote:
> * If you were involved enough that you can read the summary and say
> "Yeah, that's more or less what happened," please please do that. (If
> you think I got something wrong in the summary, then please say that too)
I read almost
TL;DR: I'd feel a lot more comfortable if a couple of people would
explicitly review wether I correctly captured the discussion in the
summary.
So, we've received a number of comments on aspects of the discussion.
That plus the original discussion leads me to believe we really are
interested in
On 11/5/19 9:51 PM, Nicholas D Steeves wrote:
> Richard Laager writes:
>> I'd love to see more information about a recommended branch
>> structure. FWIW, I've been using branches named for each release
>> (e.g. "sid" is the default, but I also have "buster" for a (proposed)
>> stable update, will
Richard Laager writes:
> This all looks very good.
>
> Presumably the repository / Salsa project name should match the source
> package name? If so, that might be good to note, at least as the
> default.
>
I'm curious what other people think about this point, because it could
cause a lot of chur
Sam Hartman writes:
> General Recommendation
> ==
> [...]
> You should document the branch format (such as patches unapplied (gbp
> pq)) that your repository uses. Best practice for documenting this is
> still evolving. The best current option is to document your branch
> fo
This all looks very good.
Presumably the repository / Salsa project name should match the source package
name? If so, that might be good to note, at least as the default.
I'd love to see more information about a recommended branch structure. FWIW,
I've been using branches named for each release
Sam Hartman dixit:
>depend on non-free software. Github is a common example of a web
>service that uses non-free software.
So is Salsa. It does not use the packaged version of GitLab,
which is in a sorry state anyway, and not suitable for a stable
release, but the proprietary “open core” versioi
On Tue, Oct 22, 2019 at 09:58:00PM -0400, Sam Hartman wrote:
> I think we have about two weeks left in the review period.
> Just as a reminder we do need comments.
> Even if people generally agree, we do need at least a few comments to
> that effect.
I like the current proposal for a default sugg
I think we have about two weeks left in the review period.
Just as a reminder we do need comments.
Even if people generally agree, we do need at least a few comments to
that effect.
Hi Sam & Debianistas,
this is far TLDR for me. That is not meant as a critique, but as a
feedback so you have a data point from some random Debianer's available
CPU resources.
(in general I'm fine to declare best practices for whatever issue so
that people can orient themselves on where to head t
TL;DR: These are only guidelines. You're free to ignore them. So I
think the issue you bring up isn't a big deal in this case.
In more detail:
> "Theodore" == Theodore Y Ts'o writes:
Theodore> One thing that is been left unclear is what does it mean
Theodore> to "use salsa"?
Us
One thing that is been left unclear is what does it mean to "use
salsa"? For example, the e2fsprogs git repository is hosted at
multiple locations:
* https://git.kernel.org/pub/scm/fs/ext2/e2fsprogs.git
* https://github.com/tytso/e2fsprogs.git
* https://git.code.sf.net/p/e2fsprogs/code
*
On Wed, 09 Oct 2019 12:40:12 -0400, Sam Hartman wrote:
> > "gregor" == gregor herrmann writes:
>
> >> General Recommendation ==
>
> This entire section effectively only applies to individual packages that
> are not in a team.
>
> Would "When there is no Team to use"
> "gregor" == gregor herrmann writes:
>> General Recommendation ==
This entire section effectively only applies to individual packages that
are not in a team.
Would "When there is no Team to use" or similar be a better headline
and address your concern?
>> This r
On Mon, 07 Oct 2019 21:22:46 -0400, Sam Hartman wrote:
> Ansgar argued that documenting the branch format is unnecessary given
> all the work you need to do to contribute to a package. Several
> disagreed arguing that it helped them do their work.
I have an idea where Ansgar might be coming from
On Tue, 08 Oct 2019, Holger Levsen wrote:
> On Mon, Oct 07, 2019 at 09:22:46PM -0400, Sam Hartman wrote:
> > [...] as a last opportunity for
> > others to comment.
>
> what's the deadline to grok this 20k and respond?
It's in the subject: [comments by 11/05/2019]
November 5th.
Cheers,
--
Raph
On Mon, Oct 07, 2019 at 09:22:46PM -0400, Sam Hartman wrote:
> [...] as a last opportunity for
> others to comment.
what's the deadline to grok this 20k and respond?
--
cheers,
Holger
---
holger
This is a summary of discussions we had in August and September around
how we want to use salsa. Presented so those involved in the discussion
can see if I'm calling consensus correctly and as a last opportunity for
others to comment. A few tweaks from my original proposed
recommendations. If y
20 matches
Mail list logo
