Patchbot failures metaticket

[Maarten Derickx]

Hi all,

During the recent writing of new code and reviewing I got annoyed that it costs really a lot of effort for me to see if there was already a ticket for a certain patchbot failure. I therefore decided to create a metaticket that should serve as an overview of all currently known patchbot failures. It can be found here:

https://trac.sagemath.org/ticket/23832

I think that all patchbot failure tickets should automatically deserve the status critical. Since patchbot failures make sage development and reviewing way more troublesome. Are there any other people with an opinion on this?

Thanks,

Maarten

p.s. Tips on how to search for tickets on trac are welcome!

[David Roe]

On Mon, Sep 11, 2017 at 12:59 PM, Maarten Derickx <m.derick...@gmail.com> wrote:

Hi all,

During the recent writing of new code and reviewing I got annoyed that it costs really a lot of effort for me to see if there was already a ticket for a certain patchbot failure. I therefore decided to create a metaticket that should serve as an overview of all currently known patchbot failures. It can be found here:

https://trac.sagemath.org/ticket/23832

I think that all patchbot failure tickets should automatically deserve the status critical. Since patchbot failures make sage development and reviewing way more troublesome. Are there any other people with an opinion on this?

That's a great idea, and I agree that patchbot failures should be marked as critical.  I see that you added a link to the metaticket on the front page; I've updated it with a brief description of what the patchbot does for newcomers.

David

[Samuel Lelievre]

Mon 2017-09-11 16:59:48 UTC, Maarten Derickx:

> p.s. Tips on how to search for tickets on trac are welcome!

Trac has both a search feature and a (much more powerful) query feature:

- https://trac.sagemath.org/search

- https://trac.sagemath.org/query

See some examples of using the query feature at

https://wiki.sagemath.org/slelievre#Some_Sage_trac_queries_and_tickets

[Jeroen Demeyer]

On 2017-09-11 18:59, Maarten Derickx wrote:
> I think that all patchbot failure tickets should automatically deserve
> the status critical.

They should be blockers (unless the error comes from a broken patchbot).

> p.s. Tips on how to search for tickets on trac are welcome!

Google

site:trac.sagemath.org elliptic curves

The only annoying thing with Google is that it tends to prefer old pages
for bugs which are fixed long ago.

[Vincent Delecroix]

On 12/09/2017 12:23, Jeroen Demeyer wrote:
> On 2017-09-11 18:59, Maarten Derickx wrote:
>> I think that all patchbot failure tickets should automatically deserve
>> the status critical.
>
> They should be blockers (unless the error comes from a broken patchbot).

+1

>> p.s. Tips on how to search for tickets on trac are welcome!
>
> Google
>
> site:trac.sagemath.org elliptic curves
>
> The only annoying thing with Google is that it tends to prefer old pages
> for bugs which are fixed long ago.

Or possibly, we could use the tag "patchbot" and hence a very simple
trac query.

[Vincent Delecroix]

Hi,

I think a meta-ticket is a complete burden to maintain. And as already
said in other mails, this identification should be done by other means.

Vincent

[Maarten Derickx]

Hi Vincent,

I think "a complete burden" is highly exaggerated, there should not be a new patchbot ticket to often. And if someone has to create a ticket then just copy pasting the failing files and the ticket number to the ticket description should not be to much work.

As for removing old stuff I am totally happy to volunteer as a maintainer of the ticket so that failures for old beta's and other releases are removed from time to time.

The ticket also has some benefits, namely you see a nice overview of all the files affected, so this will make checking wether the files for which you currently have a patchbot failing way faster then clicking on all the results of a trac query.

As a summary your solution would make writing new tickets easier, and the current solution makes checking wether a ticket exists easier. Since the latter will happen way more often I think the benefits outweigh the costs.

[Vincent Delecroix]

Hi Marteen,

"complete burden" = "each release". So precisely, we need somebody to
volunteer to maintain this list. I already hardly find the energy to
fill a ticket for the reasons why my patchbot is not working any more at
each new release (including the fact that I need to search for a
reason). In case I know the problem, I just send an e-mail on
sage-release and in case I find the answer (or somebody finds it) I
disable explicitely the package on my patchbot. Here is the list of 11
broken optional packages on quasar

# deformation:
https://groups.google.com/forum/#!topic/sage-devel/gEFC-ZwtAGU
# normaliz: https://trac.sagemath.org/ticket/23586
# giac: https://groups.google.com/forum/#!topic/sage-devel/QMfm3NOBZaI
# polytopes_db:
https://groups.google.com/forum/#!topic/sage-devel/KI0qtg1kYoA
# cbc: https://trac.sagemath.org/ticket/22006
# gap_packages, database_gap: https://trac.sagemath.org/ticket/22576
# qepcad: https://trac.sagemath.org/ticket/22851
# database_cremona_ellcurve: https://trac.sagemath.org/ticket/23840
# libtheora??
# sip: https://groups.google.com/forum/#!topic/sage-devel/Jc-5u9YslkI
# openblas is not used anywhere

Though in an ideal world
- tickets should not be merged if any patchbot is not happy with it
- patchbot should also be identified with its set of optional packages
installed (for now the server does not make any distinction)
- patchbot should test tickets upgrading an optional package

Best
Vincent

PS: thank you for willing to work on this. People do not seem to care so
much about failing doctests due to installation of optional packages.

[Maarten Derickx]

Hi Vincent,

Thanks for pointing out the point of view from a patchbot maintainer, my statement "I think a complete burden is highly exaggerated" was made from my perspective as a developer not knowing how this looks from a patchbot maintainer point of view. And I can see that having to deal with this every release instead of just when you are taking time to write or review tickets can be a complete burden. I think we should try to find a solution that makes both developers and patchbot mainainers happy. Any solution that would make people who volunteer to run a patchbot stop doing so because it creates a to high burden is clearly no solution.

[Maarten Derickx]

On Tuesday, 12 September 2017 18:43:00 UTC+2, vdelecroix wrote:

Hi Marteen,

Though in an ideal world
  - tickets should not be merged if any patchbot is not happy with it

Hi looked a bit more into this stuff and I think that the main reason why this happens is that even though we have a lot of patchbots with a lot of optional packages, we do not have a buildbot with optional packages. So I think that a lot of the current problems can be significantly reduced if we manage to setup a buildbot that runs all tests with all optional packages installed.

But I think a strict requirement for a buildbot to be added is that is should pass all tests, so as an intermediate step we should setup one using all currently working optional packages. I'm now doing my best to generate a large list of packages passing al doctest.