On Wed, Jan 12, 2011 at 11:14 AM, Dave Neary <[email protected]> wrote: > Hi, > > Sivan Greenberg wrote: >> What if I want to change something or add functionality to an existing >> package? > > Then you should go through the submission process of the upstream (code) > project. This is why I make a clear distinction between package > maintainers (who ensure the latest software is packaged for a distro) > and project maintainers (who decide what that software will do). > >> For instance, what if I want to provide fixes or apply >> somebody else's fixes to improve the core UX in meego to be more >> suitable for the idea pad[0], and I do have the time for that. >> [0]: http://bugs.meego.com/show_bug.cgi?id=10739 > > We're getting to the heart of the matter now. Let's say that you decided > to address this issue of netbook UX and touchscreen. You could pick > easier ones, but let's say, for argument's sake... > > You will need to presumably open some smaller-granularity bugs > ("Increase corner and edge target sizes on windows for touch events", > for example), against the appropriate module. Now, I don't know exactly > what is involved, but I can guess that changes would be needed in > Mutter, I guess, and it probably needs some work in XInput & Xorg to > differentiate between touch & mouse events, and related work in Clutter > and Mx. > > It's possible that the maintainers of one or all of these modules will > reject your work as not aligned with their goals - you can try to > propose that the patch be carried as a distro-specific diff, but that > would be quite a big one, and there's a good chance that the request > would be rejected by the package maintainers & MeeGo architects. So you > should work with the Mutter/Mx/Clutter maintainers first to see if they > agree with your way of doing things before you start doing the work, to > give the best possible chance of your patch being accepted. > > Once you have a good idea that patches would be accepted, you can start > working on the code for the problem.
You chose the worst example by using mutter. Meego forked mutter and its not compatible with "upstream" mutter in any sense of the word. It forked shortly after Moblin 2.0 and I when I ask about it I get "yea, should fix that" or "but we were upstream first" so it would be nice to know what the "upstream" plans are for mutter in this "always push changes upstream first" world. Peter _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
