Re: Annotating Commits

[Mike Hommey]

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 (not inside the commit messages). Here are some examples:
> 
> * Who the reviewer was. (It might be useful to have that more strongly
> defined so you don't have to parse it out of the commit message.)
> * Who approved the uplift. (OK, fine, it's a corollary of the above.)
> * The bug number. (The bug just needs to be somewhere in the commit.
> Does it really need to be in the message, taking up space?)

I don't think any of the three above would be a good idea, because it
would mandate that you use an external tool (or a very custom hg log
template) in order to make things like hg log be as useful as it is now.

That seems like a complication that would get in the way of prospective
contributors.

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

Re: New packaging code

[Neil]

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). It was already the case for
  MOZ_CHROME_FILE_FORMAT=omni, it now is also the case for
  MOZ_CHROME_FILE_FORMAT=jar. MOZ_CHROME_FILE_FORMAT=omni is
  recommended, though.


I would like to dispute this last sentence.

If you used to build SeaMonkey with --enable-chrome-format=symlink then 
the replacement is --enable-chrome-format=flat as this allows the 
in-tree extensions to be symlinked, rather then distributed.


--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

TB Tryserver WIN32 Build question: merge failure of the change to M-C portion of the source.

[ishikawa]

(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 on my own PC.

Once they compile clean and test passes, I submit the patches to
Thunderbird Tryserver and have them compiled and executed for linux
(32bits and 64bits).
Linux versions are OK.

However, I have been unable to do so for changes made to m-c
(mozilla-central portion) of the files for WIN32 build.

The changes made to mozilla-central portion of the files fail to be
merged even for WIN32 build. So the compilation never started for
WIN32 build.

Today, I bit the bullet and took out the patches created for M-C
portion of the files, and then FINALLY(!) the compilation started.
(Well, it failed because I used bzero() without declaring it. VC
complained. But that is a great progress for me although not being
able to use the patch created for m-c portion of the files is
discouraging.
To be honest, I think the code is logically OK since linux32, and
linux64 work  but we may hit these type of compiler compatibility
issues. So I wonder if I can make the win32 build work for changes in
m-c part.)

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?

TIA


BACKGROUND and my guess where something is incorrect:

For those who are unfamiliar with comm-central source tree,
the following may have a bearing on this issue. So I will explain.

Comm-central (c-c) contains the source for thunderbird (and
spidermonkey or whatever), I will simply call it MAILER in this post.
But it requires the CORE components available in Mozilla-Central (m-c)
source tree.
So c-c ADDS m-c under its top-level directory as "./mozilla"
subdirectory.
Everything in m-c is under this "./mozilla" directory.
(So I think we can build Firefox under this mozilla directory. I have
not tried, but mozilla web page suggests so.)

We must pay attention to the following issue carefully: Mercurial
repositories for c-c's MAILER portion and mercurial for this "m-c as
part of c-c" are independent and separate.

There are ".hg" subdirectory "./.hg" immediately in the top-level
directory of c-c source tree to manage c-c (MAILER) source tree, AND
there is another "./mozilla/.hg" subdirectory that manages the "m-c as
part of c-c" source tree.

This means that "hg status", if you issue it in the c-c's MAILER
portion of the source tree, say at the top-level and its
subdirectories such as ./mail, ./mailnews, etc., it will print ONLY
the status of c-c's MAILER portion of the source tree. It will not
print out the modifications made to files in "m-c as part of c-c"
source tree.

The reverse is also true.

If I am under "./mozilla" subdirectory and its subdirectories ("m-c as
part of c-c"), "hg status" will print out only the modification under
the ./mozilla subdirectory and no changes made to the MAILER portion
of "c-c" are printed.

We have to be careful when creating patches so that we will not leave
out the changes made in the other repository.

C-C's client.py takes care of this issue when updating the source
files from c-c repository, by calling hg commands for these
independent mercurial repositories multiple times as necessary.

  python client.py update

First it updates c-c's MAILER portion of the local repository, then
it descends into "./mozilla" subdirectory and then reissues
hg commands to update the "m-c as part of c-c" repository.

Enough for a local management (on one's local PC).
This setup makes it a little tricky to submit a job to Thunderbird
Tryserver.

After all, at the superficial level during Thunderbird TryServer job
submission, we only tell the thunderbird TryServer we have made
changes to the top-level "c-c" (MAILER) source tree.

How do we tell the Thunderbird TryServer we have made changes to the
files in "m-c as part of c-c" source tree?

The trick used by Thunderbird Tryserver currently is as follows.: I am
quoting this from
https://wiki.mozilla.org/Thunderbird/Infrastructure/TryServer

--- quote begin
Pushing mozilla-central patches

There's two steps to this process.

Edit client.py-args: remove the hgtool option, add --apply-patches
Example patch here
Do this as a separate item in your mq and you can use whenever you want
Note: hgtool option removal is because I'm not convinced if applying
a patch affects the hg share or not
Take your mozilla-central patch and name it something like:
mozilla-.patch
hg add your patch
Then hg commit your changes, or use hg qnew for a new item on your patch
queue
Push your patches to try-comm-central

The client.py code will automatically apply your patch when the code is
checked out. Any apply failures will cause the buil

Re: reorganizing some test directories

[Neil]

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 files (e.g. iframes, images?)


Now, the real question is whether we still generate Makefile for these 
directories. If everyone used mach commands for running tests, we wouldn't need 
Makefile or their targets to invoke per-directory tests.

Don't mochitests use TEST_PATH from the root Makefile? I can't remember 
which tests need a per-directory Makefile but it might include xpcshell 
tests.


--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Landing on Trunk - Target Milestone vs. Status Flag Usage vs. Tracking for Future Releases

[Marco Bonardo]

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 it (let alone consistently).

It's actually very useful when you look for a bug and want to know which 
version got it first, or to gather most of the bugs fixed in a given 
version (unfortunately may not be 100% correct due to the fact some 
teams don't use it).  For example when someone files a regression bug 
and you remember a related bug was fixes not a lot of time ago, the TM 
can often hint you if it may be involved, just by checking the user 
version.  This may save expensive mozregression time.
As well as if you are in a middle of a regression-window and want to 
check which version was active at that time, without having to search 
for the very specific merge time and try to figure if something landed 1 
minute before or after the merge.


I agree there could be better options and better tools may be built, 
though I don't think we can remove TM without first having those.


> The whiteboard should be
> adequate for indicating aspirational landings.

Right, there is no need to use the TM to track future work.

>
> There is _significant_ value in eliminating/replacing niche workflows in
> favor of a more consistent system that people can actually understand.

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 sure it's a niche workflow. It's probably not well 
documented though.


In the end we surely need a reliable and automated solution for "fixed 
from this version on", though I'd be against throwing away the current 
solution until we have the new one.


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

Re: Landing on Trunk - Target Milestone vs. Status Flag Usage vs. Tracking for Future Releases

[Ed Morley]

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 :-)

Best wishes,

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

Re: [devtools] Ready to replace the Error Console: the Browser Console landed

[Mihai Sucan]

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.

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

Re: reorganizing some test directories

[Ms2ger]

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/browser
/tests/chrome

I have noticed this happens naturally in the newer folders (i.e. 
browser/metro).  A couple weeks ago I heard a concern this might bitrot some 
patches, while that might happen in the last couple weeks only a handful 
directories had tests which changed (added/deleted/editing) such that my 
patches experienced bitrot. Please comment here or in bug 852065 as I would 
like to land these patch this by this weekend.



I do not understand the purpose of these change. They do not appear to 
have any benefits.


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

Re: [devtools] Ready to replace the Error Console: the Browser Console landed

[ISHIKAWA, Chiaki]

(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 Error Console in the current release cycle, 
maybe in bug 602006
 [8].


What are the implications for non-Firefox based projects like Thunderbird and 
SeaMonkey?


There should be no implications for non-Firefox based projects. We will not 
touch the Error Console, we will only hide
it by default, as explained in the initial email I sent.



Where will the ~650 uses in mozilla-central/comm-central of 
Components.utils.reportError report errors to?



Cu.reportError() will continue to work as usual. You will see all of those 
errors in the Browser Console.



Best regards,
Mihai



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 routine 
:-(
I got a few dozen such messages during "make mozmill" test run that gets dumped 
in the tty console
where I run DEBUG BUILD of TB.

These happen during the normal operation of thunderbird, UI interaction or 
message operation and such,
and without any WEB browsing involved (after all it is TB).

So let me clarify my understanding is correct or not.

These errors issued by JavaScript interpreter will still go to error console, 
won't they?
So, if I need to look at them, I touch the about:config to re-enable error 
console
to appear on the menu and then click the menu item to see the console for real.

Am I correct in the above understanding?

TIA

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

Re: [devtools] Ready to replace the Error Console: the Browser Console landed

[Mihai Sucan]

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 routine :-(
I got a few dozen such messages during "make mozmill" test run that 
gets dumped in the tty console

where I run DEBUG BUILD of TB.

These happen during the normal operation of thunderbird, UI 
interaction or message operation and such,

and without any WEB browsing involved (after all it is TB).

So let me clarify my understanding is correct or not.

These errors issued by JavaScript interpreter will still go to error 
console, won't they?
So, if I need to look at them, I touch the about:config to re-enable 
error console
to appear on the menu and then click the menu item to see the console 
for real.


Am I correct in the above understanding?


You are correct. Errors will continue to show in the Error Console in 
Firefox and Thunderbird. Also, these changes will not affect Thunderbird 
in any way.


The only change is the new Browser Console will become the default way 
to look at all of the errors you have in the Error Console - the same 
ones, and even more stuff. So, in Firefox you do not need to enable the 
Error Console (unless you want to!). The Browser Console is made with 
the goal to track errors that are not related to the web.


Best regards,
Mihai

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

Re: Annotating Commits

[Benjamin Smedberg]

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 messages). Here are some examples:
I don't think this is a good idea, except perhaps for DONTBUILD/CLOSED 
TREE. You'd be hiding essential data from the web hg log/blame, the 
client hg log/blame, the git equivalents of those, and all sorts of 
external tools like hgk. You'd have to do extensive surgery on things 
like MQ in order to preserve the relevant data in MQ patches.


The incremental value of having the secondary metadata is far outweighed 
by its invisibility, the amount of work required to update just the 
basic developer tools, and the extra extension install step that would 
be required for all developers.


I think that anyone who had time to do this work could spend an 
equivalent amount of time and get a decent "pull request" system 
integrated with bugzilla, which would be an order of magnitude more 
valuable.


--BDS

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

Re: reorganizing some test directories

[Scott Johnson]

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/browser
> /tests/chrome
Will this also affect reftests? Specifically, if we had the following
structure:

/tests/mochitest
/reftests/

Will the latter be affected and placed in /tests/reftests?

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

Re: TB Tryserver WIN32 Build question: merge failure of the change to M-C portion of the source.

[Joshua Cranmer 🐧]

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 
patches twice, which, obviously, fails. The solution I added (kudos to 
Mark Banner for originally coming up with it) was to add these lines to 
my push-to-try script:
  sed -i -e 's/--hgtool=[^ ]*/--apply-patches/' 
$ccrepo/build/client.py-args
  sed -i -e '/ALWAYS_RUN_CLIENT_PY/d' 
$ccrepo/mail/config/mozconfigs/win32/*


[ccrepo is a shell variable that refers to the root of the comm-central 
repository]


--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

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

Re: reorganizing some test directories

[jmaher]

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 structures 
> > from #1 to a format of #2.  This means we would see:
> 
> > /tests/mochitest
> 
> > /tests/browser
> 
> > /tests/chrome
> 
> Will this also affect reftests? Specifically, if we had the following
> 
> structure:
> 
> 
> 
> /tests/mochitest
> 
> /reftests/
> 
> 
> 
> Will the latter be affected and placed in /tests/reftests?
> 
> 
> 
> ~Scott

Great question- the main goal is to have each test type in a directory for that 
specific harness.  Currently reftest/crashtest files are in subfolders to 
indicate that.  The existing patches on the referenced bug have a couple 
instances of moving crashtests to the tests/ subfolder, but in general they are 
staying put. 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Landing on Trunk - Target Milestone vs. Status Flag Usage vs. Tracking for Future Releases

[Gavin Sharp]

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 sure it's a niche workflow. It's probably not well
> documented though.

Indeed. Now that mcMerge sets it automatically, it's pretty much
always set for anything landing on inbound (or any other integration
branch). And even before that came around, it was being set manually
quite consistently by a majority of developers when they landed their
patches, I think.

I don't mind switching to something whose purpose is a little bit
clearer and more explicit, but "the target milestone field is not
useful/can't be depended upon in its current state" is absolutely not
true and shouldn't be used as an argument in favor.

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

Using sqlite to implemnent Enhanced Customization APIs

[riadh chtara]

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 occurs if  sqlite will be used to implement this apis.
Enhanced Customization APIs include a external apis that could be run by
another program.
The problem is the following: what could happens if two processes try to
access the same database (firefox and another app try to change the setting
at the same time)?
Could this cause a problem?
And is it possible to neglect such problem because there is not
enough concurrency and it could in most of the cases never happen ? (see
http://stackoverflow.com/questions/4060772/sqlite3-concurrent-access)

Thank you a lot again
Best
Riadh
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: reorganizing some test directories

[Benjamin Smedberg]

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 possible and put all the tests in a single tests/ directory. 
Or even for small code modules, skip the tests/ directory entirely and 
put the tests directly next to the code.


--BDS

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

Re: reorganizing some test directories

[Gregory Szorc]

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 others).
>>
> Do these manifests include associated files (e.g. iframes, images?)

Presumably, yes.

>
>> Now, the real question is whether we still generate Makefile for
>> these directories. If everyone used mach commands for running tests,
>> we wouldn't need Makefile or their targets to invoke per-directory
>> tests.
>>
> Don't mochitests use TEST_PATH from the root Makefile? I can't
> remember which tests need a per-directory Makefile but it might
> include xpcshell tests.
>

My memory is foggy since I've been using mach exclusively for months.
But, I know xpcshell tests have you invoking a leaf Makefile. e.g. |make
-C services/sync/tests xpcshell-tests| or |SOLO_FILE=test_foo.js make -C
services/sync/tests|. What makes it confusing is the xpcshell test
directory doesn't usually contain a Makefile, so you have to know where
XPCSHELL_TESTS is defined. Since mach talks directly to the xpcshell
test harness, you just need to give it a path to a test file or
directory and it "just works." Not to mention you can just type |mach
help xpcshell-test| to see how you can influence test execution. Try
doing that with make!

Once the build system is aware of the type of every test, my plan is to
expose a |mach test | that automagically invokes the appropriate
test runner(s). We could even go a step further and do |mach do |.
If the path is a .cpp, it gets compiled. If it's a test, it gets
executed. There's a lot of magic you can do once annotations are in
moz.build files...
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Landing on Trunk - Target Milestone vs. Status Flag Usage vs. Tracking for Future Releases

[Steve Fink]

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 explained.

The name "target milestone" implies an aspirational landing. Should we
just change the bug template to change the name of the field? "Fixed In"
would cover the current usage, it seems to me. Or perhaps "Fixed By" if
you want to split its meaning for resolved/unresolved bugs. The current
naming suggests that it's only valid for unresolved bugs, which is the
opposite of reality.

I use the field with its current semantics when fixing a bug that will
need aurora/beta approval, to figure out how what versions the
triggering bug affected. The alternative would be to use the landing
revision and try to figure out what version it first landed in, which is
probably doable but I don't know how. Using the target milestone is way
simpler, and probably more likely to be correct in edge cases.

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

Re: Landing on Trunk - Target Milestone vs. Status Flag Usage vs. Tracking for Future Releases

[Marco Bonardo]

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 "standard", even if, 
as said, it's surely not the best tool we may have.  A self-documenting 
name would solve most doubts.


By renaming the field though we "disallow" people from using it as an 
aspirational target field _while the bug is open_. On the other side, as 
Dolske suggested, the whiteboard can be used for that, so an immediate 
solution already exists.


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

Re: Landing on Trunk - Target Milestone vs. Status Flag Usage vs. Tracking for Future Releases

[Byron Jones]

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 would be possible to change the name of that field in the 
show_bug template on a per-product basis, it would be difficult on other 
pages such as advanced search.  i suspect this will cause more confusion 
that it would fix :(


--
byron - irc:glob - bugzilla.mozilla.org team -

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

Re: Annotating Commits

[Steve Fink]

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 computing statistics that could 
then drive automation optimizations. But I think using push metadata 
for all of this is a non-starter, both for new and existing 
contributors.

If I were to propose something, it would probably be (1) define a 
format for metadata that could be placed after the first line of a 
commit message, (2) make the automation check push metadata (the 
built-in kind) for DONTBUILD and CLOSED TREE, and (3) make tbpl expose 
DONTBUILD/CLOSED TREE and perhaps backout metadata in the UI. The value 
of #2 is debatable, since you can already put it after the first line 
and it's fairly easily ignorable.

If you wanted to ensure that #1 serves its purpose, you might also want 
to implement a push hook that requires that if the metadata is present, 
then it must be properly formatted (and semantically valid, to the 
extend that it's automatically checkable.)

I can also see the argument for externalizing this metadata, since 
there are some related things that are not known at the time of commit 
-- whether it crashed and burned on landing, for example.

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

Re: Annotating Commits

[Justin Lebar]

> 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 look at
only the first line of the commit message, so it seems to me this
would eliminate most of the aesthetic offense, without requiring us to
develop entirely new tools for interacting with our SCM.

This would have the added benefit of teaching people that they can
write multiline commit messages, which is something I hope we can all
agree on.  :)

On Thu, Apr 11, 2013 at 12:48 PM, Steve Fink  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. 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 computing statistics that could
> then drive automation optimizations. But I think using push metadata
> for all of this is a non-starter, both for new and existing
> contributors.
>
> If I were to propose something, it would probably be (1) define a
> format for metadata that could be placed after the first line of a
> commit message, (2) make the automation check push metadata (the
> built-in kind) for DONTBUILD and CLOSED TREE, and (3) make tbpl expose
> DONTBUILD/CLOSED TREE and perhaps backout metadata in the UI. The value
> of #2 is debatable, since you can already put it after the first line
> and it's fairly easily ignorable.
>
> If you wanted to ensure that #1 serves its purpose, you might also want
> to implement a push hook that requires that if the metadata is present,
> then it must be properly formatted (and semantically valid, to the
> extend that it's automatically checkable.)
>
> I can also see the argument for externalizing this metadata, since
> there are some related things that are not known at the time of commit
> -- whether it crashed and burned on landing, for example.
>
> ___
> 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: Annotating Commits

[Mike Hommey]

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 a new line
> at the bottom of their commit message?  Most of the time we look at
> only the first line of the commit message, so it seems to me this
> would eliminate most of the aesthetic offense, without requiring us to
> develop entirely new tools for interacting with our SCM.
> 
> This would have the added benefit of teaching people that they can
> write multiline commit messages, which is something I hope we can all
> agree on.  :)

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.

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

Re: Landing on Trunk - Target Milestone vs. Status Flag Usage vs. Tracking for Future Releases

[Justin Dolske]

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, that's my point. What do we _need_ to have, and can we support 
those needs in a clearer way than the current Target Milestone field.


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. That could also help out in the 
(admittedly rare) cases if a bug a branch-only fix 
(status-firefox23:unaffected + status-firefox22:fixed), because it could 
then automatically indicate "22 only" or "it's complicted".


Something similar could be done for "first fixed in".

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

Re: Annotating Commits

[Ted Mielczarek]

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 keys" which are what's used to
implement bookmarks:
http://www.selenic.com/blog/?p=644

It's possible we could piggyback on that.

-Ted

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

Re: Annotating Commits

[Gregory Szorc]

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
>> nicely.
> Mercurial has this thing called "push keys" which are what's used to
> implement bookmarks:
> http://www.selenic.com/blog/?p=644
>
> It's possible we could piggyback on that.

A potential concern with push keys would be Git users. If (and that's a
big if) we ever set up a Git server that allows pushes, I don't believe
Git supports a similar extensible model for attaching metadata to pushes
(it does support metadata on commits). I believe your recourse in Git
would be to push a specially-named ref and/or a special object (not a
blob, tree, or commit) and derive special behavior from that.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Landing on Trunk - Target Milestone vs. Status Flag Usage vs. Tracking for Future Releases

[Gavin Sharp]

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 trunk
in version X" and "backported to version X". If you're looking for a
trunk regression candidates, for example, you don't want to include
backport-only patches (since they were never on trunk in that cycle).

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

Re: TB Tryserver WIN32 Build question: merge failure of the change to M-C portion of the source.

[ISHIKAWA,chiaki]

(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 Windows try server is attempting to apply the patches 
twice, which, obviously, fails. The solution I
added (kudos to Mark Banner for originally coming up with it) was to add these 
lines to my push-to-try script:
   sed -i -e 's/--hgtool=[^ ]*/--apply-patches/' $ccrepo/build/client.py-args
   sed -i -e '/ALWAYS_RUN_CLIENT_PY/d' $ccrepo/mail/config/mozconfigs/win32/*

[ccrepo is a shell variable that refers to the root of the comm-central 
repository]



THANK YOU. I will try.

I need a small clarfication. The above sed commands need to be invoked on the 
try server.
Exactly what file is "push-to-try script"?
I mean which file should I change to include the above two lines so that they 
are invoked on
the TryServer after my job submission.

I have a patch below (as suggested in
https://wiki.mozilla.org/Thunderbird/Infrastructure/TryServer )
in my TB TrySEever Job submission. Presumably this can be omitted once I have 
the above two lines
that will take effect.

diff --git a/build/client.py-args b/build/client.py-args
--- a/build/client.py-args
+++ b/build/client.py-args
@@ -1,1 +1,1 @@
---hg-options='--time' --hgtool=../tools/buildfarm/utils/hgtool.py --skip-chatzilla --skip-comm --skip-inspector 
--skip-venkman --tinderbox-print

+--hg-options='--time' --apply-patches --skip-chatzilla --skip-comm 
--skip-inspector --skip-venkman --tinderbox-print

The name of the file to be modified or some try-server hooks or something
that I need to modify would be appreciated.
(Now it dawns on me that I may need to edit something on my TryServer account 
so that the above two lines
are changed before the TryServer kicks in...)


Now, does anyone know/suggest who should be contacted to have the web page description for Thunderbird TryServer 
submission updated? We need the community support for TB bug fixing and all that. And we need to ensure that

the basic document is up-to-date for that to take effect, correct?

I could come up with a replacement paragraph when I figure out all the details.

TIA



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

Re: TB Tryserver WIN32 Build question: merge failure of the change to M-C portion of the source.

[Joshua Cranmer 🐧]

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 linux64 work as expected?


The bug is that the Windows try server is attempting to apply the 
patches twice, which, obviously, fails. The solution I
added (kudos to Mark Banner for originally coming up with it) was to 
add these lines to my push-to-try script:
   sed -i -e 's/--hgtool=[^ ]*/--apply-patches/' 
$ccrepo/build/client.py-args
   sed -i -e '/ALWAYS_RUN_CLIENT_PY/d' 
$ccrepo/mail/config/mozconfigs/win32/*


[ccrepo is a shell variable that refers to the root of the 
comm-central repository]




THANK YOU. I will try.

I need a small clarfication. The above sed commands need to be invoked 
on the try server.

Exactly what file is "push-to-try script"?


I locally wrote a shell script that I call "push-to-try" that 
automatically does everything I need to do when pushing to try. One of 
its features is automatically converting applied patches in the 
mozilla-central repository to the applied patches. In effect, the actual 
change you would need to do is delete "ALWAYS_RUN_CLIENT_PY=1" from the 
mail/config/mozconfigs/win32/ files.


--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

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

Re: TB Tryserver WIN32 Build question: merge failure of the change to M-C portion of the source.

[ishikawa]

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 because the patches
fail although linux32 and linux64 work as expected?


The bug is that the Windows try server is attempting to apply the patches 
twice, which, obviously, fails. The solution I
added (kudos to Mark Banner for originally coming up with it) was to add 
these lines to my push-to-try script:
   sed -i -e 's/--hgtool=[^ ]*/--apply-patches/' 
$ccrepo/build/client.py-args
   sed -i -e '/ALWAYS_RUN_CLIENT_PY/d' 
$ccrepo/mail/config/mozconfigs/win32/*


[ccrepo is a shell variable that refers to the root of the comm-central 
repository]




THANK YOU. I will try.

I need a small clarfication. The above sed commands need to be invoked on 
the try server.

Exactly what file is "push-to-try script"?


I locally wrote a shell script that I call "push-to-try" that automatically 
does everything I need to do when pushing to try. One of its features is 
automatically converting applied patches in the mozilla-central repository 
to the applied patches. In effect, the actual change you would need to do is 
delete "ALWAYS_RUN_CLIENT_PY=1" from the mail/config/mozconfigs/win32/ files.




Thank you. I now see what I should do.
Creating a shell script to take care of the mundane act of picking up
the patches in mozilla-central repository, and creating/updating the files
[mozila-something-*.patch files and adding/committing in c-c portion of the
source tree so that Thunderbird TryServer will pick them up and apply is
something I was hoping to do soonish. Now that I got the hang of mercurial
MQ [a prerequisite of using tryserver], I will see what I can.

Thank you again.

PS: I can summarize this and come up with a new paragraph for Thunderbird
TryServer Web page. What should I do?
Should I file a bugzilla on this so that the paragraph is replaced?



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