Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #116184 > unrolled thread

Re: Bits from DPL

Back to article view | Back to linux.debian.devel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Bits from DPL Nilesh Patra <nilesh@iki.fi> - 2025-03-05 19:30 +0100
    Growing new FTP-masters (Re: Bits from DPL) Otto Kekäläinen <otto@debian.org> - 2025-03-05 20:00 +0100
      Re: Growing new FTP-masters (Re: Bits from DPL) Matthias Urlichs <matthias@urlichs.de> - 2025-03-06 09:10 +0100
        Re: Growing new FTP-masters (Re: Bits from DPL) Sean Whitton <spwhitton@spwhitton.name> - 2025-03-06 11:00 +0100
          Re: Growing new FTP-masters (Re: Bits from DPL) Matthias Urlichs <matthias@urlichs.de> - 2025-03-06 14:10 +0100
            Re: Growing new FTP-masters (Re: Bits from DPL) Sean Whitton <spwhitton@spwhitton.name> - 2025-03-09 05:40 +0100
              Re: Growing new FTP-masters (Re: Bits from DPL) Simon Josefsson <simon@josefsson.org> - 2025-03-09 12:20 +0100
                Re: Growing new FTP-masters (Re: Bits from DPL) Simon Josefsson <simon@josefsson.org> - 2025-03-09 12:40 +0100
                  Re: Growing new FTP-masters (Re: Bits from DPL) Sean Whitton <spwhitton@spwhitton.name> - 2025-03-09 12:50 +0100
                Re: Growing new FTP-masters (Re: Bits from DPL) Sean Whitton <spwhitton@spwhitton.name> - 2025-03-09 12:40 +0100
                  Re: Growing new FTP-masters (Re: Bits from DPL) "G. Branden Robinson" <g.branden.robinson@gmail.com> - 2025-03-09 12:50 +0100
                  Re: Growing new FTP-masters (Re: Bits from DPL) Simon McVittie <smcv@debian.org> - 2025-03-09 15:00 +0100
                    Re: Growing new FTP-masters (Re: Bits from DPL) Sean Whitton <spwhitton@spwhitton.name> - 2025-03-19 00:30 +0100
            Re: NEW review & revision process (or lack thereof) (Re: Growing  new FTP-masters (Re: Bits from DPL)) Simon Josefsson <simon@josefsson.org> - 2025-03-10 11:10 +0100
            Re: NEW review & revision process (or lack thereof) (Re: Growing  new FTP-masters (Re: Bits from DPL)) Philip Hands <phil@hands.com> - 2025-03-10 11:50 +0100
            Re: NEW review & revision process (or lack thereof) (Re: Growing  new FTP-masters (Re: Bits from DPL)) "Jonathan Dowland" <jmtd@debian.org> - 2025-03-10 13:00 +0100
          Re: Growing new FTP-masters (Re: Bits from DPL) Otto Kekäläinen <otto@debian.org> - 2025-03-06 20:20 +0100
    Re: Bits from DPL Sean Whitton <spwhitton@spwhitton.name> - 2025-03-06 02:10 +0100
      Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL) Charles Plessy <plessy@debian.org> - 2025-03-06 05:30 +0100
        Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL) Sean Whitton <spwhitton@spwhitton.name> - 2025-03-06 10:50 +0100
          Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL) Julien Plissonneau Duquène <sre4ever@free.fr> - 2025-03-06 11:00 +0100
          Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL) Charles Plessy <plessy@debian.org> - 2025-03-07 02:00 +0100
            Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL) Simon Josefsson <simon@josefsson.org> - 2025-03-07 18:30 +0100
              Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL) Charles Plessy <plessy@debian.org> - 2025-03-08 02:10 +0100
                Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL) Simon Josefsson <simon@josefsson.org> - 2025-03-08 09:50 +0100
                Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL) Sean Whitton <spwhitton@spwhitton.name> - 2025-03-09 06:30 +0100
                  Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL) Philip Hands <phil@hands.com> - 2025-03-10 11:40 +0100
            Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL) Maytham Alsudany <maytham@debian.org> - 2025-03-09 11:10 +0100
              Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL) Charles Plessy <plessy@debian.org> - 2025-03-11 10:00 +0100
                Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL) Simon Josefsson <simon@josefsson.org> - 2025-03-11 16:40 +0100
                  Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL) Charles Plessy <plessy@debian.org> - 2025-03-12 02:00 +0100
                    Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL) Maytham Alsudany <maytham@debian.org> - 2025-03-12 04:10 +0100
                      Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL) Simon Josefsson <simon@josefsson.org> - 2025-03-12 09:50 +0100
                        Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL) Charles Plessy <plessy@debian.org> - 2025-03-13 10:10 +0100
        Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL) Simon Josefsson <simon@josefsson.org> - 2025-03-06 13:30 +0100
        Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL) Otto Kekäläinen <otto@debian.org> - 2025-03-06 20:10 +0100
          Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL) Pirate Praveen <praveen@onenetbeyond.org> - 2025-03-07 09:00 +0100
            Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL) Simon McVittie <smcv@debian.org> - 2025-03-07 11:20 +0100
              Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL) Otto Kekäläinen <otto@debian.org> - 2025-03-07 16:00 +0100
              Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL) Sean Whitton <spwhitton@spwhitton.name> - 2025-03-09 06:20 +0100
      Re: Bits from DPL Marc Haber <mh+debian-devel@zugschlus.de> - 2025-03-06 09:10 +0100
        STFU please (Re: Bits from DPL) Holger Levsen <holger@layer-acht.org> - 2025-03-06 09:40 +0100
          Re: STFU please (Re: Bits from DPL) Marc Haber <mh+debian-devel@zugschlus.de> - 2025-03-06 10:00 +0100
            Re: STFU please (Re: Bits from DPL) Matthias Urlichs <matthias@urlichs.de> - 2025-03-06 10:10 +0100
            Re: STFU please (Re: Bits from DPL) Soren Stoutner <soren@debian.org> - 2025-03-08 00:30 +0100
          Re: STFU please (Re: Bits from DPL) Holger Levsen <holger@layer-acht.org> - 2025-03-06 11:10 +0100
        Re: Bits from DPL Matthias Urlichs <matthias@urlichs.de> - 2025-03-06 10:10 +0100
      Re: Bits from DPL Pierre-Elliott Bécue <peb@debian.org> - 2025-03-10 12:00 +0100

Page 1 of 3  [1] 2 3  Next page →

#116184 — Re: Bits from DPL

On 05/03/25 4:47 pm, Sean Whitton wrote:
> On Tue 04 Mar 2025 at 09:40am +01, Andreas Tille wrote:
> 
>> Dear Debian community,
>>
>> this is bits from DPL for February.
>>
>>
>> Ftpmaster team is seeking for new team members
>> ==============================================
> 
> No, we are not.
> 
> Andreas asked us whether we would like a call for volunteers included in
> Bits.  Multiple team members explicitly told him that we now would not
> be a good time for that, for us.

Do you mind clarifying why that's the case, unless the reason is truly personal or undisclosable?

[toc] | [next] | [standalone]

#116186 — Growing new FTP-masters (Re: Bits from DPL)

Hi,

On Wed, 5 Mar 2025 at 10:24, Nilesh Patra wrote:
> On 05/03/25 4:47 pm, Sean Whitton wrote:
> > On Tue 04 Mar 2025 at 09:40am +01, Andreas Tille wrote:
> >
> >> Dear Debian community,
> >>
> >> this is bits from DPL for February.
> >>
> >>
> >> Ftpmaster team is seeking for new team members
> >> ==============================================
> >
> > No, we are not.
> >
> > Andreas asked us whether we would like a call for volunteers included in
> > Bits.  Multiple team members explicitly told him that we now would not
> > be a good time for that, for us.
>
> Do you mind clarifying why that's the case, unless the reason is truly personal or undisclosable?

+1

According to https://ftp-master.debian.org/ there are currently no
'FTP Trainees'. I would assume you would like to have some at all time
to ensure the team has a healthy pipeline of new members being
trained?

Looking at the stats for NEW queue length in
https://ftp-master.debian.org/stat/new-5years.png it seems to have
been the highest ever in November 2024 to January 2025, and the
numbers didn't come down until heroic efforts by mainly one person
(Thorsten).

Many of the aspiring Debian Developers I mentor have been stuck with
their work pending in the NEW queue for months. For example an upload
of src:godot to change source package name to src:godot3 with almost
no other changes has been pending almost two months, and the new
contributor Travis Wrightsman has been mostly idle with his Debian
work just waiting for the package to pass in order to proceed with new
Godot version.

With this experience I am surprised that one FTP-team member is saying
that no help is needed? I wonder if that really is the opinion of
others in the team too?

- Otto

[toc] | [prev] | [next] | [standalone]

#116207 — Re: Growing new FTP-masters (Re: Bits from DPL)

[Multipart message — attachments visible in raw view] — view raw

On 05.03.25 19:51, Otto Kekäläinen wrote:
> With this experience I am surprised that one FTP-team member is saying
> that no help is needed?

Apparently the problem isn't that no help is needed but that nobody has 
time to train the new help, citing possible burn-out trying to get 
answers from the existing members and leaving in disappointment, if not 
disgust. (My interpretation …)

While that's a valid concern, it's a problem every manager of an 
overworked team in the world has faced, volunteer or not.

There are (of course) multiple ways to approach this issue. The point 
(and I assume the reason Andreas basically ignored the team's rejection 
of new members) is that "do nothing until somebody has time to train new 
people" is among the worst possible approaches: experience tells us that 
the most likely outcome is "another team members quits".

-- 
-- regards
-- 
-- Matthias Urlichs

[toc] | [prev] | [next] | [standalone]

#116218 — Re: Growing new FTP-masters (Re: Bits from DPL)

[Multipart message — attachments visible in raw view] — view raw

Hello,

On Thu 06 Mar 2025 at 08:41am +01, Matthias Urlichs wrote:

> Apparently the problem isn't that no help is needed but that nobody has time
> to train the new help, citing possible burn-out trying to get answers from the
> existing members and leaving in disappointment, if not disgust. (My
> interpretation …)
>
> While that's a valid concern, it's a problem every manager of an overworked
> team in the world has faced, volunteer or not.
>
> There are (of course) multiple ways to approach this issue. The point (and I
> assume the reason Andreas basically ignored the team's rejection of new
> members) is that "do nothing until somebody has time to train new people" is
> among the worst possible approaches: experience tells us that the most likely
> outcome is "another team members quits".

You can't just throw people at a team of volunteers who are busy doing
other things and say "train them".  Nobody wins, there, and the
candidates won't come back at a time when those volunteers *do* have the
time to do the training.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#116225 — Re: Growing new FTP-masters (Re: Bits from DPL)

[Multipart message — attachments visible in raw view] — view raw

On 06.03.25 10:51, Sean Whitton wrote:
> You can't just throw people at a team of volunteers who are busy doing
> other things and say "train them".

That's true in general. However.

* this episode demonstrates that there are obviously a few crossed wires 
between ftpmaster and DPL; I think it's fair to assume that this is not 
a recent development. Andreas' ignoring your NACK may not have been 
particularly nice (he can apologize himself :-P ) but at least it threw 
the problem into the spotlight.

* there seem to be some reasonable(IMHO) ideas out there to reduce 
and/or spread the workload of NEW processing. These obviously need some 
fleshed-out proposal, discussion, and people who then implement the 
result. This requires volunteers , but not necessarily any up-front 
training.

* I have learned (thanks @roehling) that the *actual* median time 
packages spend in NEW is less than two days. In other words, *somebody* 
must have *some* time available.

* Speaking from personal experience: Fighting an ongoing uphill battle 
is much less rewarding than bulldozing some of that hill away. The 
effect on actual time available for the task in question should be obvious.

My personal suggestion would be to work with one or two volunteers to 
write a somewhat-comprehensive how-to-ftpmaster-the-NEW-queue manual, so 
that the *next* time you have a bottleneck you can throw that document 
at the volunteer and say "here's ten example packages, find their 
problems if any, then come back".

Finally, a question -- as you don't seem to document the issues you have 
with long term packages in their ITP bug, where *do* you document them?

-- 
-- regards
-- 
-- Matthias Urlichs

[toc] | [prev] | [next] | [standalone]

#116309 — Re: Growing new FTP-masters (Re: Bits from DPL)

[Multipart message — attachments visible in raw view] — view raw

Hello,

On Thu 06 Mar 2025 at 01:54pm +01, Matthias Urlichs wrote:

> * I have learned (thanks @roehling) that the *actual* median time packages
>   spend in NEW is less than two days. In other words, *somebody* must have
>  *some* time available.

It is almost entirely Thorsten.

> My personal suggestion would be to work with one or two volunteers to write a
> somewhat-comprehensive how-to-ftpmaster-the-NEW-queue manual, so that the
> *next* time you have a bottleneck you can throw that document at the volunteer
> and say "here's ten example packages, find their problems if any, then come
> back".

The docs are public: https://salsa.debian.org/ftp-team/manpages

> Finally, a question -- as you don't seem to document the issues you have with
> long term packages in their ITP bug, where *do* you document them?

There is a notes system in the 'dak process-new' command.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#116321 — Re: Growing new FTP-masters (Re: Bits from DPL)

[Multipart message — attachments visible in raw view] — view raw

Sean Whitton <spwhitton@spwhitton.name> writes:

>> My personal suggestion would be to work with one or two volunteers to write a
>> somewhat-comprehensive how-to-ftpmaster-the-NEW-queue manual, so that the
>> *next* time you have a bottleneck you can throw that document at the volunteer
>> and say "here's ten example packages, find their problems if any, then come
>> back".
>
> The docs are public: https://salsa.debian.org/ftp-team/manpages

Those are helpful even for me as uploading packages to NEW!  I wish I
had read them before.

Is there any policy to forbid or accept uploading two packages A and B
at the same time to NEW where package A depends on package B?

I am guessing based on earlier e-mail interactions that this causes
problems for your review workflow, so I've stopped doing simultaneous
uploads and instead upload package B first and then wait for ACCEPT and
then upload package A etc.

That policy lead to a slow migration path, since for many Go packages
the dependency chain of NEW packages can be quite deep.  If I recall
correctly, I had this dependency situation earlier:

  sigstore
    -> sigstore-go
      -> cosign
        -> gittuf
          -> gitsign

It would be nice to clarify in those documents if indeed there is a
policy on this.  It seems surprising to me, since it would make it
impossible to get a set of NEW packages which have cyclic dependencies
into Debian.

Of course, a more gray situation like "we don't want to forbid it but it
causes us more work so please don't do it" is perfectly fine too.
Writing that down helps people do the right thing.  The question has
come up two times for me when sponsoring new Go package uploads.

/Simon

[toc] | [prev] | [next] | [standalone]

#116324 — Re: Growing new FTP-masters (Re: Bits from DPL)

[Multipart message — attachments visible in raw view] — view raw

Sean Whitton <spwhitton@spwhitton.name> writes:

> Hello,
>
> On Sun 09 Mar 2025 at 12:17pm +01, Simon Josefsson wrote:
>
>> Sean Whitton <spwhitton@spwhitton.name> writes:
>>
>>> The docs are public: https://salsa.debian.org/ftp-team/manpages
>>
>> Those are helpful even for me as uploading packages to NEW!  I wish I
>> had read them before.
>
> Mmm.  They sat private access only for ten years, but when I joined the
> FTP team I worked to get them published.
>
>> Is there any policy to forbid or accept uploading two packages A and B
>> at the same time to NEW where package A depends on package B?
>
> No such policy.  'dak inspect-upload' is meant to highlight unmet deps
> in red so that we don't ACCEPT them in the wrong order, but we often
> miss it.
>
> IMO it is the maintainer's responsibility to ensure that NEW+unstable
> together is always all installable, if you see what I mean.

Thank you for clarifying, and for getting those documents published.

What should I do if NEW+unstable becomes uninstallable during the NEW
review period?

Do you want maintainers to re-upload a newly built binary?  I've never
done that, but doing so would make sense if you really want maintainers
to ensure that NEW+unstable is installable.

A binary Go package can have 500+ build dependencies transitively, and
the chance of all of those packages staying at the same version in
unstable during NEW review period is pretty slim.  I guess that you
already work around this, because I have only very rarely gotten REJECTS
because of this reason (guessing max 3 times), and I know the situation
must have occured for several packages that I did get ACCEPT on.

/Simon

[toc] | [prev] | [next] | [standalone]

#116327 — Re: Growing new FTP-masters (Re: Bits from DPL)

[Multipart message — attachments visible in raw view] — view raw

Hello,

On Sun 09 Mar 2025 at 12:38pm +01, Simon Josefsson wrote:

> What should I do if NEW+unstable becomes uninstallable during the NEW
> review period?
>
> Do you want maintainers to re-upload a newly built binary?  I've never
> done that, but doing so would make sense if you really want maintainers
> to ensure that NEW+unstable is installable.
>
> A binary Go package can have 500+ build dependencies transitively, and
> the chance of all of those packages staying at the same version in
> unstable during NEW review period is pretty slim.  I guess that you
> already work around this, because I have only very rarely gotten REJECTS
> because of this reason (guessing max 3 times), and I know the situation
> must have occured for several packages that I did get ACCEPT on.

Hmm, your answer makes me think that I didn't understand the question
correctly.

So, a more general answer: we mostly care about individual packages and
rely on maintainers and britney to care about how they interact.
But if we see something which seems obviously like introducing breakage
we'll probably ask you about it, and if you tell us it's fine, we'll
probably go ahead.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#116325 — Re: Growing new FTP-masters (Re: Bits from DPL)

[Multipart message — attachments visible in raw view] — view raw

Hello,

On Sun 09 Mar 2025 at 12:17pm +01, Simon Josefsson wrote:

> Sean Whitton <spwhitton@spwhitton.name> writes:
>
>> The docs are public: https://salsa.debian.org/ftp-team/manpages
>
> Those are helpful even for me as uploading packages to NEW!  I wish I
> had read them before.

Mmm.  They sat private access only for ten years, but when I joined the
FTP team I worked to get them published.

> Is there any policy to forbid or accept uploading two packages A and B
> at the same time to NEW where package A depends on package B?

No such policy.  'dak inspect-upload' is meant to highlight unmet deps
in red so that we don't ACCEPT them in the wrong order, but we often
miss it.

IMO it is the maintainer's responsibility to ensure that NEW+unstable
together is always all installable, if you see what I mean.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#116326 — Re: Growing new FTP-masters (Re: Bits from DPL)

[Multipart message — attachments visible in raw view] — view raw

At 2025-03-09T19:32:32+0800, Sean Whitton wrote:
> On Sun 09 Mar 2025 at 12:17pm +01, Simon Josefsson wrote:
> > Sean Whitton <spwhitton@spwhitton.name> writes:
> >> The docs are public: https://salsa.debian.org/ftp-team/manpages
> > Those are helpful even for me as uploading packages to NEW!  I wish
> > I had read them before.
> 
> Mmm.  They sat private access only for ten years,

Why?

> but when I joined the FTP team I worked to get them published.

Thank you!

Regards,
Branden

[toc] | [prev] | [next] | [standalone]

#116330 — Re: Growing new FTP-masters (Re: Bits from DPL)

On Sun, 09 Mar 2025 at 19:32:32 +0800, Sean Whitton wrote:
>IMO it is the maintainer's responsibility to ensure that NEW+unstable 
>together is always all installable, if you see what I mean.

Do I assume correctly that this principle can be weakened for 
experimental-NEW?

As a general principle I think uploads to NEW that are more complicated 
than a completely new leaf package should usually be to experimental, 
unless there is a reason why this specific package can't (for example if 
foo_2.0 is already in experimental and now the maintainer needs a 
package-split or a new SONAME for foo_1.2 in unstable). A lot of the 
time the NEW package will need a new sourceful upload after it's been 
accepted *anyway*, to get a source-only upload that can migrate to 
testing - and if the package is in binary-NEW because it has a new 
SONAME, it's better to have the maintainer and not the ftp team be in 
control of the point at which it hits unstable and starts a transition.

Does the ftp team agree with that as a general idea? And if a largeish 
dependency graph needs uploading together, is it OK to upload them all 
to experimental-NEW, with the idea that if the ftp team accepts them in 
the wrong order they'll just sit in BD-Uninstallable status until the 
whole batch has been processed, with no real harm done?

     smcv

[toc] | [prev] | [next] | [standalone]

#116529 — Re: Growing new FTP-masters (Re: Bits from DPL)

Hello,

On Sun 09 Mar 2025 at 01:57pm GMT, Simon McVittie wrote:

> Do I assume correctly that this principle can be weakened for
> experimental-NEW?
>
> As a general principle I think uploads to NEW that are more complicated than a
> completely new leaf package should usually be to experimental, unless there is
> a reason why this specific package can't (for example if foo_2.0 is already in
> experimental and now the maintainer needs a package-split or a new SONAME for
> foo_1.2 in unstable). A lot of the time the NEW package will need a new
> sourceful upload after it's been accepted *anyway*, to get a source-only
> upload that can migrate to testing - and if the package is in binary-NEW
> because it has a new SONAME, it's better to have the maintainer and not the
> ftp team be in control of the point at which it hits unstable and starts a
> transition.
>
> Does the ftp team agree with that as a general idea? And if a largeish
> dependency graph needs uploading together, is it OK to upload them all to
> experimental-NEW, with the idea that if the ftp team accepts them in the wrong
> order they'll just sit in BD-Uninstallable status until the whole batch has
> been processed, with no real harm done?

Yes, I think that is fine.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#116358 — Re: NEW review & revision process (or lack thereof) (Re: Growing new FTP-masters (Re: Bits from DPL))

[Multipart message — attachments visible in raw view] — view raw

Luke Faraone <lfaraone@debian.org> writes:

> The rationale given when I joined as ftpassistant (c. 2012) for not
> publicising decisions e.g. in the ITP was to avoid publishing
> potentially harshly-worded and embarassing reviews to maintainers in
> public (like pointing out that you missed a fairly obvious license
> declaration, incompatibility, or packaging step).
>
> I am welcome to feedback from the project as to whether this outweighs
> the benefit to having past decisions available for public
> consultation.

If that is really the only rationale, I think the reviews ought to be
public.  As an offender of fairly obvious and embarrasing license
mistakes, and other NEW packaging problems, I believe the only
sustainable way to improve is to have more eyes looking at things and
contributing and doing things in public allows people to learn how the
process works, and participate.

Charles Plessy's effort to have a pre-NEW review team to do such work
seems like a good start (although I never figured out how I would submit
a package to that effort).

I can see the need for doing private reviews with private feedback
though.  Maybe what is needed is not so much to change ftp-master's
private review process but to have this public pre-review process to
smoothen the process a bit.

/Simon

[toc] | [prev] | [next] | [standalone]

#116365 — Re: NEW review & revision process (or lack thereof) (Re: Growing new FTP-masters (Re: Bits from DPL))

[Multipart message — attachments visible in raw view] — view raw

Luke Faraone <lfaraone@debian.org> writes:

> The rationale given when I joined as ftpassistant (c. 2012) for not 
> publicising decisions e.g. in the ITP was to avoid publishing 
> potentially harshly-worded and embarassing reviews to maintainers in 
> public (like pointing out that you missed a fairly obvious license 
> declaration, incompatibility, or packaging step).
>
> I am welcome to feedback from the project as to whether this outweighs 
> the benefit to having past decisions available for public consultation.

If the price for the ability to learn from the mistakes of others is an
occasional dose of public humiliation, then that's a price I'm happy to
pay (and I speak as someone that has a talent for making trivial errors).

Also, we claim in the Debian Social Contract that we don't hide problems.

How about if the (possibly harsh) reasoning were published in a form
that only directly tied it to the package name, such that search engines
would not instantly and permanently place that comment on one's CV?

I'd imagine that the stigma of a rejection would pretty quickly become
an understanding that everyone makes mistakes occasionally, which may be
a good way of avoiding new contributors becoming intimidated by the
assumption that everyone else is doing a perfect job.

Cheers, Phil.
-- 
Philip Hands -- https://hands.com/~phil

[toc] | [prev] | [next] | [standalone]

#116376 — Re: NEW review & revision process (or lack thereof) (Re: Growing new FTP-masters (Re: Bits from DPL))

I've recently been trying to help rescue a package that is dropped for 
Trixie, partly for technical reasons (source package split means a round 
trip through NEW) and party for license reasons (some uncertainty about 
copyright of some icons, which have been in the archive for decades, but 
since a NEW round-trip is required, this is a reject-worthy bug now)

On Mon Mar 10, 2025 at 7:57 AM GMT, Luke Faraone wrote:
> We discard the source tarballs and changes files on REJECT so there is 
> nothing to `debdiff`. This partially happens for legal reasons: if we 
> determine a package is not suitable for the archive then we may no 
> longer have the legal right to retain it on ftp-master.

That makes sense. In my case, I still don't have access to the source 
package that was rejected, but that could be solved if the (very busy) 
maintainer uploaded it somewhere else (e.g. to Salsa). Since it's never 
been in Debian (technically), there's no historic packages to look at 
(yet).

> The rationale given when I joined as ftpassistant (c. 2012) for not 
> publicising decisions e.g. in the ITP was to avoid publishing 
> potentially harshly-worded and embarassing reviews to maintainers in 
> public (like pointing out that you missed a fairly obvious license 
> declaration, incompatibility, or packaging step).
>
> I am welcome to feedback from the project as to whether this outweighs 
> the benefit to having past decisions available for public consultation.

I had to ask nicely for someone with privileges to send me the ftp team 
reject notes to get some clue as to what needs fixing. So I would 
definitely prefer if they were open by default.


Thanks for your efforts!

-- 
Please do not CC me for listmail.

👱🏻	Jonathan Dowland
✎	 jmtd@debian.org
🔗	https://jmtd.net

[toc] | [prev] | [next] | [standalone]

#116243 — Re: Growing new FTP-masters (Re: Bits from DPL)

Hi,

> > Apparently the problem isn't that no help is needed but that nobody has time
> > to train the new help, citing possible burn-out trying to get answers from the
> > existing members and leaving in disappointment, if not disgust. (My
> > interpretation …)
> >
> > While that's a valid concern, it's a problem every manager of an overworked
> > team in the world has faced, volunteer or not.
> >
> > There are (of course) multiple ways to approach this issue. The point (and I
> > assume the reason Andreas basically ignored the team's rejection of new
> > members) is that "do nothing until somebody has time to train new people" is
> > among the worst possible approaches: experience tells us that the most likely
> > outcome is "another team members quits".
>
> You can't just throw people at a team of volunteers who are busy doing
> other things and say "train them".  Nobody wins, there, and the
> candidates won't come back at a time when those volunteers *do* have the
> time to do the training.

I don't think you are quoting the DPL above correctly. I think he had
good judgement, and raising awareness of FTP Masters team being spread
thin and needing more help in a Bits from DPL announcement is the
correct thing to do.

New people standing up and stating they want to help is a good thing,
even with the risk that some of those people would go away while
waiting.

I did also read the queue processing time reports by Matthias and
Timo. On a quick look I wasn't able to find stats on which FTP Master
team member has done how many reviews, but in my experience it seems
to rely on the heroic efforts of a very few people (thanks Thorsten
for all your work!), and having more people in the team would be of
great benefit for Debian, and rightly something the DPL should help
with.

[toc] | [prev] | [next] | [standalone]

#116199

[Multipart message — attachments visible in raw view] — view raw

Hello,

On Wed 05 Mar 2025 at 11:35pm +0530, Nilesh Patra wrote:

> Do you mind clarifying why that's the case, unless the reason is truly
> personal or undisclosable?

It's pretty simple -- there is no-one with the free time to train them
right now, in which case trainees will simply burn out, because they
won't get enough feedback on their NEW reviews.

We try to recruit only when there is someone who is able to dedicate
some time to training.  That depends on what the other team members are
busy with, in and outside of Debian, at a given time.

This was made very clear to Andreas.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

#116201 — Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL)

Hi Sean and everybody,

Around 12 years ago, I proposed a peer-review system to increase the quality of
the packages in the NEW queue.  https://wiki.debian.org/CopyrightReview

Maybe we could revisit the idea along these lines:

 - a Salsa group into which people fork repos and run CI screens for copyright,
   license and missing source issues.

 - a peer-review system based on issues or MRs (for instance to a master
   repository with a text file tracing the outcome of the reviews).

 - as of today people would use it to ensure their submissions to NEW are to
   the highest standards and therefore the least likely to waste time of the
   FTP team members.

 - the outcome of the NEW processing of the peer review is also recorded by
   volunteers, allowing to better measure the achievements and usefulness of
   the system.

 - The FTP team, if they wish, can provide feedback.

 - when the FTP team calls for new trainees, applicants who have a track record
   of peer reviews in that system can show it to the FTP team, who are free to
   do what they want with this information.

 - If the FTP team recruits someobody who was peer reviewer and liked that
   system, a positive loop is made.

Have a nice day,

Charles

-- 
Charles Plessy                         Nagahama, Yomitan, Okinawa, Japan
Debian Med packaging team         http://www.debian.org/devel/debian-med
Tooting from home                  https://framapiaf.org/@charles_plessy
- You  do not have  my permission  to use  this email  to train  an AI -

[toc] | [prev] | [next] | [standalone]

#116217 — Re: Revisiting the idea of pre-NEW peer review? (Re: Bits from DPL)

[Multipart message — attachments visible in raw view] — view raw

Hello,

On Thu 06 Mar 2025 at 01:21pm +09, Charles Plessy wrote:

> Hi Sean and everybody,
>
> Around 12 years ago, I proposed a peer-review system to increase the quality of
> the packages in the NEW queue.  https://wiki.debian.org/CopyrightReview
>
> Maybe we could revisit the idea along these lines:

If someone wants to set this up in a way that doesn't increase ftp team
workload but means packages have to be reject'd less often -- by all
means.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.debian.devel

csiph-web