[synchronization] Needs for a better way to synchronize external dependencies

RESOLVED WONTFIX

Status

Testing Graveyard
Mozmill
RESOLVED WONTFIX
8 years ago
2 years ago

People

(Reporter: whimboo, Unassigned)

Tracking

Details

(Whiteboard: [mozmill-2.0-])

(Reporter)

Description

8 years ago
Right now we have the sync_dependencies.py script which pulls the latest version of httpd.js and EventUtils.js from hg.mozilla.org and applies the available patches to make those work with Mozmill. 

http://github.com/mozautomation/mozmill/blob/master/mozmill/scripts/sync_dependencies.py

http://github.com/mozautomation/mozmill/tree/master/mozmill/patches/

The modified files are still part of our repository. The question is if we should pull recent versions via hooks or still want to do it the same way as for now. Using hooks could be a lesser optimal solution, at least once major changes happened to the original code and we can't apply our patch. That would mean it will be broken. On the other side we wouldn't have to store a separate and modified copy in our repository.

What do you think? Do we have other options? If we wanna continue with the current way, which type of patches shall we produce? "git apply" is really bad in applying patches while patch works pretty well. Do we wanna have git diff's or default diffs?

I still have to update the httpd.patch but want to wait for a solution on this bug.

Comment 1

8 years ago
I would be against hooks.  As far as git apply vs patch, I vote for patch, but i'm +0 on it.

httpd will be going away from mozmill at some point soon, I think, anyway, unless I've misunderstood.  So then it's just EventUtils.js, and we should probably reconsider that issue when it is just one file.

So I'd say go ahead and patch this any way now.  IMHO we probably don't need this bug since httpd.js is going away anyway and then we can figure out what to do with EventUtils.js down the line.
(Reporter)

Comment 2

8 years ago
(In reply to comment #1)
> httpd will be going away from mozmill at some point soon, I think, anyway,
> unless I've misunderstood.  So then it's just EventUtils.js, and we should
> probably reconsider that issue when it is just one file.
> 
> So I'd say go ahead and patch this any way now.  IMHO we probably don't need
> this bug since httpd.js is going away anyway and then we can figure out what to
> do with EventUtils.js down the line.

Clint, I would love to also get a feedback from you on this topic.

Comment 3

8 years ago
I agree with Jeff.  Neither of these files should live in the mozmill repo.  Neither of these should require patches to work with Mozmill.  We need to understand why we're patching them and then either land those changes "upstream" or fix mozmill not to require those patches.

Updated

8 years ago
Whiteboard: [mozmill-2.0?]
(Reporter)

Comment 4

8 years ago
(In reply to comment #3)
> I agree with Jeff.  Neither of these files should live in the mozmill repo. 
> Neither of these should require patches to work with Mozmill.  We need to
> understand why we're patching them and then either land those changes
> "upstream" or fix mozmill not to require those patches.

That make sense. But until we have a solution here, I should update the patch so we can make sure that it will not fail when trying to patch the httpd.js or eventutils.js in the future. Would that be ok?

Comment 5

8 years ago
(In reply to comment #4)
> (In reply to comment #3)
> > I agree with Jeff.  Neither of these files should live in the mozmill repo. 
> > Neither of these should require patches to work with Mozmill.  We need to
> > understand why we're patching them and then either land those changes
> > "upstream" or fix mozmill not to require those patches.
> 
> That make sense. But until we have a solution here, I should update the patch
> so we can make sure that it will not fail when trying to patch the httpd.js or
> eventutils.js in the future. Would that be ok?

Yeah, that should be fine.
(Reporter)

Comment 6

8 years ago
(In reply to comment #5)
> > That make sense. But until we have a solution here, I should update the patch
> > so we can make sure that it will not fail when trying to patch the httpd.js or
> > eventutils.js in the future. Would that be ok?
> 
> Yeah, that should be fine.

I'm kinda unsure which diff format we want to have. Creating a diff file in the git format is kinda hard and I always forget about the steps. On the other side it's much better readable as the default 'diff' format. What would you propose?

Updated

8 years ago
Summary: Needs for a better way to synchronize external dependencies → [synchronization] Needs for a better way to synchronize external dependencies

Comment 7

7 years ago
Where are we on this?

Comment 8

7 years ago
Not sure if we are anywhere ;) The problem is clear;  not sure what the solution is.  Ideally there would be a generic tool to sync external dependencies irrespective of project.  Probably not hard to do, but perhaps hard to spec

Comment 9

7 years ago
This isn't really a mozmill bug, -> wontfix
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX

Updated

7 years ago
Whiteboard: [mozmill-2.0?] → [mozmill-2.0-]
(Reporter)

Comment 10

7 years ago
Why not the current scripts are located in the mozmill repository and this bug is about to improve those. Even when it doesn't block any Mozmill 2 work, it's still Mozmill related.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

Comment 11

7 years ago
(In reply to comment #10)
> Why not the current scripts are located in the mozmill repository and this bug
> is about to improve those. Even when it doesn't block any Mozmill 2 work, it's
> still Mozmill related.

No, we decided in the meeting that those scripts will be removed and this will be solved outside of mozmill entirely, probably through new python packages and dependencies.
(Reporter)

Comment 12

7 years ago
Even with those scripts removed, the problem persists and has to be tracked until it is solved. So if this is not the right component move it accordingly.
(Reporter)

Comment 13

4 years ago
Mozmill will reach its end of life soon. We are currently working on getting all the tests for Firefox ported to Marionette. For status updates please see bug 1080766.
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago4 years ago
Resolution: --- → WONTFIX
(Assignee)

Updated

2 years ago
Product: Testing → Testing Graveyard
You need to log in before you can comment on or make changes to this bug.