Project Messages

  • gugahoi

    Logging Standards

    Posted by gugahoi on Apr 10th | 0 comments | 0 attachments

    Just want to clarify for future development what the logging standards will be.

    TIME :: LOG-LEVEL :: MODULE NAME :: message

    As an example:

    17:07:36 :: INFO :: LIBRARY :: Retrieving movies
    17:07:42 :: INFO :: LIBRARY :: Showing only unwatched movies

    Any changes or ideas are welcome...

    Tuesday Apr 10

  • Brad

    Streamlined setup process

    Posted by Brad on Jan 11th | 4 comments | 0 attachments

    This ticket is to discuss streamlining the setup process. It will probably involve:

    • choosing just one way of serving Maraschino (CherryPy's WSGI server, Werkzeug, etc.)
    • looking at the existing process, identifying what is tricky, working out any kinks
    • improving the documentation


    Wednesday Jan 11

  • Brad

    Programming style guide

    Posted by Brad on Dec 20th | 3 comments | 0 attachments

    When committing code, please ensure that that your editor is set up in the following way (my "dotfiles" repo on GitHub contains my emacs setup if that helps):

    • Use Unix encoding
    • Use spaces instead of tabs
    • Don't commit trailing whitespace (I've set up emacs to highlight trailing whitespace in red, which helps me avoid committing it)
    • Files should contain a newline at the end (I've set up a pre-save hook in emacs to insert one when I save)

    Regarding indentation:

    • Python: 4 spaces
    • Everything else (HTML, CSS, JS): 2 spaces

    Regarding commits:

    • Make them as small and autonomous as possible
    • Same for pull requests; one feature at a time please
    • If changing the indentation of a block of code, please don't mix it in with code changes (as this will be hard to review)

    Tuesday Dec 20

  • Brad


    Posted by Brad on Dec 12th | 3 comments | 0 attachments

    Am I right in thinking that we can only have 2 members on a free Lighthouse account? If so that sucks as there are 3 of us. Anybody know if this changes if it's open source or whatever?

    If there's no way around this, do we need to find a new ticketing system? Not keen on paying $15/mo for 3 members...

    Monday Dec 12

  • Brad

    Development plan

    Posted by Brad on Dec 11th | 2 comments | 0 attachments

    Hey guys (specifically gugahoi, DejaVu, antant, Mikie-Ghost),

    I decided that it was time to finally sort things out with regards to development, as you're all doing such amazing work and there's no possible way that I could find the time to review every single thing before adding it to the official repo. This is what I've decided on:

    • Some of you are now contributors in the official GitHub repo (, so you can commit to it as you see fit.

    • I merged Maraschino/maraschino/master into the official repo on a new branch (mrkipling/Maraschino/prerelease).

    • As you can now all develop on the official repo I think that it would be a good idea to delete the Maraschino account, as that just confuses matters. Let's keep it all in the official repo and personal forks.

    • Master branch remains the same for now. Let's work on tidying up prerelease until it's pretty solid before adding new features, then we can merge it into master. By "tidying up" I mean that we need to make sure that there aren't any bugs, the code is clean and re-usable, and the design/UI is up to scratch. We can discuss this in more depth later. I've created a new milestone ("v0.1") for this release.

    • Please go through Lighthouse and create tickets for any new modules/features that you have done on prerelease (the former testing repo) assigned to milestone "v0.1". Similarly, please assign any existing tickets that are on prerelease to v0.1. This will show us what is left to be tidied/reviewed before prerelease is good to go.

    • Once we've released prerelease, we will use good practice to stop things from getting messy - new features will be written on their own branch (e.g. a movie recommendations module would belong on movie-recommendations), and when tested, merged into master.

    • Please feel more than free to do bug-fixes and such straight on master, but for new features I'd appreciate it if they were done on a different branch and shown to me for approval before merging into master. Hope that's not too much of an imposition, I just want to make sure that Maraschino is headed in the right direction.

    Thoughts/opinions, everyone?

    Sunday Dec 11

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

Open-source front-end for XBMC HTPCs

Shared Ticket Bins

Recent Comment Activity