On 2013-05-05 1:20 PM, Gregory Szorc wrote:
On 5/4/2013 9:59 PM, Justin Dolske wrote:
On 5/1/13 8:41 PM, Ehsan Akhgari wrote:
Another disadvantage of project branches in addition to the ones
mentioned before is that it limits/delays the amount of testing that you
can get on Nightly and from all
On 5/4/2013 9:59 PM, Justin Dolske wrote:
On 5/1/13 8:41 PM, Ehsan Akhgari wrote:
Another disadvantage of project branches in addition to the ones
mentioned before is that it limits/delays the amount of testing that you
can get on Nightly and from all of the developers who run things like
fuzzer
On 5/1/13 8:41 PM, Ehsan Akhgari wrote:
Another disadvantage of project branches in addition to the ones
mentioned before is that it limits/delays the amount of testing that you
can get on Nightly and from all of the developers who run things like
fuzzers on ours code. Not everyone's project has
L. David Baron wrote:
> On Saturday 2013-04-27 08:26 +1000, Nicholas Nethercote wrote:
> > If I have a patch ready to land when inbound closes, what would be
> > the sequence of steps that I need to do to land it on inbound2?
> > Would I need to have an up-to-date inbound2 clone and transplant
> >
> Given the whole point of this thread is about how unreliable inbound is, why
> are people trying to develop against it?
You still need a copy of inbound to rebase your patches against when pushing.
Whatever your personal opinions about git happen to be, I don't think
a "git doesn't need a copy
Ehsan Akhgari wrote:
On 2013-05-02 9:29 AM, Neil wrote:
Ehsan Akhgari wrote:
Multiheaded repos are evil. They're very hard to deal with, and I
don't think that buildbot can deal with them properly. Also, they
cannot be represented in git, which means that they will break the
git mirror.
On 5/3/2013 12:20 AM, Dirkjan Ochtman wrote:
On Fri, May 3, 2013 at 8:43 AM, Ehsan Akhgari wrote:
In git, the only way to have something in your history is for it to be
reachable by a ref (for example, a branch name). When you convert an hg
repo with a multi-headed branch to git, you can only
On 2013-05-03 3:19 AM, Mike Hommey wrote:
On Fri, May 03, 2013 at 02:59:21AM -0400, Ehsan Akhgari wrote:
On 2013-05-03 2:52 AM, Mike Hommey wrote:
On Fri, May 03, 2013 at 02:43:36AM -0400, Ehsan Akhgari wrote:
On 2013-05-02 9:40 AM, Mike Hommey wrote:
On Thu, May 02, 2013 at 09:21:57AM -0400,
On Fri, May 3, 2013 at 8:43 AM, Ehsan Akhgari wrote:
> In git, the only way to have something in your history is for it to be
> reachable by a ref (for example, a branch name). When you convert an hg
> repo with a multi-headed branch to git, you can only choose to represent one
> of those heads b
On Fri, May 03, 2013 at 02:59:21AM -0400, Ehsan Akhgari wrote:
> On 2013-05-03 2:52 AM, Mike Hommey wrote:
> >On Fri, May 03, 2013 at 02:43:36AM -0400, Ehsan Akhgari wrote:
> >>On 2013-05-02 9:40 AM, Mike Hommey wrote:
> >>>On Thu, May 02, 2013 at 09:21:57AM -0400, Ehsan Akhgari wrote:
> Also,
On 2013-05-03 2:52 AM, Mike Hommey wrote:
On Fri, May 03, 2013 at 02:43:36AM -0400, Ehsan Akhgari wrote:
On 2013-05-02 9:40 AM, Mike Hommey wrote:
On Thu, May 02, 2013 at 09:21:57AM -0400, Ehsan Akhgari wrote:
Also, they cannot be represented in git
I doubt this is true. The bridging tools m
On Fri, May 03, 2013 at 02:43:36AM -0400, Ehsan Akhgari wrote:
> On 2013-05-02 9:40 AM, Mike Hommey wrote:
> >On Thu, May 02, 2013 at 09:21:57AM -0400, Ehsan Akhgari wrote:
> >>Also, they cannot be represented in git
> >
> >I doubt this is true. The bridging tools may well not support it, but
> >th
On 2013-05-02 10:58 AM, Boris Zbarsky wrote:
On 5/2/13 10:09 AM, Matt Brubeck wrote:
The suggested workflow
with inbound2 would lead to almost-identical multi-headed repos in
developers' local clones anyway.
Only temporary ones, until inbound and inbound2 merge.
Using multiple mozilla reposi
On 2013-05-02 9:29 AM, Neil wrote:
Ehsan Akhgari wrote:
Multiheaded repos are evil. They're very hard to deal with, and I
don't think that buildbot can deal with them properly. Also, they
cannot be represented in git, which means that they will break the git
mirror.
Why does mozilla-inbound
On 2013-05-02 9:40 AM, Mike Hommey wrote:
On Thu, May 02, 2013 at 09:21:57AM -0400, Ehsan Akhgari wrote:
Also, they cannot be represented in git
I doubt this is true. The bridging tools may well not support it, but
there's nothing structural about multiple-head repository that would
prevent th
On 5/2/13 10:09 AM, Matt Brubeck wrote:
The suggested workflow
with inbound2 would lead to almost-identical multi-headed repos in
developers' local clones anyway.
Only temporary ones, until inbound and inbound2 merge.
-Boris
___
dev-platform mailing
On 5/2/2013 6:21 AM, Ehsan Akhgari wrote:
On 2013-05-02 5:46 AM, Neil wrote:
Why do we need a separate repo? Can we not simply close the broken head
and start again at the last green changeset?
Multiheaded repos are evil. They're very hard to deal with, and I don't
think that buildbot can dea
On Thu, May 02, 2013 at 09:21:57AM -0400, Ehsan Akhgari wrote:
> Also, they cannot be represented in git
I doubt this is true. The bridging tools may well not support it, but
there's nothing structural about multiple-head repository that would
prevent them to be mirrored in git.
Mike
Ehsan Akhgari wrote:
Multiheaded repos are evil. They're very hard to deal with, and I
don't think that buildbot can deal with them properly. Also, they
cannot be represented in git, which means that they will break the git
mirror.
Why does mozilla-inbound need a git mirror?
--
Warning: M
On 2013-05-02 5:46 AM, Neil wrote:
Ryan VanderMeulen wrote:
My proposal:
-Create an inbound2 branch identically configured to mozilla-inbound.
-Under normal circumstances (i.e. m-i open), inbound2 will be CLOSED.
-In the event of a long tree closure, the last green changeset from
m-i will be me
Ryan VanderMeulen wrote:
My proposal:
-Create an inbound2 branch identically configured to mozilla-inbound.
-Under normal circumstances (i.e. m-i open), inbound2 will be CLOSED.
-In the event of a long tree closure, the last green changeset from
m-i will be merged to inbound2 and inbound2 will
Another disadvantage of project branches in addition to the ones
mentioned before is that it limits/delays the amount of testing that you
can get on Nightly and from all of the developers who run things like
fuzzers on ours code. Not everyone's project has enough manpower to get
that level of
On 5/1/2013 2:15 PM, L. David Baron wrote:
On Saturday 2013-04-27 08:26 +1000, Nicholas Nethercote wrote:
On Sat, Apr 27, 2013 at 5:17 AM, Ryan VanderMeulen wrote:
-In the event of a long tree closure, the last green changeset from m-i will
be merged to inbound2 and inbound2 will be opened for
On Saturday 2013-04-27 08:26 +1000, Nicholas Nethercote wrote:
> On Sat, Apr 27, 2013 at 5:17 AM, Ryan VanderMeulen wrote:
> >
> > -In the event of a long tree closure, the last green changeset from m-i will
> > be merged to inbound2 and inbound2 will be opened for checkins.
>
> If I have a patch
On 4/30/2013 11:19 AM, Chris AtLee wrote:
It seems like a tree used by a smaller, more focused group of people
could cope better with leaving some orange on the tree for short periods
of time. Instead of backing out suspect revisions, and closing the tree
to wait for the results of the backout to
On 02:54, Tue, 30 Apr, Justin Lebar wrote:
Is there sanity to this proposal or am I still crazy?
If we had a lot more project branches, wouldn't that increase the load
on infra dramatically, because we'd have less coalescing?
Yes, it would decrease coalescing. I wonder how many tree closures
On 4/30/2013 2:46 AM, Gregory Szorc wrote:
> As a counter-proposal, I propose that we start shifting landings to
> project branches/twigs. We should aim for a small and well-defined set
> of repositories (say 3 to 5) sharing similar automation configuration
> and sheriff love. By keeping the number
On 4/30/13 8:46 AM, Gregory Szorc wrote:
On 4/26/2013 12:17 PM, Ryan VanderMeulen wrote:
Specific goals:
-Offer an alternative branch for developers to push to during extended
inbound closures
-Avoid patch pile-up after inbound re-opens from a long closure
Specific non-goals:
-Reducing infrastr
> Is there sanity to this proposal or am I still crazy?
If we had a lot more project branches, wouldn't that increase the load
on infra dramatically, because we'd have less coalescing?
This is of course a solvable problem, but the fact that the problem
exists suggests to me that your proposal her
On 4/26/2013 12:17 PM, Ryan VanderMeulen wrote:
> Specific goals:
> -Offer an alternative branch for developers to push to during extended
> inbound closures
> -Avoid patch pile-up after inbound re-opens from a long closure
>
> Specific non-goals:
> -Reducing infrastructure load
> -Changing pushing
Multiple inbounds are not a great idea for smarter usage of our infra
capacity or for load balancing, but this proposal doesn't attempt to
address the former and avoids the latter by making the availability of
the two inbounds mutually exclusive, so, it looks good.
I also doubt that it's going
On 4/29/2013 9:32 AM, Boris Zbarsky wrote:
On 4/26/13 6:26 PM, Nicholas Nethercote wrote:
If I have a patch ready to land when inbound closes, what would be the
sequence of steps that I need to do to land it on inbound2?
The following steps assume that the default and default-push for your
re
On 4/26/13 6:26 PM, Nicholas Nethercote wrote:
If I have a patch ready to land when inbound closes, what would be the
sequence of steps that I need to do to land it on inbound2?
The following steps assume that the default and default-push for your
repo are both appropriate versions of inbound
> 3/ Being a git guy, I prefer having a try-like server where you don't get
> push contention or closed tree, because we are creating a new head
> every-time, and let the sheriffs cherry-pick the good changes which are not
> source of conflicts. And ask developers to rebase their changes otherwise
On 04/26/2013 06:11 PM, Matt Brubeck wrote:
On 4/26/2013 4:14 PM, Justin Lebar wrote:
If I have a patch ready to land when inbound closes, what would be the
sequence of steps that I need to do to land it on inbound2? Would I
need to have an up-to-date inbound2 clone and transplant the patch
acr
On 4/26/2013 4:14 PM, Justin Lebar wrote:
If I have a patch ready to land when inbound closes, what would be the
sequence of steps that I need to do to land it on inbound2? Would I
need to have an up-to-date inbound2 clone and transplant the patch
across?
I think mbrubeck or someone knows how
On 4/26/2013 4:14 PM, Justin Lebar wrote:
>> If I have a patch ready to land when inbound closes, what would be the
>> sequence of steps that I need to do to land it on inbound2? Would I
>> need to have an up-to-date inbound2 clone and transplant the patch
>> across?
> Yes, I think so.
>
> I think
> If I have a patch ready to land when inbound closes, what would be the
> sequence of steps that I need to do to land it on inbound2? Would I
> need to have an up-to-date inbound2 clone and transplant the patch
> across?
Yes, I think so.
I think mbrubeck or someone knows how to maintain multipl
hi RyanVM;
I really like this proposal because it gives Mozilla a way for
developers to continue doing checkins even during a prolonged
mozilla-inbound closure. The experiment with birch as "b2g-inbound" has
been really successful so far, which is good.
To easily experiment to see if the proposal
On Sat, Apr 27, 2013 at 5:17 AM, Ryan VanderMeulen wrote:
>
> -In the event of a long tree closure, the last green changeset from m-i will
> be merged to inbound2 and inbound2 will be opened for checkins.
If I have a patch ready to land when inbound closes, what would be the
sequence of steps tha
On Fri, Apr 26, 2013 at 2:16 PM, Kartikaya Gupta wrote:
> Lately I've run into this a few times, where I see regressions on
> areweslimyet.com and dig into it, only to find the regression happened on a
> "merge from m-c" changeset. Since the mobile AWSY only runs on m-i (on the
> theory that I get
My only concern with this is that it increases the difficulty of
bisecting regressions.
Lately I've run into this a few times, where I see regressions on
areweslimyet.com and dig into it, only to find the regression happened
on a "merge from m-c" changeset. Since the mobile AWSY only runs on m
I like that inbound2 would be open only when inbound is closed. That
way you don't have to make a decision wrt which tree to push to.
sgtm.
On Fri, Apr 26, 2013 at 3:17 PM, Ryan VanderMeulen wrote:
> As has been discussed at length in the various infrastructure meetings, one
> common point of f
As has been discussed at length in the various infrastructure meetings,
one common point of frustration for developers is frequent tree closures
due to bustage on inbound. While there are other issues and ideas for
how to improve the inbound bustage situation, one problem I'm seeing is
that mul
44 matches
Mail list logo
