Notification if a branch gets merge conflicts (changes form "green" to "red")

[Wilfried Lübbe]

Recently I had a ticket waiting for review. The branch merged cleanly with develop.

As the develop branch moved to Sage-6.3.beta1 merge conflicts emerged (pun intended ;-): the branch color had changed from green to red. I learned this more or less by chance.

Would it be possible to reveive an email notification when the color changes to red (like for other changes of the ticket)?

Wilfried

[Ralf Stephan]

And set the ticket to needs-work, *beg*...

[Travis Scrimshaw]

Please don't. It's something that will need to be done before positive review, but because we're using git, the branch can still be reviewed (especially because relatively trivial merge conflicts).

Best,

Travis

[leif]

Ralf Stephan wrote:
> On Friday, May 16, 2014 1:19:08 PM UTC+2, Wilfried Lübbe wrote:
> > Would it be possible to reveive an email notification when the color changes to red (like for other changes of the ticket)?

> And set the ticket to needs-work, *beg*...

Alternatively, introduce another trac ticket field, or just fill "Work
issues"...


-leif

--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail

[R. Andrew Ohana]

Well it is a bit different than other changes, since nothing actually changes in the ticket itself (which would prompt a notification). Rather the plugin is just a special render for the branch field, so the merge is not actually checked until someone actually loads the page for the first time (results of the merge are cached in the trac database until invalidated).

If something along these lines were added, it would have to be in the release management scripts (potentially coupled with a xmlrpc interface to the trac plugin).

[leif]

Yep. But any bot able to comment on tickets (or to send mail) could
presumably trigger a recheck when the default milestone changes (i.e.,
upon a release), and hence indirectly (or directly) notify the involved
people if a branch no longer applies.

[How exactly does the cache entry get invalidated? Does is just expire?]

[R. Andrew Ohana]

When the head of the develop branch moves, or the plugin can't find the relevant commit (most likely due to git garbage collecting unreferenced commits). If you're really curious, the relevant code: https://github.com/sagemath/sage_trac_plugin/blob/master/sage_trac/git_merger.py.

-leif

--
() The ASCII Ribbon Campaign
/\   Help Cure HTML E-Mail

--
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+unsubscribe@googlegroups.com.
To post to this group, send email to sage-...@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.

--

Andrew

[Nathann Cohen]

And set the ticket to needs-work, *beg*...

You also have to consider that setting tickets to needs_work when there is nobody to review them creates a LOT of (potentially useless) work.

No offense intended, but you set something like 4-5 of my branches to needs_work yesterday, I fixed them right afterwards, and because there is nobody to review the tickets, the branches will just stay there and be broken again by a later version of Sage.

Aaaaaaaand if we have to rebase them for each version of Sage only to wait for somebody to come and review them, it will really require a lot of useless work.

While waiting for a reviewer to come and say "this ticket needs to be rebased" only makes us fix conflicts when there is a point.

Most of the time, by the way, the code can be read and understood by the reviewer while the author rebases the branch. So there is no time loss there that I fear.

Nathann 

[Ralf Stephan]

I don't care wrt patchbot. ApplyFailed with patchbot is cheap.

Ah, we could ignore testing tickets that have failed to apply once.

However, as you know, reviewing is a scarce resource, and scaring reviewers with a conflicting

patch is not nice. Also, having a reliable label that shows the author cares would help.

--
You received this message because you are subscribed to a topic in the Google Groups "sage-devel" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/sage-devel/vXK5K1IkQik/unsubscribe.
To unsubscribe from this group and all its topics, send an email to sage-devel+...@googlegroups.com.

[Nathann Cohen]

> I don't care wrt patchbot. ApplyFailed with patchbot is cheap.
> Ah, we could ignore testing tickets that have failed to apply once.
>
> However, as you know, reviewing is a scarce resource, and scaring reviewers
> with a conflicting
> patch is not nice. Also, having a reliable label that shows the author cares
> would help.

Well, I show that I care by merging them as soon as you set my ticket
to needs_work. But it took me quite some time, and my tickets are
still in needs_review.

Nathann