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. So first you'd make a patch proposal for XInput in Xorg, and a related patch request in Mx or Mutter, whichever is relevant (Thomas Wood, Thomas Friedrich or Emmanuele Bassi can tell you, I guess). They will review your patch, suggest changes, but (if you've done the work of getting everyone on the same page beforehand) these changes should only be minor. If, on the other hand, you propose patches for features the maintainers don't want, or you're doing things in a way they fundamentally disagree with, no amount of massaging the patch will help. So, once the XInput patch is accepted, and the Mx/Mutter patch is accepted, the changes will automatically propagate to the Netbook UX for the next version. Now, knowing that the next version of XInput will be releasing sometime in 2011, and Clutter (synced with GNOME I think) probably won't include your patch until September '11, MeeGo won't have it until the Winter '11 release, or perhaps Spring '12. Concretely, this is what "working upstream" actually means. > Perhaps we could at least assign a mentor or a sponsor that would > review packages and upload them on my behalf? I even touched sysvinit > in Ubuntu through this process[1]. Martin only physically uploaded it. > [1]: https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/28447/comments/14 Please let's separate code & packaging issues. Ubuntu does indeed carry many distro patches. They typically do expect changes to be proposed upstream also, but for smallish changes, or changes to config files/defaults, they will carry a diff. In this case, we're talking about a 10 line change to a shell script, which doesn't look like it got submitted upstream to Debian. In this particular case, it's hard to know if this was patching a bug also present upstream, or one which was only present in Ubuntu. When you're talking about major code changes, they really need to be done upstream, in a way the maintainer is happy to maintain, or you will end up very quickly with multi-thousand line patches that will take a huge amount of effort to maintain across releases. > Yes, that is highly desirable. Do we have an ITP request queue like > Debian has? If not, can we please start it? We still need some people > to be able to review packages or help people get their first package > the #debian-mentors style , although I've seen that already happening > in #meego. Do we keep this that way? I do think a packagine mentoring program would be a great addition - perhaps something that David Greaves might have views on via the community OBS project? But just a place & some people where you can go to figure out how to set up a zypper repository, package an RPM from a .tar.gz, and the recommended path for getting a package into the main repository (rather than propagating private repositories) would be most excellent. > Well, in Ubuntu when you wanted to add a feature you ultimately became > the package's maintainer. This is a bug, not a feature - and one we want to fix in MeeGo. If you want to add a feature, add it upstream. Otherwise, you end up with the situation like the Hundred Paper Cuts project, with bandages on bandages, all only in Ubuntu, and many of the fixes don't benefit anyone else. Any code changes really should go to the maintainer, and not into packaging. > Where do we stand with regard to that? I hope mentioning packages > need be abandoned to be cared for by the community does not imply > that's core is mostly for Intel / Nokia or other funded stakeholders > in the project? As you may have guessed, what I say is not any official word of the project - I am employed by neither Nokia nor Intel, I'm just saying how things happen elsewhere, and while we may be currently missing some policies in MeeGo regarding how packages can get from a developer into the hands of a user, I think it's not unreasonable to assume that things will work similarly to other distros. If most core packages are maintained currently by Intel or Nokia people, like I said, the path to maintainership is to help them with packaging if it's needed, perhaps offer to take over packaging an app you particularly like, or propose here the inclusion of a package not yet in Core, that you are prepared to package & maintain. This is also, as far as I can tell, the way things work in Ubuntu, Fedora, Debian, OpenSuse... Cheers, Dave. -- Email: [email protected] Jabber: [email protected] _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
