Google Summer of Code: Proposals and Mentors

[Andoni Morales]

2015-02-18 20:21 GMT+01:00 Nirbheek Chauhan <nirbheek.chauhan at gmail.com>:
> On Wed, Feb 18, 2015 at 5:23 PM, Sebastian Dröge
> <sebastian at centricular.com> wrote:
>> On Di, 2015-02-17 at 16:59 +0000, Luis de Bethencourt wrote:
>>> GStreamer is going to apply for Google Summer of Code 2015. But we need
>>> your help!
>>>
>>> We would really appreciate if you suggested proposals, volunteered for
>>> mentoring, or added content to the proposals.
>>>
>>> Current list of proposals is here:
>>> http://gstreamer.freedesktop.org/GSOC/socprojects.html
>>
>> Does anybody have any other ideas, or would like to be added as a
>> potential mentor for any of these projects? Would be great to get some
>> more ideas and potential mentors so we can properly handle all
>> projects :)
>>
>
> It might be useful to have a project to improve Cerbero.
>
> Cerbero's main use-case right now is to build binaries
> tarballs/packages from upstream sources. It's quite difficult to use
> it for other uses such as local development; which is a shame because
> it's currently our best way of doing cross-compilation.
>
> List of deficiencies (Incomplete):
> ==================================
> 1) Local development is hard; current best way is to push to a custom
> remote/branch

For local development using cerbero to rebuild changes in a project is
not the best approach to use. What I usually do is jumping into the
development shell and use a repository checkout different from the one
created by cerbero (eg: ~/git/gst-plugins-bad), configured with the
same configure options, specially for the prefix. Than the development
is make && make install as you would do with other setups, very
similar to what is done with gst-uninstalled except that you need the
extra make install step.

> 2) Difficult to maintain multiple checkouts of Cerbero (gst 1.4,
> master, custom, etc)

Multiple checkouts can be maintained easilly with different
configuration files that change the default paths used for the cache
files, the installation prefix and the build dirs. So each build is
built and installed in a different prefix using different cache files:

home_dir = os.path.expanduser('~/cerbero-builds/gstreamer-master)
cache_file = 'gstreamer-master-%s-%s' % (target_platform, target_arch)

So end up having several config files that you can easilly change to
target different builds:
./cerbero-uninstalled -c gstreamer-master.cbc
./cerbero-uninstalled -c gstreamer-1.4.cbc

But the lack of documentation is definitively a problem, since most of
the useful scenarios for developing and other features like
applications bundling and packaging are completely undocumented.

I can also help mentoring in this project if it's needed.

Andoni

> 3) Downloaded-sources management is suboptimal (no checksums, etc)
> 4) Built-sources management is supoptimal (mtime is compared, which is
> often misleading)
> 5) No way to "uninstall"/"wipeone" a recipe; need to wipe everything
> 6) Essentially no documentation about how to use it
> 7) More![1]
>
> A subset or a superset of these problems can be turned into a GSoC
> project. The aim is not to turn Cerbero into a full-fledged package
> management system, but something that at least fulfills basic
> development requirements such as "don't arbitrarily rebuild everything
> ffs". :)
>
> I volunteer myself to mentor/co-mentor this project[2] if we think
> it's worth doing.
>
> Cheers,
> Nirbheek
>
> 1. I'm sure Alessandro has many choice expletives he would love to
> share with us on the matter
> 2. I have experience being a GSoC student and a mentor with the Gentoo project
>
> --
> ~Nirbheek Chauhan
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel



-- 
Andoni Morales Alastruey

LongoMatch:The Digital Coach
http://www.longomatch.ylatuya.es