Maybe we should start a Optimus S CM7 "Bug Tracker"

[anim4l]

So as we all know, certain CM7 builds/rom's generally all have their own, what we will call "Error sets" and certain rom's have previous builds.

Why don't we as a community start taking the initiative to help dev's find and easily fix these errors?

What I suggest is when we notice errors in the build, we should have a centralized thread/subforum to post these in, with Build #/ROM/ and if applicable, the last Build it worked on, maybe if we take bit's and pieces of info from users to find when/where/why builds broke settings/configs/apps and possibly just -MOVE- the working apps from a previous build ( IE: Camera, has it -always- had the green artifacts? if not when did it show up?)

 

[drewwalton19216801]

So as we all know, certain CM7 builds/rom's generally all have their own, what we will call "Error sets" and certain rom's have previous builds.

Why don't we as a community start taking the initiative to help dev's find and easily fix these errors?

What I suggest is when we notice errors in the build, we should have a centralized thread/subforum to post these in, with Build #/ROM/ and if applicable, the last Build it worked on, maybe if we take bit's and pieces of info from users to find when/where/why builds broke settings/configs/apps and possibly just -MOVE- the working apps from a previous build ( IE: Camera, has it -always- had the green artifacts? if not when did it show up?)

Or how about we use the issue tracker built in to the github repository?

 

[cloroxx.l]

Or how about we use the issue tracker built in to the github repository?

lol so dry.

 

[anim4l]

Or how about we use the issue tracker built in to the github repository?

[sarcasm]
*Bows*

Because my post had -everything- to do with the IHO/CM7 Repo's, you have answered and acknowledged my post perfectly!
[/sarcasm]

I hate to break it to you, but such a bland and tasteless comment coming from you (whom I assume read the post) warrants this :

I was referring to the numerous CM7 builds/rom's in general, I know we have many, many (faithful, stubborn, what have you) members that swear by previous builds/rom's because it fits their need's. Within this field, (I'd assume) we could easily use USER input as to which/why they use that build/rom ver. and what's broken as to what works (pro's to con's) using that information to nail down errors/bugs and discover exactly what broke things based on changes.

Excuse me if I'm wrong, my Dev experience does not relate to Android/Java at all..

 

[drewwalton19216801]

[sarcasm]
*Bows*

Because my post had -everything- to do with the IHO/CM7 Repo's, you have answered and acknowledged my post perfectly!
[/sarcasm]

I hate to break it to you, but such a bland and tasteless comment coming from you (whom I assume read the post) warrants this :

I was referring to the numerous CM7 builds/rom's in general, I know we have many, many (faithful, stubborn, what have you) members that swear by previous builds/rom's because it fits their need's. Within this field, (I'd assume) we could easily use USER input as to which/why they use that build/rom ver. and what's broken as to what works (pro's to con's) using that information to nail down errors/bugs and discover exactly what broke things based on changes.

Excuse me if I'm wrong, my Dev experience does not relate to Android/Java at all..

The IHO CM7 repo is the only one that's being actively worked on, the Scott Pilgrim ROM is basically dead. And those are the only two that I know of for this specific device.

I am not downplaying the importance of user input, I'm simply saying that there are already issue trackers in place so we should use those for simplicity's sake.

For example, I have an issue tracker on my XioniaRedux repository and I am encouraging use of that because it allows the developer (me in this particular instance) to keep a central log of all issues and complaints rather than sifting through potentially hundreds of info-less posts.

 

[anim4l]

The IHO CM7 repo is the only one that's being actively worked on, the Scott Pilgrim ROM is basically dead. And those are the only two that I know of for this specific device.

I am not downplaying the importance of user input, I'm simply saying that there are already issue trackers in place so we should use those for simplicity's sake.

For example, I have an issue tracker on my XioniaRedux repository and I am encouraging use of that because it allows the developer (me in this particular instance) to keep a central log of all issues and complaints rather than sifting through potentially hundreds of info-less posts.

I'm not worried about them being dead/inactive. I'm sure there are fixes (quite possibly alternate ones, that each person could/would fix differently, the GLORY of Open Source is seeing and working with and seeing how others would accomplish a similar goal. What I'm suggesting isn't important because as you said there's a tracker in the git, a link in the main post to the tracker would be helpful, I can't seem to find it (I'm not stupid, I just can't seem to find it)

 

[drewwalton19216801]

I'm not worried about them being dead/inactive. I'm sure there are fixes (quite possibly alternate ones, that each person could/would fix differently, the GLORY of Open Source is seeing and working with and seeing how others would accomplish a similar goal. What I'm suggesting isn't important because as you said there's a tracker in the git, a link in the main post to the tracker would be helpful, I can't seem to find it (I'm not stupid, I just can't seem to find it)

The issue you are having is that the issue tracker is not accessible from the main repository page, you kind-of have to choose the sub-repository that your issue is a part of, if that makes sense.

I therefore retract what I said about the issue tracker needing to be used (which it really does, but whatever). I'm just not convinced that a forum is quite the appropriate place to have an issue database/tracker, simply because of the potential for that to be quite huge and riddled with info-less posts.

 

[blarf]

I was referring to the numerous CM7 builds/rom's in general, I know we have many, many (faithful, stubborn, what have you) members that swear by previous builds/rom's because it fits their need's. Within this field, (I'd assume) we could easily use USER input as to which/why they use that build/rom ver. and what's broken as to what works (pro's to con's) using that information to nail down errors/bugs and discover exactly what broke things based on changes.

Find another CM7 build that's not been abandoned for the Optimus S/V and then we'll talk. Until then your comment was and attitude is totally unwarranted.

Scott Pilgrim hasn't been updated since April? aospCMod hasn't been updated since June, and with no publicly available source, good luck doing anything useful with an issue tracker. Especially considering the security issues inherent in both, I can't think of a single reason to use either one. If you're talking about other non-CM7 ROMs, chances are their source is up on Github as well.

 

[blarf]

I'm not worried about them being dead/inactive. I'm sure there are fixes (quite possibly alternate ones, that each person could/would fix differently, the GLORY of Open Source is seeing and working with and seeing how others would accomplish a similar goal. What I'm suggesting isn't important because as you said there's a tracker in the git, a link in the main post to the tracker would be helpful, I can't seem to find it (I'm not stupid, I just can't seem to find it)

The main IHO dev threads (in the OV sections of Android Central and XDA) have links to the IHO issue tracker, CM bug tracker, and CM code review site. I agree that a prominent link to issue trackers is important.

As far as IHO goes, I've actually just stuffed everything except for pull requests into the android_device_lge_thunderc issue tracker. I can't (yet?) close bugs from other repos, but I can reference them and Github DTRT.

See, for instance, this issue:

https://github.com/inferiorhumanorgans/android_device_lge_thunderc/issues/14

 

[gilbequick]

Especially considering the security issues inherent in both, I can't think of a single reason to use either one.

What security issues are you referring to?

 

[anim4l]

Find another CM7 build that's not been abandoned for the Optimus S/V and then we'll talk. Until then your comment was and attitude is totally unwarranted.

Scott Pilgrim hasn't been updated since April? aospCMod hasn't been updated since June, and with no publicly available source, good luck doing anything useful with an issue tracker. Especially considering the security issues inherent in both, I can't think of a single reason to use either one. If you're talking about other non-CM7 ROMs, chances are their source is up on Github as well.

I'm so lost as to how any of this even applies, the origination of this post was to attempt to help, not cause strife and drama. If my attempt at helping is lost in translation, misunderstood or perceived as anything other then reasonable questions and a quest for knowledge and help I am quite sorry.

No hard feelings here nor was there ever, this seems to be nothing more then a huge misunderstanding.

 

[deathangel1496]

Is there any that have working Bluetooth?

Sent from my clean optimus using a gameboy advance :3

 

[drewwalton19216801]

Is there any that have working Bluetooth?

Sent from my clean optimus using a gameboy advance :3

Depends on what you define "working" to mean. Bluetooth stereo works fine AFAIK but bluetooth headsets? Not a chance.