On 2015/04/22 22:15, Ehsan Akhgari wrote:
Note that it's not just the turn around time that can become an issue.
For me personally the reasons I choose to not use the try server are:
1) If I have ~20 unlanded patches in my queue (which is normal for my
workflow on an average day), I need to juggle 20 open tabs for 20 try
pushes if I wanted to send each one of them to the try server, which
means that I would need to spend the time to look at each result, go
through the intermittents on them, retrigger the runs for the
intermittents that have not been filed yet (I get them surprisingly
often), etc.
I gave up on using tryserver when my hg patch queues
became around 20 ~ 30 for a similar reason.
If code is very mature and I only realize a few bugs a year, it is OK.
But code like C-C TB has so many hidden issues, accumulated over the
years, when one starts to investigate a real-world issue, one can easily
end up with 20 patch queue entries over time :-(
To me, it is a mystery how one can cope with the situation with
hg queue feature. If a single bug is tackled fine. But when multiple
bugs are noticed and handled at the same time, it needs improvement (I
found git is much more amenable in this regard by making different
branch creation very easy, but I digress.)
Back to my main topic:
I use my local PC to test the patch that it builds and passes tests.
Only when I am not quite confident that my patch tested locally on linux
would not break Windows binaries, I ask someone to push it to try.
(I am mainly submitting patches for C-C TB, my main mail client.)
Oh I remember now:
Another practical reason I have not used try for C-C TB for sometime
is this.
In C-C TB, we have a subtree of a clone of M-C under "./mozilla"
subdirectory.
Submitting patches to the main C-C portion is easy.
*IF*, however, one needs to patch code under M-C subtree also,
we have an issue.
We have to go through a contortion of creating a tentative copy of patch
IN the top-level directory of C-C which tryserver cleverly understands
as a patch for M-C portion,
and changes it into the patch for M-C portion of the tree and apply it
before running the build and test jobs.
I am sure many TB developers have tried to automate this process of
creating the tentative copy of M-C patch at the top-level directory
by creating a script on their own. It is a tricky procedure prone to
errors if done manually.
Now, such a script needs to look at
the patch queue as a whole so that one does not misses a patch to be
submitted.
However, this means that, if like many developers, one has a lot of
unrelated patches, there is a problem.
I work on multiple bugs and mutiple set of patches at the same time,
When I need to submit a job to tryserver in order to test the particular
patch set to fix a bug, I need to clear from the patch queue of other
unrelated patches so that my hand-crafted script for patch job
submission to tryserver
does not pick them up.
This clearing the patch queues before try server submission forced me to
give up the use of try server. I can't have so many
different source trees just for try server job submission.
(git makes it easy to create branches easily.)
On my local test, I can barely manage the testing of intended patches
only by re-ordering the patches in the queue and only applying the first
N patches and test. Only when this works, I submit the patches to bugzilla.
(git makes it easy to create many branches easily and I can test a
particular bug fixes there. Maybe using a queue of patch queues(?) is a
way to go with HG/mercurium locally, but
I have no idea how such approach can work with try server job
submission. Remember the M-C patch handling? If I have multiple queues,
I don't think a simple script can work it out.
BTW, This complexity is one reason many developer wish for C-C merge
with M-C. If C-C subtree can sit below the main M-C tree as a mere
sub-directory, NOT an independent repository,
I think some practical issues will be gone.)
So I am trying to test my paches with tryserver or local test although
there is practical difficulty of using tryserver under the circumstances.
Well, less workload on tryserver is a good thing :-)
However, looking at the discussion, although I thought that everyone
checks the patches locally if try is not used,
this may not have been the case always.
That at least ought to be clearly documented (!?).
TIA
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
