So Chrome and Firefox are not large projects? Because they do the very thing you claim that "no large project" does.
Do they? Does the build number increase every time every developer makes a submission? Maybe. WebKit doesn't and Apple have thousands if engineers. The full OS build is not run every submission or it would be much larger than 451. Think about it. Also think about the waste of building every time the passbook guy fixes a comment.
It's every night. The question is why it's 451.
I mean they may have moved to two builds a day. Not every submission. That seems pointless though.
Do they? Does the build number increase every time every developer makes a submission? Maybe. WebKit doesn't and Apple gave thousands if engineers. The full OS build is not run every submission or it would be much larger than 451. Think about it.
Yes. They do. From Google's documentation about their version numbers:
BRANCH_BUILD will be updated every time a new build is started on a branch. This happens whenever a commit is made to the branch.
Mozilla uses Tinderbox (feel free to look it up) which is used to continuously build and test after each change checked in. You can even view this here: https://tbpl.mozilla.org/
So either Firefox and Chrome are not "large projects" or you were speaking out of your ass. I'm going with the latter.
So Chrome and Firefox are not large projects? Because they do the very thing you claim that "no large project" does.
Crome and Firefox are applications, this is an operating system... a much, much larger project.
Furthermore, that can't be true. I seriously doubt those projects are completely recompiled after each submission, there has to be a limit number of submissions before a compile can occur.
More than likely, individual developers can compile their "branch" to make sure their code is working properly. And then it is submitted to the main trunk that is compiled probably once a day.
Crome and Firefox are applications, this is an operating system... a much, much larger project.
Furthermore, that can't be true. I seriously doubt those projects are completely recompiled after each submission, there has to be a limit number of submissions before a compile can occur.
More than likely, individual developers can compile their "branch" to make sure their code is working properly. And then it is submitted to the main trunk that is compiled probably once a day.
BRANCH_BUILD will be updated every time a new build is started on a branch. This happens whenever a commit is made to the branch.
Yeah, that's a branch, not the main trunk. The build number in OS X is a recompile of the main trunk, which may only happen once a day, regardless of how many times a specific branch is compiled.
Quote:
Originally Posted by Applelunatic
It is true. See my post right above yours.
It's not. A branch is not the actual project that is released, it's a developers version, that could be compiled over and over again. Before changes are submitted to the main project.
Yeah, that's a branch, not the main trunk. The build number in OS X is a recompile of the main trunk, which may only happen once a day, regardless of how many times a specific branch is compiled.
Yes, it's the current development branch for that version of the product. Nice attempt at a semantics game, though. Also I like how you ignored my link to Mozilla's continuous build console where you can see that each commit gets it's own build and test run.
Yes, it's the current development branch for that version of the product. Nice attempt at a semantics game, though. Also I like how you ignored my link to Mozilla's continuous build console where you can see that each commit gets it's own build and test run.
Never said it wasn't a current development branch. Yes I did look at the link. Nothing to do with semantics...
From Mozilla pages...
"mozilla-inbound is an integration branch that merges to and from mozilla-central about once a day. It's a place where changes can land and be tested without risk of breaking the main mozilla-central trunk."
So, as I stated, the main trunk is not compiled with every commit from every developer. And again, the revision number of OS X reflects a recompile of the main trunk, which probably also happens about once a day.
mdriftmeyer is almost certainly correct, and probably knows what he's talking about. As for Gruber, even if he's under NDA, he can most likely publish info he receives from sources other than official Apple channels.
Before moving into Professional Services at NeXT and later Apple my primary role in Software Quality Assurance was to manage, trouble ticket and escalate workarounds/code fixes to be staged in the build process by the build Engineers for Openstep/Openstep for Windows, EOF1.x/2.x, WOF 1.x-3.5., PDO, D'OLE. Myself and one other colleague who later joined the Interface Builder Team handpicked all third party devs under NDA who were given access from the earliest builds possible to let them beat on the products. Whether that be Merrill Lynch, ATT, CIA, Banc Suisse, you name it, we carried this process over to Apple.
Later I was focused on supporting the Enterprise NeXT legacy and then OS X transition. Select developers/developing houses are chosen for their high probability of adding value to the testing phases and finding showstoppers.
This is still true for all projects with strict NDA requirements. All the FOSS based projects that include LLVM/Clang/LLDB/Compiler-RT, WebKit, CUPS, and more have specific internal branches that roll out those changes after already being introduced into Apple specific projects ala XCode, OS X updates, etc.
That's a remarkable build number. It makes no sense to build twice a day or even most weekends.
This makes excellent sense. Build numbers may have started at 100 (triple digits). And check-ins are happening all the time, so multiple builds per day could be very helpful for developers wanting to test ASAP. Some build attempts may fail and have to be restarted, too, and still receive a unique build number of their own. I would hazard to guess virtually all Apple developers work nearly all weekends.
Just a few years ago, builds would take a day (if they succeeded), but the situation is likely much improved today.
Yeah, that's a branch, not the main trunk. The build number in OS X is a recompile of the main trunk, which may only happen once a day, regardless of how many times a specific branch is compiled.
It's not. A branch is not the actual project that is released, it's a developers version, that could be compiled over and over again. Before changes are submitted to the main project.
Yes, we ran nightly builds of OS X with specific AppKit/Foundation Kit changes against other builds to ease targeted SQA testing and later merged changes back in to a main branch. Been that way since NeXTSTEP 1.0 to OS X present. Specific teams have custom builds made to test changes before they roll the update back into the mainline, etc., etc.
MAPS was not a bug in the software, it was the data that was being displayed. Apple can only do so much with third party data, especially when you are displaying the entire world. Even Google has bugs in the data, even to this day. Apple should have spent another 6 months to a year cleaning it up, but it's faster if they have customers submitting problems.
What they should've done is released Maps as a public beta and kept Google Maps as the default until Maps was ready. The problem was that they real-world feedback from the users. And time to work on that feedback. Instead, they only had feedback from developers who happened to mostly share the same geographic areas. I live in Silicon Valley, so it's no wonder Maps worked well for me on day 1.
While the build count really means nothing I'm surprised that so many people expect so little from 10.9. I actually see it having the potential to be a huge update. For example we could see support for heterogeneous computing in the memory manager, up to date OpenGL and OpenCL support, improved power management code to take advantage of Haswell, new networking code, general driver updates, UNIX subsystem improvements, maybe a fix to iCloud and a whole host of other improvements. I could go on for awhile but the idea is that there is huge potential for a major OS revision.
As a side note, for those of you that got the latest 10.8 update and iTunes update, have you noticed major improvements on low memory machines? Maybe it is me but my machine feels far less sluggish than it did befor the update running a bunch of programs all at once. Just a thought but maybe 10.9 will clean up a lot of memory management issues and other things leading to sluggish performance on old hardware.
You have no reason to say that at all. First; on modern hardware you can rebuild an entire OS rather quickly, they could hit the build button at lunch time for example. I wouldn't be the least bit surprised to find builds happening on a large cluster to cut build times even further. Beyond that if they are working on one component a rebuild might just be limited to code for what is being worked on.
I am pointing out the absurdity in your argument about "knowing" how integrated builds work.
If there are 451 builds of OS X it took 451 days. Minimum.
Nothing bugs me more than sneering statements from people who have no clue.
Yes it is sad! I really don't understand your point of view though, you have no reason at all to believe that Apple can only manage one build a day. I wouldn't be surprised to find that Apple has the ability to rebuild the entire Mac OS code base several times a day if they really wanted too.
What they should've done is released Maps as a public beta and kept Google Maps as the default until Maps was ready. The problem was that they real-world feedback from the users. And time to work on that feedback. Instead, they only had feedback from developers who happened to mostly share the same geographic areas. I live in Silicon Valley, so it's no wonder Maps worked well for me on day 1.
Maps was accurate in your area not because of developers giving Apple feedback, but because the people there are more likely to jump on new technology first, this would include using something like OpenStreetMap and giving feedback to them.
Apple uses OpenStreetMap data, along with many, many other public databases around the world for its location information (Google uses these as well to update its own database). There is no reason for a "beta" version. Apple's Maps worked fine. The small number of instances of inaccuracies were blown way out of proportion by people who scream "bomb" when a firecracker is lit.
Google's data has many errors as well, but no one really cared, they just reported it to Google and went on their merry way. No one made a big deal about it. Mapping data is EXPECTED to have errors and not be complete as new roads are constantly being changed, torn up and built, etc., etc.
A big deal was made when Apple dumped Google's Maps because some people wanted -- no, like to see Apple to fail, so every little issue went under the microscope.
I live on the otherwise of the country and frankly maps has worked great every time I've used it. It often got skewered in the media due to data base errors that every GPS based mapping system has had or does have to this day. In the end much of the complaining about maps was either based own ignorance or a mischievous attempt to harm Apple. A rational look at Maps would have people seeing a well done version one app.
What they should've done is released Maps as a public beta and kept Google Maps as the default until Maps was ready.
Maps was ready from day one, it does precisely what a mapping program should do.
The problem was that they real-world feedback from the users. And time to work on that feedback.
Sometimes that user feedback is more damaging than helpful. You could see this in places data where users obviously screwed up in one manner or another.
Instead, they only had feedback from developers who happened to mostly share the same geographic areas. I live in Silicon Valley, so it's no wonder Maps worked well for me on day 1.
If you looked at complaints closely, at release, it wasn't an issue of maps not working it was either data base issues or unreasonable expectations. For one it was totally unreasonable of people to expect that Apple would release a maps app that copied Googles solution 100%. It is this expectation that frankly lead to a lot of drizzle on the net about nothing. It amounted to complaining about Pages because it doesn't work like MS Word.
It is funny that people get so bent out of shape over Maps which works well for most users and gloss over iCloud which for most users is a big disappointment. For whatever reason Maps got elected to be the punching bag.
Comments
I am pointing out the absurdity in your argument about "knowing" how integrated builds work.
If there are 451 builds of OS X it took 451 days. Minimum.
Nothing bugs me more than sneering statements from people who have no clue.
Do they? Does the build number increase every time every developer makes a submission? Maybe. WebKit doesn't and Apple have thousands if engineers. The full OS build is not run every submission or it would be much larger than 451. Think about it. Also think about the waste of building every time the passbook guy fixes a comment.
It's every night. The question is why it's 451.
I mean they may have moved to two builds a day. Not every submission. That seems pointless though.
Quote:
Originally Posted by asdasd
I am pointing out the absurdity in your argument about "knowing" how integrated builds work.
If there are 451 builds of OS X it took 451 days. Minimum.
Nothing bugs me more than sneering statements from people who have no clue.
And I should believe what you say, why? Because you personally work for Apple on OS X?
Quote:
Originally Posted by asdasd
Do they? Does the build number increase every time every developer makes a submission? Maybe. WebKit doesn't and Apple gave thousands if engineers. The full OS build is not run every submission or it would be much larger than 451. Think about it.
Yes. They do. From Google's documentation about their version numbers:
BRANCH_BUILD will be updated every time a new build is started on a branch. This happens whenever a commit is made to the branch.
Mozilla uses Tinderbox (feel free to look it up) which is used to continuously build and test after each change checked in. You can even view this here: https://tbpl.mozilla.org/
So either Firefox and Chrome are not "large projects" or you were speaking out of your ass. I'm going with the latter.
Quote:
Originally Posted by Applelunatic
So Chrome and Firefox are not large projects? Because they do the very thing you claim that "no large project" does.
Crome and Firefox are applications, this is an operating system... a much, much larger project.
Furthermore, that can't be true. I seriously doubt those projects are completely recompiled after each submission, there has to be a limit number of submissions before a compile can occur.
More than likely, individual developers can compile their "branch" to make sure their code is working properly. And then it is submitted to the main trunk that is compiled probably once a day.
Quote:
Originally Posted by mjtomlin
Crome and Firefox are applications, this is an operating system... a much, much larger project.
Furthermore, that can't be true. I seriously doubt those projects are completely recompiled after each submission, there has to be a limit number of submissions before a compile can occur.
More than likely, individual developers can compile their "branch" to make sure their code is working properly. And then it is submitted to the main trunk that is compiled probably once a day.
It is true. See my post right above yours.
Quote:
Originally Posted by Applelunatic
BRANCH_BUILD will be updated every time a new build is started on a branch. This happens whenever a commit is made to the branch.
Yeah, that's a branch, not the main trunk. The build number in OS X is a recompile of the main trunk, which may only happen once a day, regardless of how many times a specific branch is compiled.
Quote:
Originally Posted by Applelunatic
It is true. See my post right above yours.
It's not. A branch is not the actual project that is released, it's a developers version, that could be compiled over and over again. Before changes are submitted to the main project.
Quote:
Originally Posted by mjtomlin
Yeah, that's a branch, not the main trunk. The build number in OS X is a recompile of the main trunk, which may only happen once a day, regardless of how many times a specific branch is compiled.
Yes, it's the current development branch for that version of the product. Nice attempt at a semantics game, though. Also I like how you ignored my link to Mozilla's continuous build console where you can see that each commit gets it's own build and test run.
Fahrenheit 451: The temperature at which an operating system gets so f@cking cool that it catches fire with the masses!
(I like what you did there
That build was almost a month ago. Search for 13A451 in:
https://trac.webkit.org/export/151283/trunk/Source/WebKit2/ChangeLog
I've never seen an ocelot!
Quote:
Originally Posted by Applelunatic
Yes, it's the current development branch for that version of the product. Nice attempt at a semantics game, though. Also I like how you ignored my link to Mozilla's continuous build console where you can see that each commit gets it's own build and test run.
Never said it wasn't a current development branch. Yes I did look at the link. Nothing to do with semantics...
From Mozilla pages...
"mozilla-inbound is an integration branch that merges to and from mozilla-central about once a day. It's a place where changes can land and be tested without risk of breaking the main mozilla-central trunk."
So, as I stated, the main trunk is not compiled with every commit from every developer. And again, the revision number of OS X reflects a recompile of the main trunk, which probably also happens about once a day.
Quote:
Originally Posted by anonymouse
mdriftmeyer is almost certainly correct, and probably knows what he's talking about. As for Gruber, even if he's under NDA, he can most likely publish info he receives from sources other than official Apple channels.
Before moving into Professional Services at NeXT and later Apple my primary role in Software Quality Assurance was to manage, trouble ticket and escalate workarounds/code fixes to be staged in the build process by the build Engineers for Openstep/Openstep for Windows, EOF1.x/2.x, WOF 1.x-3.5., PDO, D'OLE. Myself and one other colleague who later joined the Interface Builder Team handpicked all third party devs under NDA who were given access from the earliest builds possible to let them beat on the products. Whether that be Merrill Lynch, ATT, CIA, Banc Suisse, you name it, we carried this process over to Apple.
Later I was focused on supporting the Enterprise NeXT legacy and then OS X transition. Select developers/developing houses are chosen for their high probability of adding value to the testing phases and finding showstoppers.
This is still true for all projects with strict NDA requirements. All the FOSS based projects that include LLVM/Clang/LLDB/Compiler-RT, WebKit, CUPS, and more have specific internal branches that roll out those changes after already being introduced into Apple specific projects ala XCode, OS X updates, etc.
Quote:
Originally Posted by asdasd
That's a remarkable build number. It makes no sense to build twice a day or even most weekends.
This makes excellent sense. Build numbers may have started at 100 (triple digits). And check-ins are happening all the time, so multiple builds per day could be very helpful for developers wanting to test ASAP. Some build attempts may fail and have to be restarted, too, and still receive a unique build number of their own. I would hazard to guess virtually all Apple developers work nearly all weekends.
Just a few years ago, builds would take a day (if they succeeded), but the situation is likely much improved today.
Quote:
Originally Posted by mjtomlin
Yeah, that's a branch, not the main trunk. The build number in OS X is a recompile of the main trunk, which may only happen once a day, regardless of how many times a specific branch is compiled.
It's not. A branch is not the actual project that is released, it's a developers version, that could be compiled over and over again. Before changes are submitted to the main project.
Yes, we ran nightly builds of OS X with specific AppKit/Foundation Kit changes against other builds to ease targeted SQA testing and later merged changes back in to a main branch. Been that way since NeXTSTEP 1.0 to OS X present. Specific teams have custom builds made to test changes before they roll the update back into the mainline, etc., etc.
Quote:
Originally Posted by drblank
MAPS was not a bug in the software, it was the data that was being displayed. Apple can only do so much with third party data, especially when you are displaying the entire world. Even Google has bugs in the data, even to this day. Apple should have spent another 6 months to a year cleaning it up, but it's faster if they have customers submitting problems.
What they should've done is released Maps as a public beta and kept Google Maps as the default until Maps was ready. The problem was that they real-world feedback from the users. And time to work on that feedback. Instead, they only had feedback from developers who happened to mostly share the same geographic areas. I live in Silicon Valley, so it's no wonder Maps worked well for me on day 1.
As a side note, for those of you that got the latest 10.8 update and iTunes update, have you noticed major improvements on low memory machines? Maybe it is me but my machine feels far less sluggish than it did befor the update running a bunch of programs all at once. Just a thought but maybe 10.9 will clean up a lot of memory management issues and other things leading to sluggish performance on old hardware.
Yes it is sad! I really don't understand your point of view though, you have no reason at all to believe that Apple can only manage one build a day. I wouldn't be surprised to find that Apple has the ability to rebuild the entire Mac OS code base several times a day if they really wanted too.
Quote:
Originally Posted by macslut
What they should've done is released Maps as a public beta and kept Google Maps as the default until Maps was ready. The problem was that they real-world feedback from the users. And time to work on that feedback. Instead, they only had feedback from developers who happened to mostly share the same geographic areas. I live in Silicon Valley, so it's no wonder Maps worked well for me on day 1.
Maps was accurate in your area not because of developers giving Apple feedback, but because the people there are more likely to jump on new technology first, this would include using something like OpenStreetMap and giving feedback to them.
Apple uses OpenStreetMap data, along with many, many other public databases around the world for its location information (Google uses these as well to update its own database). There is no reason for a "beta" version. Apple's Maps worked fine. The small number of instances of inaccuracies were blown way out of proportion by people who scream "bomb" when a firecracker is lit.
Google's data has many errors as well, but no one really cared, they just reported it to Google and went on their merry way. No one made a big deal about it. Mapping data is EXPECTED to have errors and not be complete as new roads are constantly being changed, torn up and built, etc., etc.
A big deal was made when Apple dumped Google's Maps because some people wanted -- no, like to see Apple to fail, so every little issue went under the microscope.
Maps was ready from day one, it does precisely what a mapping program should do. Sometimes that user feedback is more damaging than helpful. You could see this in places data where users obviously screwed up in one manner or another.
If you looked at complaints closely, at release, it wasn't an issue of maps not working it was either data base issues or unreasonable expectations. For one it was totally unreasonable of people to expect that Apple would release a maps app that copied Googles solution 100%. It is this expectation that frankly lead to a lot of drizzle on the net about nothing. It amounted to complaining about Pages because it doesn't work like MS Word.
It is funny that people get so bent out of shape over Maps which works well for most users and gloss over iCloud which for most users is a big disappointment. For whatever reason Maps got elected to be the punching bag.