On 1/6/25 10:11 PM, Andreas Tille wrote:
Personally, my main challenge is having to focus on the same issue
twice, with a minimum delay of 21 days in between. For example, I
encountered an ITS bug that had been lingering in the BTS for over a
year. The waiting period is entirely reasonable under
Hi Tobias,
Am Mon, Jan 06, 2025 at 10:30:04AM +0100 schrieb Tobias Frost:
> On Mon, Jan 06, 2025 at 09:19:26AM +0100, Niels Thykier wrote:
> > Rather than inactive maintainers. For inactive maintainers, we have the ITS
> > process, which I believe is working (at least better than what we had befor
Hi all
On Mon, Jan 06, 2025 at 09:19:26AM +0100, Niels Thykier wrote:
> Rather than inactive maintainers. For inactive maintainers, we have the ITS
> process, which I believe is working (at least better than what we had before
> the ITS process).
When introducing the process ad Debconf18 in Taiwa
Andreas Tille:
Hi Niels,
Am Sun, Jan 05, 2025 at 12:40:54PM +0100 schrieb Niels Thykier:
The "I'll do the job until the second someone else shows up" sounds close to
RFA (Request For Adoption).
Maybe we can do with a variant like OFA (Open For Adoption), which does not
have the "lingering owne
Hi Niels,
Am Sun, Jan 05, 2025 at 12:40:54PM +0100 schrieb Niels Thykier:
> The "I'll do the job until the second someone else shows up" sounds close to
> RFA (Request For Adoption).
>
> Maybe we can do with a variant like OFA (Open For Adoption), which does not
> have the "lingering ownership" t
Hi,
> Gioele Barabucci:
> We need different levels of responsibility:
>
> * Nobody cares ⇒ orphan package
> * I care a bit, but I don't have time to handle all the responsibilities
> that a maintainership entail, but try to contact me anyway, I may reply
> ⇒ MISSING LEVEL discussed here
> * I care
Niels Thykier:
Marc Haber:
On Sat, 21 Dec 2024 22:23:19 +0100, Gioele Barabucci
wrote:
This branch of the discussion started by pointing out the fact that some
maintainers _do_ in fact orphan their packages to remove the "feeling of
being responsible", and then go on maintaining these packages
Marc Haber:
On Sat, 21 Dec 2024 22:23:19 +0100, Gioele Barabucci
wrote:
This branch of the discussion started by pointing out the fact that some
maintainers _do_ in fact orphan their packages to remove the "feeling of
being responsible", and then go on maintaining these packages.
Its a way to
* Andreas Metzler [241224 11:53]:
> On 2024-12-23 Gioele Barabucci wrote:
> > On 22/12/24 06:56, Andreas Metzler wrote:
> >> On 2024-12-22 Sean Whitton wrote:
> >>> On Sat 21 Dec 2024 at 10:23pm +01, Gioele Barabucci wrote:
>
> We have a mechanism for when you feel responsible: "Maintainer
On 2024-12-23 Gioele Barabucci wrote:
> On 22/12/24 06:56, Andreas Metzler wrote:
>> On 2024-12-22 Sean Whitton wrote:
>>> On Sat 21 Dec 2024 at 10:23pm +01, Gioele Barabucci wrote:
We have a mechanism for when you feel responsible: "Maintainer: $me".
What is being discussed here is a
On 22/12/24 06:56, Andreas Metzler wrote:
On 2024-12-22 Sean Whitton wrote:
On Sat 21 Dec 2024 at 10:23pm +01, Gioele Barabucci wrote:
We have a mechanism for when you feel responsible: "Maintainer: $me".
What is being discussed here is a mechanism for shared, collective,
diffused respons
Hi Andreas,
On Sun, Dec 22, 2024 at 07:26:15AM +0100, Andreas Metzler wrote:
> On 2024-12-22 Sean Whitton wrote:
> > On Sat 21 Dec 2024 at 06:15pm +01, Chris Hofstaedtler wrote:
>
> >> Uploads to the archive are not irreversible. You can just as well
> >> upload a new version reverting whatever
* Andrey Rakhmatullin [241222 10:15]:
> On Sun, Dec 22, 2024 at 07:26:15AM +0100, Andreas Metzler wrote:
> > >> Uploads to the archive are not irreversible. You can just as well
> > >> upload a new version reverting whatever was done.
> >
> > >> Please everybody stop treating the archive as the h
On Sun, Dec 22, 2024 at 07:26:15AM +0100, Andreas Metzler wrote:
> >> Uploads to the archive are not irreversible. You can just as well
> >> upload a new version reverting whatever was done.
>
> >> Please everybody stop treating the archive as the holy thing that
> >> only blessed maintainers can
On Sat, 21 Dec 2024 22:23:19 +0100, Gioele Barabucci
wrote:
>This branch of the discussion started by pointing out the fact that some
>maintainers _do_ in fact orphan their packages to remove the "feeling of
>being responsible", and then go on maintaining these packages.
Its a way to visibly sa
On 2024-12-22 Sean Whitton wrote:
> On Sat 21 Dec 2024 at 06:15pm +01, Chris Hofstaedtler wrote:
>> Uploads to the archive are not irreversible. You can just as well
>> upload a new version reverting whatever was done.
>> Please everybody stop treating the archive as the holy thing that
>> only
On 2024-12-22 Sean Whitton wrote:
> On Sat 21 Dec 2024 at 10:23pm +01, Gioele Barabucci wrote:
>> We have a mechanism for when you feel responsible: "Maintainer: $me".
>> What is being discussed here is a mechanism for shared, collective,
>> diffused responsibility: "If this package is in bad sh
> From
> https://wiki.debian.org/Salsa/Doc#Collaborative_Maintenance:_.22Debian.22_group:
>
> The debian group is for CollaborativeMaintenance (the old collab-maint
> on Alioth).
>
> The group is accessible to all Debian developers upon linking their
> SSO Account, and are granted Maintain
> > Commits onto a git repo can be reversed easily (via `git revert`
> > or forced push, if one really wants to), but problematic uploaded
> > packages to the archive are irreversible and might cause broader
> > damages. That is why people are okay with allowing random git commits
> > to Debian gro
> The https://go-team.pages.debian.net/ pages may have some flaws, but one
> key social function is that it establishes the group as a team effort.
> That goal is something to take after. I'm trying migrate my
+1
> pkg-auth-maintainers packages to pkg-security just because
> https://wiki.debian.
Hello,
On Sat 21 Dec 2024 at 10:23pm +01, Gioele Barabucci wrote:
> We have a mechanism for when you feel responsible: "Maintainer: $me".
>
> What is being discussed here is a mechanism for shared, collective, diffused
> responsibility: "If this package is in bad shape, the whole Debian project
>
Hello,
On Sat 21 Dec 2024 at 06:15pm +01, Chris Hofstaedtler wrote:
> Uploads to the archive are not irreversible. You can just as well
> upload a new version reverting whatever was done.
>
> Please everybody stop treating the archive as the holy thing that
> only blessed maintainers can touch. T
Hello,
On Sat 21 Dec 2024 at 09:37am +01, Simon Josefsson wrote:
> I've long though about changing maintainer to QA for my packages like
> you suggest, but there has been at least on reason I haven't done so:
> lack of clear effective written down team policy in what the conventions
> are. I don
Hello,
Another thought I had was just to use the packages.d.o address.
E.g.
Maintainer: Debian developers
It would be invalid to use this in maintainers without any human
uploaders. Only q...@packages.debian.org is valid without human
uploaders.
--
Sean Whitton
On 21/12/24 15:32, Tobias Frost wrote:
On Sat, Dec 21, 2024 at 02:09:28PM +0100, Gioele Barabucci wrote:
On 21/12/24 10:15, Pirate Praveen wrote:
We could use collab maint list, which was specifically created for this
https://wiki.debian.org/CollaborativeMaintenance
Good idea.
To sum up all
On Sat, Dec 21, 2024 at 12:09:57PM -0500, Boyuan Yang wrote:
> Commits onto a git repo can be reversed easily (via `git revert`
> or forced push, if one really wants to), but problematic uploaded
> packages to the archive are irreversible and might cause broader
> damages. That is why people are ok
* Boyuan Yang [241221 18:10]:
> 在 12/21/2024 12:02 PM, Jeremy Sowden 写道:
> > On 2024-12-21, at 17:55:39 +0100, Marc Haber wrote:
> > > On Sat, 21 Dec 2024 12:08:35 +0100, Tobias Frost wrote:
> > > > We DO already have the debian namespace on salsa, everything in this
> > > > namespace is "team mai
在 12/21/2024 12:02 PM, Jeremy Sowden 写道:
On 2024-12-21, at 17:55:39 +0100, Marc Haber wrote:
On Sat, 21 Dec 2024 12:08:35 +0100, Tobias Frost wrote:
We DO already have the debian namespace on salsa, everything in this
namespace is "team maintained by everyone.",
Is that so? I know that I agre
On 2024-12-21, at 17:55:39 +0100, Marc Haber wrote:
> On Sat, 21 Dec 2024 12:08:35 +0100, Tobias Frost wrote:
> > We DO already have the debian namespace on salsa, everything in this
> > namespace is "team maintained by everyone.",
>
> Is that so? I know that I agree that anybody can commit to my
On Sat, 21 Dec 2024 12:08:35 +0100, Tobias Frost
wrote:
>We DO already have the debian namespace on salsa, everything in this
>namespace is "team maintained by everyone.",
Is that so? I know that I agree that anybody can commit to my
repositories that are in Salsa's debian namespace, but I actual
On Sat, Dec 21, 2024 at 02:09:28PM +0100, Gioele Barabucci wrote:
> On 21/12/24 10:15, Pirate Praveen wrote:
> > We could use collab maint list, which was specifically created for this
> > https://wiki.debian.org/CollaborativeMaintenance
>
> Good idea.
>
> To sum up all suggestions until now:
>
On 21/12/24 10:15, Pirate Praveen wrote:
We could use collab maint list, which was specifically created for this
https://wiki.debian.org/CollaborativeMaintenance
Good idea.
To sum up all suggestions until now:
Some packages will be maintained in a default-open way and outside a
specific team
On Sat, Dec 21, 2024 at 10:11:55AM +0800, Sean Whitton wrote:
> Hello,
>
> On Thu 12 Dec 2024 at 10:43am +01, Gioele Barabucci wrote:
>
> > an alternative that I was thinking of, is making this "everybody is onboard"
> > policy more explicit by having a special email to use for the Maintainer
> >
Le 21 décembre 2024 10:15:35 GMT+01:00, Pirate Praveen
a écrit :
>
>Please don't. We did the opposite for javascript team, we created a dedicated
>discussion list since the volume of mails were too huge, go and ruby teams do
>this too. All accepted, processed mails come to this list.
+1
W
Em 20 de dezembro de 2024 23:11:55 GMT-03:00, Sean Whitton
escreveu:
>Hello,
>
>On Thu 12 Dec 2024 at 10:43am +01, Gioele Barabucci wrote:
>
>> an alternative that I was thinking of, is making this "everybody is onboard"
>> policy more explicit by having a special email to use for the Maintain
On ശ, ഡിസം 21 2024 at 04:44:01 വൈകു +08:00:00
+08:00:00, Sean Whitton wrote:
Hello,
On Sat 21 Dec 2024 at 08:09am +01, Gioele Barabucci wrote:
On 21/12/24 03:11, Sean Whitton wrote:
an alternative that I was thinking of, is making this "everybody
is onboard"
policy more explicit by hav
Hello,
On Sat 21 Dec 2024 at 08:09am +01, Gioele Barabucci wrote:
> On 21/12/24 03:11, Sean Whitton wrote:
>>> an alternative that I was thinking of, is making this "everybody is onboard"
>>> policy more explicit by having a special email to use for the Maintainer
>>> field. For example:
>>>
>>>
Gioele Barabucci writes:
> Hi,
>
> an alternative that I was thinking of, is making this "everybody is
> onboard" policy more explicit by having a special email to use for the
> Maintainer field. For example:
>
> Maintainer: Debian community
>
> The stewards of the package could be listed a
Hi Sean,
Am Sat, Dec 21, 2024 at 10:11:55AM +0800 schrieb Sean Whitton:
>
> We don't need new vocabulary and a new mailing list for this.
> Let's use:
>
> Maintainer: Debian developers
>
> Maintainer: Debian contributors
>
> (lowercase 'd' deliberate)
I really like this suggestion i
On 21/12/24 03:11, Sean Whitton wrote:
an alternative that I was thinking of, is making this "everybody is onboard"
policy more explicit by having a special email to use for the Maintainer
field. For example:
Maintainer: Debian community
The stewards of the package could be listed as Uplo
Hello,
On Thu 12 Dec 2024 at 08:57am +01, Matthias Urlichs wrote:
> On 04.12.24 18:08, Andreas Tille wrote:
>> in the
>> absence of a debian/dont_touch_my_package file, any Debian Developer is
>> permitted to upload the package.
>
> I like this idea.
>
> The next step: agree on a "standard" Debia
Hello,
On Thu 12 Dec 2024 at 10:43am +01, Gioele Barabucci wrote:
> an alternative that I was thinking of, is making this "everybody is onboard"
> policy more explicit by having a special email to use for the Maintainer
> field. For example:
>
> Maintainer: Debian community
>
> The stewards
Hi Matthias,
Quoting Matthias Urlichs (2024-12-15 06:33:35)
> On 12.12.24 12:48, Holger Levsen wrote:
> > On Thu, Dec 12, 2024 at 08:57:57AM +0100, Matthias Urlichs wrote:
> >> On 04.12.24 18:08, Andreas Tille wrote:
> >>> in the
> >>> absence of a debian/dont_touch_my_package file, any Debian Dev
On 12.12.24 12:48, Holger Levsen wrote:
On Thu, Dec 12, 2024 at 08:57:57AM +0100, Matthias Urlichs wrote:
On 04.12.24 18:08, Andreas Tille wrote:
in the
absence of a debian/dont_touch_my_package file, any Debian Developer is
permitted to upload the package.
I like this idea.
so you like reali
On Thu, Dec 12, 2024 at 08:57:57AM +0100, Matthias Urlichs wrote:
> On 04.12.24 18:08, Andreas Tille wrote:
> > in the
> > absence of a debian/dont_touch_my_package file, any Debian Developer is
> > permitted to upload the package.
> I like this idea.
so you like reality. good.
--
cheers,
On 04/12/24 18:08, Andreas Tille wrote:
We could introduce this change starting with Debian Policy version X.
Maintainers who adopt this policy version by updating the
Standards-Version in their packages would implicitly agree that, in the
absence of a debian/dont_touch_my_package file, any Debia
On Thu, Dec 12, 2024 at 09:36:01AM +0100, Jonas Smedegaard wrote:
> > > in the
> > > absence of a debian/dont_touch_my_package file, any Debian Developer is
> > > permitted to upload the package.
> >
> > I like this idea.
> >
> > The next step: agree on a "standard" Debian workflow and allow
> >
Quoting Matthias Urlichs (2024-12-12 08:57:57)
> On 04.12.24 18:08, Andreas Tille wrote:
> > in the
> > absence of a debian/dont_touch_my_package file, any Debian Developer is
> > permitted to upload the package.
>
> I like this idea.
>
> The next step: agree on a "standard" Debian workflow and a
On 04.12.24 18:08, Andreas Tille wrote:
in the
absence of a debian/dont_touch_my_package file, any Debian Developer is
permitted to upload the package.
I like this idea.
The next step: agree on a "standard" Debian workflow and allow
(encourage?) people to convert existing packages to it (assu
On Wed, Dec 04, 2024 at 06:08:00PM +0100, Andreas Tille wrote:
> I wonder if we should reconsider the default assumption of package
> ownership. Instead, we could introduce a file, such as
> debian/dont_touch_my_package (or a similarly named file), where
> maintainers can document their reasons for
Andreas Tille writes:
> I wonder if we should reconsider the default assumption of package
> ownership.
(This is a reas objective, but) i wasnt sure how the following text would
achieve the above)
> Instead, we could introduce a file, such as
> debian/dont_touch_my_package (or a similarly named
Am Tue, Dec 03, 2024 at 01:49:33PM +0500 schrieb Andrey Rakhmatullin:
> raise certain
> barriers between the package and other people.
The current barrier appears to be the ITS procedure[1], which I now
engage with nearly daily through the "Bug of the Day"[2] workflow.
Previously, the requirement
52 matches
Mail list logo
