Database Users

Open source miui

If you follow any miui.us developer chances are you have over heard some talk of a open source Miui project.
You may ask yourself what does it matter if Miui is closed or open? A lot of the community is happy with stopping by their particular fansite each week, grabbing the new release and moving on.
Well from a developer stand point Miui being closed source has been a huge burden. There are very few developers outside of China have access to beta builds through out the week. Even with them it does nothing more then give us the opportunity to see what may be coming down the pipe on Friday.
We translate the officially supported devices and port these to unofficial devices. With no real communication as to what they have done code wise week to week. When bugs exist the experienced developers scramble to try to figure out a fix or band aid to get through to the next week. The truth is that it is not always easy and sometimes builds will suffer
FULL ARTICLE HERE
http://www.miui.us/content.php?272-OPEN-SOURCE-MIUI-PROJECT

YES

Kernel teacher...

Hey everyone, I'm looking for a developer who will be willing to help and teach me how to make a kernel! I would like to be able to add anything I want; meaning I'm looking for someone to teacher how to edit and add things to make it my own, not just teach me how to compile. I've never made anything deal with a source code, meaning I've never made an AOSP ROM nor kernel; I have made some touchwiz based ROMs, but that's a bit different. I would like to start by making something for the nexus 7 (WiFi only) then moving my way to the GsIII (d2spr). I'm currently using opensuse 12.3 KDE 64-bit, on its own HDD. Please, if anyone could help me and teach me, it would be greatly greatly appreciated!!!

What hourly rate are you willing to pay? LOL
What I would recommend you do is to start simply by:
a) installing the current NDK
b) downloading a complete stock kernel build tree as a tarball (.tgz)
c) setting up a build environment and successfully build the kernel
d) unpack an existing boot image, stuff your kernel in there, & re-pack it
e) boot it on your device. Does it run? Congrats! You are a kernel-builder!
The reason that I suggest this outline plan above is that it initially avoids learning git & associated tools until after seeing something you've built running on the device; that's a confidence-booster. That's the good news.
The bad news is that becoming a *good* kernel dev from scratch means that you simultaneously are learning kernel coding conventions, build tree structuring, and kernel APIs *plus* achieving an excellent understanding of how git & gerrit work.
In addition to some amount of original source code mods authored by a kernel dev, they spend a fair amount of time integrating patch sets (commits) coming from unrelated kernel projects (e.g. Linux kernel mainline or kernel mods from unrelated devices). Learning simple operations (commits) in git is easy enough, but understanding branch creation & multi-way merge strategies in the face of cherry-picks coming from arbitrary places is a bit of a mind bender the first time through it.
And there is the issue of compliance with the GPL. As soon as you decide to make public your work, you have an obligation to publish your sources.
There is at least one way to do this simply: don't worry about git/gerrit/github at all - use whatever source code control system you want, including none at all. When you are ready to publish, you publish a patch kit that transforms a specific commit on some other developer's (or google!) tree to your tree. That should satisfy the GPL.
Another thing to consider is to build these skills in an incremental fashion: if you have in mind a very specific kernel modification of original authorship as a first project, why not consider submitting your kernel patches as pull requests to an existing developer's kernel tree? If your patch/mod rocks, other devs will incorporate it - and probably be much more willing to answer twisty questions from you. You scratch their back, they scratch yours.
The point of the above two strategies is that they allow you to build skills incrementally rather than needing to know everything before you can begin doing anything. Don't try to learn it all simultaneously.
cheers

bftb0 said:
What hourly rate are you willing to pay? LOL
What I would recommend you do is to start simply by:
a) installing the current NDK
b) downloading a complete stock kernel build tree as a tarball (.tgz)
c) setting up a build environment and successfully build the kernel
d) unpack an existing boot image, stuff your kernel in there, & re-pack it
e) boot it on your device. Does it run? Congrats! You are a kernel-builder!
The reason that I suggest this outline plan above is that it initially avoids learning git & associated tools until after seeing something you've built running on the device; that's a confidence-booster. That's the good news.
The bad news is that becoming a *good* kernel dev from scratch means that you simultaneously are learning kernel coding conventions, build tree structuring, and kernel APIs *plus* achieving an excellent understanding of how git & gerrit work.
In addition to some amount of original source code mods authored by a kernel dev, they spend a fair amount of time integrating patch sets (commits) coming from unrelated kernel projects (e.g. Linux kernel mainline or kernel mods from unrelated devices). Learning simple operations (commits) in git is easy enough, but understanding branch creation & multi-way merge strategies in the face of cherry-picks coming from arbitrary places is a bit of a mind bender the first time through it.
And there is the issue of compliance with the GPL. As soon as you decide to make public your work, you have an obligation to publish your sources.
There is at least one way to do this simply: don't worry about git/gerrit/github at all - use whatever source code control system you want, including none at all. When you are ready to publish, you publish a patch kit that transforms a specific commit on some other developer's (or google!) tree to your tree. That should satisfy the GPL.
Another thing to consider is to build these skills in an incremental fashion: if you have in mind a very specific kernel modification of original authorship as a first project, why not consider submitting your kernel patches as pull requests to an existing developer's kernel tree? If your patch/mod rocks, other devs will incorporate it - and probably be much more willing to answer twisty questions from you. You scratch their back, they scratch yours.
The point of the above two strategies is that they allow you to build skills incrementally rather than needing to know everything before you can begin doing anything. Don't try to learn it all simultaneously.
cheers
Click to expand...
Click to collapse
Wow, okay, thank you! I'll start with that. Honestly I like having someone just point me in the directions then me teach myself the rest! That is probably the best thing to do all around. I just have somethings:
1.) If I get lost somewhere and am not able to find answer for something anywhere; do you mind if I PM you?
2.) Almost everywhere I read---including from source.android.com---it say, use Ubuntu; why? Do I have to? Ubuntu doesn't support my graphics card---and isn't easy to set up, even when using things from other OSes or just other stuff someone made---which is kinda needed because of my monitors.

jamcar said:
2.) Almost everywhere I read---including from source.android.com---it say, use Ubuntu; why? Do I have to? Ubuntu doesn't support my graphics card---and isn't easy to set up, even when using things from other OSes or just other stuff someone made---which is kinda needed because of my monitors.
Click to expand...
Click to collapse
I've used Unix/Linux for quite a long time, and if there is one thing that seems to never change is package dependency differences from distro to distro. Getting them resolved is mandatory (when you are stopped out by them), but typically quite a distraction from whatever it is you are trying to accomplish.
By using Ubuntu you will be following the footsteps of many others in front of you (including Google developers), and that means that when you encounter a problem, it will be very likely that exact problem has already been encountered and resolved, and you can find the solutions on the internet. That may not be the case for some other arbitrary distro. So, why make your life more difficult?
As far as kernel development goes, you can do anything you want inside a VM, assuming your machine has enough ram (say 4+ GB) and disk space (say 100G free). So get VirtualBox and create an Ubuntu VM.
There are small downsides to using a VM, but for code-building they are just fine - their performance in doing kernel builds is probably 95% of native metal.
jamcar said:
1.) If I get lost somewhere and am not able to find answer for something anywhere; do you mind if I PM you?
Click to expand...
Click to collapse
I would never commit to something open-ended like that - esp. since you said you have never coded anything before. You are free to PM me though, so long as you understand that I am free to choose not to reply. Given those ground rules, it might be better for you to just post your questions in public (say stackoverflow.com) so more eyeballs will see what you are asking.
cheers and good luck - you've chosen a pretty steep mountain to climb.

[Q] Some essential documentation badly needed

I read @Entropy512 write somewhere "we are more in need of developers than of testers at the moment"
To that effect I want to make an appeal to @maxwen @XpLoDWilD @Entropy512 @pulser_g2 and all other people who started the initiative to properly document out a few things
1. If a device maintainer wants to get his device added to omni ROM what should the steps be ?
2. To set up a omni ROM - compliant device tree what are the prerequisites. As in omniROM trees have been seen to be using a format of aosp.mk+custom.mk device makefiles where aosp.mk makes it AOSP-compliant and custom.mk is the omni additions. How custom.mk is to be made (a template maybe ?) should be be documented. In fact I would go out to say a device/custom/sample tree should be made as an example
3. Are there any guidelines as to how much the hardware side codes can be hacked with to make the devices supported ? (Many groups of developers have forks of hardware/qcom/* repos that are pretty liberally spread with #ifdef's and makes them break CTS/CDD in a huge way). How much will these hacks be supported ?
4. Obvious point, what are the fields in which you need help most badly as of now. That is to say ril/telephony experts are highly needed right now or are features the topmost priority or is the highest concern to make the hardware repos tip-top so that devices are completely stable
Also publishing some guides on how to get sources and build the ROM would be good too, but since you are looking for "Developers" right now, it can be assumed that they will figure that much out on their own at least

This documentation will be done.
Actually one of the key goals of omni is to properly document things.
Bear in mind exactly how early this is in the process - it was only yesterday we even made the links available for github...
Documentation will be a large part of going forward and it has been ongoing for a while. Currently that's the biggest task actually, much moreso than the actual development.
Developers don't only write code, they also write docs
To that effect, http://docs.omnirom.org is going to be the home

Among other things I want to do is a "patches for a given feature" document so it's easier to find out how a given feature (such as status bar brightness) was implemented.
I really want to do it before I have too many patches to put in there, but I also have tons of stuff to fix!

Entropy512 said:
Among other things I want to do is a "patches for a given feature" document so it's easier to find out how a given feature (such as status bar brightness) was implemented.
I really want to do it before I have too many patches to put in there, but I also have tons of stuff to fix!
Click to expand...
Click to collapse
What do you think about this idea? These common kernel patches could also fit into that document.

pulser_g2 said:
This documentation will be done.
Actually one of the key goals of omni is to properly document things.
Bear in mind exactly how early this is in the process - it was only yesterday we even made the links available for github...
Documentation will be a large part of going forward and it has been ongoing for a while. Currently that's the biggest task actually, much moreso than the actual development.
Developers don't only write code, they also write docs
To that effect, http://docs.omnirom.org is going to be the home
Click to expand...
Click to collapse
if I can be of any help let me know,
I would love to see this project start off right from the beginning with proper documentation about EVERYTHING
also +100 to @Entropy512 's idea. documenting each feature and how it has been added is really important
I strongly urge that submissions via gerrit should be enforced to have a well written description in the commit message too. (it is so much easier now with gerrit 2.7+ we can do it right inside our browser after the patch has been uploaded too)

championswimmer said:
if I can be of any help let me know,
I would love to see this project start off right from the beginning with proper documentation about EVERYTHING
also +100 to @Entropy512 's idea. documenting each feature and how it has been added is really important
I strongly urge that submissions via gerrit should be enforced to have a well written description in the commit message too. (it is so much easier now with gerrit 2.7+ we can do it right inside our browser after the patch has been uploaded too)
Click to expand...
Click to collapse
Yup. I've always tried to have a detailed commit message in anything I create, but I think we may need to start enforcing it so everyone does it.

Is there any kind of current features / bugs / patches list on the official build? Or even just a changelog?

orangekid said:
Is there any kind of current features / bugs / patches list on the official build? Or even just a changelog?
Click to expand...
Click to collapse
There are no official builds yet. Too early for that.
so much work to do.

Entropy512 said:
There are no official builds yet. Too early for that.
so much work to do.
Click to expand...
Click to collapse
Oh, I was under the impression there was a compiled "official" version for the N4, N7, etc...
No worries, in due time I'm sure. Be looking forward to the Nexus 5 build..

orangekid said:
No worries, in due time I'm sure. Be looking forward to the Nexus 5 build..
Click to expand...
Click to collapse
give us the device first

I follow Omni for the Nexus 5. Nightlies have started since Monday so I'd like to know if there's a general Omni changelog now or a specific one for each device.

I'm a developer without much ROM/Android development. I'd love to give a hand wherever possible, but like @championswimmer said, it's kind of overwhelming to jump in and help. I'm totally cool to be relegated to documenting things if that helps, but I also understand the interruption that it would cause for you guys to slow down long enough to explain what I need to know.
What I do have experience with:
Java
Jenkins
Minimal app development
Other crap that might or might not be helpful

B2G OS: Call for contributors

Due to the fact that I'm a new member here, I can't post outside links, you'll have to copy/paste them, sorry for the inconvenience.
What is B2G OS?
The Boot to Gecko (B2G) project was started [1] in 2011 to build a complete, standalone operating system for the open web. B2G is a community maintained open source project based on the Linux kernel and Gecko rendering engine and has been used as the basis of commercial Firefox OS smartphone and smart TV products.
In December 2015 the Mozilla Corporation announced [2] it was shifting its focus away from smartphones to other types of connected devices [3]. Since then a transition project [4] has been underway to modernize B2G and create a leaner platform on which to build smart TVs and other potential connected devices products in the future. As part of this transition, Mozilla's community of volunteers is taking ownership over the smartphone-specific parts of B2G so that Mozilla employees can focus their efforts elsewhere.
The transition project aims to replace Mozilla's legacy app runtime with new standards-based web apps and move the core B2G system closer to the architecture of the Firefox web browser. This will reduce complexity and maintenance costs and create a platform for the future based on emerging web standards.
Why Do We Need Your Help?
Maintaining an operating system is a big project and a large community of volunteers is needed if we are to keep B2G running on the smartphone form factor. There are many ways to contribute such as building and testing the OS, filing and fixing bugs, developing new features, porting to new devices, helping with documentation and localization and even just using and talking about the B2G project.
Help is already needed on the transition project to get core system features working, port smartphone apps to the new architecture and document everything which has changed. Once the transition is complete we hope to build an even bigger community of contributors to help making B2G move forward.
If you're interested in the challenge of helping to maintain a complete, standalone operating system for the open web, then we want to hear from you! B2G is made by the community for the community and we need your help.
How to Get Started
There are many ways to get in touch with the B2G community including the main forum [5], the dev-fxos mailing list [6], our #fxos IRC channel for real-time chat [6] and telegram group [7] for more general and informal discussions. We also hold weekly public meetings [8] on Vidyo where you can catch up with the latest news and meet other members of the team.
See B2G OS [9] on MDN for a list of ways you can get involved depending on your particular interests.
1. https://wiki.mozilla.org/Booting_to_the_Web
2. https://blog.mozilla.org/blog/2015/12/09/firefox-os-pivot-to-connected-devices/
3. https://wiki.mozilla.org/Connected_Devices
4. https://wiki.mozilla.org/B2G/Transition_Project
5. https://discourse.mozilla-community.org/c/firefox-os-participation
6. https://wiki.mozilla.org/IRC
7. https://telegram.me/B2GOS
8. https://wiki.mozilla.org/B2G/Meeting
9. https://developer.mozilla.org/en-US/docs/Mozilla/B2G_OS

What to do with discontinued devices

Over time, new devices are added and other devices drop off the list. Would it not make sense to create a space somewhere on the Lineage downloads page(s) to allow individuals to access the last official build - not the whole history but just the final build - for any given device (and maybe be able to resurrect them if they have interest in being a maintainer) ? It seems to me that having the devices simply disappear from view is not necessarily the best approach. While folks who have frequently updated their devices will probably be aware that the updates have ended (at least in the short term) newcomers will probably not. How much server space are we really talking about to keep ONE build and the device information for "X" number of devices, anyway?
FYI - 02 April, 2019 - another "obscure" device - the Galaxy S6 - just disappeared from the downloads page. HOW difficult would it be to create a tab for "retired builds" ?
FYI - 27 April, 2019 - the S6 edge is also gone, and the S7 is soon to follow.

I would also like to have discontinued device ROMs downloadable. It is also good to know that such builds existed. I agree that the a device should be allowed to be maintained again in the future should someone wish to become the maintainer or the previous maintainer wishes to continue.

Ascii3 said:
I would also like to have discontinued device ROMs downloadable. It is also good to know that such builds existed. I agree that the a device should be allowed to be maintained again in the future should someone wish to become the maintainer or the previous maintainer wishes to continue.
Click to expand...
Click to collapse
I absolutely and totally agree with this. Why throw it all away. Yes, maybe someone will pick up some of these de-appreciated devices in the future.

... Hello?

That explains it ......
Over 1,000 views and barely more than a dozen votes. To everyone who will scratch their heads when their devices up and vanish, at least you may now know why.