During the discussions about NEW on debian-devel in recent times, I had
the idea that instead of the current mechanism of sending REJECT mails, Debian could switch to using the BTS for most feedback on NEW packages.
This means that most discussion about NEW packages would become public,
but of course the ftpmasters could opt to send private mail instead if
in some cases if there were sensitive issues to be discussed.
The ftpmasters could simply file severity serious bug reports against
NEW packages that have issues blocking their entry into Debian. When
there are minor issues noticed at the same time, then file bugs of a
lower severity. Only when a NEW package has not had its serious bugs
fixed in a long time would an eventual removal and REJECT mail happen, perhaps after a few months of zero action on the bug reports.
The changes that are needed to make this happen include:
The community needs to decide that this change is a good idea and be
willing to recieve most feedback on their work in public.
The BTS and ftpmaster teams need to agree with this change.
One BTS admin said this is feasible in principle and one of the
ftpmasters seemed to like the idea when I mentioned it on IRC.
Where the bug mail should go to needs to be decided on. Personally I'm thinking the person who did the upload plus the Maintainer field.
The people doing processing of NEW packages need to be willing to file
bug reports against them where necessary.
dak needs to export debian/changelog version lists for NEW packages.
debbugs needs to import packages/versions from the new.822 file:
https://ftp-master.debian.org/new.822
dak needs to link to the BTS from new.822 and the NEW packages info.
https://ftp-master.debian.org/new.html
The technical work needed here is minimal, so if there are no other volunteers to do that work, then I would be willing to do it. I have experience with Perl/Python but only a small amount of experience with working on the debbugs and dak codebases.
Thoughts welcome, especially from those who don't like this idea.
What about WNPP bug?ย When I asked ftpmaster to kindly CC their
rejects to the WNPP bug I was told that not all packages in new have WNPP bugs. If we want to formalise this it could probably be enforced that new packages really need to have such a bug and we only need to decide
for existing packages that need to pass NEW.
(BTW, I usually bounce any reject to the according WNPP bug to have
the issue documented in a publicly visible place where any interested
person should look.)
The changes that are needed to make this happen include:
During the discussions about NEW on debian-devel in recent times, I hadThis looks like a good idea to me, but I think that the big problem
the idea that instead of the current mechanism of sending REJECT mails, Debian could switch to using the BTS for most feedback on NEW packages.
There are two main categories of NEW packages; source and binary.
Packages adding an new source should have an ITP bug, but don't
always, for eg the Rust/Golang teams don't file them for every
library. Packages adding a new binary package often have a transition
bug, but those are usually filed after the upload is accepted.
Filing a new WNPP bug for every NEW package upload seems a bit tedious
and I think lots of people aren't going to bother/remember to do it.
The proposal I make would mean that the manual bug filing for every
upload wouldn't be needed, instead the BTS would know about packages
in NEW and ftpmasters and others could file bugs against them, which
would mainly only be needed when there are REJECTable issues present.
In addition there could be separate bugs for each individual issue,
rather than one long discussion about multiple different issues.
This is probably especially important for low severity issues.
(BTW, I usually bounce any reject to the according WNPP bug to have
the issue documented in a publicly visible place where any interested person should look.)
That seems reasonable if the ftpmasters are fine with that.
If the
BTS for NEW proposal gets implemented it would no longer be needed.
Am Thu, Apr 28, 2022 at 08:54:05AM +0800 schrieb Paul Wise:
The changes that are needed to make this happen include:
I guess tracker.d.o would also need to show NEW packages.
This looks like a good idea to me, but I think that the big problem
which needs to be solved is not discussing REJECTs but the packages
which stay in NEW for many months with no feedback.
But filing an ITP bug is cheap.ย The R-pkg team has a script itp_from_debian_dir[1] which creates this bug automatically once the packaging work is done.
That's true.ย I just wanted to mention that some of your ideas
are in a way used even now.
The packaging work is supposed to start *after* the ITP is filed,
so
this is a suboptimal order to do things in and doesn't provide much
value,
except as a way to prevent people packaging the same R library
during the wait in NEW, but the presence of the R library in the R-pkg
team VCS already provides that, so the ITP bug isn't really needed.
Even when filing ITPs before packaging, for language ecosystem teams
where all library packages for the language go through the same team,
team co-ordination mechanisms are probably enough of a way to prevent duplication of work, and that work is mostly automated anyway for
several such teams, so the ITP bug mostly isn't really needed.
Some teams make exceptions for packages that aren't strictly just
libraries; for eg Rust folks to ITPs for things that ship executables,
so that people can hear about things they might want to use on Debian.
That's true. I just wanted to mention that some of your ideas
are in a way used even now.
Yeah, the proposal was derived from the suggestion to file ITPs for all
NEW packages, mostly aimed at avoiding the deficiencies with that idea.
During the discussions about NEW on debian-devel in recent times, I had
the idea that instead of the current mechanism of sending REJECT mails, >Debian could switch to using the BTS for most feedback on NEW packages.
This means that most discussion about NEW packages would become public,
but of course the ftpmasters could opt to send private mail instead if
in some cases if there were sensitive issues to be discussed.
The ftpmasters could simply file severity serious bug reports against
NEW packages that have issues blocking their entry into Debian. When
there are minor issues noticed at the same time, then file bugs of a
lower severity. Only when a NEW package has not had its serious bugs
fixed in a long time would an eventual removal and REJECT mail happen, >perhaps after a few months of zero action on the bug reports.
Paul Wise wrote:
During the discussions about NEW on debian-devel in recent times, I
had the idea that instead of the current mechanism of sending
REJECT mails, Debian could switch to using the BTS for most
feedback on NEW packages.
This means that most discussion about NEW packages would become
public, but of course the ftpmasters could opt to send private mail
instead if in some cases if there were sensitive issues to be
discussed.
The ftpmasters could simply file severity serious bug reports
against NEW packages that have issues blocking their entry into
Debian. When there are minor issues noticed at the same time, then
file bugs of a lower severity. Only when a NEW package has not had
its serious bugs fixed in a long time would an eventual removal and
REJECT mail happen, perhaps after a few months of zero action on
the bug reports.
Just to clarify: is this suggesting that packages from NEW would end
up in the archive even with serious bugs? If not, what's the point
of the "eventual removal" above? I'm not following you here...
2. Not rejecting packages with serious defects:
I'm not sure I understand what it proposed:
The ftpmasters could simply file severity serious bug reports against
NEW packages that have issues blocking their entry into Debian. When
there are minor issues noticed at the same time, then file bugs of a
lower severity. Only when a NEW package has not had its serious bugs
fixed in a long time would an eventual removal and REJECT mail happen, perhaps after a few months of zero action on the bug reports.
I think this proposes to accept all packages regardless of how defective they are and then remove them later if the bugs aren't fixed. If that's what is proposed, my thought is absolutely not.
If a package is not suitable for the archive then it should be rejected with appropriate feedback and re-uploaded.
Note: Although I am a member of the FTP Team, I am only speaking for myself here, not the team as a whole.
Hi all,
During the discussions about NEW on debian-devel in recent times, I had
the idea that instead of the current mechanism of sending REJECT mails, Debian could switch to using the BTS for most feedback on NEW packages.
This means that most discussion about NEW packages would become public,
but of course the ftpmasters could opt to send private mail instead if
in some cases if there were sensitive issues to be discussed.
The ftpmasters could simply file severity serious bug reports against
NEW packages that have issues blocking their entry into Debian. When
there are minor issues noticed at the same time, then file bugs of a
lower severity. Only when a NEW package has not had its serious bugs
fixed in a long time would an eventual removal and REJECT mail happen, perhaps after a few months of zero action on the bug reports.
The changes that are needed to make this happen include:
The community needs to decide that this change is a good idea and be
willing to recieve most feedback on their work in public.
The BTS and ftpmaster teams need to agree with this change.
One BTS admin said this is feasible in principle and one of the
ftpmasters seemed to like the idea when I mentioned it on IRC.
Where the bug mail should go to needs to be decided on. Personally I'm thinking the person who did the upload plus the Maintainer field.
The people doing processing of NEW packages need to be willing to file
bug reports against them where necessary.
dak needs to export debian/changelog version lists for NEW packages.
debbugs needs to import packages/versions from the new.822 file:
https://ftp-master.debian.org/new.822
dak needs to link to the BTS from new.822 and the NEW packages info.
https://ftp-master.debian.org/new.html
The technical work needed here is minimal, so if there are no other volunteers to do that work, then I would be willing to do it. I have experience with Perl/Python but only a small amount of experience with working on the debbugs and dak codebases.
Thoughts welcome, especially from those who don't like this idea.
The ftpmasters could simply file severity serious bug reports against
NEW packages that have issues blocking their entry into Debian. When
there are minor issues noticed at the same time, then file bugs of a
lower severity. Only when a NEW package has not had its serious bugs
fixed in a long time would an eventual removal and REJECT mail happen, perhaps after a few months of zero action on the bug reports.
Hi Scott,
thanks a lot for becoming involved into this discussion.
Am Fri, Apr 29, 2022 at 11:26:33AM -0400 schrieb Scott Kitterman:
2. Not rejecting packages with serious defects:
I'm not sure I understand what it proposed:
The ftpmasters could simply file severity serious bug reports against
NEW packages that have issues blocking their entry into Debian. When there are minor issues noticed at the same time, then file bugs of a lower severity. Only when a NEW package has not had its serious bugs fixed in a long time would an eventual removal and REJECT mail happen, perhaps after a few months of zero action on the bug reports.
I think this proposes to accept all packages regardless of how defective they are and then remove them later if the bugs aren't fixed. If that's what is proposed, my thought is absolutely not.
If a package is not suitable for the archive then it should be rejected with appropriate feedback and re-uploaded.
To give some actual examples that IMHO are candidates for accept + bug report:
1. In case versioneer.py (Creative Commons "Public Domain Dedication"
license (CC0-1.0) is missing in d/copyright like in propka[1]
2. Packages which are DFSG free but might miss some single copyright
statement.
My favourite example would be r-bioc-basilisk[2]. In this specific
example I even disagree with ftpmaster[3] but I see no real chance
as a maintainer to discuss my point and can only re-re-re-upload
what I consider correct. So I gave up and this package is not yet
inside Debian. This could be discussed more sensibly in a bug
report IMHO.
I think Paul was not talking about non-distributable software but rather
code that is considered DFSG free but missing proper paragraphs inside d/copyright which can be easily fixed in BTS.
Just to clarify: is this suggesting that packages from NEW would end
up in the archive even with serious bugs? If not, what's the point of
the "eventual removal" above? I'm not following you here...
On Fri, 2022-04-29 at 13:36 +0100, Steve McIntyre wrote:
Just to clarify: is this suggesting that packages from NEW would end
up in the archive even with serious bugs? If not, what's the point of
the "eventual removal" above? I'm not following you here...
No, the bugs I propose to be filed would be filed *while* the package
is in NEW and then *after* the serious ones are all fixed, that is a
positive indication that the package is probably suitable for an ACCEPT >action by the ftpmasters, although of course a final review is needed.
To give some actual examples that IMHO are candidates for accept + bug report:
I think Paul was not talking about non-distributable software but rather
code that is considered DFSG free but missing proper paragraphs inside d/copyright which can be easily fixed in BTS.
I don't understand why this is any better than just rejecting the
package?ย Once it's been determined that the upload won't be
accepted, I don't see a benefit to having it remain in New.
1.ย Making reject/prod emails more public:
There are actually two different types of messages we can send while reviewing
packages in DAK:
a.ย Reject: As indicated by the name, this is an email that accompanies the package being rejected from the New queue.
b. Prod: These leave the package in New and are used to ask the maintainer a question.
My recollection is that these go to the maintainer and changed by.ย In many cases the maintainer is a team, so these are already not considered private.
Whatever is done in this area should definitely be integrated into DAK as part
of process-new.ย I don't think it would be helpful to try to add steps to the
work the FTP Team has to do.ย New is slow enough that we should definitely not
make is slower.
Also, if any of this will depend on the existence of a WNPP bug, then policy should be changed to require them.ย They are currently not required and not everyone files them.ย If something is going to be required to get a package accepted, it should be in policy.
On a related note: It is not unusual for me to notice packaging issues which are not serious enough to reject the package, but should be documented.
This is particularly true when an existing package goes through New due to a new
binary package.ย It would be useful to have the option to accept with bug report so that we don't need to go through the steps of filing a bug by hand.ย
When I do this I also send a prod to the uploader/maintainer and it's effectively doing work twice.ย Making New processing more efficient will help
make it faster.
2.ย Not rejecting packages with serious defects:
I'm not sure I understand what it proposed:
The ftpmasters could simply file severity serious bug reports against
NEW packages that have issues blocking their entry into Debian. When
there are minor issues noticed at the same time, then file bugs of a
lower severity. Only when a NEW package has not had its serious bugs
fixed in a long time would an eventual removal and REJECT mail happen, perhaps after a few months of zero action on the bug reports.
I think this proposes to accept all packages regardless of how defective they
are and then remove them later if the bugs aren't fixed.ย If that's what is proposed, my thought is absolutely not.
If a package is not suitable for the archive then it should be rejected with appropriate feedback and re-uploaded.
Note: Although I am a member of the FTP Team, I am only speaking for myself here, not the team as a whole.
On Fri, 2022-04-29 at 23:32 +0000, Scott Kitterman wrote:
I don't understand why this is any better than just rejecting the
package?ย Once it's been determined that the upload won't be
accepted, I don't see a benefit to having it remain in New.
The initial upload might not get an ACCEPT, but later revisions of the >package might be suitable for inclusion in Debian.
The main aim of the proposal is transparency for all problems getting
the package into NEW. Often it isn't clear what happened to a package
that was rejected, the proposal makes it easy to find out; just check
the bug reports for the source package.
It also means the ftpmasters can file separate bugs for each problem,
rather than combining them all into one mail.
It also means the ftpmasters can easily point out other issues they
noticed that don't block the package from being accepted and ensure
that those issues won't be forgotten.
I'm still not understanding how any of that needs to have a package
we've decided not to accept sitting in New?
In my mind if a package is in New it's in one of two states:
1.ย Not reviewed yet.
2.ย Partly/completely reviewed, pending resolution of a question
(e.g. prod sent to maintainer, waiting for reply).
What's the advantage of added a third:
3.ย Not going to be accepted, waiting for a new upload or for enough
time to pass before rejecting.
Packages with incomplete or incorrect debian/copyright information
currently would recieve a REJECT rather than acceptance. The proposal
would not change that, just turn that REJECT into a bug report, which
you could fix in a second upload to NEW and then the package would be reprocessed and get an ACCEPT or another bug.
currently, as far as i understand things, a REJECT can be issued
for the first REJECT-worthy problem.
if resolving the resulting bug report is the bar needing clearing to
enter the archive, that does seem to require FTPmasters to create a
complete statement of REJECT-worthy problems in each uploaded
package, which seems like more work than they must currently do.
It also means the ftpmasters can file separate bugs for each problem,
rather than combining them all into one mail.
This would really slow things down;
I don't think we could work that way.
if resolving the resulting bug report is the bar needing clearing to
enter the archive, that does seem to require FTPmasters to create a complete statement of REJECT-worthy problems in each uploaded
package, which seems like more work than they must currently do.
The bar for acceptance would be the same as it is now, the proposal
just changes how the issues blocking acceptance are communicated.
Now you get a REJECT mail, under the proposal you get a serious bug.
i understand. i suppose that what i'm saying is it will probably
be worthwhile to convey in Mentors etc. documentation that
"resolving the bugs filed thus far [regarding the package in
NEW] does not imply that no further bugs will be filed."
i'm just worried that people will get a bug filed that is not a
complete, exhaustive analysis, and think that it's the only
thing standing between them and archive glory. perhaps whatever
files the bug ought indicate this in the text of the bug itself.
I think the same problem and suggestions also apply with the current
system of prods and rejects, so please do add or propose adding it in
the appropriate documentation and templates. I will of course seek to preserve these statements if I end up working on the BTS proposal.
I don't understand why this is any better than just rejecting theI think this is a matter of perspective: for the FTP team, the
package? Once it's been determined that the upload won't be
accepted, I don't see a benefit to having it remain in New.
* Scott Kitterman <debian@kitterman.com> [2022-04-29 23:32]:
I don't understand why this is any better than just rejecting theI think this is a matter of perspective: for the FTP team, the
package? Once it's been determined that the upload won't be
accepted, I don't see a benefit to having it remain in New.
upload is basically a stateless process; a package is either fit for >inclusion in the archive or it is not. For the uploading DD, it is
merely a particular (undesirable) state in the packaging process.
The NEW queue is a mandatory review of their packaging effort, and
the REJECT is feedback which they will (hopefully) address, and then
try again. Maybe, in some circumstances, they will abandon the
package, but I'd say that this not typical.
Converting the NEW review process into a bug-centric approach
instead of a mail-centric approach reinforces the DD's point of
view, focusing more on the package upload as a part of package >maintainership.
The question is: how will this affect the FTP team's point of view?
If it will clutter the NEW queue with half-processed packages, I'd
say it is a bad tradeoff, because it adds mental load to the FTP
team. At a minimum, there needs to be appropriate tooling which
allows to distinguish easily between new packages requiring FTP team
review and packages waiting for fixes to be applied.
What does it help to have it sitting there instead of rejected?I gave it more thought, and I don't think it has to be sitting in
I suppose debbugs could allow the package state to go out of sync with
NEW and instead retain the addresses for a certain period of time
after packages are removed from NEW and while there are open bugs on
the packages that were removed from NEW.
On Sat, 2022-04-30 at 14:20 -0700, Sean Whitton wrote:
This would really slow things down;
I don't think we could work that way.
Using separate bug reports or not would of course be up to the person
filing them, but I expect the process could be automated well enough
that it wouldn't be much different to the current process (which I am
not familiar with). An automated multi-bug process might be something
like this; press the button for filing a bug, get a template with the
right version etc, type out the problem details, press send, repeat the process. Is the current process any different other than the repeating?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 18:40:06 |
| Calls: | 6,707 |
| Calls today: | 1 |
| Files: | 12,239 |
| Messages: | 5,351,549 |