Yes, having "issues" and "pull requests" separated is a huge change to the way things are handled on trac. Naturally there are advantages and disadvantages for both approaches. In the github world, issues are treated more as a list of open tasks and are usually more user-focused. For example, a user proposing a new feature or reporting a bug. This is reflected in that the discussion in an issue is largely on a meta-level. For example, discussing weather the proposed feature is actually needed or fit into the roadmap of the project; or for bugs outline how it can be reproduced. Discussions in pull requests on the other hand revolve more around the proposed implementation, code style and other such feedback.
Misstyping an issue reference is not very common on github since it provides a nice auto-completion / hover functionality that displays the full name of the referenced issue or pull request. On Tuesday, 13 September 2022 at 07:25:57 UTC+2 Travis Scrimshaw wrote: > >> The downside (that will always remain to me) with GH/GL is anything with >>> their web interface is highly decentralized, >>> >> >> No, no such thing. >> > > The fact that PRs and issues are on two completely different pages is > already decentralized. There is no clear single place for discussion, with > multiple PRs that can have their own threads. > >> >> >>> whereas with trac, things are highly concentrated on tickets, which are >>> a single point of reference. Using the GH/GL model, we have all of these >>> forks >>> >> >> Irrelevant because in the proposed workflow you never look at another >> developer's fork. >> > > This is not true. You do not have a central point for branch access. Now > because of PRs that get attached to the main project, they do become > centralized. However, I cannot easily share or get a branch from another > developer that is not linked by a PR. > >> >> (which we have to tell newbies are not the same as branches and should >>> not be used as such). >>> >> There is also more manual things we have to type and sync subject to >>> human (typo) error. This is likely manageable to me compared to some of the >>> other benefits (although I will personally experience none of those). >>> Despite this, I still have reservations about the increased pains of >>> development from trying to fit a mostly square peg into a round hole, and >>> subsequently am still opposed to the move >>> >> >> Sorry, this is just a rant based on nothing >> > > Matthias, your dismissive attitude is not helpful. I am even starting to > come around that this move could have benefits that outweigh the costs. > > The linking of issues to PRs is something that a human has to manually > type in, right? (Just today I mistyped a ticket number on trac.) For trac > tickets, you would have had to not realized you were on the wrong page, > which is far less subtle. My opposition also based on how easy it is to > share and manage different branches and communication of things involving a > single issue. > > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/a932a629-9b04-4eb2-be22-5c55ac9c886dn%40googlegroups.com.
