Details

April 9th, 2013 @ 11:30am PDT / 2:30pm EDT

dial-in:

• vidyo: Jgriffin's vidyo room

Backchannel #ateam on irc.mozilla.org

Take meeting notes here: https://etherpad.mozilla.org/great-automation-refactor Then copy and paste them below afterwards

Meeting Notes

Quick Status Updates

• [ahal] b2g mochitests now using mozprofile for profile management
  • seem to have regressed b2g desktop mochitests, need to investigate (bug 859485)
• [jhammel] some manifestdestiny improvements coming shortly

Issues of the Two Weeks (since you looked at me)

Mozbase discussion

• Currently mozbase is: in github, in tree, in pypi and in puppetagain
  • Test harnesses get it all sorts of ways
    • this creates confusion - a developer tries to fix a mozbase issue in testing/mozbase, but the change doesn't work because the puppetagain version is being used
    • this creates extra work - syncing from github to m-c, uploading to pypi/puppetagain
    • this makes turn around time for fixes longer
    • this hurts stability - merging a massive set of patches from github to m-c at once often causes problems
• What should we do?
  • Use in-tree packages instead of puppetagain? (https://bugzilla.mozilla.org/show_bug.cgi?id=855893) -> yes, no disagreement
  • Use requirements.txt files in conjunction with puppetagain to ensure a commit with a package update? -> no
  • Use strict versioning? -> leaning yes (no concensus reached)
  • pros:
    • ensures results are idempotent (we get this anyway for the in-tree case if we use in-tree mozbase)
    • guarantees a commit message is associated with a version bump (could use requirements.txt or in-tree mozbase)
  • cons:
    • potentially more difficult to maintain (we can use scripts to mitigate this)
    • potential conflicts if a consumer has two external packages requiring different versions (probably not likely)
    • easier for human error
• Should mozbase be moved to m-c for good? -> leaning yes (no concensus reached)
  • pros:
    • increases efficiency for automation developers (don't need to wait days or even weeks for changes to be mirrored)
    • better visibilty for developers, they can make fixes to the in-tree version where it won't be overwritten
    • no need to worry about mirroring and all the complexity it brings (in practice we've seen conflicts and backouts which add to turnaround time)
  • cons:
    • makes it more difficult for contributors, much higher barrier to entry
    • lose travis ci, readthedocs (we can still reverse mirror to keep them)
    • makes things more complicated for out-of-tree packages (they need to clone m-c to work on it, get it from pypi)
    • can't use git submodules to embed it in a project (eideticker works this way afaik)
  • If so how do we know when to version bump?
  • Should mozbase be removed from github?
    • could be just as complex as the current mirroring
    • would cause confusion for contributors/developers if the canonical repo all of a sudden switched (need good communication)
    • on the other hand, it might be good to reverse mirror for things like readthedocs, travis ci, git submodules etc..

• Immediate Action
  • Work on removing the dependency on mozbase in puppetagain
  • Work on adding mozbase tests to make check
  • both of these are prerequisites to moving mozbase to m-c and need to be done anyway

Milestone / goal discussion

• 2013 Q2: https://wiki.mozilla.org/Auto-tools/Projects/Mochitest_on_Mozbase#Goal_2013_tQ2