[Soc-coordination] Summer of Code Ideas

Obey Arthur Liu arthur at milliways.fr
Fri Feb 11 22:18:51 UTC 2011


Hi Chris,

On Thu, Feb 10, 2011 at 9:14 PM, Chris Baines <cbaines8 at gmail.com> wrote:

> Hello,
>
> My name is Christopher Baines and I am looking at applying to
> participate in the Google Summer of Code program. Since hearing about
> the program while participating in the Google Code In, I have been
> thinking of a few project ideas which I thought I would run by you.
>
> I have been running Debian for over a year now, since moving from
> Ubuntu when I decided to try and get involved with the development of
> the OS. In that time I have been packaging, or attempting to package a
> number of applications, I currently have one package in Debian
> ant-contrib-cpptasks, and hopefully a few more on the way.
>
>
Thanks for your interest in Debian!


> While learning to package software for Debian, I found the process
> fragmented in a sense, many tools and programs that come together to
> make it all work (hopefully). While I see the enormous flexibility
> this gives it made the learning curve that little bit steeper. Thus I
> was thinking that for my project I could try and begin a Debian
> package IDE.
>
> After a bit of research I see this has already been attempted in a
> sense, however unlike the wizards (eg:
> http://sourceforge.net/projects/packin/), or the more complex programs
> (eg: https://code.google.com/p/debianpackagemaker/), it would be like
> a good programming IDE, less hiding, more helping.
>
>  I was thinking of offering either a graphical (text fields,
> tickboxes) or text editor (gedit, kedit) style for editing the files,
> with lots of inline help (from both the program, and the relevant
> Debian documentation eg: the policy manual and the developer guide).
> Combined with lots of automated testing features from pbuilder and
> lintian, all usable directly from the program, it could speed up the
> process of learning to make packages and packaging itself by both
> reducing errors and bringing together the many applications that can
> help with the process.
>

Actually, this "Debian packaging GUI" comes up pretty much every year.
"Do X, but with a GUI" is a rather common pattern and it has quite a few
pitfalls, from underestimated complexity to overestimated usefulness
(compared to the replaced non-GUI, etc.). You should be aware of it.
(actually, if you have a long memory, I could apply this to myself in
hindsight).

One way I would see this implementable without unreasonable amount of work
and with immediate improvement over some existing workflows is to write an
Eclipse plugin.
This solution avoids having to reinvent the IDE parts of the tool by
leveraging the quite decent aspects of Eclipse.
Now you're going to tell me that few people even consider doing Debian
packaging using Eclipse, but I'd retort that the Eclipse framework is
probably the only one were such work would make sense (compared to an Emacs
mode or a Vim plugin).
I think that such a plugin can have a lot of potential to integrate the many
packaging tools available to Debian developers, including: git-buildpackage,
lintian, pbuilder, dput, mini-dinstall...
Besides this, Eclipse brings VCS integration (SVN, Git, Hg...), syntax
coloring, auto-formatting (and that could include control files someday!
possibly using Config::Model)...
Examples across the industry have shown that it is possible to create very
good Eclipse plugins dedicated to specific development environment (I'm
thinking about Android, Java App Engine/GWT and countless others). These are
so polished that they have been able to attract developers that would
usually never use Eclipse. I believe we can do a comparably good job by
leveraging and visually integrating the existing Debian packaging tools.


>
> My second idea came from my recent usage of debdelta, a amazing tool
> to reduce download size and increase speed when updating Debian,
> perfect if like me you are on a slow internet connection. I would be
> looking to integrate it with apt-get and/or aptitude and improve the
> program its self by implementing a method of predicting the best
> approach for fetching the debs, and possibly looking at how to provide
> debdeltas in a better more comprehensive way, perhaps by allowing
> normal apt repositories to provide them?
>
> I am also quite open to other ideas if you would like to suggest any?
>
> I'm sure the apt/dpkg would be interested to pitch in on these. Daniel?
David?

Good luck and don't hesitate to ask more questions and come talk to us on
#debian-soc on irc.debian.org.

Cheers!
Arthur
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/soc-coordination/attachments/20110211/896f3b52/attachment.htm>


More information about the Soc-coordination mailing list