On Sat, May 18, 2024 at 08:25:10PM -0700, Otto Kekäläinen wrote:
> Hi Bill and Wookey!
>
> In a recent long thread on debian-devel you had somewhat negative
> sentiments towards the usefulness of Salsa.
I am not sure this characterize my position. I have no opposition to
Salsa (even though it is
Quoting Mathias Behrle (2024-05-19 11:08:58)
> * Jonas Smedegaard: " Re: Salsa - best thing in Debian in recent years? (Re:
> finally end single-person maintainership)" (Sun, 19 May 2024 10:47:38
> +0200):
>
>
> > i.e. you are being
> > asocial if you don'
* Jonas Smedegaard: " Re: Salsa - best thing in Debian in recent years? (Re:
finally end single-person maintainership)" (Sun, 19 May 2024 10:47:38 +0200):
> i.e. you are being
> asocial if you don't, and can expect your behavior being discussed as a
> public-wide issue f
Quoting Paul Gevers (2024-05-19 10:05:38)
> In this discussion about mandating things, I've been wondering
>
> On 19-05-2024 9:11 a.m., Jonas Smedegaard wrote:
> > * mandate VCS-tracking
> > * Yes
> > * mandate the use of one specific VCS
> > * Yes: git
>
> What do people think
Two mistakes spotted
On 19-05-2024 10:05 a.m., Paul Gevers wrote:
I think there's a large majority (maybe
even consensus) that believe you *should* have the packaging in VCS
I meant "at least should", as in "should or must".
I think what pere did [3]
[3]
Hi all,
In this discussion about mandating things, I've been wondering
On 19-05-2024 9:11 a.m., Jonas Smedegaard wrote:
* mandate VCS-tracking
* Yes
* mandate the use of one specific VCS
* Yes: git
What do people think this should mean, a *should* or *must* in policy?
That
Quoting Otto Kekäläinen (2024-05-19 05:25:10)
> In a recent long thread on debian-devel you had somewhat negative
> sentiments towards the usefulness of Salsa. I do see you doing good
> technical work for Debian and recently a MR from Bill too, so I was
> thinking that maybe you will change your
Hi Bill and Wookey!
In a recent long thread on debian-devel you had somewhat negative
sentiments towards the usefulness of Salsa. I do see you doing good
technical work for Debian and recently a MR from Bill too, so I was
thinking that maybe you will change your mind when you read more
in-depth
On 12.04.24 00:52, Bill Allombert wrote:
These contributions always need to be carefull reviewed before being
accepted. As likely as not, they are either slightly incorrect or
introducing subtle breakages in some case the submitter did not
envision. This is where an expert maintainer is most
Am Fri, Apr 12, 2024 at 09:36:25PM +0200 schrieb Bastian Blank:
> > - I also think disallowing single-person maintainership would be very
> > unwise,
> > though I agree team maintenance in general is probably better than
> > single-person maintainership. Still disallowing single-person
> >
On Fri, 12 Apr 2024 09:26:10 +, Mike Gabriel wrote:
> Debian is about freedom, so let's apply that to free choice of the tooling
> to be usable.
I disagree. "Freedom" is about Free Software, so-called freedom in
packaging has high costs as people (who look at more than their
"own" favourite
On Sat, 13 Apr 2024 at 10:11, Salvo Tomaselli wrote:
>
> > New contributors won't start in a vacuum, most will start contributing
> > first to existing projects on Salsa
>
> Or maybe they start with an ITP+RFS… was that an informed statement or a
> supposition?
It is my experience in receiving
On Sat, Apr 13, 2024 at 10:08:07AM +0200, Andreas Tille wrote:
> Am Sat, Apr 13, 2024 at 01:16:37AM +0900 schrieb Simon Richter:
> >
> > For example, any repository that does not list debian/files and
> > debian/*.substvars in the gitignore will fail to build twice in a row,
> > because these
On Sat, Apr 13, 2024 at 10:08:07AM +0200, Andreas Tille wrote:
> > For example, any repository that does not list debian/files and
> > debian/*.substvars in the gitignore will fail to build twice in a row,
> > because these files are created and are subsequently untracked.
>
> Sorry, no. We
Am Sat, Apr 13, 2024 at 01:16:37AM +0900 schrieb Simon Richter:
>
> For example, any repository that does not list debian/files and
> debian/*.substvars in the gitignore will fail to build twice in a row,
> because these files are created and are subsequently untracked.
Sorry, no. We should
On 12.04.24 19:28, Luca Boccassi wrote:
New contributors won't start in a vacuum, most will start contributing
first to existing projects on Salsa, which are already set up and
configured to do what is needed, if it is needed.
+1 here
Git is the bare
minimum these days, and has been for
On Tue, Apr 09, 2024 at 06:37:23PM +, Holger Levsen wrote:
> - I very much dislike git-buildpackage, too much magic. I try to avoid it
> where I can.
We still like those VCS-in-VCS workflows over everything else. Those
debian/patches, where you need to call something special and can't just
On Fri, 12 Apr 2024 at 17:17, Simon Richter wrote:
>
> Hi,
>
> On 13.04.24 00:19, Marc Haber wrote:
>
> >> 'Require' is probably the wrong word. I simply have heard from several
> >> potential young contributors that they feel blocked by the tooling and
> >> specifically not everything in Git.
>
Hi,
On 13.04.24 00:19, Marc Haber wrote:
'Require' is probably the wrong word. I simply have heard from several
potential young contributors that they feel blocked by the tooling and
specifically not everything in Git.
That does not only apply to young contributors. I am an old fart and I
On Wed, 10 Apr 2024 22:44:25 +0200, Andreas Tille
wrote:
>'Require' is probably the wrong word. I simply have heard from several
>potential young contributors that they feel blocked by the tooling and
>specifically not everything in Git.
That does not only apply to young contributors. I am an
On 12/04/24 15:00, Marc Haber wrote:
On Fri, 12 Apr 2024 09:26:10 +, Mike Gabriel
wrote:
Also regarding gbp, my packaging workflow does not require it
(debian/-folder-only in Git). Being enforced to use some other pkg'ing
style would reduce my fun and end up with less productivity, I fear.
On Tue, 9 Apr 2024 20:51:45 +0200, Gioele Barabucci
wrote:
>Asking maintainers "to use git" means: please push your changes, even
>those unreleased to a public git repository (salsa, github, codeberg,
>your own domain...), so other people can contribute 1) knowing that they
>are working
On Fri, 12 Apr 2024 09:26:10 +, Mike Gabriel
wrote:
>Also regarding gbp, my packaging workflow does not require it
>(debian/-folder-only in Git). Being enforced to use some other pkg'ing
>style would reduce my fun and end up with less productivity, I fear.
>The gbp workflow has its
On Tue, 9 Apr 2024 18:37:23 +, Holger Levsen
wrote:
>- I also think disallowing single-person maintainership would be very unwise,
> though I agree team maintenance in general is probably better than
> single-person maintainership.
Agreed.
> Still disallowing single-person maintainership
On Fri, Apr 12, 2024 at 09:53:29AM +0100, Jonathan Dowland wrote:
> On Tue Apr 9, 2024 at 7:37 PM BST, Holger Levsen wrote:
[...]
> I agree with everything you say here!
:)
> Wrt git-buildpackage, I'd like to add that personally, I respect the gbp
> authors and maintainers and it's a very useful
Hi all, hi Holger,
On Di 09 Apr 2024 18:37:23 UTC, Holger Levsen wrote:
hi,
just adding some random data points to this thread:
- I love git.
- I very much dislike git-buildpackage, too much magic. I try to avoid it
where I can.
- I like salsa. (though I think for many new contributors
On Tue Apr 9, 2024 at 7:37 PM BST, Holger Levsen wrote:
> - I love git.
> - I very much dislike git-buildpackage, too much magic. I try to avoid it
> where I can.
> - I like salsa. (though I think for many new contributors this is rather
> a barrier "why not use github" directly. Also salsa is
Le Tue, Apr 09, 2024 at 12:18:02AM +0200, Johannes Schauer Marin Rodrigues a
écrit :
> we need both. Domain specific knowledge is clearly very important and I'm not
> trying to argue against it. But doing packaging in a way such that it becomes
> easy for others to contribute is *also* every
Quoting Andreas Tille (2024-04-10 22:44:25)
> > I do understand the argument that lots of different workflows adds
> > friction. But I'm just still using what used to be _the_ standard one
> > (insofar as we ever had such a thing). Putting everything in salsa/git
> > doesn't standardise workflows
On Tue, 09 Apr 2024 17:52:43 +0100, Wookey wrote:
> On 2024-04-08 21:44 +0900, Simon Richter wrote:
> > Testing a package requires me to
> > commit everything into git first, so I have to remember to squash all these
> > commits later.
> Right - this was (one of the) main thing(s) that annoyed me
Hi Wookey,
Am Tue, Apr 09, 2024 at 05:52:43PM +0100 schrieb Wookey:
> Right - this was (one of the) main thing(s) that annoyed me enough to
> just go back to the non-git based workflow.
I started packaging with VCS in 2007i. Thanks to some Debian Med team
members (mainly Charles Plessy) I was
On Tue, 09 Apr 2024 16:07:20 +0200, Andreas Tille wrote:
> Am Mon, Apr 08, 2024 at 03:45:48PM +0200 schrieb Julien Puydt:
> > I only use salsa's git. That begs two questions:
> > - What do I miss by not using the web interface?
> If you are owner of a team repository you need to manage members.
On April 9, 2024 6:37:23 PM UTC, Holger Levsen wrote:
>hi,
>
>just adding some random data points to this thread:
>
>- I love git.
>- I very much dislike git-buildpackage, too much magic. I try to avoid it
> where I can.
>- I like salsa. (though I think for many new contributors this is
On 09/04/24 18:52, Wookey wrote:
So why mandate salsa rather than make dgit more official?
Independently from whether salsa should be mandated, "git", "salsa" and
"dgit" are three different things and should not be used as replacement
of one another.
Asking maintainers "to use git" means:
On Mon, Apr 08, 2024 at 11:00:52PM +0100, Luca Boccassi wrote:
> ...right up until the point where that "bus factor of 1" moves
> on/changes priorities/changes job/etc and the package is abandoned.
> Fortunately that never happens, though!
Having a repository on salsa or even "packaging team"
hi,
just adding some random data points to this thread:
- I love git.
- I very much dislike git-buildpackage, too much magic. I try to avoid it
where I can.
- I like salsa. (though I think for many new contributors this is rather
a barrier "why not use github" directly. Also salsa is Debian
On Tue Apr 9, 2024 at 1:52 PM -03, Wookey wrote:
> On 2024-04-08 21:44 +0900, Simon Richter wrote:
>
> > Testing a package requires me to
> > commit everything into git first, so I have to remember to squash all these
> > commits later.
>
> Right - this was (one of the) main thing(s) that annoyed
On Tue, Apr 09, 2024 at 07:43:04PM +0200, Johannes Schauer Marin Rodrigues
wrote:
> > And I do just prefer having two directories rather than multiple
> > version on top of each other. My simple brain finds it a lot easier to
> > keep track of a version directory to diff between, rather than
On Tue, Apr 09, 2024 at 05:52:43PM +0100, Wookey wrote:
> Right - this was (one of the) main thing(s) that annoyed me enough to
> just go back to the non-git based workflow. I want to make changes and
> try them. I don't want to have to commit every damn time - it's not
> done yet - I'll commit it
Hi Wookey and all,
Quoting Wookey (2024-04-09 18:52:43)
> On 2024-04-08 21:44 +0900, Simon Richter wrote:
> > Testing a package requires me to commit everything into git first, so I
> > have to remember to squash all these commits later.
> Right - this was (one of the) main thing(s) that annoyed
On 2024-04-08 21:44 +0900, Simon Richter wrote:
> Testing a package requires me to
> commit everything into git first, so I have to remember to squash all these
> commits later.
Right - this was (one of the) main thing(s) that annoyed me enough to
just go back to the non-git based workflow. I
Hi Julien,
Am Mon, Apr 08, 2024 at 03:45:48PM +0200 schrieb Julien Puydt:
>
> I only use salsa's git. That begs two questions:
> - What do I miss by not using the web interface?
If you are owner of a team repository you need to manage members. As
far as I know this is only possible via web
On Mon, 8 Apr 2024 at 23:23, Joerg Jaspert wrote:
>
> On 17194 March 1977, Luca Boccassi wrote:
> >> Simple packages need someone who is responsible and responsive for
> >> them
> >> in the long run and know there history much more than needing
> >> sporadic
> >> contributions.
> > ...right up
On 17194 March 1977, Luca Boccassi wrote:
Simple packages need someone who is responsible and responsive for
them
in the long run and know there history much more than needing
sporadic
contributions.
...right up until the point where that "bus factor of 1" moves
on/changes priorities/changes
Quoting Bill Allombert (2024-04-08 23:49:05)
> Le Sun, Apr 07, 2024 at 11:37:47PM +0200, Gioele Barabucci a écrit :
> > On 07/04/24 23:11, Bill Allombert wrote:
> > > > What is your opinion about pushing logtool to Salsa?
> > >
> > > Not speaking for logtool obviously, but maintaining simple
On Mon, 8 Apr 2024 at 22:49, Bill Allombert wrote:
>
> Le Sun, Apr 07, 2024 at 11:37:47PM +0200, Gioele Barabucci a écrit :
> > On 07/04/24 23:11, Bill Allombert wrote:
> > > > What is your opinion about pushing logtool to Salsa?
> > >
> > > Not speaking for logtool obviously, but maintaining
Le Sun, Apr 07, 2024 at 11:37:47PM +0200, Gioele Barabucci a écrit :
> On 07/04/24 23:11, Bill Allombert wrote:
> > > What is your opinion about pushing logtool to Salsa?
> >
> > Not speaking for logtool obviously, but maintaining simple packages on
> > salsa is
> > just useless bureaucracy.
>
Hi Julien,
On 4/8/24 22:45, Julien Puydt wrote:
I only use salsa's git. That begs two questions:
- What do I miss by not using the web interface?
> - What does that web interface have that people don't like?
It's a normal GitLab install. For anything that is a normal software
project (like
Il 08/04/2024 15:45, Julien Puydt ha scritto:
Hi
Le lun. 8 avr. 2024, 14:45, Simon Richter a écrit :
The web interface presented by salsa also does not have the necessary
data<->metadata filters to provide an actual insight into what is
really
happening in the repository.
Hi
Le lun. 8 avr. 2024, 14:45, Simon Richter a écrit :
> The web interface presented by salsa also does not have the necessary
> data<->metadata filters to provide an actual insight into what is really
> happening in the repository.
>
It's been several times already some people complain about
On Mon, Apr 08, 2024 at 09:44:55PM +0900, Simon Richter wrote:
> > I don't mind what other people do, but I worry that conversations like
> > this seem to take the new thing as so self-evidently better that
> > no-one can reasonably complain about them being made a
> > requirement. Well, we don't
Hi,
On 4/8/24 05:42, Wookey wrote:
I don't mind what other people do, but I worry that conversations like
this seem to take the new thing as so self-evidently better that
no-one can reasonably complain about them being made a
requirement. Well, we don't all think it's better, and I wouldn't
Bill Alombert wrote:
>On Sun, Apr 07, 2024 at 04:04:18PM +0200, Andreas Tille wrote:
>> Hi Wouter,
>>
>> Am Sun, Apr 07, 2024 at 03:31:43PM +0200 schrieb Wouter Verhelst:
>> > [Feel free to quote any part of this email which I wrote outside of this
>> > mailinglist]
>>
>> OK, moving the
> Then there is salsa... I have mixed feelings about it. On the one hand, it's
> this big beast with tons of javascript and apparently we are not even
> dog-fooding gitlab as packaged in Debian to overseves. I'd like our
> infrastructure to be based on the things we offer in our distro. And it's
Hi,
Quoting Wookey (2024-04-07 22:42:34)
> On 2024-04-07 16:04 +0200, Andreas Tille wrote:
> > Am Sun, Apr 07, 2024 at 03:31:43PM +0200 schrieb Wouter Verhelst:
> > > [Feel free to quote any part of this email which I wrote outside of this
> > > mailinglist]
> > OK, moving the discussion to
On 07/04/24 23:11, Bill Allombert wrote:
What is your opinion about pushing logtool to Salsa?
Not speaking for logtool obviously, but maintaining simple packages on salsa is
just useless bureaucracy.
As a contributor, having a package on salsa is extremely useful, far
from "useless".
By
On Sun, Apr 07, 2024 at 04:04:18PM +0200, Andreas Tille wrote:
> Hi Wouter,
>
> Am Sun, Apr 07, 2024 at 03:31:43PM +0200 schrieb Wouter Verhelst:
> > [Feel free to quote any part of this email which I wrote outside of this
> > mailinglist]
>
> OK, moving the discussion to debian-devel where it
On Apr 07, Wookey wrote:
> I think that's a mistake, and I'm not a fan. Because so far as I can
> tell 'use salsa' actually means 'maintain your packages in git'. So
> far as I can see it is not possible to use our existing 'uscan, patch,
> sbuild, dupload' type workflows with Salsa. And that's
On 2024-04-07 16:04 +0200, Andreas Tille wrote:
> Am Sun, Apr 07, 2024 at 03:31:43PM +0200 schrieb Wouter Verhelst:
> > [Feel free to quote any part of this email which I wrote outside of this
> > mailinglist]
>
> OK, moving the discussion to debian-devel where it should belong.
Good plan.
> >
Hi again,
Am Sun, Apr 07, 2024 at 04:10:15PM +0200 schrieb Wouter Verhelst:
> >
> > What is your opinion about pushing logtool to Salsa?
>
> I did that as part of my latest upload :)
>
> https://salsa.debian.org/wouter/logtool
Great.
> (I realize now that I forgot to add VCS headers... ah
On Sun, Apr 07, 2024 at 04:04:18PM +0200, Andreas Tille wrote:
> Hi Wouter,
>
> Am Sun, Apr 07, 2024 at 03:31:43PM +0200 schrieb Wouter Verhelst:
> > [Feel free to quote any part of this email which I wrote outside of this
> > mailinglist]
>
> OK, moving the discussion to debian-devel where it
Hi Wouter,
Am Sun, Apr 07, 2024 at 03:31:43PM +0200 schrieb Wouter Verhelst:
> [Feel free to quote any part of this email which I wrote outside of this
> mailinglist]
OK, moving the discussion to debian-devel where it should belong.
> Debian packages need to be well maintained. In some cases,
On Sat, Apr 06, 2024 at 06:32:47PM +0200, Bastian Germann wrote:
> Am 06.04.24 um 18:29 schrieb Colin Watson:
> > There might be some small errors in this, but I couldn't see any when
> > eyeballing the resulting uniquified list of Maintainer fields. It looks
> > like 78% of source packages in
Am 06.04.24 um 18:29 schrieb Colin Watson:
There might be some small errors in this, but I couldn't see any when
eyeballing the resulting uniquified list of Maintainer fields. It looks
like 78% of source packages in unstable are team-maintained, which can't
reasonably be called an "exception".
64 matches
Mail list logo
