Re: Canonical cinnabar repository

[Ehsan Akhgari]

On 09/18/2017 03:30 PM, Bobby Holley wrote:
CVS history feels like an odd bar for cinnabar. The goal of cinnabar 
is to enable seamless integration between git and mercurial with 
reproducible, 1:1 commit mappings. Our canonical mercurial 
repositories don't have CVS history, so we shouldn't expect the 
cinnabar clones of those repositories to have CVS history either.
FWIW the question here is moving from a canonical repository with CVS 
history to one without.


Really, we should think of gecko-dev as an entirely different tool 
that provides full history at the cost of being read-only with respect 
to our canonical repositories. Personally, I prefer to use a cinnabar 
clone for a first-class pull/push repo experience, and using searchfox 
whenever I want to see pre-2008 blame.
Searchfox is great, and I use it a lot, but for me the CVS history in 
the repository is valuable because it integrates with my text editor, so 
I can also use it as I'm editing the code without switching to Searchfox 
and figure out where the unedited line of code comes from.




bholley

On Mon, Sep 18, 2017 at 11:35 AM, Jeff Muizelaar 
> wrote:


FWIW, https://github.com/jrmuizel/gecko-cinnabar
 doesn't have the CVS
history so is no better than https://github.com/mozilla/gecko
. Having
a canonical repo that includes the CVS history will make the SHA's
incompatible with doing a direct conversion of hg which is a
disadvantage. I'm not sure what's more valuable.

-Jeff

On Mon, Sep 18, 2017 at 2:21 PM, Ehsan Akhgari
> wrote:
> On 09/18/2017 01:16 PM, Bobby Holley wrote:
>>
>> On Mon, Sep 18, 2017 at 8:25 AM, Andrew McCreight
>
>> wrote:
>>
>>> On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta
>
>>> wrote:
>>>
 I've tried using cinnabar a couple of times now and the last
time I
 tried, this was the dealbreaker for me. My worfklow often
involves
 moving a branch from one machine to another and the extra
hassle that
 results from mismatched SHAs makes it much more complicated
than it
 needs to be. gecko-dev doesn't have this problem as it has a
canonical
 upstream that works much more like a regular git user expects.

>>> For what it is worth, I regularly pull from one machine to
another with
>>> git-cinnabar, and it works just fine without any problems from
mismatched
>>> SHAs. For me, the switch from a clone of gecko-dev to
git-cinnabar has
>>> been
>>> totally transparent.
>>>
>> +1. The non-stable SHA problem was solved a long time ago. Same
goes for
>> any big performance issues. In my experience, cinnabar is
pretty darn
>> transparent.
>>
>> https://github.com/mozilla/gecko
 is effectively the canonical
repo people
>> are talking about. I sometimes pull that, but git-cinnabar is
fast enough
>> that it works fine to just clone the hg repo directly. If it
weren't for
>> the occasional annoyance of mapping commits between local revs
and hg.m.o
>> links, I would basically forget that the core infrastructure is
running
>> hg.
>
> That repo doesn't have the CVS history.  :-(  I realize that is
fixable with
> a local graft and a clone of gecko-dev, but a lot of blood and
sweat went
> into making our current canonical git repo include the full CVS
history (I
> maintained it myself for ~3 years and a lot of people spent
quite a bit of
> time and energy to stand up the current infrastructure that
maintains
> gecko-dev.)  Would it be possible to base the canonical
git-cinnabar repo on
> https://github.com/jrmuizel/gecko-cinnhabar
 which does have the
full CVS
> history?
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-platform





___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Ehsan Akhgari]

On 09/18/2017 02:35 PM, Jeff Muizelaar wrote:

FWIW, https://github.com/jrmuizel/gecko-cinnabar doesn't have the CVS
history so is no better than https://github.com/mozilla/gecko.


Right.  Jeff corrected my confusion on IRC.  His repo has both lines of 
history, and the cinnabar conversion is on the cinnabar branch without 
the CVS history.



Having
a canonical repo that includes the CVS history will make the SHA's
incompatible with doing a direct conversion of hg which is a
disadvantage. I'm not sure what's more valuable.
I think there is a way to have our cake and eat it too, which is 
enabling git-cinnabar to understand a custom mapping of SHA1 so that we 
can rewrite the history and have cinnabar be able to deal with that when 
it maps hg/git revisions to each other.


It is difficult for me to compare these two things and say which is more 
valuable, but it seems like a very bad choice to have to choose one of 
these two alternatives.  The CVS history is extremely valuable to people 
dealing with code that still has a lot of its root back in the old 
days.  Losing it seems like a step backwards to me.




-Jeff

On Mon, Sep 18, 2017 at 2:21 PM, Ehsan Akhgari  wrote:

On 09/18/2017 01:16 PM, Bobby Holley wrote:

On Mon, Sep 18, 2017 at 8:25 AM, Andrew McCreight 
wrote:


On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta 
wrote:


I've tried using cinnabar a couple of times now and the last time I
tried, this was the dealbreaker for me. My worfklow often involves
moving a branch from one machine to another and the extra hassle that
results from mismatched SHAs makes it much more complicated than it
needs to be. gecko-dev doesn't have this problem as it has a canonical
upstream that works much more like a regular git user expects.


For what it is worth, I regularly pull from one machine to another with
git-cinnabar, and it works just fine without any problems from mismatched
SHAs. For me, the switch from a clone of gecko-dev to git-cinnabar has
been
totally transparent.


+1. The non-stable SHA problem was solved a long time ago. Same goes for
any big performance issues. In my experience, cinnabar is pretty darn
transparent.

https://github.com/mozilla/gecko is effectively the canonical repo people
are talking about. I sometimes pull that, but git-cinnabar is fast enough
that it works fine to just clone the hg repo directly. If it weren't for
the occasional annoyance of mapping commits between local revs and hg.m.o
links, I would basically forget that the core infrastructure is running
hg.

That repo doesn't have the CVS history.  :-(  I realize that is fixable with
a local graft and a clone of gecko-dev, but a lot of blood and sweat went
into making our current canonical git repo include the full CVS history (I
maintained it myself for ~3 years and a lot of people spent quite a bit of
time and energy to stand up the current infrastructure that maintains
gecko-dev.)  Would it be possible to base the canonical git-cinnabar repo on
https://github.com/jrmuizel/gecko-cinnhabar which does have the full CVS
history?

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Bobby Holley]

CVS history feels like an odd bar for cinnabar. The goal of cinnabar is to
enable seamless integration between git and mercurial with reproducible,
1:1 commit mappings. Our canonical mercurial repositories don't have CVS
history, so we shouldn't expect the cinnabar clones of those repositories
to have CVS history either.

Really, we should think of gecko-dev as an entirely different tool that
provides full history at the cost of being read-only with respect to our
canonical repositories. Personally, I prefer to use a cinnabar clone for a
first-class pull/push repo experience, and using searchfox whenever I want
to see pre-2008 blame.

bholley

On Mon, Sep 18, 2017 at 11:35 AM, Jeff Muizelaar 
wrote:

> FWIW, https://github.com/jrmuizel/gecko-cinnabar doesn't have the CVS
> history so is no better than https://github.com/mozilla/gecko. Having
> a canonical repo that includes the CVS history will make the SHA's
> incompatible with doing a direct conversion of hg which is a
> disadvantage. I'm not sure what's more valuable.
>
> -Jeff
>
> On Mon, Sep 18, 2017 at 2:21 PM, Ehsan Akhgari 
> wrote:
> > On 09/18/2017 01:16 PM, Bobby Holley wrote:
> >>
> >> On Mon, Sep 18, 2017 at 8:25 AM, Andrew McCreight <
> amccrei...@mozilla.com>
> >> wrote:
> >>
> >>> On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta 
> >>> wrote:
> >>>
>  I've tried using cinnabar a couple of times now and the last time I
>  tried, this was the dealbreaker for me. My worfklow often involves
>  moving a branch from one machine to another and the extra hassle that
>  results from mismatched SHAs makes it much more complicated than it
>  needs to be. gecko-dev doesn't have this problem as it has a canonical
>  upstream that works much more like a regular git user expects.
> 
> >>> For what it is worth, I regularly pull from one machine to another with
> >>> git-cinnabar, and it works just fine without any problems from
> mismatched
> >>> SHAs. For me, the switch from a clone of gecko-dev to git-cinnabar has
> >>> been
> >>> totally transparent.
> >>>
> >> +1. The non-stable SHA problem was solved a long time ago. Same goes for
> >> any big performance issues. In my experience, cinnabar is pretty darn
> >> transparent.
> >>
> >> https://github.com/mozilla/gecko is effectively the canonical repo
> people
> >> are talking about. I sometimes pull that, but git-cinnabar is fast
> enough
> >> that it works fine to just clone the hg repo directly. If it weren't for
> >> the occasional annoyance of mapping commits between local revs and
> hg.m.o
> >> links, I would basically forget that the core infrastructure is running
> >> hg.
> >
> > That repo doesn't have the CVS history.  :-(  I realize that is fixable
> with
> > a local graft and a clone of gecko-dev, but a lot of blood and sweat went
> > into making our current canonical git repo include the full CVS history
> (I
> > maintained it myself for ~3 years and a lot of people spent quite a bit
> of
> > time and energy to stand up the current infrastructure that maintains
> > gecko-dev.)  Would it be possible to base the canonical git-cinnabar
> repo on
> > https://github.com/jrmuizel/gecko-cinnhabar which does have the full CVS
> > history?
> >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Jeff Muizelaar]

FWIW, https://github.com/jrmuizel/gecko-cinnabar doesn't have the CVS
history so is no better than https://github.com/mozilla/gecko. Having
a canonical repo that includes the CVS history will make the SHA's
incompatible with doing a direct conversion of hg which is a
disadvantage. I'm not sure what's more valuable.

-Jeff

On Mon, Sep 18, 2017 at 2:21 PM, Ehsan Akhgari  wrote:
> On 09/18/2017 01:16 PM, Bobby Holley wrote:
>>
>> On Mon, Sep 18, 2017 at 8:25 AM, Andrew McCreight 
>> wrote:
>>
>>> On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta 
>>> wrote:
>>>
 I've tried using cinnabar a couple of times now and the last time I
 tried, this was the dealbreaker for me. My worfklow often involves
 moving a branch from one machine to another and the extra hassle that
 results from mismatched SHAs makes it much more complicated than it
 needs to be. gecko-dev doesn't have this problem as it has a canonical
 upstream that works much more like a regular git user expects.

>>> For what it is worth, I regularly pull from one machine to another with
>>> git-cinnabar, and it works just fine without any problems from mismatched
>>> SHAs. For me, the switch from a clone of gecko-dev to git-cinnabar has
>>> been
>>> totally transparent.
>>>
>> +1. The non-stable SHA problem was solved a long time ago. Same goes for
>> any big performance issues. In my experience, cinnabar is pretty darn
>> transparent.
>>
>> https://github.com/mozilla/gecko is effectively the canonical repo people
>> are talking about. I sometimes pull that, but git-cinnabar is fast enough
>> that it works fine to just clone the hg repo directly. If it weren't for
>> the occasional annoyance of mapping commits between local revs and hg.m.o
>> links, I would basically forget that the core infrastructure is running
>> hg.
>
> That repo doesn't have the CVS history.  :-(  I realize that is fixable with
> a local graft and a clone of gecko-dev, but a lot of blood and sweat went
> into making our current canonical git repo include the full CVS history (I
> maintained it myself for ~3 years and a lot of people spent quite a bit of
> time and energy to stand up the current infrastructure that maintains
> gecko-dev.)  Would it be possible to base the canonical git-cinnabar repo on
> https://github.com/jrmuizel/gecko-cinnhabar which does have the full CVS
> history?
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Ehsan Akhgari]

On 09/18/2017 01:16 PM, Bobby Holley wrote:

On Mon, Sep 18, 2017 at 8:25 AM, Andrew McCreight 
wrote:


On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta 
wrote:


I've tried using cinnabar a couple of times now and the last time I
tried, this was the dealbreaker for me. My worfklow often involves
moving a branch from one machine to another and the extra hassle that
results from mismatched SHAs makes it much more complicated than it
needs to be. gecko-dev doesn't have this problem as it has a canonical
upstream that works much more like a regular git user expects.


For what it is worth, I regularly pull from one machine to another with
git-cinnabar, and it works just fine without any problems from mismatched
SHAs. For me, the switch from a clone of gecko-dev to git-cinnabar has been
totally transparent.


+1. The non-stable SHA problem was solved a long time ago. Same goes for
any big performance issues. In my experience, cinnabar is pretty darn
transparent.

https://github.com/mozilla/gecko is effectively the canonical repo people
are talking about. I sometimes pull that, but git-cinnabar is fast enough
that it works fine to just clone the hg repo directly. If it weren't for
the occasional annoyance of mapping commits between local revs and hg.m.o
links, I would basically forget that the core infrastructure is running hg.
That repo doesn't have the CVS history.  :-(  I realize that is fixable 
with a local graft and a clone of gecko-dev, but a lot of blood and 
sweat went into making our current canonical git repo include the full 
CVS history (I maintained it myself for ~3 years and a lot of people 
spent quite a bit of time and energy to stand up the current 
infrastructure that maintains gecko-dev.)  Would it be possible to base 
the canonical git-cinnabar repo on 
https://github.com/jrmuizel/gecko-cinnhabar which does have the full CVS 
history?

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Bobby Holley]

On Mon, Sep 18, 2017 at 8:25 AM, Andrew McCreight 
wrote:

> On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta 
> wrote:
>
> > I've tried using cinnabar a couple of times now and the last time I
> > tried, this was the dealbreaker for me. My worfklow often involves
> > moving a branch from one machine to another and the extra hassle that
> > results from mismatched SHAs makes it much more complicated than it
> > needs to be. gecko-dev doesn't have this problem as it has a canonical
> > upstream that works much more like a regular git user expects.
> >
>
> For what it is worth, I regularly pull from one machine to another with
> git-cinnabar, and it works just fine without any problems from mismatched
> SHAs. For me, the switch from a clone of gecko-dev to git-cinnabar has been
> totally transparent.
>

+1. The non-stable SHA problem was solved a long time ago. Same goes for
any big performance issues. In my experience, cinnabar is pretty darn
transparent.

https://github.com/mozilla/gecko is effectively the canonical repo people
are talking about. I sometimes pull that, but git-cinnabar is fast enough
that it works fine to just clone the hg repo directly. If it weren't for
the occasional annoyance of mapping commits between local revs and hg.m.o
links, I would basically forget that the core infrastructure is running hg.

bholley



> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Gregory Szorc]

A few posts here and in the other thread have mentioned abstracting away
complexity to servers as if it is a magical solution that makes all
problems go away.

Yes, deploying a server-side solution to do some "syncing" is doable and
solves a subset of notable problems.

But I advise extreme caution against asserting simplicity for anything.

One of the large shifts that we're starting to see take place for Firefox
tooling are the breakdown of the barriers between a) the build system and
version control b) the build system and automation. Transitively, we're
seeing all 3 of these things (which are easy to mentally model as
independent concepts) start to merge. This is both terrifying and exciting.

I really owe a blog post or gdoc or something on this topic, but
essentially we're at a few tipping points in terms of scale where we need
tighter cohesion between these systems to continue to scale in a way that
meets developers' needs. Artifact builds are an example of such a system.
Automation builds these artifacts and indexes against the version control
revision (currently Mercurial). The build system ties it all together. In
order to use an artifact build locally, you need to find an artifact build
from automation. This means knowing the indexed version control revision.
With git-cinnabar, the commit map is locally known (read: fast and
well-defined). With vanilla Git, that commit map is... not local. (Yes, we
could work our way out of this commit mapping problem using various
mechanisms (notably caching and/or content-based hashing for indexing). But
there is no obvious solution at this time.) Artifact builds are only the
tip of the iceberg for this class of problem.

In 2-4 years I see us in a position where version control, the build
system, and automation function as one logical system working in harmony.
We're still in the early stages of this shift, which is probably why you
haven't noticed it. Therefore, decisions and policies around how to support
version control today thus incur a magnitude more effort to support down
the road (and even then may result in poorer outcomes for the user base not
on the "primary" set of tools). I'm particularly sensitive to the butterfly
effect on this (likely inevitable) transition and I don't want to hamstring
future productivity efforts by committing us to a short-sighted version
control support policy that won't easily scale.

That being said, I think a canonical git-cinnabar repository might be
doable. I view that as a glorified cache to offload the expensive
first-time conversion. But using it with vanilla Git is a bit more
concerning from a future compatibility perspective, so we should set
expectations for appropriate use accordingly.

On Mon, Sep 18, 2017 at 8:59 AM, Nicholas Hurley  wrote:

> I've had quite a few times (every time I get a new machine) that I've had
> issues with git-cinnabar and multiple machines. This has resulted in me
> just scp'ing my entire repo every time I get a new machine (which comes
> with its own set of issues... messed up paths in the .git/config, for
> example). I grant that some of this is due to my own stupidity, but aren't
> tools supposed to make it harder for one's own stupidity to get in the way?
>
> I haven't even tried to share anything with anyone else via git, I just
> send them a patch. The chance of mismatched sha's is Too Damn High! This
> is, as the saying goes, suboptimal.
>
> All this to say, I think having an official cinnabar repo (preferably with
> cinnabar metadata I can fetch, too) would make things significantly easier
> for a lot of use-cases, and I can't think of a single use-case that it
> would make things worse for over the long-term (ie, once we have autoland
> everywhere and no manual pushes to m-c or try). The initial fetch might
> take a while if we include metadata, but that's a one-time (per machine)
> cost.
>
> Even better would be the "all the magic happens server-side" solution. Then
> I could Just Use Git, and never have to worry about any of this junk ever
> again.
>
> On Mon, Sep 18, 2017 at 8:25 AM, Andrew McCreight 
> wrote:
>
> > On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta 
> > wrote:
> >
> > > I've tried using cinnabar a couple of times now and the last time I
> > > tried, this was the dealbreaker for me. My worfklow often involves
> > > moving a branch from one machine to another and the extra hassle that
> > > results from mismatched SHAs makes it much more complicated than it
> > > needs to be. gecko-dev doesn't have this problem as it has a canonical
> > > upstream that works much more like a regular git user expects.
> > >
> >
> > For what it is worth, I regularly pull from one machine to another with
> > git-cinnabar, and it works just fine without any problems from mismatched
> > SHAs. For me, the switch from a clone of gecko-dev to git-cinnabar has
> been
> > totally transparent.
> > 

Re: Canonical cinnabar repository

[Kartikaya Gupta]

On Mon, Sep 18, 2017 at 11:04 AM, Myk Melez  wrote:
> Having said that, I agree that it's worth enabling developers to clone a
> canonical Git repo. I've been syncing mozilla/gecko using cinnabar for a
> while to experiment with ways of doing this.

That's great, thanks. If we can do something like this but (a) with
all the pre-mercurial history, and (b) include integration/release
branches, that would basically be exactly what I want as a canonical
upstream cinnabar repo.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Nicholas Hurley]

I've had quite a few times (every time I get a new machine) that I've had
issues with git-cinnabar and multiple machines. This has resulted in me
just scp'ing my entire repo every time I get a new machine (which comes
with its own set of issues... messed up paths in the .git/config, for
example). I grant that some of this is due to my own stupidity, but aren't
tools supposed to make it harder for one's own stupidity to get in the way?

I haven't even tried to share anything with anyone else via git, I just
send them a patch. The chance of mismatched sha's is Too Damn High! This
is, as the saying goes, suboptimal.

All this to say, I think having an official cinnabar repo (preferably with
cinnabar metadata I can fetch, too) would make things significantly easier
for a lot of use-cases, and I can't think of a single use-case that it
would make things worse for over the long-term (ie, once we have autoland
everywhere and no manual pushes to m-c or try). The initial fetch might
take a while if we include metadata, but that's a one-time (per machine)
cost.

Even better would be the "all the magic happens server-side" solution. Then
I could Just Use Git, and never have to worry about any of this junk ever
again.

On Mon, Sep 18, 2017 at 8:25 AM, Andrew McCreight 
wrote:

> On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta 
> wrote:
>
> > I've tried using cinnabar a couple of times now and the last time I
> > tried, this was the dealbreaker for me. My worfklow often involves
> > moving a branch from one machine to another and the extra hassle that
> > results from mismatched SHAs makes it much more complicated than it
> > needs to be. gecko-dev doesn't have this problem as it has a canonical
> > upstream that works much more like a regular git user expects.
> >
>
> For what it is worth, I regularly pull from one machine to another with
> git-cinnabar, and it works just fine without any problems from mismatched
> SHAs. For me, the switch from a clone of gecko-dev to git-cinnabar has been
> totally transparent.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Andrew McCreight]

On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta  wrote:

> I've tried using cinnabar a couple of times now and the last time I
> tried, this was the dealbreaker for me. My worfklow often involves
> moving a branch from one machine to another and the extra hassle that
> results from mismatched SHAs makes it much more complicated than it
> needs to be. gecko-dev doesn't have this problem as it has a canonical
> upstream that works much more like a regular git user expects.
>

For what it is worth, I regularly pull from one machine to another with
git-cinnabar, and it works just fine without any problems from mismatched
SHAs. For me, the switch from a clone of gecko-dev to git-cinnabar has been
totally transparent.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Jeff Muizelaar]

I agree having a canonical version would be very valuable. In the mean
time if you want to avoid having to do the entire conversion locally
you can start by cloning the cinnabar branch of
https://github.com/jrmuizel/gecko-cinnabar which is a local full
conversion that I painfully uploaded to github.

-Jeff

On Mon, Sep 18, 2017 at 11:04 AM, Myk Melez  wrote:
>> Kartikaya Gupta 
>> 2017 September 18 at 07:05
>> It seems to me that a lot of people are now assuming a cinnabar repo
>> is the canonical way for git users to develop on mozilla-central. If
>> we want to make this mozilla policy I don't really have objections,
>> but I think that if we do that, we should maintain a canonical git
>> repo that is built using cinnabar, rather than having everybody have
>> their own "grafted" version of a cinnabar repo. The problem with the
>> latter approach is that different people will have different SHAs for
>> the same upstream commit, thus making it much harder to share repos.
>
> Note that there's a third option, which is for everyone to have their own
> non-grafted version of a cinnabar repo. If you clone mozilla-central using
> cinnabar, instead of grafting commits onto a gecko-dev clone, then that's
> what you get, since cinnabar revision ID conversion is deterministic (as I
> understand it, anyway).
>
> Having said that, I agree that it's worth enabling developers to clone a
> canonical Git repo. I've been syncing mozilla/gecko using cinnabar for a
> while to experiment with ways of doing this. There've also been
> conversations about syncing new commits to mozilla/gecko-dev with cinnabar
> for a few years, although I don't know of any active efforts to do this.
>
> -myk
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Canonical cinnabar repository

[Myk Melez]

Kartikaya Gupta 
2017 September 18 at 07:05
It seems to me that a lot of people are now assuming a cinnabar repo
is the canonical way for git users to develop on mozilla-central. If
we want to make this mozilla policy I don't really have objections,
but I think that if we do that, we should maintain a canonical git
repo that is built using cinnabar, rather than having everybody have
their own "grafted" version of a cinnabar repo. The problem with the
latter approach is that different people will have different SHAs for
the same upstream commit, thus making it much harder to share repos.
Note that there's a third option, which is for everyone to have their 
own non-grafted version of a cinnabar repo. If you clone mozilla-central 
using cinnabar, instead of grafting commits onto a gecko-dev clone, then 
that's what you get, since cinnabar revision ID conversion is 
deterministic (as I understand it, anyway).


Having said that, I agree that it's worth enabling developers to clone a 
canonical Git repo. I've been syncing mozilla/gecko using cinnabar for a 
while to experiment with ways of doing this. There've also been 
conversations about syncing new commits to mozilla/gecko-dev with 
cinnabar for a few years, although I don't know of any active efforts to 
do this.


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to require `mach try` for submitting to Try

[Myk Melez]

James Graham 
2017 September 18 at 02:56
5. Allows vanilla git and hg on the client side, but requires 
something complex, custom, and scary on the server side to allow 
pushing to either repo. Could be possible if we eliminate ~all manual 
pushes (i.e. everything goes via autoland), but cinnabar or similar is 
still there in the background.
If the Gecko repository that developers clone is synced with cinnabar 
(which is how I sync mozilla/gecko, and which folks've discussed doing 
with mozilla/gecko-dev for years), then the scary server-side thing 
could be a Git repository synced with cinnabar that forwards pushes to 
the current tryserver.


That's essentially the same amount of scariness as is currently the case 
(i.e. cinnabar), except, as ekr noted, it is only maintained on the 
server rather than on each individual developer's machine.


-myk

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to require `mach try` for submitting to Try

[Gregory Szorc]

On Fri, Sep 15, 2017 at 10:21 PM, ISHIKAWA,chiaki 
wrote:

> Does "mozilla/mach try" will work for try-comm-central?
>
> (Well, I know there has been a general talk of moving thunderbird to
> somewhere else, but it is not going to happen overnight.)
>

I'm not sure. There's no good reason why it should or shouldn't. Also, we
may not impose this Try push restriction on try-comm-central. It depends
how tightly linked they are. Realistically, we likely go with whatever is
the least effort way forward for Firefox because we're not supposed to be
spending time hacking on Thunderbird's infra and tooling.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Canonical cinnabar repository

[Kartikaya Gupta]

This message was inspired by the `mach try` thread but is off-topic
there so I think deserves its own thread.

It seems to me that a lot of people are now assuming a cinnabar repo
is the canonical way for git users to develop on mozilla-central. If
we want to make this mozilla policy I don't really have objections,
but I think that if we do that, we should maintain a canonical git
repo that is built using cinnabar, rather than having everybody have
their own "grafted" version of a cinnabar repo. The problem with the
latter approach is that different people will have different SHAs for
the same upstream commit, thus making it much harder to share repos.

I've tried using cinnabar a couple of times now and the last time I
tried, this was the dealbreaker for me. My worfklow often involves
moving a branch from one machine to another and the extra hassle that
results from mismatched SHAs makes it much more complicated than it
needs to be. gecko-dev doesn't have this problem as it has a canonical
upstream that works much more like a regular git user expects.

As an aside, I also think that the cinnabar workflow as it exists now
actually demotes git to more of a "second-class citizen".
Conceptually, if you're using gecko-dev, everything works exactly as a
git user would expect, and only when you need to push to official
mozilla hg repos do you need to overcome the vcs translation hurdle
(which things like moz-git-tools help with). However if you use
cinnabar the vcs translation is more woven into your everyday git
commands (e.g. git pull) and you need to be more consciously aware of
it. This makes it harder to use whatever your normal git workflow is,
which is why I claim it demotes git to second-class. It would be great
if we could come up with a way to avoid this but honestly since I
haven't used a cinnabar workflow for any significant period of time I
haven't given much thought as to how to go about doing this.

Discussion welcome!

Cheers,
kats
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Race Cache With Network experiment on Nightly

[Wellington Torrejais da Silva]

Em quarta-feira, 24 de maio de 2017 12:36:45 UTC-3, Valentin Gosu  escreveu:
> As part of the Quantum Network initiative we are working on a project
> called "Race Cache With Network" (rcwn) [1].
> 
> This project changes the way the network cache works. When we detect that
> disk IO may be slow, we send a network request in parallel, and we use the
> first response that comes back. For users with slow spinning disks and a
> low latency network, the result would be faster loads.
> 
> This feature is currently preffed off - network.http.rcwn.enabled
> In bug 1366224, which is about to land on m-c, we plan to enable it on
> nightly for one or two days, to get some useful telemetry for our future
> work.
> 
> For any crashes or unexpected behaviour, please file bugs blocking 1307504.
> 
> Thanks!
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=rcwn
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1366224

Very useful information! Helped me in a lot. 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to require `mach try` for submitting to Try

[Eric Rescorla]

On Mon, Sep 18, 2017 at 2:56 AM, James Graham 
wrote:

> On 18/09/17 04:05, Eric Rescorla wrote:
>
> But that's just a general observation; if you look at this specific case,
>>> it might not be much effort to support native git for richer/future try
>>> pushing. But that's very different from requiring all the tools to
>>> support
>>> native git on an equal basis. And it seems reasonable to evaluate the
>>> utility of this specific support via a poll, even one known to be biased.
>>>
>>>
>> I don't think that's true, for the reasons I indicated above. Rather,
>> there's a policy decision about whether we are going to have Git as a
>> first-class thing or whether we are going to continue force everyone who
>> uses Git to fight with inadequate workflows. We know there are plenty of
>> people who use Git.
>>
>
> I don't entirely understand what concrete thing is being proposed here. As
> far as I can tell the git-hg parameter space contains the following points:
>
>  1. Use hg on the server and require all end users to use it
>  2. Use git on the server and require all end users to use it
>  3. Use hg on the server side and use client-side tooling to allow git
> users to interact with the repository
>  4. Use git on the server side and use client-side tooling to allow hg
> users to interact with the repository
>  5. Provide some server side magic to present both git and hg to clients
> (with git, hg, or something else, as the on-disk format)
>
> These all seem to have issues relative to the goal of "vanilla git with no
> custom code":
>
>  1. Doesn't allow git to be used at all.
>  2. Requires a multi-year transition away from hg. Probably not popular
> with hg fans.
>  3. The status quo. Requires using a library for converting between hg and
> git (i.e. cinnabar) or some mozilla-specific custom scripts (the old
> moz-git-tools)
>  4. Like 3. but with an additional multi-year transition and different
> custom tooling.
>  5. Allows vanilla git and hg on the client side, but requires something
> complex, custom, and scary on the server side to allow pushing to either
> repo. Could be possible if we eliminate ~all manual pushes (i.e. everything
> goes via autoland), but cinnabar or similar is still there in the
> background.
>

This is what I meant. And having something complex and scary on the server
side is (at least to me) obviously better than having something complex and
 scary (and did I mention constantly out of date) on the client side,
because it's all in one place and externally just looks like the thing the
client is expecting. Note that we already have half of this because we have
one-way synching to gecko-dev on the server side. Perhaps one could also
rip off some of the servo-gecko synching stuff here, but I don't know much
about how that's architected.


Given none of those options seem to fit, the only other possibility I can
> think of is to skip the general problem of how to interact with the VCS for
> try specifically by making submitting to try not look like a VCS push, but
> like some other way of sending a blob of code to a remote machine (e.g.
> using some process that generates a patch file). But unless there's some
> extant way to achieve that it seems like it would be replacing
> known-working code (cinnabar) with new custom code.
>

> So my best guess is that you mean that all pushes should go via autoland
> and we should provide read-only hg/git repositories, and try pushes should
> also go via something other than a vcs push. But I'm probably missing
> something.


Well, I do think this is the direction we should be moving towards, as it
seems to have a pile of advantages. Indeed, if we're *already* going to be
forcing people to submit to try via mach rather than via vcs push, why
wouldn't we do that for this piece of it now?

-Ekr


>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to require `mach try` for submitting to Try

[Eric Rescorla]

On Mon, Sep 18, 2017 at 1:10 AM, Henri Sivonen  wrote:

> On Mon, Sep 18, 2017 at 6:05 AM, Eric Rescorla  wrote:>
> I don't think that's true, for the reasons I indicated above. Rather,
> > there's a policy decision about whether we are going to have Git as a
> > first-class thing or whether we are going to continue force everyone who
> > uses Git to fight with inadequate workflows. We know there are plenty of
> > people who use Git.
>
> Besides occasionally having to convert between hg and cinnabar
> changeset ids, what's inadequate about cinnabar workflow(s)?
>

That's a big part of it. I've also had it fail randomly and for unobvious
reasons (especially if you have some kind of unconventional hg install) and
then had to figure out why. And of course it means you need to install and
maintain hg and cinnabar, not just git. It's just another piece of wacky
custom machinery that we make devs suffer through.

-Ekr


>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[Firefox Desktop] Issues found: September 11th to September 15th

[Cornel Ionce]

Hi everyone,

Here's the list of new issues found and filed by the Desktop Release QA 
Team last week, *September 11 - September 15* (week 37).


Additional details on the team's priorities last week, as well as the 
plans for the current week are available at:


   https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus



*RELEASE CHANNEL*
none

*BETA CHANNEL
*
ID  Summary Product Component   Is a regression 
Assigned to
1399373 
	[W10 Fall Creators Update] Crash in js::jit::BytecodeAnalysis::init 
while scrolling on Yahoo Music

Core
JavaScript Engine: JIT
NO  NOBODY
1399495 
Jerkiness while scrolling on Facebook pages
Tech Evangelism
Desktop
NO  Benoit Girard 
1399501 
[Ubuntu] Jenga WebGL game is not loading in the webpage
Core
	Canvas: WebGL 	YES 
 
	Michael Leu 

1400154 
Preference UI cloud storage option flicker
Firefox
Preferences
YES NOBODY
1399856  	No highlighter displayed when 
searching for strings inside Use custom settings from History

Firefox Preferences NO  NOBODY


*NIGHTLY CHANNEL**
*
ID  Summary Product Component   Is a regression 
Assigned to
1398760 
The log persistence checkbox isn't vertically centered in the Toolbar
Firefox
Developer Tools: Console
NO  Brian Grinstead 
1399125 
	The hidden messages label is overlapping the log persistence label for 
a certain console width interval

Firefox
Developer Tools: Console
NO  NOBODY
1399065 
	[Form Autofill] - Credit Card doorhanger is not displayed properly and 
according to the mocks

Toolkit
Form Manager
NO  NOBODY
1399402 
	[Form Autofill] - "Never Save Credit Cards" text is displayed with 
small c for credit in the door hanger

Toolkit
Form Manager
NO  Steve Chung 
1400238 
[Ubuntu] Autoscroll indicator is placed below mouse pointer in new 
windows
Core
Panning and Zooming
YES NOBODY
1400271 
[OSX] Black flicker while scrolling with cmd+up/down arrow
Core
Panning and Zooming
TBD NOBODY


*ESR CHANNEL*
none


Regards,
Cornel (:cornel_ionce)
Desktop Release QA
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to require `mach try` for submitting to Try

[James Graham]

On 18/09/17 04:05, Eric Rescorla wrote:


But that's just a general observation; if you look at this specific case,
it might not be much effort to support native git for richer/future try
pushing. But that's very different from requiring all the tools to support
native git on an equal basis. And it seems reasonable to evaluate the
utility of this specific support via a poll, even one known to be biased.



I don't think that's true, for the reasons I indicated above. Rather,
there's a policy decision about whether we are going to have Git as a
first-class thing or whether we are going to continue force everyone who
uses Git to fight with inadequate workflows. We know there are plenty of
people who use Git.


I don't entirely understand what concrete thing is being proposed here. 
As far as I can tell the git-hg parameter space contains the following 
points:


 1. Use hg on the server and require all end users to use it
 2. Use git on the server and require all end users to use it
 3. Use hg on the server side and use client-side tooling to allow git 
users to interact with the repository
 4. Use git on the server side and use client-side tooling to allow hg 
users to interact with the repository
 5. Provide some server side magic to present both git and hg to 
clients (with git, hg, or something else, as the on-disk format)


These all seem to have issues relative to the goal of "vanilla git with 
no custom code":


 1. Doesn't allow git to be used at all.
 2. Requires a multi-year transition away from hg. Probably not popular 
with hg fans.
 3. The status quo. Requires using a library for converting between hg 
and git (i.e. cinnabar) or some mozilla-specific custom scripts (the old 
moz-git-tools)
 4. Like 3. but with an additional multi-year transition and different 
custom tooling.
 5. Allows vanilla git and hg on the client side, but requires 
something complex, custom, and scary on the server side to allow pushing 
to either repo. Could be possible if we eliminate ~all manual pushes 
(i.e. everything goes via autoland), but cinnabar or similar is still 
there in the background.


Given none of those options seem to fit, the only other possibility I 
can think of is to skip the general problem of how to interact with the 
VCS for try specifically by making submitting to try not look like a VCS 
push, but like some other way of sending a blob of code to a remote 
machine (e.g. using some process that generates a patch file). But 
unless there's some extant way to achieve that it seems like it would be 
replacing known-working code (cinnabar) with new custom code.


So my best guess is that you mean that all pushes should go via autoland 
and we should provide read-only hg/git repositories, and try pushes 
should also go via something other than a vcs push. But I'm probably 
missing something.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to require `mach try` for submitting to Try

[James Graham]

On 18/09/17 09:27, Samael Wang wrote:

In a rare case that we need to send a "CLOSED TREE" try job,
will we be able to do that with ./mach try?
Last time I didn't use mach try to submit try job was because of that.



That doesn't work right now, but it should be easy to add a 
--closed-tree flag or similar. File a bug please?

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to require `mach try` for submitting to Try

[Samael Wang]

In a rare case that we need to send a "CLOSED TREE" try job,
will we be able to do that with ./mach try? 
Last time I didn't use mach try to submit try job was because of that.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to require `mach try` for submitting to Try

[Henri Sivonen]

On Mon, Sep 18, 2017 at 6:05 AM, Eric Rescorla  wrote:>
I don't think that's true, for the reasons I indicated above. Rather,
> there's a policy decision about whether we are going to have Git as a
> first-class thing or whether we are going to continue force everyone who
> uses Git to fight with inadequate workflows. We know there are plenty of
> people who use Git.

Besides occasionally having to convert between hg and cinnabar
changeset ids, what's inadequate about cinnabar workflow(s)?

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform