* Spencer, Bob
| Lastly, perhaps we could agree on some standards for branching existing
| projects. For example #ifdef tag, for code, Makefile.am,
| configure.in, etc. Then we could easily go to a project and find
| where/if someone else had added mobile-device-specific changes.
|
| tag =
Tollef Fog Heen wrote:
* Spencer, Bob
Lastly, perhaps we could agree on some standards for branching
existing projects. For example #ifdef tag, for code, Makefile.am,
configure.in, etc. Then we could easily go to a project and find
where/if someone else had added mobile-device-specific
Ola
In the style of autoconf, I suggest we use #ifdef USE_HILDON
maemo uses #ifdef MAEMO_CHANGES
maybe keeping compatible with this could be 'a good thing'
[]'s
Ian
--
http://ianlawrence.info
--
Ubuntu-mobile mailing list
Ubuntu-mobile@lists.ubuntu.com
Modify settings or unsubscribe at:
On Fri, Sep 21, 2007 at 02:36:04PM -0400, Pat McGowan wrote:
When custom versions of gnome based components are created, is it the
intention to manage these as patches upstream in gnome, for example in the
gnome mobile project?
If not, what is the plan to sync these customizations
I believe for Network Admin and Date/Time settings, Todd was planning
on providing a patch to gnome-system-tools for the UI changes
necessary for running in the hildon environment. But I'm not sure
about all of the other control panel applets. Todd, does it make
sense to do this for all
Bill Filler wrote:
I believe for Network Admin and Date/Time settings, Todd was planning
on providing a patch to gnome-system-tools for the UI changes
necessary for running in the hildon environment. But I'm not sure
about all of the other control panel applets. Todd, does it make
sense to do
I agree with Matt that we should always attempt to push changes
upstream. Non-UI changes seem like a no-brainer. In time upstream
component owners might have to decide if they want to support a
Hildon-esque UI in addition to their standard UI which could be more
than a few #define's.
I
When custom versions of gnome based components are created, is it the
intention to manage these as patches upstream in gnome, for example in the
gnome mobile project?
If not, what is the plan to sync these customizations with upstream changes?
If so, should they not be named something like
