> > > This will be a pain to manage. These branches will go stale very quickly > > and rebasing will be a frustrating chore. If you have programs that you > > don't want to install in sage proper, then just maintain them as a > > python package with sage as a dependency and put the source on github if > > you like. Then you don't get bogged down by the sage development process > > at all. In this form it will also be much easier to combine it with > > other such features (without having to merge branches). > > +1. If you have a branch that you don't want to be merged in Sage, don't > put it on the Sage trac. This looks more in the scope of a separate > package, which can be a Sage optional package. >
Ok for a branch that is not to be merged. For a branch that is to be merged, but is not going into the review process anytime soon, you suggest to keep it in "new" status or "needs_review" with a comment "just for a patchbot". I think neither of the two status is appropriate. I suggested "needs_feedback" as a status for the ticket with working code that needs attention of patchbots and interested people. This will not disrupt our review system as we have now, except sharing patchbot resources. But I will not insist on this anymore, as I am not sure if there will be many such sage-feature tickets and thus it may "complicate things for something that would likely not be used", as Travis and Nils said. -- 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.
