Group Details Private

moderator

  • RE: Proposal for a Telegram Stickers Project

    One point i want to add, is that we might want to remove the "Ubuntu logo" since for this exact reason we are limited. Things that we want to include yumi on might be approved each time, like if we want to have it on the pinephone for example. We also want to move into debian and other distros, so a removal of the logo would be a good move in my opinion.

    Yumi itself can be used by anyone, that was one of the main point when it was made, but i see now adding the ubuntu logo was a mistake.

    posted in Marketing Incubator
  • RE: PinePhone

    @Jackl said in PinePhone:

    2 Being a privacy oriented phone, it would be cool a physical switch to turn off the module, and maybe the cameras, microphone. I dont trust very much the module stand-by state.

    It will have physical switched for all those 🙂

    @Jackl said in PinePhone:

    • 3 The display manager should be i3 or lxde (kde or gnome would be f00l(no offence ubports)) and the OS arch or debian. All the always-running apps should be gtk2.

    gtk on phones is a bad idea. It's not designed for low end hardware nor is it designed to work on a phone form factor. Why do you want gtk?
    Qt has superior performance on embedded, ARM based devices. Also LXDE is moving to LXQT which is qt based.

    UBports does not use kde or gnome, we use unity8 that's crafted specifically to work on phones and desktop alike, based on qt.

    i3 would be hard to use? no keyboard?

    But you can run whatever you want 🙂 there is debian builds already for it, and i know other project are working on it as well, like arch, plasma mobile, etc.

    @Jackl said in PinePhone:

    4 I hope that the pinephone 2 will use a mediatek or qualcomm soc. Not a surprise a battery of 3000 mAh.

    It will use the allwinner a64

    posted in General
  • RE: Issue priorities - basic phones features shouldn't be the first ?

    Little the same as i wrote on github https://github.com/ubports/ubuntu-touch/issues/860,

    Also please understand, we are a small team with a huge task, we have many moving parts and moving to a newer version of mir and unity8 at the same time is not helping, we are doing our best to make an an awesome operative system. but we are in a really busy period after taking over from canonical, we updated to xenial, we are updating mir and updating unity8 all these are huge since canonical left it all the current version far behind the latest releases, this forces us to make major changes. We are also building Halium and following the evolving of android and newer devices to be able to follow the mobile marked. At halium we are also trying to move our sensor, gps, media and camera system over to an active maintained system instead of maintaining our own. And we are also looking at merging our patched in celluar and pulse with an active maintained one. Once we move things to active maintained systems where we can work together to get to the same goal, we will then get more time to focuses on core functions.

    About replacing the browser, this is an huge part for us, we are not able to maintain our own fork of chromium (oxide) that why we are forced to move the browser, this move will in fact give more time to focused on the core functions on the phone.

    We are moving to newer version of pretty much every part of the system, this is a major work. Once we have done the major upgrade we will get a lot more time. And in fact we are really close go get to this point, we now are super close to finish all the mir/unity8/libhybris upgrades. And we don't have a big enough team to focus on all the bugs right now as the code may have merge errors to be able to merge with never version and to risk spending lots of time on bugs that might be fixed in newer version. that's why we are upgrading, getting our source aligned with newer sources to then focus on fixing and improving.

    In fact most of these bugs comes from the canonical days, they was a much bigger team then we are right now, so we don't work at the same speed.

    We are doing our best with the small team we have.

    OTA 8 will include new mir and unity8 (and many other updated parts), we hope these have many of these issues fixed, but we have to expect some bugs to be included also since the upgrade is so major.

    Thanks for understanding 😉

    posted in General
  • RE: for device-tarball question

    @kuailexs Sorry that it took a little, i had to setup eveything, but Its mostly ready now 🙂

    Do you have an gitlab account? If so whats your username? That way i can add you to the repo.

    I have setup an repo on gitlab where you can push your files, those will then get automatically pushed to our infrastructure and pushed to the system image server.

    https://gitlab.com/ubports/community-ports/cancro

    The format inside this is same as device tarball with, partition images in partitions folder and rootfs files in system folder.

    Required files are:
    partitions / boot.img
    partitions / recovery.img
    system/var/lib/lxc/system.img

    Files should not be compressed, our infrastructure will do this 🙂

    posted in Porting
  • RE: Morph Browser is exellently trackable

    This is defiantly something we should resolve within the browser (at least have an option to block ads and trackers) But the browser is quite new and still is under heavy development, i do expect something like this to be added in newer versions.

    Right now using https://open-store.io/app/uadblock.mariogrip blocks most ads and trackers.

    posted in General
  • RE: for device-tarball question

    Hey!

    This is awesome! 🙂

    We have something called community channels where there is no requirements other then it needs to boot. https://system-image.ubports.com/16.04/community/ These channels work exactly like the other channels, only difference is its a community supported device.

    For the normal channels, it will need to have all the supported hardware/important parts working. But we can move to the normal channels once its 100% supported.

    If you would like an community channel, i will gladly setup one and give you the details how to upload new images etc 🙂

    I just needs some info to be able to set it up,
    Is this based on 5.1 or 7.1?
    does it uses 64 or 32bit user space?
    What username do you want on the channel?
    Do you use edge or the normal devel?

    posted in Porting
  • A personal road blocker

    Hey,

    As you may or may not have seen, i have been a bit offline last week. This was due to one of my close family member got into hospital with an serious infection, it was so bad that he got picked up by the ambulance. And since I'm living in the same house and is really close to this person, this has not been an easy week for me. This is the reason why i have been gone, but with all this said, hes now back home and in much better shape, he is still recovering but overall doing fine. and I'm slowly getting back to everything.

    Thanks everyone!

    posted in General
  • RE: semantic versioning for UT

    @alan_g Yes that what i meant, sorry a mistake.

    posted in OS
  • semantic versioning for UT

    With the new idea for changing up OTA process, I also want to propose new version system that makes sense.

    I propose to use Semantic Versioning
    https://semver.org/

    0_1539724648267_c4f00cf3-507c-4db6-bbb8-be949563f74f-image.png

    This way we could completely get rid of framework and only rely on the version to describe both version and api/abi compat. It would also give you a lot more info about the version you are on example that a major bump has a much bigger change then for example patch.

    MAJOR: bigger change that Breaks ABI/API
    MINOR: adds backwards-compatible bug fixes, changes and functionality (may break smaller library ABI in really special cases, but this should be notified about!)
    PATCH: adds backwards-compatible bug fixes.

    Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

    This would be how our different channels would look
    1.6.2-beta2 -> 1.6.2-rc1 -> 1.6.2
    beta -> rc -> stable

    This way you would know what version becomes what, example you know that 1.6.2-rc will become 1.6.2 stable.

    This fits great in with the "gotta go fast" proposal by dalton, here is an example how that would work

    1 week:

    • 1.5.6-devel0
    • 1.5.6-devel1
    • ----- / ----- Devel continues like this daily
    • Last weeks rc becomes stable: 1.5.5-rc1 -> 1.5.5
    • Last devel build of the week becomes rc: 1.5.6-devel6 -> 1.5.6-rc1

    2 week:

    • New devel version starts: 1.5.7-devel1
    • Last weeks rc becomes stable: 1.5.6-rc1 -> 1.5.6
    • Last devel build of the week becomes rc: 1.5.7-devel6 -> 1.5.7-rc1
    • This continues weekly.

    Then monthly we do a minor bump with more advances feathers.

    We could also do a mix between slow and fast, where we are releasing stable monthly:
    1 week:

    • 1.5.6-devel0
    • 1.5.6-devel1
    • ----- / ----- Devel continues like this daily
    • Last devel build of the week becomes rc: 1.5.6-devel6 -> 1.5.6-rc1

    2 week:

    • Devel continues daily
    • Last devel build of the week becomes rc: 1.5.6-devel12 -> 1.5.6-rc2
    • This continues weekly

    Then after the month is over last weeks rc becomes stable: 1.5.6-rc1 -> 1.5.6

    Examples:

    xenial stable: 1.6.2
    xenial rc: 1.6.2-rc0
    xenial rc: 1.6.2-rc1
    xenial devel: 1.6.2-devel1
    bionic devel: 2.6.2-devel1

    We would also make a clear build date in settings, this way we can know we are on the latest build.

    posted in OS