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?
Marc. I'll take my Popcorn with salt please.
On Thu, Mar 06, 2025 at 08:58:48AM +0100, Marc Haber wrote:
Marc. I'll take my Popcorn with salt please.
yeah, it's pretty funny to see a team burn out and have the same silly
& salty discussion about this again and again.
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.
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".
On 3/6/25 2:09 PM, Holger Levsen wrote:
so if the/a team says they cannot handle new members right now and thus there should be no big announcement asking for new members, I very much think this should be respected and not be ignored and spread on ourThis has been an long term recurring complaint without any tangible solution or a plan from the concerned team, so I think it is important for the whole project to address it, and not just leave it to the ftp team to resolve it (they ave not been able to address it by themselves for a long time).
most visible mailing list, where there pain will be consumed with popcorn.
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
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
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.
On Thu 06 Mar 2025 at 01:21pm +09, Charles Plessy wrote:
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
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.
Hi!
Around 12 years ago, I proposed a peer-review system to increase the quality ofFor packages that I sponsor, I already do reviews of the
the packages in the NEW queue. https://wiki.debian.org/CopyrightReview
debian/copyright and all other files. These are recorded as Merge
Requests in Salsa. Perhaps the easiest way to achieve the workflow you envision would be to have a field in the upload metadata that links to
the Merge Request on Salsa, so FTP masters can see who reviewed the
contents and if their feedback was properly addressed in addition to reviewing the uploaded artifacts from scratch?
On 7/3/25 12:29 AM, Otto Keklinen wrote:
Around 12 years ago, I proposed a peer-review system to increase the quality ofFor packages that I sponsor, I already do reviews of the
the packages in the NEW queue. https://wiki.debian.org/CopyrightReview
debian/copyright and all other files. These are recorded as Merge
Requests in Salsa. Perhaps the easiest way to achieve the workflow you envision would be to have a field in the upload metadata that links to
the Merge Request on Salsa, so FTP masters can see who reviewed the contents and if their feedback was properly addressed in addition to reviewing the uploaded artifacts from scratch?
May be this can go to changelog? As adding new filed may need tools and people to adjust and can take a long time.
I have prepared a stub for a "Gateway to NEW" on Salsa:
https://salsa.debian.org/newgateway-team
I added `Debian` as a team member.
I am under the impression that forking repositories will not be necessary: if we provide CI pipeline packages like the salsa-ci project, and smart ways to turn them on and off, then people can run their tests in their own repositories. I have some new r-cran-* packages to prepare next week; I will use them as a proof of principle. Everybody is welcome to be faster than me to
test the idea.
I am not entirely sure on where to continue the discussion, but maybe we can try to leverage Salsa as much as possible for that as well?
On Thu, Mar 06, 2025 at 08:39:13AM +0000, Holger Levsen wrote:
On Thu, Mar 06, 2025 at 08:58:48AM +0100, Marc Haber wrote:
Marc. I'll take my Popcorn with salt please.
yeah, it's pretty funny to see a team burn out and have the same silly
& salty discussion about this again and again.
I apologize for trying to bring a smile into a heated discussion and
will now return to shutting up to non-technical issues.
Thanks for starting this -- could you re-enable Issues for the Pipelines >project?
I suggest to use 'lrc' in the pipeline. I already do this for many
packages, and I just add
- https://salsa.debian.org/debian/licenserecon/raw/main/debian/licenserecon.yml
Yes, false positives happens, and it doesn't always handle Autotools
projects with a lot of generated files with complex licenses well.
I suggest to use 'lrc' in the pipeline. I already do this for many >>packages, and I just add
- https://salsa.debian.org/debian/licenserecon/raw/main/debian/licenserecon.yml
Looks good!
Yes, false positives happens, and it doesn't always handle Autotools >>projects with a lot of generated files with complex licenses well.
Here we are in the context of entirely new packages, so we can explore
the idea that packages need either to be licenserecon-clean, or to
include a note why they can't, in order to get a review. For instance,
the form to request a review (issue, MR, or service counter, I am not
sure yet), could contain a checklist item about this.
* 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.
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?
If the public NEW-queue viewer at https://ftp-master.debian.org/new.html
is an accurate reflection of the files that the ftp team would look at
first in their internal processes, then the top changelog entry (but only
the top changelog entry, and not later ones), debian/README.source, or
the copyright file itself would be the places to put evidence supporting
the copyright file being correct.
A change history of problems that were reported and fixed doesn't seem
like something that would speed up the ftp team's work: if they feel that they have to review a change history *in addition* to reviewing the uploaded artifacts, I don't see how that would take a shorter time than only
reviewing the uploaded artifacts. The only way this could help is if the
ftp team were willing to trust the information from peer review and do
a less in-depth review of packages that have had a positive peer review,
but I have not seen any indication from the ftp team that they would be prepared to do that.
So I think it could be better to frame this in terms of finding a good
place to put supporting evidence ("I know the licensing situation
in contrib/foo/ looks strange at first glance, but in fact it's OK because..."), rather than somewhere to put a change history of previous negative feedback being addressed. The ftp team don't need to know about
the existence of previous, wrong packages, they are only approving or rejecting the hopefully-correct final package that has been submitted
for their review.
I have prepared a stub for a "Gateway to NEW" on Salsa:
https://salsa.debian.org/newgateway-team
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.
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?
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
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.
IMO it is the maintainer's responsibility to ensure that NEW+unstable >together is always all installable, if you see what I mean.
Hello Charles,
Thanks. Please put prominent links to these three places:
- Policy 2.3 -- this covers 90% of my NEW rejects
Based on my experience processing NEW, a lot of DDs don't seem to
really have an understanding of the requirements explained here.
Including me, before I joined the ftp team.
I updated this section to try to capture what I learned.
- Policy 12.5 -- covers some of the othe REJECTs
- the REJECT-FAQ.
I have prepared a stub for a "Gateway to NEW" on Salsa:
https://salsa.debian.org/newgateway-team
Am I correct in assuming that each package to be reviewed will be an
issue under the "reviews" repo (and possibly also mention the relevant package maintainer there)?
Will packages be reviewed upon request, or will it be fine to pick out packages from the NEW queue and review them to assist FTP masters?
On Fri, 2025-03-07 at 09:51 +0900, Charles Plessy wrote:
I have prepared a stub for a "Gateway to NEW" on Salsa:
https://salsa.debian.org/newgateway-team
Le Sun, Mar 09, 2025 at 06:00:55PM +0800, Maytham Alsudany a crit :
Am I correct in assuming that each package to be reviewed will be an
issue under the "reviews" repo (and possibly also mention the relevant
package maintainer there)?
Will packages be reviewed upon request, or will it be fine to pick out
packages from the NEW queue and review them to assist FTP masters?
The way I envision it, is that people will ask for peer review before uploading
to the NEW queue.
Could you explain how I would ask for review of a package? I re-read
this thread, and the newgateway-team homepages, but I still don't
understand how you think the process should work.
Could we test the process by reviewing 'litetlog'?
I have just drafted a workflow in
https://salsa.debian.org/newgateway-team/reviews#how-to-request-or-make-a-review
which I quote here:
0. (We are in pilot phases. Improvements of this workflow are welcome)
1. The package maintainer adds the
[pipelines](https://salsa.debian.org/newgateway-team/pipelines) to its Salsa CI
file. (It would be cool to have a _devscripts_ script for that.)
2. The package maintainer opens an issue with _Review_ template (shall we
just make it default?). Salsa ID pings in the issue can be useful for
exchanging reviews.
3. Once the checklist is clear, the maintainer uses the create merge request
button in the issue page, to add the package in the table below. (Or just
editing the file directly is fine?)
4. Somebody merges the request after verifying quickly that the checklist was
properly addressed.
5. Reviewers open issues with the _Review_ template. If problems are found,
they ping the maintainer with their salsa ID in the issue discussion. Reviews
end by adding the issue ID in the table below via a MR to be accepted and
merged by the package maintainer.
6. Once all reviewers thumbs are up, update the table below (with or without
MR), and upload to NEW.
7. Once the package leaves the NEW queue, record the outcome in the table below.
2. The package maintainer opens an issue with _Review_ template (shall we >> just make it default?). Salsa ID pings in the issue can be useful for >> exchanging reviews.
3. Once the checklist is clear, the maintainer uses the create merge request
button in the issue page, to add the package in the table below. (Or just
editing the file directly is fine?)
Wouldn't using an issue's open/closed status and tags be sufficient
rather than MRs for each issue? For instance:
- open = not in the archive yet
- closed = in the archive / abandoned
- tag "passed-review"
- tag "accepted" when the package enters the archive
I also suggest using a standard naming scheme like "package/version"
(e.g. "r-cran-multitaper/1.0-17-1") for easy lookup of packages as well
as different versions (for binNEW).
Then, if ftp-masters want to check for a peer-review, they can just look
for the name of the package in the list of open issues, named with a
standard "package-name/package-version".
And if the table in README is still necessary, then (I think) a CI
pipeline can update it from the issue data.
4. Somebody merges the request after verifying quickly that the checklist was
properly addressed.
5. Reviewers open issues with the _Review_ template. If problems are found,
they ping the maintainer with their salsa ID in the issue discussion. Reviews
end by adding the issue ID in the table below via a MR to be accepted and
merged by the package maintainer.
6. Once all reviewers thumbs are up, update the table below (with or without
MR), and upload to NEW.
7. Once the package leaves the NEW queue, record the outcome in the table below.
Some definition of scope would be useful (e.g. "we don't check if the
program runs or if the package builds (that's the responsibility of the uploader), we just do the same checks as those that happen in the NEW queue").
Let me know how I can help! I enjoy reviewing copyright files, so if any arise, please send them my way :)
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?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 546 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 169:00:16 |
| Calls: | 10,385 |
| Calls today: | 2 |
| Files: | 14,057 |
| Messages: | 6,416,551 |
