Replying to an old thread I realized I'd starred... On Thu, May 29, 2014 at 6:48 PM, kcrisman <kcris...@gmail.com> wrote: > Well, I am thankful that my rant led to some pretty substantive discussion. > Here let me summarize some thoughts. > > A) +1 to having something where a github-like editing thing works. I've > used this at least once with matplotlib. My beef with github is orthogonal > to the web interface piece. If there is a good workflow where we can direct > contributors to make smaller edits on the github mirror and they'll be taken > care of, that's great.
All pull requests on github turn into tickets, so this easy web interface flow works now. > B) I didn't realize that the "release manager" commits were separate from > the "author" ones. That is strange to me, but I guess it's there. > Nonetheless, I think that the vast majority of ticket descriptions are (or > at least start as) fairly half-baked notions of what could be added or > fixed, and are entirely inappropriate for a commit message to siphon through > in "git log". Especially since they are so long compared to most commit > messages (and not for good reasons). This is an awareness issue--ticket descriptions should be well written descriptions of what's in the ticket, and now there's further motivation to do so as they're also stored in the git log when the ticket in question is closed. > C) I haven't heard any -1's to "Merged in" being resuscitated, so maybe that > should really happen. > > [More thoughts: Robert B: I think Travis' point about doing it near the > release time is so that people know where to start from. My whole trouble > earlier today ended up being because, since it said closed, I assumed the > Maxima upgrade HAD to be in the latest beta - which it wasn't. And several > "git pull" attempts in my develop branch did nothing, since develop is still > at 6.3.beta2 as of this writing (on github at least). As it turned out, it > wasn't based on the right ticket, so I guess that could have been "needs > work", but it *says* "Depends on #13973" so in the old workflow that should > have been enough (install #13973, then install this one). I feel like this > is closely related.] You can still have "depends on." The nice thing is that if you merge a depends on that's already in it's a no-op. > D) Patchbot? What patchbot? At least the colorings aren't working right > now, it seems. But I would love to trust that again and not have to rebuild > trivial things. Just checked, it's still up. There may eventually be a replacement, but if you want tickets to get updated faster, run a patchbot client on your own machine. (You can even configure it to test your tickets/favorite category first.) > E) Please everyone let's put Trac #s back in the commit messages, then, if > the immutability is a barrier there. Some of the most recent ones are > completely mystifying. And then it will be possible to figure out where the > new code IS in the tree, as opposed to just the merges which can be > patchbombs. > > -- > 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 http://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. -- 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 http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
