I tried to remove a package from NEW with `dcut rm package.deb`, `dcut
rm package.changes` and `dcut cancel package.changes`, but nothing
worked.
Is there even a way to remove a package from NEW?

Regards,
Stephan

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am 18. November 2021 10:30:37 MEZ schrieb Stephan Lachnit <stephanlachnit@debian.org>:

I tried to remove a package from NEW with `dcut rm package.deb`, `dcut
rm package.changes` and `dcut cancel package.changes`, but nothing
worked.
Is there even a way to remove a package from NEW?

Regards,
Stephan

ask FTP Masters for a reject.

(speculatinng on the why you want it rejected: if you want to replace it with e.g. a newer version, you can just upload the new version)

--
tobi

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Quoting Tobias Frost (2021-11-18 10:38:40)

(speculatinng on the why you want it rejected: if you want to replace it with e.g. a newer version, you can just upload the new version)

slightly related question: if I upload a new version to NEW, will the Age of the package be reset? I'm asking because my package has been in NEW for four months already and I'd like to avoid loosing that place by an upload of a new upstream version.

Thanks!

cheers, josch
--==============332282338045937079=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEElFhU6KL81LF4wVq58sulx4+9g+EFAmGWKmQACgkQ8sulx4+9 g+F+uA/8DRHYWNqc8xtF5b16N6BL8/KeAtNUyypj6FhIz2jCzfs96bVcTgC/lU0J 09OBb3uh1fhg5kOrMFF5vqjV13+c387No1SmfWtAsPPYsCcDhRLL/+jtnEpNQIgL hMlBps1HsKeCnGAbJdf3JvxP0WDsnwrGiNoEo8+o7jizqE440IrMaDdFQ00lTL7X XquXYYrpACWdfhFEsv3L43NpzxuhPbrhHFRGcvQ8xERoQFYeeJMxPt4U8F4G1WY2 zVFaVmtEjdY1eauH/r08N0WEz0g9akHV0Bmv491EoV9KlSD3rnbOhKYJ98QZZ8JS VVtv+Qf0tigecYbitn7Bl014sgacn5+ztoq13KoDoA53hicX60LEd+U5JFmQ4tCy 1r1ofdOr5L9GwKYNHH3jAH1nntIFT5IZS6ptU0nZS3VitALB1uJP66HpA6Fx2NJz EQnPYSivljwvzUtK5aHkMznROx18QTH5tWFpdJVtewK7UyXzdLSX8nVUuqC1vIPi IGcl4aMdMRzzi+upFyi3oNnOkhdV/toQWTsk+p/QcGhnhVTFOVdNDFxltgo3ASlv 3cl4YFQRX8M8q5UGmGTgWdOlY7TshXzhOod9WVwEKJreHXzslApxm6aNM7LWX6Hx B7FFCYu3PhCQdzm93J9meDl//WKPNGc8Q5aqd14sBYaAWKl3gEA=
=w6eX
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Quoting Johannes Schauer Marin Rodrigues (2021-11-18 11:26:44)

Quoting Tobias Frost (2021-11-18 10:38:40)

(speculatinng on the why you want it rejected: if you want to replace it with e.g. a newer version, you can just upload the new version)

slightly related question: if I upload a new version to NEW, will the
Age of the package be reset? I'm asking because my package has been in
NEW for four months already and I'd like to avoid loosing that place
by an upload of a new upstream version.

I guess that by "Age" you are referring to 5th column at https://ftp-master.debian.org/new.html

Seems that field do get reset on new uploads: See e.g. ignition-utils
which was uploaded in september and again in november - its "Age" is 2
days.

Is "Age" used to rank processing of NEW requests? Is that documented somewhere? Or alternatively, do anyone have some (non cargo cult)
empirical knowledge about that?


- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private --==============70222757510995015=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmGWfZUACgkQLHwxRsGg ASHzVg/9G7zi90rl0Ko/CV3hklUG7uAGIUnJJOay5wbrMuwRiJw8Igrp8EH4m033 Z4Ed8/GNClxK+JDl8SGWWpqvh9XArMYnKaKzjtvxSPPB0QrTMhuDB2sXVxgx+q2e GQ2jU14kOI0hzbqUD//O6k3bqRUVD4V/xiRP6AS1sAggd8/oldQ7cayxwBVKQMwD lls1C4M3I45wxYu2WMFYDZfRQrRHwVC25nDzPsxf+0OxhFhrY5Yjg0U20WBczev+ RZmrwxqN9m3bUSs9pOLB0fC2+FG5BzoNPcM4LePZt+5d1lz7FjAxzBs6mQ63j0WR +g8inuNCBHKKL3W+G36e/Hi2baR9Anzb1+4QseytwQLj/+r6zgz2tcMR4nXUjAyQ OTSEbTqEYWTqb6vLv7YZcgU485gATTWcM3JR1H58CMUcaI6PR7uA/lq/jDE9Wl1l 0TYOELdXNH1MLaJmRCS1Gf9TgU+BwxWZ+ddlRPwi4+nehxXzz2haEb65qDaLf99i Pyl2h2m2nXU2ROiu2

Hi Jonas,

I've thought that it is probably not my turn to answer your questions
but since there was no answer yet I'd like to report from my experience.

Am Thu, Nov 18, 2021 at 05:21:45PM +0100 schrieb Jonas Smedegaard:

Is "Age" used to rank processing of NEW requests?

I have some evidence that "Age" is at least not the only ranking
factor for processing NEW requests. I've made the experience that
the following hints are well perceived by ftpmaster:

1. Package in new fixes RC bug #xy
2. Package has just a new binary name and might be easier
to process than other packages
3. Package has some importance for reason XY (this worked
extremely well in April last year when we had the Debian
Med Covid-19 sprint - I observed processing times less
than 24 hours and I can't say frequently enough how thankful
I am about this

It is not always clear to me what channel is best for submitting
those hints. IRC usefully works nicely, but not always. Responding
to the mail that a package is in new can be helpful as well. For
the Covid-19 sprint we had setup a dedicated Wiki page.

Is that documented somewhere?

As far as I know it is not documented.

Or alternatively, do anyone have some (non cargo cult)
empirical knowledge about that?

See above about my experience with ranking. I also think that my habit
to say thank you to ftpmaster whenever there is a sensible chance is
also a good way to motivate ftpmaster to do a work which I personally
would consider not the most thrilling task on my own desk. It probably
helps more than telling that ftpmaster is slow in working down the
queue. So: Thank you to ftpmaster for processing the queue.

However, I wished at least one member of ftpmaster team would lurk here
on this list to clarify questions like these. What I was explicitly
told by more than one ftpmaster is that kind of "free text" e-mails in
their mailbox tend to be forgotten in the large amount of so many mails
to this mailbox I can not even imagine. Thus I do not ftpmaster in my
response which I would usually do in cases like this.

Kind regards

Andreas.

--
http://fam-tille.de

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Monday, December 6, 2021 8:58:15 AM EST Andreas Tille wrote:

Hi Jonas,

I've thought that it is probably not my turn to answer your questions
but since there was no answer yet I'd like to report from my experience.

Am Thu, Nov 18, 2021 at 05:21:45PM +0100 schrieb Jonas Smedegaard:

Is "Age" used to rank processing of NEW requests?

I have some evidence that "Age" is at least not the only ranking
factor for processing NEW requests. I've made the experience that
the following hints are well perceived by ftpmaster:

1. Package in new fixes RC bug #xy
2. Package has just a new binary name and might be easier
to process than other packages
3. Package has some importance for reason XY (this worked
extremely well in April last year when we had the Debian
Med Covid-19 sprint - I observed processing times less
than 24 hours and I can't say frequently enough how thankful
I am about this

It is not always clear to me what channel is best for submitting
those hints. IRC usefully works nicely, but not always. Responding
to the mail that a package is in new can be helpful as well. For
the Covid-19 sprint we had setup a dedicated Wiki page.

Is that documented somewhere?

As far as I know it is not documented.

Or alternatively, do anyone have some (non cargo cult)
empirical knowledge about that?

See above about my experience with ranking. I also think that my habit
to say thank you to ftpmaster whenever there is a sensible chance is
also a good way to motivate ftpmaster to do a work which I personally
would consider not the most thrilling task on my own desk. It probably
helps more than telling that ftpmaster is slow in working down the
queue. So: Thank you to ftpmaster for processing the queue.

However, I wished at least one member of ftpmaster team would lurk here
on this list to clarify questions like these. What I was explicitly
told by more than one ftpmaster is that kind of "free text" e-mails in
their mailbox tend to be forgotten in the large amount of so many mails
to this mailbox I can not even imagine. Thus I do not ftpmaster in my response which I would usually do in cases like this.

Speaking only for myself here, not the team as a whole:

The tools we use default to age order, so if one just starts working through packages in the order given, it's oldest first. Personally, I rather rarely do that. I don't have a lot of time for this (I'm only recently returned from a hiatus in fact) and so I try to focus on packages of types that I'm more familiar with so that I can accomplish more with the time I do have.

I took time off of $work to focus on New for the COVID-19 sprint because I thought it was important, so that level of service should not be generally expected. It was a very special case.

IRC (#debian-ftp) works best for me. It's actually less likely to get lost than email.

Scott K

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Quoting Scott Kitterman (2021-12-06 16:03:31)

Speaking only for myself here, not the team as a whole:

The tools we use default to age order, so if one just starts working
through packages in the order given, it's oldest first. Personally, I rather rarely do that. I don't have a lot of time for this (I'm only recently returned from a hiatus in fact) and so I try to focus on
packages of types that I'm more familiar with so that I can accomplish
more with the time I do have.

I took time off of $work to focus on New for the COVID-19 sprint
because I thought it was important, so that level of service should
not be generally expected. It was a very special case.

IRC (#debian-ftp) works best for me. It's actually less likely to get
lost than email.

Thanks for sharing those insights, and for your ftp-master work
generally.

- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private --==============†59284832720824901=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmGuMXcACgkQLHwxRsGg ASFcLhAAi4PmrBkgb0fi/CH20phZw9K7N+uD/si6q7q0koob2xhl9p7JtW8+2AZN K3cqLtPW2ZtVLOs1AcQ77aCkmgnTrS4q9wTf8C8HgI4TdjibKhf4KaN0vxpwqCN9 OFyBXIdEbn/C9XOoi9lOzGkuOyloo4RVh+SCnqbEkV4TutFq4QzBcrf3MG4MC/9a U8N4/KxGwQzuxRXJK6D6rSb8axo7R3iFooS8Fb/Upb7d6C+Tu0omnNMryogkHctP mrdtwBkkAL/VGoUTe0g8agz04b5ZeoXeunguwDc6J1ufZKmcx2Uje7J+wx0dTwrr l/BOF1wmgm4pPfPPYxVPS3vcszCzgycWHKrCtKqsWQfLsO+7aIkQai5RNmch8fdM T69pAsegZPE0kQQ69rwhheIhn4Gto/X3ZpK6vQwZ7FLrDXOve2UEU88vp/yCpp70 RIJ7bFdM6NH/+cRB6QqV1nR3CFS6XF3IeJlj2HVbjPTF5uQCW531QTEhheh2H0F5 k6nIPNlbAIapXGABa