Source tree re-organization, difficulties contributing to media code

[Jean-Baptiste Queru]

We've been re-organizing the platform source tree in our internal
branches, which will allow to reduce the pressure on frameworks/base.

For the next major release (and therefore in our internal branches),
the following directories have moved to separate project. As a
consequence, it won't be possible to contribute to those until the
next major release.

Sorry for the inconvenience, thanks for being patient.

frameworks/base/media/libeffects
frameworks/base/media/libmedia
frameworks/base/media/libmedia_native
frameworks/base/media/libmediaplayerservice/
frameworks/base/media/libstagefright
frameworks/base/media/mediaserver
frameworks/base/media/mtp
frameworks/base/include/media
frameworks/base/include/private/
frameworks/base/cmds/stagefright
frameworks/base/services/audioflinger/
frameworks/base/libs/camera/
frameworks/base/services/camera
frameworks/base/include/camera/
frameworks/base/drm/common
frameworks/base/drm/drmserver
frameworks/base/drm/libdrmframework
frameworks/base/include/drm/

JBQ

--
Jean-Baptiste M. "JBQ" Queru
Software Engineer, Android Open-Source Project, Google.

Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further
warning.

[Jean-Baptiste Queru]

I've been reminded by one of my teammates that the same thing had been
done for some lower-level graphics-related framework modules, in the
following directories:

frameworks/base/libs/utils/
frameworks/base/libs/ui/
frameworks/base/libs/gui/
frameworks/base/libs/binder/
frameworks/base/opengl/
frameworks/base/include/utils/
frameworks/base/include/ui/
frameworks/base/include/gui/
frameworks/base/include/binder/
frameworks/base/include/private/utils/
frameworks/base/include/private/ui/
frameworks/base/include/private/binder/
frameworks/base/cmds/surfaceflinger/
frameworks/base/services/surfaceflinger/

We also won't be able to accept contributions in those directories

until the next major release.

JBQ

[Martin Storsjö]

Hi,

On Tue, 24 Apr 2012, Jean-Baptiste Queru wrote:

> For the next major release (and therefore in our internal branches),
> the following directories have moved to separate project. As a
> consequence, it won't be possible to contribute to those until the
> next major release.
>
> Sorry for the inconvenience, thanks for being patient.

Thanks for the clarification and listing of which directories it concerns.

I hope you understand how frustrating it is, to be back at square one
again (after waiting for gerrit to come back up after the incident last
year) - waiting for some future event without any estimate about when it
will happen (I do realize you can't comment on when the next major release
is and I'm not asking for an estimate). My queue of submitted patches
waiting for review is >30 at the moment (most of them quite simple, some
of them fixing embarrasing portability issues), and every single one of
them touch this area.

At least I did manage to get a bit over 30 old patches merged within the
short window of time after gerrit came up again until reviews/merges
suddenly seemed to stop in early March (not sure if that coincided with
this repo split or if it was for some other reason). And I still at least
got some progress - it seems to me that Gergely Kis's telephony patches
(as mentioned in
http://groups.google.com/group/android-contrib/browse_thread/thread/e10a8780b3ab04ef)
don't have moved anywhere at all yet, so I guess I'm still kinda lucky.

// Martin

[Jean-Baptiste Queru]

I know :(

We've been wanting to split frameworks/base pretty much since the very
beginning. Literally, it has such an imprecise name because it was
created as some kind of catch-all in the 1.0 timeframe, when we
already knew that it was too big but didn't have enough experience to
split it further. It has grown to be one of our largest projects.

What happened in early March is simply that I went on vacation for a
while, and since coming back (5 weeks ago) I've been trying to catch
up with my backlog.

One of the intended side-effects of cleaning up frameworks/base is to
make it easier to contribute to the parts of the code getting split
off, but unfortunately that means that things had to get worse before
they get better.

Once the next version is available, I expect we'll be able to work
together to carry your contributions forward. It's not impossible, but
it's hard to do on a private branch.

JBQ

--

[Shachar Shemesh]

On 04/24/2012 11:16 PM, Jean-Baptiste Queru wrote:

Once the next version is available, I expect we'll be able to work
together to carry your contributions forward. It's not impossible, but
it's hard to do on a private branch.

Assuming most of the merge conflicts are the mere movement of the directories to a different project, isn't there some way to automatically resolve this?

Shachar

-- 
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
http://www.lingnu.com

[Jean-Baptiste Queru]

That'd be possible, in theory.

It boils down to maintaining 2-way mappings between the old locations
and the new locations, and for each change in frameworks/base to move
all the code from the new projects back in frameworks/base, do the
merge, and return the code to its real location.

However, that's simply not practical. Implementing and maintaining
that automation would come at the expense of other work that I could
do instead. Since I anticipate that I'm not going to run out of work
before the next major release, if I look in a 1-release timeframe,
working on this would be a net loss overall.

JBQ

[Jacob Nordfalk]

2012/4/24 Jean-Baptiste Queru <j...@android.com>

One of the intended side-effects of cleaning up frameworks/base is to
make it easier to contribute to the parts of the code getting split
off, but unfortunately that means that things had to get worse before
they get better.

+1 for being open about the situation (which I think we all hope will improve).

Apart from my 3 small patches submitted (which I can do again, no problem), some unsubmitted documentation improvements (during my Android classes I have a good opportunity to see what students usually misread) I have brewed an article on how to check out, build, modify and contribute to the Android open source project - thanks to the help in here.

Naturally, I'll wait publishing that last article until you are ready for the rush-in of contributors.

(well, its in Danish, so .. :-)

Anyways, keep up the good work on being able to handle contributions and keep sending monthly updates that you are working on it.

Yours,

Jacob

 

--
Jacob Nordfalk

http://javabog.dk

Android-udvikler og underviser på IHK og Lund&Bendsen

[Roger Madsen]

Hi.

Any plans on moving frameworks/base/telephony to a separate git as well? It would get a huge +1 from me!

Best Regards,

Roger Madsen
Software Architect, Telephony.
Sony Mobile

[Jean-Baptiste Queru]

We've been strongly considering it. It's a little bit more tricky than
the low-level graphics and media code, because there isn't as much
separation between the public APIs and the deep implementation. It
would certainly be beneficial, though, for several reasons (including
and especially for AOSP contributions).

This isn't going to happen in the timeframe of the next major release,
but we're thinking about it for a more distant future. No promises and
no schedules, though.

JBQ