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
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
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, 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
> "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 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"
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
*
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
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
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.
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
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
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 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
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
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
16 matches
Mail list logo