Jesse Ruderman Reporter
	Description • 12 years ago

1. Push your mq of 4 changesets to Try
2. Look at https://tbpl.mozilla.org/?tree=Try

Result:
* If you recently rebased, it looks like you pushed "too many" changesets.
* If you recently Try'd part of the queue, it looks like you pushed "too few".

This leads to developer confusion about what was actually tested.

Here's what I think TBPL should do:
* Guess the developer's qbase by finding the most recent changeset that also exists in mozilla-central or mozilla-inbound.
* Show all changesets atop the guessed qbase, followed by the qbase with opacity: 0.2.

	Avi Halachmi (:avih)
	Comment 1 • 11 years ago

Suggesting a possibly simpler, more manual solution to the same problem:

- TBPL should support a URL argument, for instance |&log=NN| where NN is the number of parents to display. This would make it relatively easy to post URLs which represent and display the correct patch sequence which is being tested.

- We could later add an input field just below the series of displayed changesets which will display the current number of displayed sets, and modifying it would result in reload with updated URL which includes the new length.

Until we have a solution for this, this can be solved by |hg qpop -a| followed by |hg qgo NN| to return to the same position within the queue, but all the changesets will be new (new push date), which will result in all of them displayed on TBPL.

	Ed Morley [:emorley]
	Comment 2 • 9 years ago

TBPL is EOL, & bundle-try will make this go away :-)