/me just realized he made a stupid mistake by grep'ing Packages instead
of Sources.
Approximate data based on grep'ing Sources:
- 452 teams maintaining packages in unstable
- 3 is the median number of packages maintained by a team
- 155 teams maintaining a single package
On Mon, Aug 07, 2017 at
On Sat, Aug 05, 2017 at 04:29:34PM -0700, Russ Allbery wrote:
>...
> since teams are less likely to only have a single leaf package.
Approximate data based on grep'ing Packages[1]:
- 466 teams maintaining packages in unstable
- 8 is the median number of packages maintained by a team
- 73 teams
On Sat, Aug 05, 2017 at 04:22:03PM -0400, gregor herrmann wrote:
> > So, if you want to count votes: I am working in teams (mainly Debian
> > Astro), and I would favour keeping it --
>
> Perfectly fine, thanks for adding your point of view.
>
> (And just to be sure: The proposal is not to
On Sat, Aug 05, 2017 at 06:38:15PM +, Holger Levsen wrote:
> > It is the official place to list co-maintainers.
>
> you keep repeating this but its still broken by design.
>
> > > ;tl;dr: I think we need a better system to manage team membership in
> > > Debian.
> > > (Ab)using the
Ole Streicher writes:
> So, if you want to count votes: I am working in teams (mainly Debian
> Astro), and I would favour keeping it -- exactly for the reasons Adrian
> wrote: In Debian Astro, most packages are practically maintained by
> a single person, who should also
Tobias Frost writes:
> Am Donnerstag, den 03.08.2017, 11:58 -0700 schrieb Russ Allbery:
>> Or track MIA teams, which in a lot of ways is a much easier problem,
>> and seems like a worthwhile problem to solve anyway.
> No, because with a $TEAM you have to expand it to
On Sat, 05 Aug 2017 21:20:37 +0200, Ole Streicher wrote:
> > So far I've seen mostly voices from people working in teams in this
> > thread who are in favour of dropping the required Uploaders field.
> So, if you want to count votes: I am working in teams (mainly Debian
> Astro), and I would
gregor herrmann writes:
> On Sat, 05 Aug 2017 21:39:40 +0300, Adrian Bunk wrote:
>
>> Regarding the first point, most large teams do have have the concept of
>> package ownership inside the team.
>
> Maybe, maybe not.
> So far I've seen mostly voices from people working in
On Sat, 05 Aug 2017 21:39:40 +0300, Adrian Bunk wrote:
> Regarding the first point, most large teams do have have the concept of
> package ownership inside the team.
Maybe, maybe not.
So far I've seen mostly voices from people working in teams in this
thread who are in favour of dropping the
One thing that is worth discussing here:
For how many teams would it bring real benefits if they no longer
have to maintain team membership information in every source packages?
My guesstimate is that these might perhaps be 5 teams.
Why is my guestimate so low?
It only brings real benefits
On Sat, Aug 05, 2017 at 09:05:46PM +0300, Adrian Bunk wrote:
> > I think using the uploaders: field to guess who's a team member is just a
> > work-around / an estimate, as we have nothing better.
> It is the official place to list co-maintainers.
you keep repeating this but its still broken by
On Sat, Aug 05, 2017 at 03:28:57PM +, Holger Levsen wrote:
> On Sat, Aug 05, 2017 at 10:39:02AM +0300, Adrian Bunk wrote:
> > > I don't understand this suggestion. If it can be automatically
> > > generated, just generate it when you need it -- why store it in the
> > > source package?
> >
>
On Sat, Aug 05, 2017 at 10:39:02AM +0300, Adrian Bunk wrote:
> > I don't understand this suggestion. If it can be automatically
> > generated, just generate it when you need it -- why store it in the
> > source package?
>
> What cannot be automatically generated is the other side of the
>
On Fri, Aug 04, 2017 at 06:20:31PM -0700, Sean Whitton wrote:
> Hello,
>
> On Fri, Aug 04 2017, Adrian Bunk wrote:
>
> > Autogenerating Uploaders like GNOME does [1] would be an alternative
> > approach.
> >
> > [1]
> > https://sources.debian.net/src/gnome-pkg-tools/0.19.9/1/rules/uploaders.mk/
Hello,
On Fri, Aug 04 2017, Adrian Bunk wrote:
> Autogenerating Uploaders like GNOME does [1] would be an alternative
> approach.
>
> [1]
> https://sources.debian.net/src/gnome-pkg-tools/0.19.9/1/rules/uploaders.mk/
I don't understand this suggestion. If it can be automatically
generated, just
Hi,
On Fri, Aug 04, 2017 at 01:58:15AM +0300, Adrian Bunk wrote:
> Finding unmaintained packages is the hard part.
True.
> In a bigger team maintaining 500 packages it is a non-trivial amount of
> extra work searching for packages no-one inside the team is actively
> taking care of.
My way
Hi,
On Thu, Aug 03, 2017 at 11:09:06PM +, Clint Adams wrote:
>
> I agree. This information is useless, and even if it's not, the source
> package is entirely the wrong place for it. Let's get rid of the
> Uploaders field entirely.
I fail to see what problem is solved by droping the
Hi Holger,
On Fri, Aug 04, 2017 at 02:33:03PM +, Holger Levsen wrote:
> > Your definition is completely detached from the reality in Debian.
> >
> > Many (likely the majority) of teams in Debian have not more
> > than 1 active member.
>
> citation needed.
>
> I seriously doubt this is
On Fri, Aug 04, 2017 at 12:37:53PM +0300, Adrian Bunk wrote:
>
> As an example, we do have teams that define in their policy the
> semantics for "person in Maintainer, team in Uploaders".
That should be changed. Its a perfect way to exclude "Uploaders" from
beeing informed about issues with a
Hi,
On Thu, Aug 03, 2017 at 06:48:27PM -0700, Russ Allbery wrote:
> Adrian Bunk writes:
> > Your definition is completely detached from the reality in Debian.
>
> > Many (likely the majority) of teams in Debian have not more than 1
> > active member.
>From my teamstatistics
On Fri, Aug 04, 2017 at 04:19:21AM +0300, Adrian Bunk wrote:
> Your definition is completely detached from the reality in Debian.
>
> Many (likely the majority) of teams in Debian have not more
> than 1 active member.
citation needed.
I seriously doubt this is true. There are some of these
On Thu, Aug 03, 2017 at 06:48:27PM -0700, Russ Allbery wrote:
>...
> One approach as Holger points out: look for
> packages where all the recent uploads have been by the MIA member, which
> doesn't require the Uploaders field at all.
As I already tried to explain, this is an easy part that could
Adrian Bunk writes:
> On Thu, Aug 03, 2017 at 05:41:00PM -0700, Russ Allbery wrote:
>> Adrian Bunk writes:
>>> Regressing on being able to orphan all packages of a known-MIA/retired
>>> maintainer would be very bad.
>> I agree, but that's not directly relevant
On Thu, Aug 03, 2017 at 05:41:00PM -0700, Russ Allbery wrote:
> Adrian Bunk writes:
>
> > Regressing on being able to orphan all packages of a known-MIA/retired
> > maintainer would be very bad.
>
> I agree, but that's not directly relevant here, since we're talking about
>
On Thu, Aug 03, 2017 at 08:16:30PM -0400, gregor herrmann wrote:
> On Fri, 04 Aug 2017 02:16:03 +0300, Adrian Bunk wrote:
>
> > On Thu, Aug 03, 2017 at 06:25:46PM -0400, gregor herrmann wrote:
> > > What I don't understand in the point of view of the "keep Uploaders"
> > > proponents: What does
On Thu, Aug 03, 2017 at 12:11:07PM -0700, Russ Allbery wrote:
> Tobias Frost writes:
>
> > Some time ago I did some spring cleaning going over DDs that have
> > retired but still in the Maintainer/Uploader fields: There were quite a
> > lot "team maintained" packages where the
Adrian Bunk writes:
> Regressing on being able to orphan all packages of a known-MIA/retired
> maintainer would be very bad.
I agree, but that's not directly relevant here, since we're talking about
team-maintained packages. The whole *point* of team maintenance is that
On Fri, 04 Aug 2017 02:16:03 +0300, Adrian Bunk wrote:
> On Thu, Aug 03, 2017 at 06:25:46PM -0400, gregor herrmann wrote:
> > What I don't understand in the point of view of the "keep Uploaders"
> > proponents: What does this information, whether correct or not,
> > actually give others? Are they
On Thu, Aug 03, 2017 at 06:25:46PM -0400, gregor herrmann wrote:
>...
> What I don't understand in the point of view of the "keep Uploaders"
> proponents: What does this information, whether correct or not,
> actually give others? Are they going to email or phone these persons
> privately when
Clint Adams writes:
> On Thu, Aug 03, 2017 at 06:25:46PM -0400, gregor herrmann wrote:
>> What I don't understand in the point of view of the "keep Uploaders"
>> proponents: What does this information, whether correct or not,
>> actually give others? Are they going to email or
On Thu, Aug 03, 2017 at 12:36:04PM -0400, Sean Whitton wrote:
> On Thu, Aug 03, 2017 at 12:06:16PM +0300, Adrian Bunk wrote:
> > Please be more thoughtful about the consequences of such changes to policy.
> >
> > This would not be "a purely informative change".
> >
> > Your suggested wording has
On Thu, Aug 03, 2017 at 06:25:46PM -0400, gregor herrmann wrote:
> What I don't understand in the point of view of the "keep Uploaders"
> proponents: What does this information, whether correct or not,
> actually give others? Are they going to email or phone these persons
> privately when emails
On Thu, Aug 03, 2017 at 06:04:17PM -0400, gregor herrmann wrote:
> On Thu, 03 Aug 2017 12:11:07 -0700, Russ Allbery wrote:
> […]
> Thanks for putting my thoughts (again!) into better words than I ever
> could!
+1
> > (I am entirely in favor of giving the MIA team more actual power.)
> (Me too.
On Thu, 03 Aug 2017 21:25:32 +0200, Christian Seiler wrote:
Thanks for your long and elaborate email.
Unfortunately I find myself disagreeing with your two main points:
> I wonder whether we are framing this in the right way anyway. There
> are two orthogonal questions in my mind:
> - is a
On Thu, 03 Aug 2017 12:11:07 -0700, Russ Allbery wrote:
> Tobias Frost writes:
> > Some time ago I did some spring cleaning going over DDs that have
> > retired but still in the Maintainer/Uploader fields: There were quite a
> > lot "team maintained" packages where the team did
On 08/03/2017 08:58 PM, Russ Allbery wrote:
> Jonas Smedegaard writes:
>
>> Do the MIA team also track MIA teams?
>
>> My concern is that packages without maintainers may go unnoticed when
>> none of its previously active maintainers were tracked individually.
>
>> For such
Tobias Frost writes:
> Some time ago I did some spring cleaning going over DDs that have
> retired but still in the Maintainer/Uploader fields: There were quite a
> lot "team maintained" packages where the team did not recognize that the
> (sole) Uploader wasn't there anymore
Jonas Smedegaard writes:
> Do the MIA team also track MIA teams?
> My concern is that packages without maintainers may go unnoticed when
> none of its previously active maintainers were tracked individually.
> For such detection of abandonment we need not track _all_ active
>
Quoting Russ Allbery (2017-08-03 11:41:12)
> Bill Allombert writes:
>
> > The patch also remove the requirement to list individual email of the
> > maintainers. That is what I am objecting to.
>
> Oh, okay, I see that, but I'm not sure why. What is the purpose of
> listing
Am Donnerstag, den 03.08.2017, 12:44 -0400 schrieb Sean Whitton:
> Hello Tobias,
>
> Thank you for writing about this bug from the MIA team's perspective,
> which is very relevant to resolving this.
>
> On Thu, Aug 03, 2017 at 08:44:36AM +0200, Tobias Frost wrote:
> > Some remarks / questions I
Hello Tobias,
Thank you for writing about this bug from the MIA team's perspective,
which is very relevant to resolving this.
On Thu, Aug 03, 2017 at 08:44:36AM +0200, Tobias Frost wrote:
> Some remarks / questions I do not see adressed:
> - If you have not a name on some task human nature tends
On Thu, Aug 03, 2017 at 12:06:16PM +0300, Adrian Bunk wrote:
> Please be more thoughtful about the consequences of such changes to policy.
>
> This would not be "a purely informative change".
>
> Your suggested wording has the potential to create a HUGE amount of tensions.
You're right. After
Bill Allombert writes:
> The patch also remove the requirement to list individual email of the
> maintainers. That is what I am objecting to.
Oh, okay, I see that, but I'm not sure why. What is the purpose of
listing those email addresses that you want to preserve?
> When
On Thu, Aug 03, 2017 at 12:30:11PM +0300, Adrian Bunk wrote:
> On Thu, Aug 03, 2017 at 11:01:24AM +0200, Bill Allombert wrote:
> > On Wed, Aug 02, 2017 at 04:22:41PM -0700, Russ Allbery wrote:
> > > Bill Allombert writes:
> > > > On Wed, Aug 02, 2017 at 05:48:15PM -0400, Sean
On Thu, Aug 03, 2017 at 11:01:24AM +0200, Bill Allombert wrote:
> On Wed, Aug 02, 2017 at 04:22:41PM -0700, Russ Allbery wrote:
> > Bill Allombert writes:
> > > On Wed, Aug 02, 2017 at 05:48:15PM -0400, Sean Whitton wrote:
> >
> > >> I've also included a purely informative
On Wed, Aug 02, 2017 at 05:48:15PM -0400, Sean Whitton wrote:
>...
> I've also included a purely informative change which emphasises that
> packages that are team maintained in name only should be orphaned
> properly, with their maintainer field set to the QA team. This is
> already current best
On Wed, Aug 02, 2017 at 04:22:41PM -0700, Russ Allbery wrote:
> Bill Allombert writes:
> > On Wed, Aug 02, 2017 at 05:48:15PM -0400, Sean Whitton wrote:
>
> >> I've also included a purely informative change which emphasises that
> >> packages that are team maintained in name
Am 2. August 2017 23:48:15 MESZ schrieb Sean Whitton :
>Hello,
>
>Here is an updated diff for this bug, against the docbook version of
>the policy manual.
>
>I've also included a purely informative change which emphasises that
>packages that are team maintained in name
Bill Allombert writes:
> On Wed, Aug 02, 2017 at 05:48:15PM -0400, Sean Whitton wrote:
>> I've also included a purely informative change which emphasises that
>> packages that are team maintained in name only should be orphaned
>> properly, with their maintainer field set to
On Wed, Aug 02, 2017 at 05:48:15PM -0400, Sean Whitton wrote:
> Hello,
>
> Here is an updated diff for this bug, against the docbook version of
> the policy manual.
>
> I've also included a purely informative change which emphasises that
> packages that are team maintained in name only should be
50 matches
Mail list logo