Quickly Reboot

What are we trying to achieve?

All related information are on this blog post.

What work has been done already?

There is now a reboot series under the Launcpad project for Quickly where the new code is being developed.

Progress on the reboot is being blogged about here and here.

The core of the Quickly reboot is largely completed, and the work of porting the existing templates and commands is underway.

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

Template discussion

Hangouts

• On air recording (we had some technical issues with this new "ubuntu on air" account that are now fixed)

Notes

• We discussed the default templates, seems that the conscensus is about:
  • one python + gtk template (using pygi)
  • one html5 template (with a python wrapper) (migrated from the community repository)
  • the unity lens template
• ubuntu-cli will be pushed in the community repository
• We discussed what the ubuntu-html5 template should look like. We will at first depend on few framework as the web diversity and opinions for framework are even worse than in the desktop. The only one is the requirejs dependency system that will be bundled by default for the backend history.
• We come back to the discussion about updating the boiler plate or not for supported templates. The majority seems in favor of enabling that, detect if the "private_lib" part of the project changed, and update that on user behalf. There will still be a detection mecanism if the developers changed those file asking for an overwrite. We need though to leave those files in the public domain
• We discussed as well the build system. Some questions about the bake build system. We are going to move to use it: bake for the project itself. People working on ubuntu are upstream for it and we can easily make it friendly to our project layout. Also, being an html5 or python or flash package, we would have the system build system.
• For the auto packaging system, we can use pkgme for that. The rationale is that we can provide bake support for it and that we would have the same client-side vs server-side packaging system, so coherence for the win!

• Those two decisions are depending on further investigations though. Distribute can also be seen as a build system for python apps.

• We discussed as well inheritance between templates and how that would go. The discussion continued to the quickly-talk mailing list and we figured out a way to accomodate everyone. The templates will still be completely opinionated about technology (the default ubuntu ones will use bzr and launchpad for instance), and the inheritance will be achieved through the Command classes (all commands will be in python and will be classes, with multiple parts that you can override).

• We continued on the completing and other internal real class with metadata. Some further benchmark are needed to see if we can avoid using the commandsconfig file.

Q&A session

Hangouts

• On air recording

Notes

• Some discussion about supporting only one version of Quickly. Seems there is no blocker on this apart from the SRU and shipping Quickly in the extra repository. On the positive side: less maintenance, same environment on all Ubuntu versions, help people having their application supported on multiple versions of ubuntu. On the negative side: more difficulty to have that accepted as a SRU policy.
• Related to that discussion, there was one question about how to know with which version of Quickly a project was created/maintained? We support upgrading a project, not downgrading it. Having a warning when you try to use an older version of Quickly with a project supported to the new version seems handful. It doesn't solve the problem for people contributing to multiple projects, each one having different versions of Quickly. However, supporting just one version of Quickly will also help dealing with that situation. (especially as we decided to upgrade the private_lib unconditionally)
• Multiple contributors for a project, how to help them? Some quickly applications like jono's accomplishement system attracted a lot of contributors and we don't have a good story apart from bzr branch, bzr merge and so on. The state of art is to not focus to much on this, however, just provide one way or the other to guide the user (tutorial or command making a merge proposal, and starting from an existing project) and helping them merging, but not automating the whole part.

• Inheritance -> we won't have a good way nor try to prevent template multiple inheritance

• We need to find a clear definition of "opportunistic developer". The term seems to put people in trouble to define it. Also, having a way to tell "The default templates provided with Quickly are for those users. There are other templates maintained by the extended community for other kind of users…"
• Copyright files: will be hard to automate if we go the DEP5 way and deal with all issues. We still need to look if the GPL mandate to have the copyright in each header. And have a clear strategy to bootstrap it.

Future discussion still needed discussion emerging from those notes

• Discuss what people want to configure in their projects
• Checking that AUTHORS and COPYING are enough for GPL code. No need to have the license in every file header.
• Commands dependency system: how to make it work? which conditions should be blocking again?
• Integration with myapps, talking with different partners

• Integration quickly <-> quickly widgets?

• Talking about the snippet project and how we can make that flawless.
• adding frameworks to html5 template should and keep them refreshed.

refs

• Some proposed API: http://bazaar.launchpad.net/~mhall119/+junk/quickly-reboot-mockups/files

Feedback/Ideas