automated bulk github issue creation

[Timo Heister]

Hey all,

while I am very happy to see many static analysis problems to be
reported and fixed, I would like to discuss the bulk creation of
github issues that has happened over the last weeks.

I feel these create unnecessary noise (when browsing issues and in our
email inboxes) that makes it difficult to look at other pullrequests
and issues and as such waste time. I also don't see an advantage over
having a single issue and partially addressing it if it is too much
work to tackle them in a single PR.

Thoughts?

--
Timo Heister
http://www.math.clemson.edu/~heister/

[Wolfgang Bangerth]

On 11/11/2016 02:24 PM, Timo Heister wrote:
> I feel these create unnecessary noise (when browsing issues and in our
> email inboxes) that makes it difficult to look at other pullrequests
> and issues and as such waste time. I also don't see an advantage over
> having a single issue and partially addressing it if it is too much
> work to tackle them in a single PR.
>
> Thoughts?

I feel you pain with the emails -- my apologies for the many you must
have gotten.

Back with the first batch of warnings that @kostyfisik sent around, I
simply didn't see a way for anyone to keep track what has and hasn't
already been fixed. A lot of people helped fix all of these, which I
think would not have happened if we hadn't broken things up into
manageable chunks.

But I may also have been wrong. I'd be happy to consider better
strategies that (i) reduce the email load, (ii) allow to crowd-source
things.

Cheers
W.

--
------------------------------------------------------------------------
Wolfgang Bangerth email: bang...@colostate.edu
www: http://www.math.colostate.edu/~bangerth/

[Matthias Maier]

I just want to share a few numbers:

I received roughly 6000 e-mail notifications from Github for
dealii/dealii over the course of the last 4 months. This amounts to
roughly 50 messages a day (that are generated by any means of activity
on the repository github page).

Currently 500 messages bear the subject line "Static analysis:"


Best,
Matthias

[Denis Davydov]

One could probably break the PVS report into a big TODO list and then check items once someone

addresses a part of the big issue.

Another option is to break them into comments and then one can link to a comment

inside PVS issue, but this would quickly render issue page unusable.

From my point of view -- both are worse than scripting separate sub-issues. 

E-mails can be deleted and issues which are closed don't obscure the view

of opened issues.

Cheers,

Denis.

[Denis Davydov]

One more:  notes in the "Project" screen. But most likely this can't be automated.

[Matthias Maier]

On Fri, Nov 11, 2016, at 23:48 CST, Denis Davydov <davy...@gmail.com> wrote:

> One could probably break the PVS report into a big TODO list and then check
> items once someone
> addresses a part of the big issue.
>
> Another option is to break them into comments and then one can link to a
> comment
> inside PVS issue, but this would quickly render issue page unusable.
>
> From my point of view -- both are worse than scripting separate sub-issues.

Agreed, they are issues after all. We could group a bunch of similar
reports in one issue, though.


Further, we simply have to accept the fact that with 200 open issues you
cannot keep track of them in a single list. But, I find the list per tag
view for issues and prs quite enlightening.

So, I simply suggest that we

- create a separate tag for issues found by static analyzer

- also tag the other 50 open bugs that have no tag at all.

Further, let's think about a bug day to resolve some long outstanding
issues and get that freaking list a bit smaller again.

Best,
Matthias

[Denis Davydov]

> So, I simply suggest that we
>
> - create a separate tag for issues found by static analyzer
>
> - also tag the other 50 open bugs that have no tag at all.

agreed on both accounts.

Best,
Denis.

[Wolfgang Bangerth]

That shouldn't be too complicated. Do you want me to do that retroactively?
It's easy to script.

Best
W>

[Wolfgang Bangerth]

On 11/12/2016 11:14 AM, Matthias Maier wrote:
> Further, let's think about a bug day to resolve some long outstanding
> issues and get that freaking list a bit smaller again.

Agreed.

What do people think about a couple of days in the first half of January?
Maybe in the first week of January, and then bring out a release right after?

[Daniel Arndt]

What do people think about a couple of days in the first half of January?
Maybe in the first week of January, and then bring out a release right after?

Sounds good.

Best,
Daniel

[Matthias Maier]

> Agreed.
>
> What do people think about a couple of days in the first half of
> January? Maybe in the first week of January, and then bring out a
> release right after?

I'm in.

[Denis Davydov]

On Saturday, November 12, 2016 at 11:16:23 PM UTC+1, Wolfgang Bangerth wrote:

On 11/12/2016 11:39 AM, Denis Davydov wrote:
>> > So, I simply suggest that we
>> >
>> > - create a separate tag for issues found by static analyzer
>> >
>> > - also tag the other 50 open bugs that have no tag at all.
> agreed on both accounts.

That shouldn't be too complicated. Do you want me to do that retroactively?
It's easy to script.

If you know an easy way to script this, please go ahead. At least for opened issues it would be helpful.

Cheers,

Denis.

[Wolfgang Bangerth]

On 11/14/2016 01:17 AM, Denis Davydov wrote:
>
> If you know an easy way to script this, please go ahead. At least for opened
> issues it would be helpful.

I could easily do this with the ghi script, but on second thought:
- We only have a couple of issues left
- I already find the list of labels too long, and adding another label
for something we're not likely going to use on a regular basis seems
like the wrong direction to go. I'll reconsider if we do this
exercise on a semi-regular basis.

Best
W.

[Denis Davydov]

> On 14 Nov 2016, at 15:31, Wolfgang Bangerth <bang...@colostate.edu> wrote:
>
> On 11/14/2016 01:17 AM, Denis Davydov wrote:
>>
>> If you know an easy way to script this, please go ahead. At least for opened
>> issues it would be helpful.
>
> I could easily do this with the ghi script, but on second thought:
> - We only have a couple of issues left
> - I already find the list of labels too long, and adding another label
> for something we're not likely going to use on a regular basis seems
> like the wrong direction to go. I'll reconsider if we do this
> exercise on a semi-regular basis.

fair enough.

Cheers,
Denis.