Clone wiki

kallithea / DeveloperMeeting2016January

Kallithea meeting Antwerp — January 2016

  • Introductions (Thomas De Schampheleire, Mathias De Maré, Jan Heylen, Andrew Shadura, Søren Løvborg, Mads Kiilerich)

  • Kallithea Organization and project — talk about how we do PRs, reviews, releases, stability

  • Dogfooding: Should we do Kallithea code pull requests to our own Kallithea?
    • Just do it!
    • need a way to "patch-bomb" pull requests from Ook to the mailing list to give transparency / visibility
    • would be nice to also 'read' comments sent by e-mail and apply to the web interface
    • our own Kallithea is (currently) not set up for public hosting or self registration - that could block 'new contributors', so auto-registrations should be interesting, should create accounts for contributors
      • Andrew created accounts for Jan, Søren and Mathias
      • meanwhile: we should probably have an option to send an email to a newly created user that their account has been created so that they reset password for themselves
      • Andrew has played with OAuth-based registration, but that went nowhere… (turbogears with repoze.who may help here)
    • with auto registration, people will be able to comment/review without further work
  • Mads is managing things conservatively and slowly - more feedback, reviews and opinions from other contributors would help make it more smooth and faster
    • Also attract more contributors could help in that aspect.
  • Regular releases (could also help in attracting contributors)
    • Should make one with hg 3.7 support very soon ;-)
    • Should not (visibly) tie releases too closely to Mercurial releases, to avoid misconception that we're Hg only
  • Some kind of general roadmap would help for people contributing

    • Based on next section, agreed on high level roadmap:
      • Web framework: move to TurboGears (branch), supporting Alessandro
      • SQLAlchemy's alembic (gating for database changes)
      • Bootstrap UI
  • Big changes - blocking

  • Bootstrap/layout / (mobile friendly)
    • rebasing this work is getting 'painful', a merge would be less work, or we could perhaps stay at an older version of Kallithea and only do 'one' final painful rebase?
      • we will figure it out when it is ready - for now, merging to dev branch instead of rebasing it is fine ... but try to keep the dev branch clean
    • hope to make progress soon ... but no hard commitments
    • impressive bootstrap demo from Andrew: bootstrap from the bottom up looks like a good approach to really get css cleaned up
  • Web framework: Pylons, Pyramid, TurboGears2 (WiP/PoC by Alessandro Molina), ...
    • Partially/possibly related: integrate or borrow ideas/implementation from Review Board https://www.reviewboard.org/ could be an argument for using same framework
    • The prospect for TurboGears and the proposal and work by Alessandro are persuasive. No alternative would be "easier", good chances for success, worst case outcome would not put us in a worse position than now.
  • pytest migration
    • switch the default to pyTest (just do it)
    • fix tox (currently not able to test python 2.6?)
  • Database migration
    • Could be interesting to rethink the ideal high level data model and how that would map to database layout, model: where do we want to end up and how will we get there
    • Hassle-free db upgrades and downgrades (for users and developers, preferably also in the presence of branchy development...)
    • migrations should be based upon (the loosely SQLAlchemy associated) alembic: https://pypi.python.org/pypi/alembic
    • our built-in sqlmigrate should be killed - but we want to keep it around until alembic is ready - we might have to use it for some features we just want
  • SSH

    • current patchset has too much duplication, has to be relooked into, TODO on the PR
  • Ideas from participants demoing their local installations, work flows and local customizations that may or may not be suitable and ready for upstreaming

    • My pull requests: do not show requests that I have responded to already
    • Naming: pull request / review request / "series"
    • Voting: rejected / needs work / ... vs. +1 / +2
    • Vacation note, admin note
    • updated pull request comment should not be in the free-text field
    • the word 'update' could be chosen differently - "refresh", "augment", "rebake", "adding", "append", "include"
    • Potential additional reviewers based on glob pattern and filenames
    • collapse per file using jQuery (in the Bitbucket queue: https://bitbucket.org/conservancy/kallithea/pull-requests/201/from-unity-2016-01-22/diff)
    • a per repositoy/per user pull request overview
    • lightweight issue tracker, Unity has an implementation in their local customization, based on feature branches (so issues kept together per 'branch')
    • change color scheme to some less-ugly default
  • Discussion of Pull Request stuff:

  • Draft comments, how to upstream?
    • rebase existing changes (the code changes)?
    • leave the comment editable after save, with message "Saved on (date,time)".
    • no longer rely on the (removed) preview system - leave editable
    • make mails with multiple comments contain link to each comment
    • proposed steps
    • perhaps as first first step, auto save as draft (and disable "navigate away from changes" when saved), make them show up on page load, but still have per comment save
    • make whole page save button, requires making it clear what will be saved (list the drafted comments just above the 'commit all comments' field at the bottom), server still processing each comment separately
    • make server process all at once, only send one mail
  • Showing comments from individual changesets, also on global pull request page (and vice-versa)
    • (use annotate to find the source line of a change. A 100% accurate solution is not possible, unmatched comments could be shown at the bottom. An initial rough version could try to get the simple cases correct, later refinements could be done in later iterations.)
    • Don't reinvent the wheel though, use diff algorithm theory and save context chunks (and like patch, 'reapply' the comment).
    • Realize that the only places you need to search for are the commits that are part of this pull request, not of the entire repo.
  • Coupling pull requests across rebases (One possible solution for Mercurial could be based on the 'extra' fields: 'histedit_source', 'rebase_source', 'amend_source'. A second could be using 'Mercurial evolve'.)
  • Coupling comments across rebases (possibly using a best-effort system with annotate)
  • Overhead of updating pull requests — can we lower it?
    • Carrying over of reviews / avoid redundant reviewing?
    • Coupling across rebases (as above)
    • Some interesting ideas from Review Board
  • Improving side-by-side diff
    • Andrew has ideas without using Mergely; also check what Review Board is using.
  • Improving standard diff:

    • more intelligent diff highlighting: highlight individual letter changes iso only words
  • Workflow support:

    • considering pull request/review request as 'a task' in a 'issue tracker'/'task tracker' could fix all these kinds of issues

    • Invite reviewers by group, for example an entire team, or module maintainers

    • Delegation of reviews by normal reviewers
    • Allow reviewers to review in differentiated capacities (e.g. review as maintainer of specific module)?
    • Split between required and optional reviewers
    • Unified reviewing and PR issue tracking? (would play well with all of the above)
    • "Automated reviewers" (style checks, CI test suites, etc.)
    • Avoid inviting real reviewers until the automated checks pass
    • How to better enable custom workflows (e.g. suggested/required reviewers)
    • Fitting Kallithea in a bigger delivery process (with compile-time validation, run-time validation, ...)
    • Unity: add local tag to show whether changes passed validation
    • Since requirements of organizations are different, just provide some proposed solution, or hook, or API, that an organization can hook into with their specific checks, or workflow steps.
    • Such checks could also be achieved by calling a web service when changes enter the system, letting an external system do all validation, then providing an API to give the results back to Kallithea (which then displays that in some form on the changeset or pullrequest).
    • Difference between notifications and 'tasks' (need action, have to mark as viewed, ...)
  • Tour through pending Pull Requests and brief discussion on how to move forward on stuck PRs

    • repository settings (phases and hooks): alternative approach is to save the settings in the repo .hgrc or corresponding .git file.
    • notifications: add pr_title and message_firstline to email subject: verify difference with patch ever sent by Thomas DS

(not discussed):

  • Feature requests from users:
    • diff limit to prevent OutOfMemoryError (load chunks on demand - like Review Board?)
    • filtering on pull request overview page (e.g. branch)
    • comments: allow toggling visibility of individual/all comments
    • vote on pull request results in vote of all changesets, even if different votes were given on changesets
    • PR to email gateway (diff and comments), and even better, email to PR gateway

Updated