Warning, /sdk/kdesrc-build/ROADMAP is written in an unsupported language. File is not indexed.

0001 The Roadmap
0002 -----------
0004 This is a list of the changes that I would like to have made in the upcoming
0005 versions, as of 2012-05-06. Unfortunately I can't give a good timeframe:
0007 1. Further modularization. This is to support enhancing the test suite by
0008 having clear boundaries between components and better-defined requirements for
0009 integration of those components.
0011 1a. Specifically, move git-related code to GitUpdate. DONE.
0013 2. Make the changes necessary to build Qt 5.
0015 3. Better documentation. Even if this means having a Markdown-to-DocBook
0016 converter, it would be much nicer to have documentation that was at least
0017 semi-consistent with the current state of building KDE software.
0019 4. Reduced duplication.
0021 4a. Remove support for "built-in" modules entirely, instead
0022 fallback to a kdesrc-buildrc hosted on KDE's git infrastructure if the user
0023 doesn't define one. DONE.
0025 4b. The kdesrc-buildrc-setup should be able to use this
0026 fallback kdesrc-buildrc as well when offering options.
0028 5. Generate `.xsession`/`.bashrc`/`.bash_profile` entries. i.e. make it
0029 possible for the environment variables needed to _run_ the installed KDE
0030 software be automatically setup by kdesrc-build, either by generating the
0031 appropriate rc files or by using kdesrc-build as a trampoline (e.g.
0032 kdesrc-build --launch startkde). DONE (2012-11-21, see xsession: commits)
0034 6. Test suite. Should be self-explanatory but the test suite can be far better
0035 than it is now. Probably should go Perl-style and split the large
0036 kdesrc-build-test.pl into a t/*.pl containing unit tests and whatever
0037 integration tests can be cooked up.  But then again, it's not like we're
0038 launching astronauts into space, so don't go overboard.
0040 7. A distro-specific "auto packager" script. I.e. some way to say "install the
0041 base dependencies that are expected to be provided by the system" and have it
0042 kept up-to-date by volunteers using each distro (not that I'd hold my breath,
0043 but it has to be better than what we have now)
0045 8. Improved output. The current output, even in --verbose, is very noisy.
0046 Instead a "dashboard" approach would be better (for ncurses). It would be nice
0047 to support GUI output if a GUI is available but it should remain optional to
0048 support headless installs.
0050 9. "Network install". Right now kdesrc-build is a single-script install that
0051 tries to rely only on Perl 5.10 core modules + LWP. Instead the single script
0052 should be a shell that downloads Perl modules of kdesrc-build as needed from
0053 anongit.  We would need to investigate how to ensure this is cryptographically
0054 safe for users, or if this is already assured by the git SCM.
0056 10. Continue porting code to standard Perl modules. Probably the biggest
0057 "problem child" to go next would be the process_arguments subroutine which
0058 really needs to be handled by a Getopt-alike.
0060 11. System reporting tool for reporting bugs. Possibly even using XML-RPC to
0061 post bug to bugs.kde.org automatically (or at least launch the wizard right).
0063 12. Use CPAN. Although I've been trying to keep kdesrc-build a kind of
0064 hyper-documented Perl, this hasn't helped a great deal with code contribution.
0065 It would be nice to be able to use some CPAN modules but I don't want to
0066 require they be installed beforehand. Having a way to download from CPAN
0067 automatically and save to the kdesrc-build working directories would solve this
0068 but again would need to look into how to mark whether a given CPAN module has
0069 been tested by the KDE developers...