Hi!
> > I would very much like to see all top-150 packages run Salsa CI at
> > least once before being uploaded to unstable. What people think is a
> > reasonable way to proceed to reach this goal?
> Advertise widely and frequently that there is a pool of people which is
> happy to help investigat
Le Tue, Aug 20, 2024 at 07:28:52AM +0200, Helmut Grohne a écrit :
>
> please allow me to open a can of worms. Package removal from unstable.
Hi all,
I think that package removal from Unstable, total or partial (for
instance, 32-bit architectures) should be an automated self-sevice
system for lea
On Aug 21, Otto Kekäläinen wrote:
> I would very much like to see all top-150 packages run Salsa CI at
> least once before being uploaded to unstable. What people think is a
> reasonable way to proceed to reach this goal?
Advertise widely and frequently that there is a pool of people which is
ha
Hi!
In short:
I would very much like to see all top-150 packages run Salsa CI at
least once before being uploaded to unstable. What people think is a
reasonable way to proceed to reach this goal?
Background:
We have had several cases recently where an upload to Debian unstable
causes widespread
Hi Lukas,
CCing d-devel,
tl;dr: I'm sorry to say I strongly oppose both removing ifupdown* in forky
as well as raising netplan to Priority: standard. To move this forward
without conflict I think we should base the default networking tool
decision on data not developer opinion.
On Tue, Aug 20, 20
On August 20, 2024 12:16:47 PM UTC, Andrey Rakhmatullin wrote:
>On Tue, Aug 20, 2024 at 12:12:33PM +, Scott Kitterman wrote:
>> >Removing packages that aren't formally orphaned always sounds too bold to
>> >me, though it should be fine if we formalize a process (any process) for
>> >that.
>
On Tue, Aug 20, 2024 at 12:12:33PM +, Scott Kitterman wrote:
> >Removing packages that aren't formally orphaned always sounds too bold to
> >me, though it should be fine if we formalize a process (any process) for
> >that.
> >
> The process currently is file an rm but against ftp.debian.org for
On August 20, 2024 7:46:05 AM UTC, Andrey Rakhmatullin wrote:
>On Tue, Aug 20, 2024 at 07:28:52AM +0200, Helmut Grohne wrote:
>> please allow me to open a can of worms. Package removal from unstable.
>> Deciding when it is time to remove a package from unstable is difficult.
>> There may be use
Hi,
On 8/20/24 18:09, Bastian Venthur wrote:
That's what I thought too: we should somehow incorporate the popcon
value.
I disagree -- the users most affected by a removal are those who
automate installation, and those will not be running popcon.
Can you elaborate on that claim? I probably mi
Hi,
On 20/08/24 at 07:28 +0200, Helmut Grohne wrote:
> There are various QA-related teams looking at packages from other
> maintainers. When it trips a check, that often incurs time from some QA
> person investigating a report or failure. Examples:
> * Lucas Nussbaum, Santiago Vila and a few more
On 2024-08-20 Helmut Grohne wrote:
> Hi fellow developers,
> (modified resend, as first attempt didn't arrive)
> please allow me to open a can of worms. Package removal from unstable.
> Deciding when it is time to remove a package from unstable is difficult.
> There may be users still and it is
On Tue, Aug 20, 2024 at 11:09:51AM +0200, Bastian Venthur wrote:
> I think popcon does give a good approximation of how much percent of people
> installed a certain package even if not everyone uses it, don't you agree?
>
> Last time I installed Debian it was still enabled by default.
Was it?
(t
On 20.08.24 10:45, Simon Richter wrote:
Hi,
On 8/20/24 17:35, Bastian Venthur wrote:
That's what I thought too: we should somehow incorporate the popcon
value.
I disagree -- the users most affected by a removal are those who
automate installation, and those will not be running popcon.
Can y
Hi,
On 8/20/24 17:35, Bastian Venthur wrote:
That's what I thought too: we should somehow incorporate the popcon value.
I disagree -- the users most affected by a removal are those who
automate installation, and those will not be running popcon.
Popcon was introduced to determine which pac
On 20.08.24 07:55, Johannes Schauer Marin Rodrigues wrote:
Hi,
[...]
if I remember correctly, a package can also become a key package by having a
high-enough popcon value. If that is correct, maybe there should also be the
inverse. Looking at your list, about 85% of those packages have a popcon
Helmut Grohne:
Hi fellow developers,
(modified resend, as first attempt didn't arrive)
please allow me to open a can of worms. Package removal from unstable.
Deciding when it is time to remove a package from unstable is difficult.
There may be users still and it is unclear whether keeping the p
On Mon, 19 Aug 2024 at 22:42:53 -0700, Otto Kekäläinen wrote:
> ## How many packages have a 'upstream-vcs-tag' and what is it typically?
Unlike most of the other questions you asked and answered (thanks!) we
should never expect this to be consistent, because it isn't Debian's
decision: it's upstre
On Tue, Aug 20, 2024 at 07:28:52AM +0200, Helmut Grohne wrote:
> please allow me to open a can of worms. Package removal from unstable.
> Deciding when it is time to remove a package from unstable is difficult.
> There may be users still and it is unclear whether keeping the package
> imposes a cos
Hi,
there's a bit of a discussion within Debian on collaborating using Git.
One of the long-standing issues is that there are multiple ways Debian
packaging can be represented in a git tree, and none of them are optimal.
The problem at hand is that the packaging workflow consists of
1. impor
19 matches
Mail list logo
