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.
On 12/09/2017 18:28, Maarten Derickx wrote:
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.
On Tuesday, 12 September 2017 15:34:11 UTC+2, vdelecroix wrote:
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
On 11/09/2017 18:59, Maarten Derickx 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?
Thanks,
Maarten
p.s. Tips on how to search for tickets on trac are welcome!
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
