Clay Baenziger wrote: > Hi Ethan, > Sorry for the delay, answers are in-line... > > Thank you, > Clay > > On Thu, 26 Mar 2009, Ethan Quach wrote: > >> Clay, >> >> Clay Baenziger wrote: >>> Hi Ethan, >>> With regards to bug 7383. I see issues surrounding this bug as: >>> * Being able to ensure an AI client gets a manifest with keywords >>> which it supports (i.e. server running build Y, client running >>> build X, x<y) >>> * Being able to identify what build (of our bits) an AI client is >>> running >> >> Can you elaborate on how you see the second bullet is related? That >> seems to be more an issue of the installer bits being compatible with >> bits that are laid down. I sent out a separate proposal for that >> earlier this week. Feel free to comment on that. > > Ethan, I see having the build available to determine manifests being a > useful thing for system configuration and perhaps even packages to > install too. For example, one might not want to install a package on > an older build where there's a security or performance issue.
Yeah but that sounds like a different problem. Using build numbers versions for the installer to infer what to configure or install is not in the scope what we're trying to solve here. I don't think we'd want to rely on build numbers for that anyway. A proper interface to determine what features are available is what we'd want to use. > >>> >>> To achieve these two ends: >>> * The schema could define what changeset (of slim_source) the >>> feature being defined was added. (Perhaps just a changeset=### >>> attribute that can be added to features in the schema.) Then, >>> publish_manifest will store what the minimum changeset necessary >>> for that schema in the criteria database as a criteria. >> >> I think you're confusing the changeset ID with the revision number. >> What you're describing above requires a sequential ordering, but >> changeset IDs are not sequentially ordered, they are just 40 digit >> hex unique identifiers. >> >> The revision number is ordered, but they would be unreliable for this >> usage because you can't rely on them to be the same over time. i.e. >> revision number 545 isn't always going to describe changeset X. >> >> See this URL for descriptions of these Mercurial terms >> http://www.selenic.com/mercurial/wiki/index.cgi/FAQ#head-64d21ec75f556ed21f840436727a82655fdfb5ac >> >> >> > > Yes, you're right, I meant revision number. Hrm, I see it mentioned > that revision numbers are not stable across multiple repository copies > but off our one development repo they should remain stable from: "A > changeset is identified uniquely by a changeset ID. In a single > repository, you can identify it using a revision number." -- > http://www.selenic.com/mercurial/wiki/index.cgi/ChangeSet See http://www.selenic.com/mercurial/wiki/index.cgi/RevisionNumber It's plainly clear to me it wouldn't be used in local context with what is being proposed here. > >>> * The client can send which changeset of slim_source it was built >>> off of in the AI server<->client criteria exchange. >> >> Exactly my point. Once you record the revision number off into the >> built image, you can't reliably compare it back to the revision number >> in the manifest because the former or latter's revision number could >> have been gotten after a shift. > > Yes, there is a problem, for example, when we move from our > development repo to ON. We could instead use a tags when available and > record a tag and revision number falling back if no tag or some such. But tags aren't automatically generated anyway, so this would be no better than incrementing a version number, and seems like it'd actually be more error prone. I'd like to proceed with this as soon as possible, so unless there are other opinions or suggestions, a simple incremented version number is what will be used. thanks, -ethan > >>> * Then all that is necessary to ensure the client gets an >>> appropriate manifest is to have the AI webserver treat the >>> changeset criteria as just any other criteria -- no work >>> necessary. >> >> I think you're on the right track with this, but instead of using >> the repository revision numbers, why not just cook up our own ordered >> numbers every time we change/add features to the manifest? What's >> wrong with 1, 2, 3, ... > > I see requiring human intervention to be a bad idea since it's limited > to when someone updates the version number (so not as generalized and > prone to forgetting). > >> >> thanks, >> -ethan >> >> >>> >>> I see this as requiring fairly little implementation (~5 days >>> with testing). Let me know what's might be missed by such an >>> approach or how else versioning could be done though. >>> Thank you, >>> Clay >>
