On Wed, Apr 10, 2013 at 08:23:37PM -0700, Gregory Szorc wrote:
> Mercurial and Git both support the ability to attach arbitrary key-value
> string data to commits. There is an abundance of awesomeness that could
> be realized if we started storing [machine readable] information inside
> our commits
Mike Hommey wrote:
* MOZ_CHROME_FILE_FORMAT/--enable-chrome-format is still used to
select the chrome format for the packaged application, but what
is installed under dist/bin is now always as if
MOZ_CHROME_FILE_FORMAT was flat or symlink (depending on the
platform).
(Sorry for posting this twice in mozilla.dev.builds. I forgot to add
mozilla.dev.platform. Iput mozilla.dev.platform as followup-to newsgroup. TIA)
I have a question regarding
submitting win32 build for Thunderbird TryServer.
I have created and tested patches for COMM-CENTRAL source tree
locally
Gregory Szorc wrote:
We should eventually be able to get to a state where there are no
moz.build/Makefile.in files in test directories. Well, at least for test suites
using manifests to define test files (xpcshell, mochitest, reftest, possibly
others).
Do these manifests include associated
On 11/04/2013 07:22, Justin Dolske wrote:
> I'd question if we really need to keep Target Milestone at all (given
> replacements for how it's used now).
We don't have replacements for "fixed from this version on", so far, as
Alex well explained.
> I don't see many Firefox/Gecko
> teams using
On 11/04/2013 03:32, Jason Smith wrote:
That's a good idea. Should we file a bug to do this?
On 4/10/2013 5:14 PM, Gregory Szorc wrote:
why don't we have a checkin hook or bot automatically
update Bugzilla flags when changesets are pushed?
Agree would be good - bug 805874 was filed for this :
Le 11/04/2013 01:37, Neil a écrit :
Mihai Sucan wrote:
let console =
Cu.import("resource://gre/modules/devtools/Console.jsm", {}).console;
Why not just import Console.jsm directly?
Good point. I got into that habit because some jsm's export multiple
symbols and I only pick what I need.
__
On 04/10/2013 09:07 PM, jmaher wrote:
There are a couple common directory structures used for storing tests in the
tree:
1) /tests
2) /tests/
I have a series of patches which will move most of the directory structures
from #1 to a format of #2. This means we would see:
/tests/mochitest
/tests
(2013/04/11 4:24), Mihai Sucan wrote:
Hello Joshua!
Le 10/04/2013 20:41, Joshua Cranmer 🐧 a écrit :
On 4/10/2013 12:05 PM, Mihai Sucan wrote:
If anyone has any concerns about us replacing the Error Console, please shout
loud and clear! We plan to do the
aforementioned steps to replace the Er
Hello!
Le 11/04/2013 15:05, ISHIKAWA, Chiaki a écrit :
Hi, as TB user, I often find javascript errors in error console when
something
does not work right. For example, syntax error (rare, but happens
during testing),
or undefined property error in error console (these are actually
rather rout
On 4/10/2013 11:23 PM, Gregory Szorc wrote:
Mercurial and Git both support the ability to attach arbitrary key-value
string data to commits. There is an abundance of awesomeness that could
be realized if we started storing [machine readable] information inside
our commits (not inside the commit m
Thus Spoke jmaher:
> There are a couple common directory structures used for storing tests in the
> tree:
> 1) /tests
> 2) /tests/
>
> I have a series of patches which will move most of the directory structures
> from #1 to a format of #2. This means we would see:
> /tests/mochitest
> /tests/bro
On 4/11/2013 2:43 AM, ishikawa wrote:
Has anyone seen the problem of the patches to M-C portion of the
COMM-CENTRAL not accepted by Thunderbird TryServer because the patches
fail although linux32 and linux64 work as expected?
The bug is that the Windows try server is attempting to apply the
pa
On Thursday, April 11, 2013 10:26:25 AM UTC-4, Scott Johnson wrote:
> Thus Spoke jmaher:
>
> > There are a couple common directory structures used for storing tests in
> > the tree:
>
> > 1) /tests
>
> > 2) /tests/
>
> >
>
> > I have a series of patches which will move most of the directory s
On Thu, Apr 11, 2013 at 2:15 AM, Marco Bonardo wrote:
> The TM set on landing is something we do from many years, as far as i
> remember could be like 4 years, and surely we started doing that more
> consistently with rapid release cycle. I'd say 80% of the developers are
> aware of this, so not s
Hey guys,
I'm a Mozilla contributor for almost year now (Gaia, and spiderMonkey). And
I want to apply for Mozilla for The Google summer of code.
I have a question and it would be awesome if you could answer it.
I was discussing with Enhanced Customization APIs mentors about the
problems that could
On 4/11/2013 11:47 AM, jmaher wrote:
Great question- the main goal is to have each test type in a directory for that
specific harness.
Yes, but why is that a good thing? In general, I feel that our directory
structures are way too deep already, and it would be better to make them
as flat as po
On 4/11/2013 1:57 AM, Neil wrote:
> Gregory Szorc wrote:
>
>> We should eventually be able to get to a state where there are no
>> moz.build/Makefile.in files in test directories. Well, at least for
>> test suites using manifests to define test files (xpcshell,
>> mochitest, reftest, possibly other
On 04/11/2013 02:15 AM, Marco Bonardo wrote:
>
> On 11/04/2013 07:22, Justin Dolske wrote:
> > I'd question if we really need to keep Target Milestone at all (given
> > replacements for how it's used now).
>
> We don't have replacements for "fixed from this version on", so far,
> as Alex well expla
On 11/04/2013 18:23, Steve Fink wrote:
The name "target milestone" implies an aspirational landing. Should we
just change the bug template to change the name of the field?
It could make sense, my understanding is that we started using it in the
lack of better options, and has become a de-facto
Steve Fink wrote:
The name "target milestone" implies an aspirational landing. Should we
just change the bug template to change the name of the field?
that would be difficult as other projects which use bugzilla.mozilla.org
use the "target milestone" field as a .. target milestone ;)
while it
It bothers me that we're cluttering up our commit messages with
ephemeral data unrelated to the actual change. DONTBUILD and CLOSED
TREE are the worst offenders. I would also like to have
machine-readable tags for regular push vs bustage fix vs backout vs
merge, because they would be useful for
> It bothers me that we're cluttering up our commit messages with
> ephemeral data unrelated to the actual change. DONTBUILD and CLOSED
> TREE are the worst offenders.
What if we asked people to put DONTBUILD / CLOSED TREE in a new line
at the bottom of their commit message? Most of the time we l
On Thu, Apr 11, 2013 at 12:57:46PM -0400, Justin Lebar wrote:
> > It bothers me that we're cluttering up our commit messages with
> > ephemeral data unrelated to the actual change. DONTBUILD and CLOSED
> > TREE are the worst offenders.
>
> What if we asked people to put DONTBUILD / CLOSED TREE in
On 4/11/13 2:15 AM, Marco Bonardo wrote:
On 11/04/2013 07:22, Justin Dolske wrote:
> I'd question if we really need to keep Target Milestone at all (given
> replacements for how it's used now).
We don't have replacements for "fixed from this version on", so far, as
Alex well explained.
Well
On 4/11/2013 1:13 PM, Mike Hommey wrote:
> That still leave the clutter forever in the mercurial log. I wonder if
> it would be possible to push special branches or bookmarks for
> DONTBUILD and CLOSED TREE, with a server side hook to handle things
> nicely.
Mercurial has this thing called "push k
On 4/11/2013 10:26 AM, Ted Mielczarek wrote:
> On 4/11/2013 1:13 PM, Mike Hommey wrote:
>> That still leave the clutter forever in the mercurial log. I wonder if
>> it would be possible to push special branches or bookmarks for
>> DONTBUILD and CLOSED TREE, with a server side hook to handle things
On Thu, Apr 11, 2013 at 10:23 AM, Justin Dolske wrote:
> For example: "Fixed from this version on" could be a static display derived
> from "status-firefox#" flags... Find the earliest "fixed" state without
> later non-fixed states.
I think we need to maintain the distinction between "landed on t
(2013/04/11 23:43), Joshua Cranmer 🐧 wrote:
On 4/11/2013 2:43 AM, ishikawa wrote:
Has anyone seen the problem of the patches to M-C portion of the
COMM-CENTRAL not accepted by Thunderbird TryServer because the patches
fail although linux32 and linux64 work as expected?
The bug is that the Wind
On 4/11/2013 1:33 PM, ISHIKAWA,chiaki wrote:
(2013/04/11 23:43), Joshua Cranmer 🐧 wrote:
On 4/11/2013 2:43 AM, ishikawa wrote:
Has anyone seen the problem of the patches to M-C portion of the
COMM-CENTRAL not accepted by Thunderbird TryServer because the patches
fail although linux32 and linux6
On (2013年04月12日 03:40), Joshua Cranmer 🐧 wrote:
On 4/11/2013 1:33 PM, ISHIKAWA,chiaki wrote:
(2013/04/11 23:43), Joshua Cranmer 🐧 wrote:
On 4/11/2013 2:43 AM, ishikawa wrote:
Has anyone seen the problem of the patches to M-C portion of the
COMM-CENTRAL not accepted by Thunderbird TryServer bec
31 matches
Mail list logo
