Application for GSoC and proposal
Alexander Rössler
mail.aroessler at gmail.com
Wed Apr 4 07:59:40 UTC 2012
Hello Kdevelop developers,
I have rewritten my proposal a bit. Maybe you can take look at it:
*Introduction*
I noticed that deploying applications to Linux is not that easy, especially
when considering that there are a lot of different Linux distributions out
there. OpenSUSE (or exactly Novell) found a solution for that, the Open
Build Service. The Build Service brings a lot of comfort for developers and
packagers, however to deploy an app with the Build Service, you need at
least do know the basics about RPM and Deb and a lot of time. For
Developers using Linux as main development platform this is of course not a
big problem, but especially when a project is developed for different
platforms, developers might be frightened about deploying applications to
Linux, especially smaller projects. The aim of the project Bretzn was to
connect various services on the internet for building and deploying
applications. In the end of 2010 the beta of a plug-in for the IDE Qt
Creator was released. The plug-in looked very interesting, but a final
version was never released. So my suggestion is, bringing project Bretzn
back to live and to create an application for deploying software on Linux.
*The goals of the project*:
-
making deployment of applications on Linux easy
-
saving lots of time for releasing applications and updates on
openDesktop.org
-
providing a plug-in for Kdevelop
*Implementation*:
The project should start where the development of the Qt Creator plug-in
was stopped. The plug-in used lib Attica, which provides an easy to use
framework for using the Open Collaboration Services. Lib Attica provides
support for connecting to the Build Service as well as the openDesktop
platform. This project will be developed as Kdevelop plug-in, so I will
refer to it as Build Service Plugin. The Build Service Plugin should
automatically generate .spec files for RPM distributions and the necessary
files for Deb distributions. Generating these files might not be possible
for every project without user interaction, but as the Build Service Plugin
is especially targeted to smaller projects, most of the time containing
only a binary, some icons, a desktop file and some documentation, this
should be possible. The GUI should provide an easy way to input data like
the application description or the change log. After all the necessary file
are created, the project will be uploaded to the Build Service. Another
idea is that the Build Service Plugin also provides an easy way to publish
projects to the openDesktop.org platform, where end users can find, comment
and rate applications.
*Timeline:*
-
Before GsoC: Analyzing the code of the previous project and getting
information from the developers
-
Designing the user interface and how the application should work
-
Implementing the specfile and debian.rules generator
-
Implementing the project-file management and tarball creator
-
Implementing the parts of the application that use the OCS API (the
network part)
-
Creating the Kdevelop plug-in
-
Creating the documentation (most should already be done during
development process)
-
Sending code to Google
-
After GsoC: Getting in touch with users, optimizing, bug fixing etc...
Especially because a lot of the tasks that should be done are well
documented, all this should be done within one to two months, providing
enough time if problems, or things that where not thought of, occur.
*About me:*
I am studying electronic engineering at the University of *A**pplied
Sciences Technikum* Vienna. I have a lot of experience developing Qt
applications, because I am a open source developer since a long time. (one
of my newest projects is PhyxCalc:
http://kde-apps.org/content/show.php/PhyxCalc?content=149161) I am also one
of the OpenSUSE ambassadors for Austria, making me especially suitable for
this job as developer of the Build Service plug-in.
Thank you for reading my proposal.
Regards
Alexander
2012/3/21 Alexander Rössler <mail.aroessler at gmail.com>
> >- You say you want to make a standalone application and then you say
> > you want to make a plugin. We don't want the application's GUI inside
> > KDevelop, that's not useful. If you don't want it integrated with the
> > IDE then don't, but don't try to say everything to see if something
> > gets us interested.
> Maybe a plug-in is a better solution, considering build and install, but
> it might not be necessary to put the whole application into KDevelop.
> A standalone application might be a more general solution, not only for
> KDevelop.
>
> > - Forget about getting in touch with the users. There will be no time
> > for that. You can do that later if you're still interested in your
> > project after the summer is over. (note that you're deciding what to
> > work on here, so please try to do something that you're interested in)
> Ok.
>
> > - Designing the parts of the UI and reading the code should happen
> > mostly before the code part starts (here you didn't specify, maybe you
> > should take a look into google's schedule). Furthermore, you should
> > have specified in the proposal what this piece of code is going to do.
> > That's not what the UI design is about, but from the functionality to
> > the actual design there won't be that much changes. We need to make
> > sure that you know what you're doing.
> Is there any place where I can get more information about that?
>
> > - Do you really expect to generate rpm and debian spec files
> automatically?
> I think it should be possible to generate rpm and debian spec files for
> standard projects,
> considering that most applications only consist only of a binary, a
> desktop file, some data and maybe a documentation.
> The build shouldn't be a problem, but the install part might a bit more
> tricky. There are to ways to install the application:
> via a make file generated by a build tool like automake, cmake, qmake, ...
> or directly copying files with the spec file.
> For smaller projects maybe the second method is easier. However, it should
> be possible to edit the configure, build and install commands
> manually.
>
> Alexander
>
> 2012/3/21 Aleix Pol <aleixpol at kde.org>
>
>> On Tue, Mar 20, 2012 at 9:46 PM, Alexander Rössler
>> <mail.aroessler at gmail.com> wrote:
>> > Here I'm starting with my proposal:
>> >
>> > Please read it and help me improving it.
>> >
>> > Introduction
>> >
>> > I noticed that deploying applications to Linux is not that easy,
>> especially
>> > when considering that there are a lot of different Linux distributions
>> out
>> > there. OpenSUSE (or exactly Novell) found a solution for that, the Open
>> > Build Service. The Build Service brings a lot of comfort for developers
>> and
>> > packagers, however to deploy an app with the Build Service, you need at
>> > least do know the basics about RPM and Deb and a lot of time. For
>> Developers
>> > using Linux as main development platform this is of course not a big
>> > problem, but especially when a project is developed for different
>> platforms,
>> > developers might be frightened about deploying applications to Linux,
>> > especially smaller projects. The aim of the project Bretzn was to
>> connect
>> > various services on the internet for building and deploying
>> applications. In
>> > the end of 2010 the beta of a plug-in for the IDE Qt Creator was
>> released.
>> > The plug-in looked very interesting, but a final version was never
>> released.
>> > So my suggestion is, bringing project Bretzn back to live and to create
>> an
>> > application for deploying software on Linux.
>> >
>> > The goals of the project:
>> >
>> > making deployment of applications on Linux easy
>> >
>> > saving lots of time for releasing applications and updates on
>> > openDesktop.org
>> >
>> > providing a plug-in for Kdevelop
>> >
>> > Implementation:
>> >
>> > The project should start where the development of the Qt Creator
>> plug-in was
>> > stopped. The plug-in used the lib Attica, which provides an easy to use
>> > framework for using the Open Collaboration Services. Instead of
>> developing
>> > this project purely as Kdevelop plug in, I would prefer developing a
>> > standalone application and providing a plug-in that makes use of this
>> > application. The application should automatically generate .spec files
>> for
>> > RPM distributions and the necessary files for Deb distributions. Data
>> like
>> > the application description or the changelog could be input with an
>> easy to
>> > use GUI.
>> >
>> > Timeline:
>> >
>> > Analyzing the code of the previous project and getting information from
>> the
>> > developers
>> >
>> > Designing first parts of the GUI
>> >
>> > Implementing the specfile and debian.rules generator
>> >
>> > Implementing the project-file management and tarball creator
>> >
>> > Implementing the parts of the application that use the OCS API
>> >
>> > Finishing the GUI
>> >
>> > Creating the Kdevelop plug-in
>> >
>> > Getting in touch with the users
>> >
>> > Testing
>> >
>> > Optimizing and bug fixing
>> >
>> > Especially because a lot of the tasks that should be done are well
>> > documented, all this should be done within one to two months, providing
>> > enough time if problems, or things that where not thought of, occur.
>> >
>> > About me:
>> >
>> > I am studying electronic engineering at the University of Applied
>> Sciences
>> > Technikum Vienna. I have a lot of experience developing Qt applications,
>> > because I am a open source developer since a long time. (one of my
>> newest
>> > projects is PhyxCalc:
>> > http://kde-apps.org/content/show.php/PhyxCalc?content=149161) I am
>> also one
>> > of the OpenSUSE ambassadors for Austria, making me especially suitable
>> for
>> > this job as developer of the Build Service plug-in.
>> >
>> >
>> > Regards
>> > Alexander
>> >
>> > 2012/3/17 Aleix Pol <aleixpol at kde.org>
>> >>
>> >> On Fri, Mar 16, 2012 at 9:27 PM, Alexander Rössler
>> >> <mail.aroessler at gmail.com> wrote:
>> >> > Hello kdeveleop-developers,
>> >> >
>> >> > I'm an electronic engineering student form Austria and I like to
>> apply
>> >> > for
>> >> > kdevelop on GSoC. I am using kdevelop as my preferred development
>> >> > environment for C and so I would like to help you improving kdevelop
>> at
>> >> > GSoc. I have a lot of experience with Qt/C++, KDE and Linux and I am
>> >> > also
>> >> > OpenSUSE ambassador for Austria. As you can see, I'm not new to the
>> open
>> >> > source community. If you like to see my current Qt project
>> >> > visit: http://kde-apps.org/content/show.php/PhyxCalc?content=149161
>> >> >
>> >> > I like your GSoC ideas for kdevelop, but I have following to add:
>> When I
>> >> > developed PhyxCalc I came to one point, where I had to deploy my
>> >> > application
>> >> > for several Linux desktops. As I am a OpenSUSE user, I knew the Open
>> >> > Build
>> >> > Service very well. So I deployed my application via the build
>> service,
>> >> > however, it was quite a pain to get everything working. New
>> developers,
>> >> > especially developers coming from Windows, might be deterred of the
>> >> > deployment of applications on Linux (without the build service it is
>> >> > even
>> >> > more a pain). So I found this on the
>> >> > internet: http://qt-project.org/forums/viewthread/2890 This plugin
>> is
>> >> > not
>> >> > developed any more (and wasn't finished anyway), but I think it
>> would be
>> >> > nice if kdevelop would have such a plugin. Especially for small
>> projects
>> >> > this would be perfect, it would make deploying applications for Linux
>> >> > easy
>> >> > (and even improve the success of the open source community).
>> >> >
>> >> > Regards
>> >> > Alexander Rössler (aka Strahlex)
>> >> >
>> >> > --
>> >> > KDevelop-devel mailing list
>> >> > KDevelop-devel at kdevelop.org
>> >> > https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>> >> >
>> >>
>> >> Hi Alexander!
>> >> Yes it's a good idea and something that can be useful, but it also has
>> >> to be properly thought through before making a proposal out of it.
>> >>
>> >> I'll be looking forward to your proposal.
>> >>
>> >> Aleix
>> >>
>> >> --
>> >> KDevelop-devel mailing list
>> >> KDevelop-devel at kdevelop.org
>> >> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>> >
>> >
>> >
>> > --
>> > KDevelop-devel mailing list
>> > KDevelop-devel at kdevelop.org
>> > https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>> >
>>
>> Hi Alexander,
>> All in all, it's a good proposal, although it still lacks some work.
>>
>> - First of all, it's KDevelop, writing a project's name properly is a
>> good start.
>> - You say you want to make a standalone application and then you say
>> you want to make a plugin. We don't want the application's GUI inside
>> KDevelop, that's not useful. If you don't want it integrated with the
>> IDE then don't, but don't try to say everything to see if something
>> gets us interested.
>> - Forget about getting in touch with the users. There will be no time
>> for that. You can do that later if you're still interested in your
>> project after the summer is over. (note that you're deciding what to
>> work on here, so please try to do something that you're interested in)
>> - Designing the parts of the UI and reading the code should happen
>> mostly before the code part starts (here you didn't specify, maybe you
>> should take a look into google's schedule). Furthermore, you should
>> have specified in the proposal what this piece of code is going to do.
>> That's not what the UI design is about, but from the functionality to
>> the actual design there won't be that much changes. We need to make
>> sure that you know what you're doing.
>> - Do you really expect to generate rpm and debian spec files
>> automatically?
>>
>> I hope this helps you find a better way to explain yourself.
>>
>> Aleix
>>
>> --
>> KDevelop-devel mailing list
>> KDevelop-devel at kdevelop.org
>> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20120404/0f3f8b03/attachment.html>
More information about the KDevelop-devel
mailing list