Roadmap

Specifications:
Storing Package Metadata

Task-focused releases:
Indented tasks means that the previous one needs to be finished before it's started.
 * 1) port to GtkBuilder (GnomeDruid heading to depreciation). Remove all Gnome dependencies (because they are heading to depreciation and the gtk+ stack is preferred)
 * 2) add a proper brasero-like (because of document orientation, the goals are similar) interface - this will allow for the creation of saving, loading projects.
 * 3) port to waf build system - because the waf manual is smaller to read than autotools (unless an autotools expert comes

∘ test case - upgrading a ubuntu package (what detdeb does)
 * 1) add proper i18n support - requires adding some variables to be build system, so that's why after the waf port.
 * 2) restructure the codebase - see gnome standards (no if {} but return_if_fail_fail)
 * 3) implement support for saving and opening projects again
 * 4) *requires having task 1 completed
 * 5) implement support for modifying existing packages
 * 1) dput file creation & ppa upload support (remember )
 * 2) support for other build systems (waf, cmake, scons) in packages
 * 3) Debian package support & derivatives (though can be done in parallel with other tasks should someone wish to step up)

Misc tasks that can be done anytime

 * create a program logo
 * update the website to be more professional
 * add SEO
 * Get a forum & add a nice skin

Undecided (click Edit and add your idea here):
Dependency calculation ideas are welcome here.
 * .desktop file generation
 * gnome-app-install integration
 * upgrade-notifier integration
 * "category" packages - theme packs, libraries, split-data
 * for theme packs: add an optional zenity script to apply the theme at once after installing it ("Would you like to apply this theme now? [✘ Keep my current theme | ✔ Apply new theme]")
 * Install dependeces automatically. (integration with auto-apt?)
 * Drag & drop support on adding the source package.
 * Since at some point giftwrap will be able to install the .deb files it creates, and it shows approximately the same data as Gdebi does (package description, details and included files)... how crazy would it be to use it to open .deb files, consider it a complete replacement for gdebi and promote its inclusion in Ubuntu by default? --Frandavid100 10:05, 31 May 2009 (UTC)
 * Very. Not planning a gdebi replacement here, and the common user in a perfect world shouldn't have to use giftwrap.
 * Pbuilder integration. Do not bother building chroot support. Pbuilder support would be probably easier. And pbuilder automatically installs build-dependencies at every build. Pbuilder makes it easy to build a package for different versions, and makes it easy to spot dependency problems. Supporting pbuilder should be pretty simple, and may avoid duplicating its functionality in GiftWrap. Also, pbuilder is the recommended way to build packages in Ubuntu.
 * (accepted: name-email-retrieval) Save Packager and Email-adress: I don't want to type in my name every time --Moose2 10:13, 3 June 2009 (UTC)
 * localisation to get it translated in multiple languages
 * update debian standards version