Quickly Reboot

What are we trying to achieve?

All related information are on this blog post.

Hangout sessions

developers feedback

Hangouts

Two sessions covered them and are available on youtube:

• First one

• Second

Notes

Those are the notes taken during the sessions:

• After running quickly create ubuntu-application -> what to do? The idea would be to have some workflow hint inside the newly created application. Some kind of "what's next?"

• Private libraries owned by Quickly: discussion about if it should be an inline or external library. Final say is that it should stays inlined. However, making it clear at the top that those files are part of Quickly and shouldn't be touched. A comment at the top of the file seems sufficient. We can then upgrade them automatically when needed, detecting if the file manually changed since last upgrade (md5sum?)
• Maybe we should just support one Quickly version for all versions and ship the tutorial online?
• quickly edit: some ideas about quickly edit opening too many files at once. We should stop opening the tests one I guess. Also some proposal about only opening the files that are oftenly touched. Maybe using zeitgeist for this? (doesn't seem a priority though)
• what to do with the files in debian/ ? Packaging should be seen as an implementation detail and get out of the way of the user (getting those generated and then throwed out).
  • What about customization for people who want to customize their build? Two approaches there:
    • still enables some additional data, like "quickly configure dependencies". We need a list of what people want to configure though.
    • having a packaging/ optional directory. If someone ship a file there, the file will be copied in the debian/ directory and not updated. For a debian/copyright file for instance, this solves the case of multiples copyrighted libraries imported from other projects.
  • that would mean that we need to keep the changelog history in same way in the project.
• Other discussions on licensing. Basically right now it's all of nothing. Someone contributes a patch to your project and you add him to AUTHORS, but then all files is getting the copyright. One of the solution for that is to have a DEP5-format like (maybe without the license content stenza?) in AUTHORS. We can prefiled some parts, get a parser to paste the right information. Still need to discuss how to boostrap it.
• Rework quickly templates versus quickly core interface. Templates should be class, with metadata, commands as well. This will enable to import them and interface them way more effectively with 3rd party like quickly-gtk. Also, all commands should be more then fine-grained to be able to only inherit for some snippet and some part of code between commands. Most of the work which can be shared between templates should be pushed in quickly core.
• Dependencies between commands were evocated. We can see multiples cases: quickly run for the unity-lens-template needs to have quickly install run before. Also quickly release needs quicky license to be run at least once. So we can see 2 family here:
  • Commands blocking (exiting with error) if another command wasn't run before. How to know the command has been run, or that we really rerun it since the code was modified if we need to check it's the case?
  • Commands that just run another command with a default parameter if it has never been run.
• Also quickly license can stop licensing every files as it's not a GPL condition. Only having the license specified in AUTHORS and COPYING seems to be enough
• More integration with myapps.ubuntu.com was also asked. That's something we should work on to definitively smooth the process. We will need to see what we need to integrate and what API is needed.
• PEP8 support for all default applications (at least that we follow the norm ;))
• Quickly save can run the available tests before committing the change
• Some issue for quickly-gtk has been discussed when the project directory isn't the current directory. Something to investigate with Michael and a detailed case.
• A lot of concerns about /opt have been raised. Like putting some troubles do developers to understand what to do (different guides talking about /opt and other about /usr), not every files having to be shipped in /opt and a lot of corner cases if you want to ship for ubuntu and in /usr. The decision of not supporting /opt seems to be the most logical way, but discussing with the ARB team and about sandboxing will be needed.

• Some delimitation between quickly and quickly widget seems to be fuzzy. We can definitively see how to merge them back together and getting that tighter. Also quickly add <widget> can maybe add an import in the code and show a snippet of code.

• How can we make people participating in creating snippet of code in general and not only for quickly widget? How can we point to them, reviving jono's code and making that part of quickly?
• Some developers wants to have hooks in their project. They can even share them. The use case is "I'm doing a new release and I want to tweet it". Pre_commands/Post_commands with hook is defintively an easy target in a project hook directory.
• Defaults templates were evocated
  • python + gtk (with pygi)
  • html5 templates
  • unity lens template
• Other templates, not installed by default:
  • ubuntu-cli
  • qt/qml template
  • flash template
  • other templates from the community repository? like vala
• updating the tutorial with the list of supported and community templates

Future discussion emerging from those notes

• Discuss what people want to configure in their projects
• Discuss on the default templates, what technology they should include
• Supporting only one Quickly version and have refreshed version even on previous distro?
• What build system to use? proposing bake
• What impact has the new AUTHORS file in the autogenerated license about dialog
• Boostrapping AUTHORS file (see the above notes)
• Commands dependency system: how to make it work? which conditions should be blocking again?
• Checking that AUTHORS and COPYING are enough for GPL code. No need to have the license in every file header.
• Integration with myapps, talking with different partners

• Integration quickly <-> quickly widgets?

• Talking about the snippet project and how we can make that flawless.
• Sharing hooks between projects? Should the hook be inside the project or enabling configuring it in a global system?
• discussing default templates: how an html5 template should looks like?

Feedback/Ideas