Hello,
On Sun 01 May 2022 at 07:52am +08, Paul Wise wrote:
> 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 expe
On Sat, 30 Apr 2022, Paul Wise wrote:
> 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.
This
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
the NEW queue at all. As far as I understand it, the main advantage
to gain is additional context; a bug report provides documentation
and a place to discuss solutions
On May 1, 2022 4:44:21 PM UTC, "Timo Röhling" wrote:
>* Scott Kitterman [2022-04-29 23:32]:
>> 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.
>I thi
* Scott Kitterman [2022-04-29 23:32]:
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.
I think this is a matter of perspective: for the FTP team, the
upload
Paul Wise left as an exercise for the reader:
> 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 u
On Sat, 2022-04-30 at 22:47 -0400, nick black wrote:
> 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 fil
Paul Wise left as an exercise for the reader:
> > 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 th
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
Hello,
On Sat 30 Apr 2022 at 07:44AM +08, Paul Wise wrote:
> 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.
--
Sean Whitton
signature.asc
Descripti
On Sat, 2022-04-30 at 03:09 -0400, nick black wrote:
> currently, as far as i understand things, a REJECT can be issued
> for the first REJECT-worthy problem.
The same would occur under the proposal, except that there would
presumably be separate bug reports for separate issues.
> if resolving t
Paul Wise left as an exercise for the reader:
> 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 NE
On Sat, 2022-04-30 at 00:13 +, Scott Kitterman wrote:
> I'm still not understanding how any of that needs to have a package
> we've decided not to accept sitting in New?
My thinking is that debbugs would require a package (imported from
new.822) to exist for maintainer addresses. If you file
On April 29, 2022 11:44:54 PM UTC, Paul Wise wrote:
>On Fri, 2022-04-29 at 23:32 +, 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 r
On Fri, 2022-04-29 at 23:32 +, 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, bu
On Fri, 2022-04-29 at 18:08 +0200, Andreas Tille wrote:
> To give some actual examples that IMHO are candidates for accept + bug
> report:
Packages with incomplete or incorrect debian/copyright information
currently would recieve a REJECT rather than acceptance. The proposal
would not change that
On April 29, 2022 11:04:57 PM UTC, Paul Wise wrote:
>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 n
On Fri, 2022-04-29 at 11:26 -0400, Scott Kitterman wrote:
> 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
> pack
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
On Friday, April 29, 2022 12:08:21 PM EDT Andreas Tille wrote:
> 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 wha
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 rep
On Wednesday, April 27, 2022 8:54:05 PM EDT Paul Wise wrote:
> 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.
>
On 2022-04-29 at 08:36, Steve McIntyre wrote:
> 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.
>>
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 b
Hi Paul,
Am Fri, Apr 29, 2022 at 07:13:42AM +0800 schrieb Paul Wise:
>
> The packaging work is supposed to start *after* the ITP is filed,
Sure.
> so
> this is a suboptimal order to do things in and doesn't provide much
> value,
The "packaging work" to create the debian/ dir is a 1min process
On Thu, 2022-04-28 at 20:24 +0200, Andreas Tille wrote:
> 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.
The packaging work is supposed to start *after* the ITP is filed, so
this is a su
On Thu, 2022-04-28 at 13:48 +0200, Marco d'Itri wrote:
> 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.
Thanks. The idea is narrowly aimed at improvin
Hi Paul,
Am Thu, Apr 28, 2022 at 06:46:43PM +0800 schrieb Paul Wise:
> 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 n
On Apr 28, 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 looks like a good idea to me, but I think
On Thu, 2022-04-28 at 09:36 +0200, Andreas Tille wrote:
> 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 t
Hi Paul,
Am Thu, Apr 28, 2022 at 08:54:05AM +0800 schrieb Paul Wise:
> 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.
>
> Th
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,
b
32 matches
Mail list logo
