On Thu, 2024-05-23 at 22:00 +0200, Sven Mueller wrote:
>
>
> Am 23.05.2024 20:16 schrieb Bernd Zeimetz :
> > On Thu, 2024-05-23 at 11:01 +0900, Simon Richter wrote:
> > > Yes, but unironically: experimental is a side branch, unstable is
> > a
> > > MR,
> > > and testing is the main branch.
> >
Am 23.05.2024 20:16 schrieb Bernd Zeimetz :On Thu, 2024-05-23 at 11:01 +0900, Simon Richter wrote:
> Yes, but unironically: experimental is a side branch, unstable is a
> MR,
> and testing is the main branch.
>
> It is entirely valid to be dissatisfied with the turnaround time of
> the
>
On Thu, 2024-05-23 at 11:01 +0900, Simon Richter wrote:
> Hi,
>
> On 5/23/24 04:32, Andrey Rakhmatullin wrote:
>
> > > > It could be argued that testing migration is a CI process. >>
> > > > Its a CI process at a way too late stage.
> > > Also, uploading to test a merge request is not the right
On Thu, 23 May 2024 at 03:01, Simon Richter wrote:
>
> Hi,
>
> On 5/23/24 04:32, Andrey Rakhmatullin wrote:
>
> >>> It could be argued that testing migration is a CI process. >> Its a CI
> >>> process at a way too late stage.
> >> Also, uploading to test a merge request is not the right thing to
Hi,
On 5/23/24 04:32, Andrey Rakhmatullin wrote:
It could be argued that testing migration is a CI process. >> Its a CI process
at a way too late stage.
Also, uploading to test a merge request is not the right thing to do.
If the archive is a VCS then uploading an untested package to
Hi
On 21-05-2024 1:08 p.m., Sean Whitton wrote:
PS: I've always wondered if the dgit server shouldn't track history, even if
uploads don't happen via it. A dgit clone could (should?) already provide
available history, even if no upload happened via it yet.
Well, 'dgit clone' adds a vcs-git
On Wed, May 22, 2024 at 09:11:16PM +0200, Bernd Zeimetz wrote:
> > > You can run autopkgtests locally, you do not need Salsa for that.
> >
> > Also, Debian runs autopkgtests on all packages that provide them, and
> > makes passing them on all supported architectures a requirement for
> > testing
On Wed, 2024-05-22 at 21:26 +0900, Simon Richter wrote:
> Hi,
>
> On 5/22/24 20:34, Bill Allombert wrote:
>
> > You can run autopkgtests locally, you do not need Salsa for that.
>
> Also, Debian runs autopkgtests on all packages that provide them, and
> makes passing them on all supported
Salvo Tomaselli writes:
> I'm also annoyed at the default ci configuration for salsa, because importing
> a
> project makes a CI start to run, then fail. Then I have to one by one point
> the CI file to something else, but the project will forever be "CI failing"
> and
> will be reported
Hi,
On 5/22/24 20:34, Bill Allombert wrote:
You can run autopkgtests locally, you do not need Salsa for that.
Also, Debian runs autopkgtests on all packages that provide them, and
makes passing them on all supported architectures a requirement for
testing migration.
It could be argued
On Wed, 22 May 2024 at 12:35, Bill Allombert wrote:
>
> On Tue, May 21, 2024 at 12:59:52AM +0200, Bernd Zeimetz wrote:
> > On Thu, 2024-04-11 at 22:52 +, Bill Allombert wrote:
> > >
> > > When a change leads to a RC bug a month or three after having be
> > > part of a package, fixing the
On Tue, May 21, 2024 at 12:59:52AM +0200, Bernd Zeimetz wrote:
> On Thu, 2024-04-11 at 22:52 +, Bill Allombert wrote:
> >
> > When a change leads to a RC bug a month or three after having be
> > part of a package, fixing the problem falls on the maintainer and not
> > on the change author.
On Wed, May 22, 2024 at 12:25:49AM +0200, Salvo Tomaselli wrote:
> > I would rather see a small but very stable base distribution, with the
> > option to add features on top.
> Doesn't this conflict with debian being universal?
for some it surely does, while for others it's needed to make Debian
On Wed, May 22, 2024 at 07:18:04AM +0200, Andreas Tille wrote:
> IMHO this is a hen-egg-problem: If NMUer could expect packages beeing on
> Salsa we could require the NMUer to add at least a MR.
those are two things:
- mandating salsa (for git)
- mandating to have MRs enabled on salsa for that
My standard workflow
I use gbp and dgit
gbp import-orig --pristine-tar --uscan
gbp dch
lintian-brush
dgit --gbp sbuild (build and autopkgtest)
...work until it is ok on my computer
gbp dch
... hand edit the changelog
gbp push
git push (to push the UNRELEASE master branch)
... wait for salsa
On Wed, May 22, 2024 at 12:32:32AM +0200, Salvo Tomaselli wrote:
> And what's the advantage? When an nmu happens the person doing it normally
> doesn't bother to push to salsa anyway.
Yes, because it's unfortunately too expensive to:
- make sure the repo exists and is uptodate
- somehow find out
Hi Stefano,
Am Tue, May 21, 2024 at 02:36:47PM + schrieb Stefano Rivera:
> Hi Philip (2024.05.21_10:05:59_+)
> > Attempts at top-down imposition of new methods on Debian strike me as
> > being unlikely to induce joy in anyone involved.
>
> Yeah, that doesn't fly in community projects
Am Wed, May 22, 2024 at 12:32:32AM +0200 schrieb Salvo Tomaselli:
>
> And what's the advantage? When an nmu happens the person doing it normally
> doesn't bother to push to salsa anyway. At most I get a patch in the
> bugreport, or I have to diff the packages and import the diff.
IMHO this is
Quoting Luca Boccassi (2024-05-22 01:45:54)
> On Wed, 22 May 2024 at 00:40, Russ Allbery wrote:
> > For what it's worth, what I do for the packages for which I'm also
> > upstream is that I just add Salsa as another remote and, after I upload
> > a new version of the Debian package, I push to
Quoting Bernd Zeimetz (2024-05-21 00:54:07)
> On Wed, 2024-04-10 at 23:16 +0200, Johannes Schauer Marin Rodrigues
> wrote:
> > 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
On Wed, 22 May 2024 at 00:40, Russ Allbery wrote:
>
> Salvo Tomaselli writes:
>
> > If the debian/ directory is on salsa, but the rest of the project is
> > somewhere else, then this no longer works, I have to tag in 2 different
> > places, I have 2 different repositories to push to and so on.
>
Salvo Tomaselli writes:
> If the debian/ directory is on salsa, but the rest of the project is
> somewhere else, then this no longer works, I have to tag in 2 different
> places, I have 2 different repositories to push to and so on.
For what it's worth, what I do for the packages for which I'm
On Tue, 2024-05-21 at 09:11 -0600, Sam Hartman wrote:
> > > > > > "Otto" == Otto Kekäläinen writes:
> Otto> Would you be kind and try to understand the opposing
> viewpoint
> Otto> by trying it for one day?
>
> Otto> You could go to
> Otto>
>
On Tue, 2024-05-21 at 12:05 +0200, Philip Hands wrote:
>
> For anyone with an opinion, I'd suggest that you should try to make
> sure
> that DEP-14 reflects your opinion, and then work on getting people to
> adopt the use of DEP-14 and/or get DEP-14 accepted.
>
To be honest: in my opinion the
On Tue, 2024-05-21 at 15:50 +0200, Salvo Tomaselli wrote:
> > Do you think that mandating Salsa is a sensible step in this
> > direction?
>
> No. It would increase my workload for all the stuff where I am also
> upstream.
Could you explain that? I do similar things (just that not everything
of
Hi!
On Sun, 19 May 2024 at 20:48, Don Armstrong wrote:
>
> On Sun, 19 May 2024, Bill Allombert wrote:
> > Also debbugs is a special case:
> > The debbugs Debian package (as opposed to the debbugs software) have never
> > been
> > really maintained. I am actually one of the very few users of
Stefano Rivera writes:
> On the other hand, dgit is only useful if you have a certain view of the
> world, that hasn't aligned with how I've done Debian packaging. I mean,
> an entirely git-centric view where you let go of trying to maintain your
> patch stack.
dgit has no problems with you
> "Otto" == Otto Kekäläinen writes:
Otto> Would you be kind and try to understand the opposing viewpoint
Otto> by trying it for one day?
Otto> You could go to
Otto> https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19
Otto> and conduct a code review?
I have
Hi Philip (2024.05.21_10:05:59_+)
> Attempts at top-down imposition of new methods on Debian strike me as
> being unlikely to induce joy in anyone involved.
Yeah, that doesn't fly in community projects like Debian at all.
However, there is a gap between getting a DEP approved and getting the
On Tue, 21 May 2024 at 14:13, Andrey Rakhmatullin wrote:
>
> On Tue, May 21, 2024 at 08:45:50PM +0900, Simon Richter wrote:
> > Hi,
> >
> > On 5/21/24 15:54, Andrey Rakhmatullin wrote:
> >
> > > > The Debian archive itself is a VCS, so git-maintained packaging is also
> > > > a
> > > >
On Mon, May 20, 2024 at 04:11:02AM +0900, Simon Richter wrote:
> The Debian archive itself is a VCS, so git-maintained packaging is also a
> duplication, and keeping the official VCS and git synchronized is causing
> additional work for developers, which is why people are opposed to having it
>
On Tue, May 21, 2024 at 08:45:50PM +0900, Simon Richter wrote:
> Hi,
>
> On 5/21/24 15:54, Andrey Rakhmatullin wrote:
>
> > > The Debian archive itself is a VCS, so git-maintained packaging is also a
> > > duplication, and keeping the official VCS and git synchronized is causing
> > > additional
Hi,
On 5/21/24 15:54, Andrey Rakhmatullin wrote:
The Debian archive itself is a VCS, so git-maintained packaging is also a
duplication, and keeping the official VCS and git synchronized is causing
additional work for developers, which is why people are opposed to having it
mandated.
The
Hello,
On Sun 19 May 2024 at 10:05am +02, Paul Gevers wrote:
>
> PS: I've always wondered if the dgit server shouldn't track history, even if
> uploads don't happen via it. A dgit clone could (should?) already provide
> available history, even if no upload happened via it yet.
Well, 'dgit
Hello,
On Sun 19 May 2024 at 12:32pm -07, Otto Kekäläinen wrote:
> You could go to
> https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 and
> conduct a code review?
>
> You might discover that GitLab is useful and is not duplicating
> Debbugs or anything else in Debian - it is
On Tue, May 21, 2024 at 12:05:59PM +0200, Philip Hands wrote:
> >> > All these things should make it much more easy for other people or
> >> > automated tools to send merge requests or keep maintaining a
> >> > package in
> >> > case the original maintainer becomes MIA.
> >>
> >>
> >> Mandating
On Mon, 20 May 2024 at 19:10:00 -0700, Otto Kekäläinen wrote:
> Exact quote: "These commits have intentionally no debian/changelog
> updates as it causes every single rebase or cherry-pick of a commit to
> always have a merge conflict. It is much better to have all commits
> as-is, and then right
On Tue, 21 May 2024 at 03:16, Simon Richter wrote:
>
> Hi,
>
> On 5/21/24 10:43, Luca Boccassi wrote:
>
> >> The ecosystem, however, does not support our workflows, and adapting it
> >> to do that is even more effort than maintaining our own tools. [...]
>
> > That's a problem of our workflows,
Bernd Zeimetz writes:
> On Mon, 2024-05-20 at 20:47 +, Scott Kitterman wrote:
>> >
>> > All these things should make it much more easy for other people or
>> > automated tools to send merge requests or keep maintaining a
>> > package in
>> > case the original maintainer becomes MIA.
>>
>>
On Mon, May 20, 2024 at 04:11:02AM +0900, Simon Richter wrote:
> > My concern about Gitlab is not its *additions* to existing services, but
> > its *duplications* of core services already in Debian.
>
> I agree, that's the key problem.
>
> The Debian archive itself is a VCS, so git-maintained
On Tue, May 21, 2024 at 12:32:52AM +0200, Bernd Zeimetz wrote:
> > > All these things should make it much more easy for other people or
> > > automated tools to send merge requests or keep maintaining a
> > > package in
> > > case the original maintainer becomes MIA.
> >
> >
> > Mandating a
Simon Richter writes:
> A better approach would not treat Debian metadata as git data. Even the
> most vocal advocate of switching everything to Salsa writes in his MR
> that the changelog should not be touched in a commit, because it creates
> conflicts, and instead a manual step will need to
Hi,
On 5/21/24 10:43, Luca Boccassi wrote:
The ecosystem, however, does not support our workflows, and adapting it
to do that is even more effort than maintaining our own tools. [...]
That's a problem of our workflows, which are horrible. The solution is
not to double down on them.
Our
Hi Simon!
> > A better approach would not treat Debian metadata as git data. Even the
> > most vocal advocate of switching everything to Salsa writes in his MR
> > that the changelog should not be touched in a commit, because it creates
> > conflicts, and instead a manual step will need to be
On Tue, 21 May 2024 at 02:08, Simon Richter wrote:
>
> Hi,
>
> On 5/21/24 07:43, Bernd Zeimetz wrote:
>
> > Also its a gitlab instance. There are all kinds of documentation,
> > tutorials, videos and software for/about gitlab, including lots of
> > beginner friendly options. There is a whole
Hi,
On 5/21/24 07:43, Bernd Zeimetz wrote:
Also its a gitlab instance. There are all kinds of documentation,
tutorials, videos and software for/about gitlab, including lots of
beginner friendly options. There is a whole ecosystem around gitlab, it
does not depend on a few (two?) developers.
On Thu, 2024-04-11 at 22:52 +, Bill Allombert wrote:
>
> When a change leads to a RC bug a month or three after having be
> part of a package, fixing the problem falls on the maintainer and not
> on the change author. Even correct changes can trigger latent bugs
> in software.
Yet another
On Wed, 2024-04-10 at 23:16 +0200, Johannes Schauer Marin Rodrigues
wrote:
> 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
On Tue, 2024-04-09 at 20:51 +0200, Gioele Barabucci wrote:
>
> Salsa is a forge, i.e. a combination of a Web interface, a git
> server,
> and a set of integrated features. In comparison to dgit, salsa has,
> like
> most forges:
>
> []
Also its a gitlab instance. There are all kinds of
On Mon, 2024-05-20 at 20:47 +, Scott Kitterman wrote:
> >
> > All these things should make it much more easy for other people or
> > automated tools to send merge requests or keep maintaining a
> > package in
> > case the original maintainer becomes MIA.
>
>
> Mandating a specific git
On May 20, 2024 7:54:46 PM UTC, Bernd Zeimetz wrote:
>Hi,
>
>On Sun, 2024-04-07 at 16:44 +0200, Andreas Tille wrote:
>>
>> Do you think that mandating Salsa is a sensible step in this
>> direction?
>
>
>Absolutely.
>
>Also I think requiring a common git layout and the usage of recent
Hi,
On Sun, 2024-04-07 at 16:44 +0200, Andreas Tille wrote:
>
> Do you think that mandating Salsa is a sensible step in this
> direction?
Absolutely.
Also I think requiring a common git layout and the usage of recent
versions of dh should be required. Using merge requests instead of
sending
On Sun, May 19, 2024 at 08:38:58PM -0700, Don Armstrong wrote:
> On Sun, 19 May 2024, Bill Allombert wrote:
> > Also debbugs is a special case:
> > The debbugs Debian package (as opposed to the debbugs software) have never
> > been
> > really maintained. I am actually one of the very few users of
> > Ideally debbugs should be made non-native so that some else could
> > maintain the Debian package.
>
> I'm happy to review patches that get the 2.6 branch of debbugs in shape
> where it can be released into Debian again if someone wants to take that
> effort. I've just assumed that anyone
On Sun, 19 May 2024, Bill Allombert wrote:
> Also debbugs is a special case:
> The debbugs Debian package (as opposed to the debbugs software) have never
> been
> really maintained. I am actually one of the very few users of this package
> and I tried several times to get the maintainers to do a
Hi,
On 5/20/24 04:32, Otto Kekäläinen wrote:
I agree that duplication is bad - but I disagree that use of version
control duplicates the use of the Debian archive for source code
storage, or that use of GitLab for code reviews would duplicate
Debbugs.
Outside of DM uploads, I'm not sure that
Thanks for reply Jonas,
> > You could go to
> > https://salsa.debian.org/debbugs-team/debbugs/-/merge_requests/19 and
> > conduct a code review?
> >
> > You might discover that GitLab is useful and is not duplicating
> > Debbugs or anything else in Debian - it is currently the only platform
> >
Quoting Otto Kekäläinen (2024-05-19 21:32:36)
> > > My concern about Gitlab is not its *additions* to existing services, but
> > > its *duplications* of core services already in Debian.
> >
> > I agree, that's the key problem.
>
> I agree that duplication is bad - but I disagree that use of
> > My concern about Gitlab is not its *additions* to existing services, but
> > its *duplications* of core services already in Debian.
>
> I agree, that's the key problem.
I agree that duplication is bad - but I disagree that use of version
control duplicates the use of the Debian archive for
Hi,
On 5/19/24 16:11, Jonas Smedegaard wrote:
My concern about Gitlab is not its *additions* to existing services, but
its *duplications* of core services already in Debian.
I agree, that's the key problem.
The Debian archive itself is a VCS, so git-maintained packaging is also
a
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
1 - 100 of 124 matches
Mail list logo
