Hi,
Il 05/05/20 09:14, Paul Wise ha scritto:
> Should we also be triaging the bugs filed against removed versioned
> source packages like golang-1.9 or python3.6?
For Boost packages I manually reassign bugs that are still relevant to
the newer Boost version whenever one old version gets removed
On Wed, May 13, 2020 at 09:27:33AM -0400, jrb3-beckenbach.us wrote:
> Offering a naive implementation idea:
> On package reintroduction, something (bot?) files a low-priority bug
> against the reintroduced package, titled eg “triage bugs from previous
> packaging”,
> containing explanatory text
[Two cents inbound from a lurker]
Greetings, Enrico Zini!
On 13 May 2020, at 05:07, you wrote:
>
> I would however guess that, for a majority of cases, we are probably
> talking about a bunch of bugs to triage, and I would rather introduce a
> practice of risking having to triage some bugs
On Wed, May 13, 2020 at 05:13:45AM -, Sune Vuorela wrote:
> But I guess it also depends on if it is one bug that needs work, or a
> "Thanks for your contribution to Debian by maintainig this package. Now
> also walk thru these 1000 old crap that probably is irellevant
> today"-experience
I
On 2020-05-12, Paul Wise wrote:
> On Tue, May 5, 2020 at 7:15 AM Paul Wise wrote:
>
>> Should we be automatically reopening these bugs?
>
> enrico suggested on IRC that we should be doing this.
I think in general it should be decided on a case by case basis.
if it was removed yesterday and
HELO,
On 12.05.20 09:26, Paul Wise wrote:
> On Tue, May 12, 2020 at 7:15 AM Ulrike Uhlig wrote:
>
>> Can you explain a bit better which issues this could cause to
>> maintainers? About how many cases per year are we talking for example?
>
> The issue is the extra work that triaging old bugs
On Tue, May 12, 2020 at 7:15 AM Ulrike Uhlig wrote:
> Can you explain a bit better which issues this could cause to
> maintainers? About how many cases per year are we talking for example?
The issue is the extra work that triaging old bugs involves, vs just
ignoring the old bugs that may or may
Hi,
On 05.05.20 09:14, Paul Wise wrote:
> One of the tasks needed when reintroducing packages after they have
> been removed is that the bugs that were closed by the removal need to
> be triaged and either reopened or version closing information added:
>
>
On Tue, May 12, 2020 at 6:08 AM Paul Wise wrote:
> I made a mistake when running the loop (binary vs source packages),
> here is the updated dd-list. Thanks to Jochen Sprickerhof for pointing
> out my mistake.
Sigh, attached the wrong one. Here is the correct one.
--
bye,
pabs
On Tue, May 5, 2020 at 7:15 AM Paul Wise wrote:
> The attached script provided by Stuart Prescott detects reintroduced
> packages and a loop around `curl | grep -F +rm` detects bugs needing
> triage. I'll attempt to run this and triage bugs when I can.
I made a mistake when running the loop
ian-devel:
anyone have any thoughts on reopening bugs closed by removal
after package reintroduction?
https://lists.debian.org/msgid-search/546c2c3d77eaef6dc2b26c7ed7663f16df847bda.ca...@debian.org
If they're still valid, I don't see why not.
theres no way to know if they are without doing t
On Monday, May 11, 2020 9:25:20 PM EDT Paul Wise wrote:
> > Should we also be triaging the bugs filed against removed versioned
> > source packages like golang-1.9 or python3.6?
>
> No response on this yet.
In cases like this, maintainers that want them moved can do it reasonably
easily. I
On Tue, May 5, 2020 at 7:15 AM Paul Wise wrote:
> Should we be automatically reopening these bugs?
enrico suggested on IRC that we should be doing this.
> Should triaging these bugs be required of maintainers?
enrico suggested on IRC that this seems not unreasonable.
> Does anyone think that
Hi all,
One of the tasks needed when reintroducing packages after they have
been removed is that the bugs that were closed by the removal need to
be triaged and either reopened or version closing information added:
14 matches
Mail list logo
