Dear Perry, On 30 April 2018 at 18:16, Perry E. Metzger wrote: > So I started looking over the Trac tickets a few days ago.
Thanks a lot for taking the initiative for this. Below are some of my thoughts. One thing I really dislike about many projects is that one sometimes spends quite a while trying to submit a reasonable report with minimum-failing example. It might have started with a long discussion, but you don't know how to fix the problem (or cannot, in case of bugs in Apple's frameworks), you keep being stuck with the problem and then out of the blue upstream or Apple closes the ticket. Just because nobody commented for a certain amount of time. They close the ticket, "problem solved and gone". I totally hate having 3-5k tickets open, but I equally hate the idea of closing them all just because they are old. In my opinion what we really need is a clear way to distinguish between tickets that could really benefit from immediate attention and tickets that we cannot address, but don't explicitly close either. Something like a "stale" state? I would really like to see tickets ending up in a special state that's neither open nor closed, but something inbetween. Say that gcc keeps segfaulting which prevents building a particular port A on PPC. Someone submits a ticket upstream, none of us knows how to fix the issue. We could label it "upstream" (potentially along with a few other labels like "if we want to solve this, we need additional help") and move the ticket to that special state. When the user searches for tickets related to port A, we could even show two queries or allow an extended query showing tickets from both states (open or stale). It would be immediately clear that there is a known issues for which we lack the expertise to fix, and it would be a clear sign that none of us is planning to work on it in some near future, but that we would be super happy to accept patches. Another example would be most of the "port requests" that have not seen any activity for N years. If we didn't respond to a request for a number of years, it's unlikely that the user who requested the port would still benefit from the addition and there might not even be any other user interested in that port. To me, seeing a port request closed as "won't fix" is sending a signal that writing a patch for such a port, even if I have time and motivation to do it at a later point, is not even desired. One question is, if some user opens a ticket saying that a certain piece of software needs to be updated and nobody does anything for 4 years (fontforge is an example of such a port which was recently picked up by someone): what would you do with such a ticket? And what would you do with some real bugs in macports base which nobody knows how to fix? Things that can really make a difference is a bunch of small things like the recent addition of list of personal tickets that automatically get displayed to logged in users. To remind users and developers. My bet would be that Chris Jones must have closed some 10+ tickets as a consequence of this change :) We have various categories of tickets. One example of such a "category" are tickets like "please add cmake.build_out_of_source yes", "github projects with different checksums", "upgrade all ports to perl5.28", "upgrade all ports to python 2.7 and 3.6", "figure out what to do with google code projects", ... tickets that are completely straightforward, easy to handle even for newbies, it's just that it takes forever to solve them because the number of ports that need a change is relatively large. If we could add more "metadata" to tickets to filter our difficult challerges and easy tasks for beginners, this would definitely help. Mojca
