[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bringing Mobian closer to Debian



On Sat, Aug 14, 2021 at 11:08 AM Arnaud Ferraris wrote:

Hello Arnaud,

Thanks for bringing this forward.

> Most of the Mobian developers are also members of the DebianOnMobile
> team[3], and we hope to contribute even more to Debian now that
> bullseye
> is being released. In order to achieve this goal, we plan on bringing
> packages from the above items #4 and #5 to the Debian archive
> (preferably in the 'main' area), and are considering several ways of
> doing so:

A question on those different options: do you see them as mutually
exclusive or could we go for a combination of them?

Examples:
- I do not see how option b. would conflict with a. or c.
- Option c: when you wrote "merge all of the above", I assume that an
intermediary approach, similar to the point a option 2 could also be
envisaged.

> a. merge all device-specific metapackages and tweaks into a single
>    (or maybe 2) source package, making it easier to maintain and
> improve
>   * option 1: have a single binary package per device, replacing both
>               the current $device-support and mobian-$device-tweaks
>   * option 2: keep generating separate metapackages and
> customizations,
>               as we currently do in Mobian
> 
> 
[...]
> 
> b. add Mobian generic customizations (initramfs scripts and hooks,
>    systemd config files, among other things) to the source package
>    holding all device-specific tweaks
> 
> 
[...]
> 
> c. merge all of the above into the existing "mobile-tweaks" source
>    package [6]
> 
> As DebianOnMobile maintainers, we agreed a while ago that mobile-
> tweaks
> would mostly hold cosmetic tweaks, and not be used to significantly
> alter the system behavior. Almost a year down the road, do we want to
> keep it that way? Or can we drop all mobian-$device-tweaks packages
> and
> add features to the existing $device-tweaks ones?
> 
> FYI, this question was raised when I filed an ITP for mobian-
> tweaks[7],
> although my answer would probably be different today.

Personnaly, I would prefer we avoid this split of tweaks settings
between 2 different binary packages (ie: mobian-$device-tweaks and
$device-tweaks). Whether that be mobian-$device-tweaks or mobile-
tweaks, I have no preference. I see some overlap between both packages,
in term of purpose, which can lead to effort duplication, which we
should avoid IMO.

I think we should challenge this split of the device tweaks (and the
common one too): let's take the UCM2 profile example, this is not a
cosmetic change and therefore belong to mobian-tweaks packages
(according to the current agreement). IMHO, it would be fine to have
this in a single tweak package (mobile-tweaks or mobian-$device-tweaks)
- this is device specific anyway, the package description is making
that clear, and could be removed later on while upstream'ed properly
(then it should become part of alsa-ucm-conf for this specific
example).

Are there use cases I am missing here where we see a strong need for
device specific tweaks split in 2 different packages?

Also, the 3 options are very much focused on the packaging work, I'd
like to ask: what about the team themselves? Eventually, if we want to
bring Mobian closer to Debian, does it make sense to keep 2 different
salsa teams (Mobian-team and DebianOnMobile-team). As you said, there's
some overlap in term of membership and I believe our objectives are
aligned.

Merging would only be benefical imho: clarity for new contributors,
reduced risk of work duplication, improved communications - there are
currently several communication channels where team devs can talk, but
not a single channel where dev related discussions are being held and
reaching everyone involved.

IMHO - we should also consider the team aspect if we want to bring
Mobian closer to Debian: that is an important dimension with its own
set of potential improvements :-)


Best regards,

Henry-Nicolas Tourneur

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: