Skip to content
emorrp1 edited this page Sep 13, 2010 · 36 revisions

Welcome to the mintupload development wiki!

Branches

  • be more disciplined with git branches, anything not directly related to current branch shouldn’t be committed. Little fixes can be shoved on community, it’s then much easier to merge back in. This also makes pushing changes upstream much easier too. Keep changes for a commit small, if a bug is introduced, it’s much easier to find when rolling back.
  1. master – this will always reflect the upstream official version
  2. fixes – little fixes (sometimes bugfixes) that don’t change anything major, so stability is guaranteed, should hopefully be pushed upstream.
    • Should be considered release quality.
  3. stable – major changes, e.g. new configuration management when complete.
    • Main integration branch, off which community repo packages may be based.
    • Should be considered release candidate quality.
  4. community – provides a testing period for new features before they make it to stable.
    • Branch off which ppa releases are based,
    • Should be considered beta quality.
  5. all others are feature branches, and should be branched off community until ready for integration.
    • Should be considered alpha quality.

TODO

Things we should do…

  • better error handling
    • in progress, community branch has implemented basic errors, but actual calling, e.g. in mintUploader needs improving
      • further improved in community. Is this good enough?
  • improved interface management e.g. cli
    • relates to error handling, as that is one major abstraction issue.
    • in progress, see gui_abstraction branch
      • kinkerl implemented basic argument handling, no uploading possible yet
      • minimum abstraction has been achieved, could write CLI now, but more cleaning would be good
        • reasonable abstraction has been achieved, write CLI!
  • Fix: If a new service is created with the same name as an existing, the existing is overwritten without warning, perhaps error/warn/prompt instead
    • clem pointed out that some users are just stupid.
  • make the edit_service popup show the url/space etc. config lines if they are initially defined?
  • Perhaps a translations tab in the credits box to attribute all the translations
  • I wasn’t aware clem no longer sells mint-space accounts, which means the default configs (in read_service) might need rethinking too, as they were specifically designed to reduce the amount of configuration for mint-space users.
    • Perhaps make them more like Default
  • mintUpload wiki page (on main linuxmint wiki)
  • a copy service button in service config, useful for e.g. different paths
  • investigate potential integration with Jaunty’s new notification system
  • perhaps only use ppa for stable branch, as people can clone the repo if they want to test unstable features.
  • convert TODO items into issues? —> kinkerl: yes
    • in progress

Done / Testing (beta)

  • nautilus integration
    • according to clem: added manually via gconf when building the iso, any way we could get this in a mintupload-gnome package?
    • mintupload-gnome package is the first implementation of this: http://github.com/kinkerl/mintupload-gnome/tree/master
  • improved configuration management
    • done, see service_config branch, now merged into community, now pulled back into stable
  • reduce code duplication
    • done, in stable
  • investigate error handling with threads
    • done, in community, needed complete rethink in approach.
Clone this wiki locally