On Tue, Jul 12, 2016 at 01:15:44AM -0400, Boris Zbarsky wrote:
> On 7/12/16 1:02 AM, Mike Hommey wrote:
> > The envisioned workflow is that you don't rebase on inbound to push,
> > since autoland handles the landing for you. So you can keep your tree as
> > it was before you wanted to land.
>
> OK
On 7/12/16 1:02 AM, Mike Hommey wrote:
The envisioned workflow is that you don't rebase on inbound to push,
since autoland handles the landing for you. So you can keep your tree as
it was before you wanted to land.
OK, what about the case when A was not authored by me? What's the
expected fre
On Mon, Jul 11, 2016 at 11:11:22PM -0400, Boris Zbarsky wrote:
> On 7/11/16 10:10 PM, Gregory Szorc wrote:
> > I recommend not developing on top of inbound (or fx-team or autoland)
> > and instead basing all work on central because:
>
> This recommendation only works if your patches never depend o
On 7/11/16 10:10 PM, Gregory Szorc wrote:
I recommend not developing on top of inbound (or fx-team or autoland)
and instead basing all work on central because:
This recommendation only works if your patches never depend on your own
patches or on patches written by others you're working with, a
On Mon, Jul 11, 2016 at 6:53 PM, Nicholas Nethercote wrote:
> On Tue, Jul 12, 2016 at 2:27 AM, Jonathan Griffin
> wrote:
> >
> > 2 - people sometimes push to try from bad heads (like a mozilla-inbound
> push
> > that will eventually get backed out)
> >
> > For 2, making sure you push to try only
Docs might be useful, but they won't cover all cases. Sometimes you
get certain failures that only show up for a short time due to infra
weirdness. I often find myself asking on IRC if a particular kind of
failure is known, and often the answer is a variation on "yes, that's
just been happening rec
On Tue, Jul 12, 2016 at 2:27 AM, Jonathan Griffin wrote:
>
> 2 - people sometimes push to try from bad heads (like a mozilla-inbound push
> that will eventually get backed out)
>
> For 2, making sure you push to try only from the current tip of m-c will
> avoid this problem, or using MozReview's a
I think what you're asking for is a description of what sheriffs do when
reviewing a push, so you can do it yourself for your own try push.
Sheriffs, do we have any such documentation?
On Mon, Jul 11, 2016 at 11:30 AM, allassopraise .
wrote:
> The suggestions for improving the way treeherder rep
The suggestions for improving the way treeherder reports are good.
Nevertheless, for now, I still would like some documentation or
pointers on how to interpret what is there, but most especially how to
know whether an error is due to the changeset that's been pushed.
*Somebody* is obviously able
Yes, a clear Yes/No answer for Try pushes is something we'd like to be able
to report.
Currently, interpreting Try results can be hard for a few reasons:
1 - intermittent test failures make it hard to separate failures your push
has caused vs pre-existing failures
2 - people sometimes push to try
Nicolas B. Pierron wrote:
On 07/10/2016 06:48 PM, allassopraise . wrote:
For example, I believe the orange and red links indicate an error, but
how do I know if they pertain to my push or not?
I have the same issue, and in many cases I feel clueless about the
oranges & reds. At the end I end-
On 07/10/2016 06:48 PM, allassopraise . wrote:
For example, I believe the orange and red links indicate an error, but
how do I know if they pertain to my push or not?
I have the same issue, and in many cases I feel clueless about the oranges &
reds. At the end I end-up pushing to inbound, eve
12 matches
Mail list logo
