Day One: October 14, 2008

This will be the main day of the conference and likely the only day that tries to follow a formal agenda.

Goals

[markphip]: My goal is to come away from this day with a roadmap for 2009. At a high-level ... what are the main features we want to tackle, what sort of release timeline do we want to follow, and who is prepared to work on these features.

[hwright]: Not a goal, per se, but it would be nice to have a keysigning party while we're all together.

Notes

I believe we need to be out of our room by 5:00 PM on this day. At 7:00 PM a Developer's Roundtable event will be held where conference attendees can ask questions to the developers attending the summit. This will be followed by some kind of social event. We need to be out of the room so that it can be prepared for these events.

Agenda

Introductions

Topic Brainstorming

Here are some topics we can talk about.

• Release policy. Do we want to firm up our plans around time/based releases? What, if any, considerations for managing our source tree do we need to take into account if we are using time based releases. IOW, we want to minimize the need to remove unstable code from a release.

• ReleasePlanning -- what features do we target, if any, for a given release?

• Tree-conflicts. Status of this feature for 1.6 release. What additional work do we need to consider for 2009 and beyond?
• Merge tracking. Current state of the feature and discussion around improving the management of the svn:mergeinfo property. Also, we need to discuss the reflective merge problem. Can the --reintegrate option be improved. Can progress be made on the ideas Kamesh has proposed around issue 2897? What about the current design do we like or not like? What can reasonably be changed?

• WC-ng. This is a hugely important feature for a number of reasons. Let's discuss the current plans for this feature. [wc-improvements], [wc-ng-design]

• Performance. The WC rewrite should make huge strides in this area, but what more can we do to make SVN perform better? As an example, the current performance of merge is not good enough.
• Off-line commits and other distributed features?

• New HTTP library focused on performance.

• fsfs performance with NFS. (This spawned hwright and cmpilato's idea of fsfs shard packing.)
• Revision graphs? What sort of API improvements could we make that would allow people to create revision graphs without having to invent their own cache of the repository?
• Unicode problems.
• Where are some of our long-lived branches headed? Custom diff/patch stuff, fs-successor-ids, fs-rep-sharing, metadata, ...
• Conference funding -- sorting out how to deal with this post-facto for this meeting, and in advance of future meetings.
• Encouraging a reduction of the defect backlog. Open Bughunt Season!
• Issue tracker management -- fiddling with metadata to create associative relationships between, say, WC bugs and the WC rewrite feature request. Better public visibility into "hot" issues, issues targetted for the upcoming releases, etc.
• What's the status of and release plans for the ctypes bindings?
• Google Summer of Code ideas

Topic Exploration

Follow along here for day one discussion

Release Timing / Logistics

• [CONSENSUS] Release every 6 months, aiming for releases in June and December. Branching 8 weeks prior (2 for stabilization, 4 for soak time, and 2 spare for resoak if necessary), with intermediate "beta" releases at branch time and perhaps weekly thereafter.
• some open questions about API stability / trunk policies with respect to release planning.
  • Does moving to strict time-based releases require branch-based development to ensure API sanity? Consider annotating the problematic class not-yet-fully-finished APIs as "experimental" and therefore subject to change in future releases.
  • We need better API-level testing (some ideas here include Python setup and then C testing, or Python direct binding testing)
  • Do we redefine "trunk is to be kept relatively stable" to include that trunk's API is also kept relatively stable (meaning, release-ready or near to it)? The whole private header directory thing feels "icky".

Tree Conflicts

Expected for 1.6:

Files

• Detection: complete
• Status/info: complete
• Commit blocking: complete
• Resolve:
  • basic "is resolved": yes
  • documented cases of how to achieve yours/theirs/etc.
  • interactive: no
  • auto-resolve: no
    • (meaning double-delete, double-copy, double-add, ...)

Directories

• Detection: partial
• Status/info: complete (where detected, of course)
• Commit blocking: complete
• Resolve:
  • basic "is resolved": yes
  • documented cases of how to achieve yours/theirs/etc.
  • interactive: no
  • auto-resolve: no
    • (meaning double-delete, double-copy, double-add, ...)

Intended for 1.7+:

• ...

Merge Tracking

How do tree conflicts factor in? Merge tracking only decides the revisions to merge, merge itself will be updated to handle tree conflicts.

Idea: New storage mechanism for svn:mergeinfo. Force user to commit an entire merge or fail it. Basically, if we do not use properties we need to know when "pending mergeinfo changes" ought to be sent with a commit.

Idea: Expand merge tracking records to support notion of delta-against-parent (instead of only explicit-full-mergeinfo as we have today)

Reflective Merges (Issue 2897)

Kamesh gave a nice presentation that explains reflective merges and his proposal for handling them. We were all interested in seeing it in action. One area of question was whether we need to store new data in the repository that describes the revisions merged in a specific revision. It was suggested that log -g needs the same information and he should examine the API and logic it uses to see if it can be reused. If it can't, it still might make sense for a single API used by both.

Julian suggested Kamesh try to implement his solution from the client, even if it is slow. This would let us prototype the core concepts on our own repos and the logic could be moved to the server to make it faster for 1.7.

What we need to know is if the concepts behind his change to the merge algorithm will deliver the results we need. Some of the details his algorithm needs can be made better once we know this direction will work.

Working Copy Improvements

Status: Greg is working right now on cleaning up the API. Some example issues include places where the code assumes that given admin files live in particularly named locations, or APIs that return said locations which arguably aren't of general interest. There are some compat concerns here, to be worked out.

See DayTwoAgenda for the continuation of this topic exploration, or go back to FrontPage