On Fri, Jan 04, 2008 at 11:09:29AM +0000, Thomas Wood wrote: > > On Fri, 2008-01-04 at 14:00 +0800, John Lee wrote: > [...] > > > > If we want to use OM mtn for development, the policy should be clear > > that ALL OM related packages cannot commit code that depends on > > upstream OE instead of OM mtn. There's no way we could maintain a > > stable daily build if we keep changing the outside dependency. > > > > Your comments? > > Sounds fine to me, as long as it is clear to all OpenMoko core > developers. I would imagine some sort of procedure describing what to do > when things break would be good as well. For example, do we: revert the > changes in openmoko-terminal, fix OM mtn at a particular revision of > openmoko-terminal until the next time OM mtn is synched with OE, or > update OM mtn straight away? >
For now: Revert it since it's the same as "break the build". Make the necessary modification after the next sync. In the future: update OM mtn straight away. Every OM developers will have commit permissions sometime after gta02 ships. > > This is rather a grey area for me. If dbus >= 1.1.1 is a requirement > > that you cannot integrate PackageKit without it, I will lean toward > > commit to OM first, make sure the latest version builds, then merge > > upstream. Commit to OE really seems reasonable but that will break > > daily builds and I really hope moko-autorev.inc + OM mtn works. > > I can see that using doing development in OM mtn would cause problems, > because of possible conflicts when re-syncing with OE. Perhaps for that > reason it would be best for development to stay upstream in OE? That way > there is only one source of changes for OM mtn and therefore no issues > with conflicts. Please don't break the daily builds. Regards, John
