← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/performance-roadmap-rationale.txt

  • Committer: Canonical.com Patch Queue Manager
  • Date: 2007-06-06 08:37:14 UTC
  • mfrom: (2506.1.4 installer-0.17)
  • Revision ID: pqm@pqm.ubuntu.com-20070606083714-rt2za45t9gt5nqqh
(bialix,r=john,r=aaron) sanitize dev docs (performance-roadmap) &
 win32 installers improvements

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/performance-roadmap-rationale.txt
1
1
What should be in the roadmap?
2
 
------------------------------
 
2
==============================
3
3
 
4
4
A good roadmap provides a place for contributors to look for tasks, it
5
5
provides users with a sense of when we will fix things that are
28
28
have learnt over the last years.
29
29
 
30
30
What should the final system look like, how is it different to what we have today?
31
 
----------------------------------------------------------------------------------
 
31
==================================================================================
32
32
 
33
33
One of the things I like the most about bzr is its rich library API, and
34
34
I've heard this from numerous other folk. So anything that will remove
50
50
on what we have learnt.
51
51
 
52
52
What use cases should be covered?
53
 
---------------------------------
 
53
=================================
54
54
 
55
55
My list of use cases is probably not complete - its just the ones I
56
56
happen to see a lot :). I think each should be analysed comprehensively
88
88
 * update
89
89
 * cbranch
90
90
 
91
 
how is development on the roadmap coordinated?
92
 
----------------------------------------------
 
91
How is development on the roadmap coordinated?
 
92
==============================================
93
93
 
94
94
I think we should hold regular get-togethers (on IRC) to coordinate on
95
95
our progress, because this is a big task and its a lot easier to start