Hi,
> Perhaps, to ease the burden of those of us maintaining many packages,
> we could instead have this more complex rule:
>
> > The default debian branch is the first available of these, in order:
> > 1. debian/latest
> > 2. debian/unstable
> > 3. debian/experimental
If no other information was
Hello,
On Thu 29 May 2025 at 11:31am +02, Marc Haber wrote:
> On Thu, May 29, 2025 at 10:27:09AM +0100, Sean Whitton wrote:
>>On Wed 28 May 2025 at 10:04pm +02, Marc Haber wrote:
>>> My personal pet peeve is the difference between the source package and the
>>> packaging git repository contents.
On Thu, May 29, 2025 at 10:27:09AM +0100, Sean Whitton wrote:
On Wed 28 May 2025 at 10:04pm +02, Marc Haber wrote:
My personal pet peeve is the difference between the source package and the
packaging git repository contents. Those two especially differ in the state of
patches: They're applied in
Hello,
On Thu 29 May 2025 at 05:26am +02, Joost van Baal-Ilić wrote:
> Isn't this what dgit is supposed to solve?
dgit solves this for people wanting to make local changes and NMUs, yes.
For maintainers, if you want to use patches-applied dgit will be happy
with it but you'll probably want to u
Hello,
On Wed 28 May 2025 at 10:04pm +02, Marc Haber wrote:
> My personal pet peeve is the difference between the source package and the
> packaging git repository contents. Those two especially differ in the state of
> patches: They're applied in the unpacked source package, and not applied in
>
On Thu, May 29, 2025 at 09:54:37AM +0200, Marc Haber wrote:
> On Thu, May 29, 2025 at 09:52:38AM +0200, Joost van Baal-Ilić wrote:
> > A, indeed. Otoh the dgit-people feel a source package should be treated as
> > an
> > intermediate build artifact; not something to be consumed by humans.
>
> Bu
Hi,
On Thu, May 29, 2025 at 09:39:01AM +0200, Marc Haber wrote:
> On Thu, May 29, 2025 at 05:26:31AM +0200, Joost van Baal-Ilić wrote:
> > On Wed, May 28, 2025 at 10:04:01PM +0200, Marc Haber wrote:
> >
> > > My personal pet peeve is the difference between the source package and the
> > > packagi
Quoting Marc Haber (2025-05-29 09:57:07)
> On Thu, May 29, 2025 at 09:21:13AM +0200, Jonas Smedegaard wrote:
> >Perhaps, to ease the burden of those of us maintaining many packages,
> >we could instead have this more complex rule:
> >
> >> The default debian branch is the first available of these,
On Thu, May 29, 2025 at 09:21:13AM +0200, Jonas Smedegaard wrote:
Perhaps, to ease the burden of those of us maintaining many packages,
we could instead have this more complex rule:
The default debian branch is the first available of these, in order:
1. debian/latest
2. debian/unstable
3. debia
On Thu, May 29, 2025 at 09:52:38AM +0200, Joost van Baal-Ilić wrote:
A, indeed. Otoh the dgit-people feel a source package should be treated as an
intermediate build artifact; not something to be consumed by humans.
But if you decide not to use dgit you're back to source packages. It
might be
On 29/05/2025 12:51 pm, Jonas Smedegaard wrote:
Quoting Xiyue Deng (2025-05-29 06:15:30)
Hi Holger,
Holger Levsen writes:
On Thu, May 29, 2025 at 12:21:16AM +0200, Jonas Smedegaard wrote:
If you suggest that using "debian/latest" should *not* be done by
default, then it seems that requires
Hi,
On Thu, May 29, 2025 at 05:26:31AM +0200, Joost van Baal-Ilić wrote:
On Wed, May 28, 2025 at 10:04:01PM +0200, Marc Haber wrote:
My personal pet peeve is the difference between the source package and the
packaging git repository contents. Those two especially differ in the state
of patches
Quoting Xiyue Deng (2025-05-29 06:15:30)
> Hi Holger,
>
> Holger Levsen writes:
>
> > On Thu, May 29, 2025 at 12:21:16AM +0200, Jonas Smedegaard wrote:
> >> If you suggest that using "debian/latest" should *not* be done by
> >> default, then it seems that requires reverting changes to DEP-14.
>
Hi,
On Wed, May 28, 2025 at 11:11:47PM +, Holger Levsen wrote:
my biggest problem with dep14 is that it doesnt recommend *one* layout. my
biggest problem with how I see that interpreted is that I think debian/unstable
is much better than debian/latest *as a default recommendation*.
because
Hi Holger,
Holger Levsen writes:
> On Thu, May 29, 2025 at 12:21:16AM +0200, Jonas Smedegaard wrote:
>> If you suggest that using "debian/latest" should *not* be done by
>> default, then it seems that requires reverting changes to DEP-14.
>
> yes. dep14 currently says "that uploads to unstable a
Hi,
On Wed, May 28, 2025 at 10:04:01PM +0200, Marc Haber wrote:
>
> thanks for writing the two most comprehensive docs about packaging, git and
> gbp I have read in the last years.
> Impressive work.
+1 !
> On Wed, May 28, 2025 at 06:36:00AM -0700, Otto Kekäläinen wrote:
> > in
> > particular
On Thu, May 29, 2025 at 12:21:16AM +0200, Jonas Smedegaard wrote:
> If you suggest that using "debian/latest" should *not* be done by
> default, then it seems that requires reverting changes to DEP-14.
yes. dep14 currently says "that uploads to unstable and experimental should
be prepared either
On Wed, May 28, 2025 at 10:05:44PM +, Holger Levsen wrote:
> I appreciate and applaus Otto's posts too, but can we please agree on
> debian/unstable, debian/experimental, debian/trixie, ... as our *default*?
> while still "allowing" debian/latest and and also debian/3.11 and
> debian/3.12 and
Quoting Holger Levsen (2025-05-29 00:05:44)
> On Wed, May 28, 2025 at 10:04:01PM +0200, Marc Haber wrote:
> > does it make sense to work in debian/latest and only last before pushing for
> > review create another branch next/debian/latest? I'd always intuitively work
> > in next/debian/latest direc
On Wed, May 28, 2025 at 10:04:01PM +0200, Marc Haber wrote:
> does it make sense to work in debian/latest and only last before pushing for
> review create another branch next/debian/latest? I'd always intuitively work
> in next/debian/latest directly.
I appreciate and applaus Otto's posts too, bu
Hi Otto,
thanks for writing the two most comprehensive docs about packaging, git
and gbp I have read in the last years. I even tried writing some. Will
stop doing that now that your docs exist. Impressive work.
I have some comments though.
On Wed, May 28, 2025 at 06:36:00AM -0700, Otto Kekäl
Hi,
In my experience many of the discussions about packaging workflows on
this list have many misconceptions, which in turn I think stems from
that our tools are a bit challenging to use, and the documentation is
somewhat lacking. Many tend to struggle to figure out how to do
something, and once t
On Wednesday, February 12, 2025 10:51:13 AM MST Raphael Hertzog wrote:
> That sounds like what the "debian_pipeline" workflow can do in
> https://debusine.debian.net, except that it is able to do it on multiple
> architectures and also run reverse dependencies autopkgtest (however it
> doesn't supp
Hi,
On Tue, 11 Feb 2025, Kirill Rekhov wrote:
> I wrote a script called chroot-debianizer that automates routine tasks related
> to Debian package management. This tool is designed to facilitate a clean and
> isolated package building process in chroot environments specifically for the
> amd64 arc
Hi, Dear Debian Engineers.
I hope this message finds you well. Sorry for advertising my small project.
I use this script often when working with Debian packages.
I wrote a script called chroot-debianizer that automates routine tasks related
to Debian package management. This tool is designed to
Hi!
Thanks for following up. Based on the feedback about the goal/scope I
decided to rewrite the DEP-18 almost completely, and published a new
draft at https://salsa.debian.org/dep-team/deps/-/merge_requests/12
On Tue, 5 Nov 2024 at 03:14, Jonathan Dowland wrote:
>
> It's been a while since -dev
It's been a while since -devel has heard anything about DEP-18¹, which
(Back in August or so) encouraged a large healthy discussion here, and
got some coverage on LWN².
Is there any news? Where are we at with this (pre-)³proposal?
[1]
https://salsa.debian.org/dep-team/deps/-/raw/798bfa5a1e160
On Sun Sep 1, 2024 at 6:14 PM BST, Otto Kekäläinen wrote:
> The discussion was summarized in a separate "Summay" email by me on this
> list, and a comment in the MR (which merges the two discussions) and it
> just happened that the next day it was also covered in
> https://lwn.net/Articles/986480/
Hi!
On Wed, Sep 4, 2024 at 12:39 PM PICCA Frederic-Emmanuel
wrote:
>
> Hello,
>
> > Well, I didn't mean we should *give up* decentralization. I mean we
> > shouldn't
> > give up *centralization*. These examples are to prove centralization
> > actually
> > works and is quite common, sometimes ne
On 04/09/2024 17:21, PICCA Frederic-Emmanuel wrote:
> Hello,
>
>> Well, I didn't mean we should *give up* decentralization. I mean we shouldn't
>> give up *centralization*. These examples are to prove centralization actually
>> works and is quite common, sometimes necessary.
>
> It would be great
Hello,
> Well, I didn't mean we should *give up* decentralization. I mean we shouldn't
> give up *centralization*. These examples are to prove centralization actually
> works and is quite common, sometimes necessary.
It would be great if we could run the salsa-ci pipeline localy easily, in
chroo
(Please send To/Cc me if you'd like to continue on this branch of conversation,
I'm not subscribed to -devel, only digests.)
On Wed, 04 Sep 2024 06:42:33 +0200, Jonas Smegegaard wrote:
> Quoting Blair Noctis (2024-09-04 04:33:10)
(...)
>> > PICCA Frederic-Emmanuel writes:
>> >
>> >> What about dog
On Tuesday, 3 September 2024 23.42.33 CDT Jonas Smedegaard wrote:
> I don't say that Debian must work for jungle developers, nor that we
> must all use email and not different forms of collaboration requiring
> better connectivity. My point is that Debian *allows* collaboration
> also without heav
Hi Blair,
Quoting Blair Noctis (2024-09-04 04:33:10)
> On 02/09/2024 06:38, Richard Lewis wrote:
> > PICCA Frederic-Emmanuel
> > writes:
> >
> >> What about dog fooding ?
> >>
> >> for now we can setup a schroot and sbuild very easily and start to build a
> >> local repository in minutes.
> >>
On 02/09/2024 06:38, Richard Lewis wrote:
> PICCA Frederic-Emmanuel
> writes:
>
>> What about dog fooding ?
>>
>> for now we can setup a schroot and sbuild very easily and start to build a
>> local repository in minutes.
>>
>> But when it comes to install gitlab and the CI system it is another
On 03/09/2024 15:36, Otto Kekäläinen wrote:
My information was based on what Salsa admin posted at
https://salsa.debian.org/salsa/support/-/issues/395
Hi Otto,
Thanks for that link,
which took me nearly a minute to open!
Quoting from there.
Could we keep the issue open for now and only clo
Hi!
> Hi Otto,
> Until recently I generally found Salsa response to be adequate,
> but for the last couple of days it has been so
> excruciatingly slow as to be almost unusable.
>
> > In response, Otto Kekäläinen noted that the Salsa admins
> > had posted about upcoming hardware upgrades and other
On 28/08/2024 03:13, Otto Kekäläinen wrote:
## Performance and Reliability
Multiple participants, including Salvo Tomaselli, Johannes Schauer
Marin Rodrigues, Andrea Pappacoda, and Gioele Barabucci, complained
about Salsa/GitLab being slow or unreliable at times, which deterred
contribution. Imp
PICCA Frederic-Emmanuel writes:
> What about dog fooding ?
>
> for now we can setup a schroot and sbuild very easily and start to build a
> local repository in minutes.
>
> But when it comes to install gitlab and the CI system it is another story. So
> we rely on the central salsa instance.
f
What about dog fooding ?
for now we can setup a schroot and sbuild very easily and start to build a
local repository in minutes.
But when it comes to install gitlab and the CI system it is another story. So
we rely on the central salsa instance.
It seems to me that a great strength of Debian i
> My overall impression is that this is a bold attempt, but the document could
> do
> with some copy-editing to whittle it down, make it more focussed, and possibly
> narrow the scope. E.g. perhaps Gitlab CI is too much in one go? Could that be
> done further down the line in a follow-up DEP?
I
Hi Jonathan!
The discussion was summarized in a separate "Summay" email by me on this
list, and a comment in the MR (which merges the two discussions) and it
just happened that the next day it was also covered in
https://lwn.net/Articles/986480/
I am currently writing revision 2 of the proposal.
Thanks for working on this. I finally had a read over it today.
I've found the split in discussion between this list and the Merge Request
comments
hard to manage. It would help a lot, I think, if some of the MR threads were
marked
resolved, assuming the issues they describe are resolved. Tha
Hi!
> NOTE: The following idea might be out-of-scope in DEP-18, but specific
> use-case to improve
> collaboration in Debian, IMHO.
>
> Here is just an idea: put collaboration policy metadata in debian/control.
> (The following idea assumes that non-maintainer DD tend to hesitate to
> commit/merge
Il 28/08/2024 04:13, Otto Kekäläinen ha scritto:
Hi!
While I intend to continue on iterating DEP-18, here is a summary to
those who did not wade through the 140+ messages on the topic.
Unfortunately, the summary itself is also a bit long :)
Big thanks for your work and of other people that are t
Hi!
While I intend to continue on iterating DEP-18, here is a summary to
those who did not wade through the 140+ messages on the topic.
Unfortunately, the summary itself is also a bit long :)
Summary of mailing list
[resending to your correct address]
Hello,
On Mon 05 Aug 2024 at 06:14am +05, Andrey Rakhmatullin wrote:
> It's similar but different: I'm talking about workflows to build a package
> from the repo (e.g. "gbp with gbp-pq and importing upstream tarballs").
> And yeah it could be a metadata field.
Hello,
On Mon 05 Aug 2024 at 06:14am +05, Andrey Rakhmatullin wrote:
> It's similar but different: I'm talking about workflows to build a package
> from the repo (e.g. "gbp with gbp-pq and importing upstream tarballs").
> And yeah it could be a metadata field.
Just to note that once people are u
Hello,
On Sat 03 Aug 2024 at 11:29am -07, Soren Stoutner wrote:
> 1. Debian workflows are too fractured. The project would be better if we
> asked people
> to standardize around a single (or a small number) of workflows. To do so,
> the workflow
> would need to be flexible enough to handle t
Hello,
On Sat 03 Aug 2024 at 09:19am +02, PICCA Frederic-Emmanuel wrote:
> Hello, I like the dgit idea, produce a git repository for people who want to
> use git and let other use whatever they want.
>
> Maybe uploading a paquage to Debian could push automatically into dgit. (maybe
> this is alre
Hello,
On Sat 03 Aug 2024 at 08:26am +02, Jonas Smedegaard wrote:
> My problem with DEP-18 is that people who have zero problem with using
> git and are also not fundamentally against using salsa, but have
> reservations surrounding *which parts* of salsa to use and the
> consequences for related
Il 05/08/2024 10:40, Simon Richter ha scritto:
Hi,
On 8/5/24 17:10, Fabio Fantoni wrote:
currently you find such information from a simple search and/or
looking a bit in the source, in the possible git in a few minutes
only in part of cases, in many other cases instead it requires more
time,
Hi,
On 8/5/24 17:10, Fabio Fantoni wrote:
currently you find such information from a simple search and/or looking
a bit in the source, in the possible git in a few minutes only in part
of cases, in many other cases instead it requires more time, the
possible contact of the maintainer, attempt
Fabio Fantoni:
Il 05/08/2024 03:14, Andrey Rakhmatullin ha scritto:
[...]
Thanks for reply, what I mean is precisely a standard field that points
to a file, inside the package or even an url as already explained can be
very useful in most cases) that contains all the useful information for
c
Il 05/08/2024 03:14, Andrey Rakhmatullin ha scritto:
On Sun, Aug 04, 2024 at 04:15:13PM +0200, Fabio Fantoni wrote:
Il 04/08/2024 15:36, Andrey Rakhmatullin ha scritto:
On Sat, Aug 03, 2024 at 04:15:33PM +0900, Charles Plessy wrote:
one problem I have with NMUs in team-maintained package is th
On Sun, Aug 04, 2024 at 04:15:13PM +0200, Fabio Fantoni wrote:
> Il 04/08/2024 15:36, Andrey Rakhmatullin ha scritto:
> > On Sat, Aug 03, 2024 at 04:15:33PM +0900, Charles Plessy wrote:
> > > one problem I have with NMUs in team-maintained package is that they
> > > often bypass Salsa… Would it ma
Il 04/08/2024 15:36, Andrey Rakhmatullin ha scritto:
On Sat, Aug 03, 2024 at 04:15:33PM +0900, Charles Plessy wrote:
one problem I have with NMUs in team-maintained package is that they
often bypass Salsa… Would it make sense to add to the DEP a request
that NMUs are started from and pushed to
On Sat, Aug 03, 2024 at 04:15:33PM +0900, Charles Plessy wrote:
> one problem I have with NMUs in team-maintained package is that they
> often bypass Salsa… Would it make sense to add to the DEP a request
> that NMUs are started from and pushed to the default branch?
Only if DEP-18 also includes
On Sat, Aug 03, 2024 at 10:37:42PM +0200, Salvo Tomaselli wrote:
> > 2. Standardizing around a single (or small number of) workflows will make
> > some people unhappy. But that is an acceptable price to pay because of the
> > general benefit to the project *as long as the correct solution is
> >
Hi all,
On 03-08-2024 22:37, Salvo Tomaselli wrote:
At the bottom, is it ok for a package to have a single maintainer or not?
I have never wanted to be the single maintainer of a package, and here I
am, I'm member of a bunch of teams, but most of my packages uploads (not
a lot luckily) are f
Hi!
> I have three feelings.
>
>
> 1. Debian workflows are too fractured. The project would be better if we
> asked people to standardize around a single (or a small number) of workflows.
> To do so, the workflow would need to be flexible enough to handle the wide
> range of technical needs
On Saturday, August 3, 2024 1:37:42 PM MST Salvo Tomaselli wrote:
> > 2. Standardizing around a single (or small number of) workflows will make
> > some people unhappy. But that is an acceptable price to pay because of
the
> > general benefit to the project *as long as the correct solution is
>
On Friday, August 2, 2024 11:26:01 PM MST Jonas Smedegaard wrote:
> I imagine that some in the silent crowd hesitate to chime in due to that
> lumping together the use of git and the use of Gitlab into an
> all-or-nothing choice. I think you intended that reduction, for the
> purpose of simplifyin
ntent of each
> >>> package repository on salsa.d.o and NMU'ed package source.
> >>> * Because other DD (non package owner) can commit/merge, then ship
> >>> NMU package.
> >>> Cons:
> >>> * Maintainers will be bothered to add
-called package hijack
with incomplete communication in some cases.
Hi, this I think is can be useful (beyond the example use of
salsa/debian packages which is not necessary as replied by Tobias
Frost), I think will be better with only one additional (and optional)
field in d/control, like Collaborat
aboration-Policy-Merge: no policy
> >because DD has maintainer rights on salsa.d.o and can commit/merge
> > it in reality.
> >
> > It might worry too much, but it might be able to block an unfortunate
> > accident, a so-called package hijack
> > with incomplete c
Il 03/08/2024 15:16, Jonas Smedegaard ha scritto:
Quoting Kentaro Hayashi (2024-08-03 14:40:51)
Hi,
Even though +1 for DEP-18 basically, I think that it might be better
to add an option
to formalize package owner's (single person maintainer) collaboration policy
especially about non-team mainta
ond the example use of
salsa/debian packages which is not necessary as replied by Tobias
Frost), I think will be better with only one additional (and optional)
field in d/control, like Collaboration-Policy that point a file or url,
this I think that can decrease the possible annoyance and in the
Quoting Kentaro Hayashi (2024-08-03 14:40:51)
> Hi,
>
> Even though +1 for DEP-18 basically, I think that it might be better
> to add an option
> to formalize package owner's (single person maintainer) collaboration policy
> especially about non-team maintained packages under
> https://salsa.debia
On Sat, Aug 03, 2024 at 09:40:51PM +0900, Kentaro Hayashi wrote:
> Hi,
>
> Even though +1 for DEP-18 basically, I think that it might be better
> to add an option
> to formalize package owner's (single person maintainer) collaboration policy
> especially about non-team maintained packages under
>
Hi, Tobias.
Thank you for kindly advice, I've misunderstood about debian/ namespace.
Please ignore the previous my post. [1]
I felt sorry posting just a noise.
[1] https://lists.debian.org/debian-devel/2024/08/msg00052.html
Regards,
2024年8月3日(土) 21:54 Tobias Frost :
>
> On Sat, Aug 03, 2024 at
afted a new DEP at
> https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18:
> Enable true open collaboration on all Debian packages".
>
> Direct link to raw text:
> https://salsa.debian.org/dep-team/deps/-/raw/798bfa5a1e1609afd4e48ee20aff80a82bcd4a2f/web/deps/dep18.md
Il 03/08/2024 01:28, Jonas Smedegaard ha scritto:
Quoting Fabio Fantoni (2024-08-02 23:51:26)
Il 02/08/2024 15:49, Jonas Smedegaard ha scritto:
I think that both email and systems like salsa/github/gitlab etc. are
useful, both with pros and cons. Forcing people to use only one or the
other coul
Hello, I like the dgit idea, produce a git repository for people who want to
use git and let other use whatever they want.
Maybe uploading a paquage to Debian could push automatically into dgit. (maybe
this is already the case)
Is it possible then to mirror this dgit repository in salsa ?
Fred
On Sat, Aug 03, 2024 at 04:15:33PM +0900, Charles Plessy wrote:
> > I have drafted a new DEP at
> > https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18:
> > Enable true open collaboration on all Debian packages".
>
> Hi Otto,
>
>
Le Sat, Jul 27, 2024 at 03:38:40PM -0700, Otto Kekäläinen a écrit :
>
> I have drafted a new DEP at
> https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled "DEP-18:
> Enable true open collaboration on all Debian packages".
Hi Otto,
thank you for your initiativ
On Sat, Aug 3, 2024 at 2:26 PM Jonas Smedegaard wrote:
>
> My problem with DEP-18 is that people who have zero problem with using
> git and are also not fundamentally against using salsa, but have
> reservations surrounding *which parts* of salsa to use and the
> consequences for related already u
Quoting Otto Kekäläinen (2024-08-03 06:38:38)
> > I am not suggesting salsa use because I think it's the best thing since the
> > invention of sliced bread. But personally, I rather use something
> > suboptimal if
> > it means that we can more or less agree on a "default" and I think that the
> >
Hi,
On Fri, 2 Aug 2024 at 16:27, Johannes Schauer Marin Rodrigues
wrote:
> Quoting Otto Kekäläinen (2024-08-02 17:23:51)
> > I agree that Salsa is sometimes a bit sluggish
> > (https://salsa.debian.org/salsa/support/-/issues/395),
>
> what kind of hardware do you have? For people like me who are
Quoting Fabio Fantoni (2024-08-02 23:51:26)
> Il 02/08/2024 15:49, Jonas Smedegaard ha scritto:
> >> I think that both email and systems like salsa/github/gitlab etc. are
> >> useful, both with pros and cons. Forcing people to use only one or the
> >> other could be counterproductive at the moment.
Hi,
Quoting Otto Kekäläinen (2024-08-02 17:23:51)
> I agree that Salsa is sometimes a bit sluggish
> (https://salsa.debian.org/salsa/support/-/issues/395),
what kind of hardware do you have? For people like me who are on slower
hardware, the web experience is absolutely not funny and "a bit slugg
Il 02/08/2024 15:49, Jonas Smedegaard ha scritto:
Hi Fabio,
Quoting Fabio Fantoni (2024-08-02 14:31:04)
One particular thing noticed in some cases (and I hope they are not
many) is the lack of use or especially updates of the Vcs-* fields in
d/control. I think is important point to packaging re
Hi!
On Fri, 2 Aug 2024 at 02:27, Andrea Pappacoda wrote:
..
> Before a certain way of doing things can be mandated or "warmly
> recommended", the technology has to be as flawless as possible - and
> today I wouldn't call Salsa "flawless", would you? Issues with
> Salsa/GitLab:
>
> 1. It is so slo
Hi Fabio,
Quoting Fabio Fantoni (2024-08-02 14:31:04)
> One particular thing noticed in some cases (and I hope they are not
> many) is the lack of use or especially updates of the Vcs-* fields in
> d/control. I think is important point to packaging repository from the
> tracker if present and t
EP-18: Enable true open collaboration on all Debian packages".
Thanks for your work on this. Trying to unify aspects of Debian
development is one of the things I think we need to do to not only
"enable true open collaboration", but also to attract more new
contributors.
While t
On 02/08/2024 06:38, Salvo Tomaselli wrote:
> Also, there's IRC/matrix for more real time communication, but I challenge
> you
> to follow those long threads on d-devel on something like teams or slack.
Discourse. Or some other "forum" software. IMO online forums and mailing lists
are pretty simi
On 02/08/24 11:20, Andrea Pappacoda wrote:
Issues with Salsa/GitLab:
1. It is so slow that it makes me want to close by browser and do
something else instead
[...]
5. Did I mention how slow it is?
Just as a side note: yes, salsa.d.o/GitLab is not the snappiest Web
application ever and somet
Hi Otto, and all the others participating in this thread :)
Il giorno sab 27 lug 2024 alle 15:38:40 -07:00:00, Otto Kekäläinen
ha scritto:
I have drafted a new DEP at
https://salsa.debian.org/dep-team/deps/-/merge_requests/8 titled
"DEP-18: Enable true open collaboration on all D
Quoting Salvo Tomaselli (2024-08-02 00:38:15)
> > saying out loud phrases such as "The only right way to
> > collaborate is reading and writing emails is in my terminal"
>
> Please. This feels like trolling.
>
> You're literally making up a quote and then you reply to it.
>
> Nobody said that.
On 2024-08-01 22:10:58 +0100 (+0100), Luca Boccassi wrote:
> On Thu, 1 Aug 2024 at 18:23, Jeremy Stanley wrote:
> >
> > On 2024-08-01 12:23:43 +0100 (+0100), Luca Boccassi wrote:
> > [...]
> > > To pick a random example, a less well known, less used, less
> > > popular distribution like Nixos has
On Thu, 1 Aug 2024 at 18:23, Jeremy Stanley wrote:
>
> On 2024-08-01 12:23:43 +0100 (+0100), Luca Boccassi wrote:
> [...]
> > To pick a random example, a less well known, less used, less
> > popular distribution like Nixos has 7000+ contributors listed on
> > Github.
> [...]
>
> Just to pick on th
On Thu, 1 Aug 2024 at 21:57, Marc Haber wrote:
>
> On Thu, 1 Aug 2024 18:36:29 +0100, Luca Boccassi
> wrote:
> >On Thu, 1 Aug 2024 at 18:16, Marc Haber wrote:
> >>
> >> On Thu, 1 Aug 2024 12:23:43 +0100, Luca Boccassi
> >> wrote:
> >> >The vast majority of people who
> >> >are forced to use ema
On Thu, 1 Aug 2024 18:36:29 +0100, Luca Boccassi
wrote:
>On Thu, 1 Aug 2024 at 18:16, Marc Haber wrote:
>>
>> On Thu, 1 Aug 2024 12:23:43 +0100, Luca Boccassi
>> wrote:
>> >The vast majority of people who
>> >are forced to use emails do so for work via a
>> >work-mediated/administered interface
On Thu, 1 Aug 2024 at 18:16, Marc Haber wrote:
>
> On Thu, 1 Aug 2024 12:23:43 +0100, Luca Boccassi
> wrote:
> >The vast majority of people who
> >are forced to use emails do so for work via a
> >work-mediated/administered interface that tries to make it somewhat
> >tolerable, like Outlook or Gma
On 2024-08-01 12:23:43 +0100 (+0100), Luca Boccassi wrote:
[...]
> To pick a random example, a less well known, less used, less
> popular distribution like Nixos has 7000+ contributors listed on
> Github.
[...]
Just to pick on this particular point, because I see this metric
used all the time by p
On Thu, 1 Aug 2024 12:23:43 +0100, Luca Boccassi
wrote:
>The vast majority of people who
>are forced to use emails do so for work via a
>work-mediated/administered interface that tries to make it somewhat
>tolerable, like Outlook or Gmail.
This must be the least accurate statement about Outlook t
Yes, tag2upload. It’s almost ready :)
Please wait a little longer.
--
Sean Whitton
Please excuse top-posting and brevity. I am writing to you from a mobile phone.
> On 1 Aug 2024, at 20:43, Charles Plessy wrote:
>
> Le Thu, Aug 01, 2024 at 12:23:43PM +0100, Luca Boccassi a écrit :
>>
>> ru
On Aug 01, Luca Boccassi wrote:
> Emails are actually a barrier against collaboration, and actively
> hinder it by preventing new people from joining in. Please understand
No, email is the only inclusive collaboration platform.
I can use email while traveling and when the least possible connectiv
On Thu, 1 Aug 2024 at 13:43, Charles Plessy wrote:
>
> Le Thu, Aug 01, 2024 at 12:23:43PM +0100, Luca Boccassi a écrit :
> >
> > run a CI before uploading, even a very basic one is just fine, better
> > than nothing.
>
> Thanks for the remider ! I will have a closer look at Salsa CI instead
> of
Le Thu, Aug 01, 2024 at 12:23:43PM +0100, Luca Boccassi a écrit :
>
> run a CI before uploading, even a very basic one is just fine, better
> than nothing.
Thanks for the remider ! I will have a closer look at Salsa CI instead
of trying to understand how to run autopkgtests locally.
Would there
1 - 100 of 1025 matches
Mail list logo
