On Tue, Nov 30, 2010 at 14:32, Alberto Mardegan <[email protected]> wrote: > > I agree that in a perfect world, we would have a distribution maintainer > that would take care of cloning the relevant bugs to the upstream > bugtracker, but the sad truth is that we don't, and the same developer who > fixes the bug is often the same guy who is packaging the component both > for MeeGo and the Nokia internal program. It's a resourcing problem, > indeed, but still it would be good if MeeGo process would acknowledge > it and take some steps to make contributors' lives easier. :-)
I'm not sure that sacrificing the aims and openness of the MeeGo project is the way to make that easier, though. Could a "clone this issue" help? Something with Greasemonkey, or another server which can see the internal Nokia bug tracker & bugs.meego.com, which will create a stub/clone of the internal issue for audit purposes? Otherwise, I think you have to think in the external maintainer instance whereby a single issue of "upgrade libfoo to x.y.z" could encompass all manner of changes; but the 'foo' project has published a changelog, and preferably links to their public bug tracker. If anything, it sounds like Nokia's processes are the ones which need to change if they want to be a good open source participant in MeeGo - I'm not sure such a change would be accepted for any other contributor, would it? Cheers, Andrew -- Andrew Flegg -- mailto:[email protected] | http://www.bleb.org/ Maemo Community Council member _______________________________________________ MeeGo-packaging mailing list [email protected] http://lists.meego.com/listinfo/meego-packaging
