Re: [MeeGo-dev] [meego-packaging] [meego-commits] 15232 accepted: Trunk:Testing/qmf
Hi, On 03/26/2011 10:00 PM, Arjan van de Ven wrote: On 3/25/2011 2:28 PM, fathi.bou...@nokia.com wrote: I looked deeper into this QMF promotion. Until now,we (MeeGo) used a modified version that includes libaccount/libsignon integration. this was done properly as the upstream tarbal + patch, right? (if not, this is very obviously an improvement, to at least not use a contaminated tarbal) I know that MeeGo QMF has its own repository in gitorious ([0]), but then I don't know how the packaging works (adding Vitaly in CC). not using libaccount/libsignon would be in the real of the architecture team obviously. will get back on that. Hopefully you'll come back with some proposal/discussion, and not a decision? 2. Why use an older QMF upstream version? (and introduce epoch) using the latest upstream version would be totally fair game. As to the why the package went away from a contaminated frankenthing to a clean upstream one... that not only sounds like a good idea, it actually is. there were many issues with the frankenpackage, while the upstream one, which is very much better maintained, fixes lots of these. The only one I'm aware of is BMC#11361. The biggest problem I can see with these Nokia-maintained packages (MeeGo QMF, AccountsSSO and probably others) is that their development teams are mainly active on the Nokia product-driven developments, and very little time is allocated for the public MeeGo packages. Luckily, at least for AccountsSSO, this is going to change starting from tomorrow. :-) Ciao, Alberto -- http://blog.mardy.it - geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [meego-packaging] [meego-commits] 15232 accepted: Trunk:Testing/qmf
On 3/27/2011 1:59 AM, Alberto Mardegan wrote: The biggest problem I can see with these Nokia-maintained packages (MeeGo QMF, AccountsSSO and probably others) is that their development teams are mainly active on the Nokia product-driven developments, and very little time is allocated for the public MeeGo packages. which indeed, for the packages where this is true, is a huge problem. the result is that the state of some of these in MeeGo is very poor... and that leaves/left the architects no choice but to design them out. Luckily, at least for AccountsSSO, this is going to change starting from tomorrow. :-) tomorrow might be too late for several of these however. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [meego-packaging] [meego-commits] 15232 accepted: Trunk:Testing/qmf
On 03/27/2011 07:06 PM, John Veness wrote: On 27/03/11 09:59, Alberto Mardegan wrote: Luckily, at least for AccountsSSO, this is going to change starting from tomorrow. :-) Interesting. What is happening tomorrow? Since tomorrow I have some time allocated to work on meego.com. Concretely, this means that I'll take care of pushing our packages to OBS (it was done till 11th of february, then the resources allocated to this task were assigned to do something else), follow our bugzilla and make sure that all development happens in the open. In other words, trying to be good citizens. :-) Ciao, Alberto -- http://blog.mardy.it - geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [meego-packaging] [meego-commits] 15232 accepted: Trunk:Testing/qmf
On 03/27/2011 04:57 PM, Arjan van de Ven wrote: which indeed, for the packages where this is true, is a huge problem. the result is that the state of some of these in MeeGo is very poor... and that leaves/left the architects no choice but to design them out. Then I would expect to see some evidence of this in bugzilla, or some unanswered or poorly answered messages of complaint in the mailing lists. Luckily, at least for AccountsSSO, this is going to change starting from tomorrow. :-) tomorrow might be too late for several of these however. I just hope that architectural decisions are being taken according to the current state of a project and the developers' commitment on supporting it, and not according to a project's affiliation to Nokia. Ciao, Alberto -- http://blog.mardy.it - geek in un lingua international! ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [meego-packaging] [meego-commits] 15232 accepted: Trunk:Testing/qmf
On 3/27/2011 9:27 AM, Alberto Mardegan wrote: Luckily, at least for AccountsSSO, this is going to change starting from tomorrow. :-) tomorrow might be too late for several of these however. I just hope that architectural decisions are being taken according to the current state of a project and the developers' commitment on supporting it, and not according to a project's affiliation to Nokia. absolutely; the current state in MeeGo of these things is leading this. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [meego-packaging] [meego-commits] 15232 accepted: Trunk:Testing/qmf
On 3/25/2011 2:28 PM, fathi.bou...@nokia.com wrote: Moving the thread to meego-dev. I looked deeper into this QMF promotion. Until now,we (MeeGo) used a modified version that includes libaccount/libsignon integration. this was done properly as the upstream tarbal + patch, right? (if not, this is very obviously an improvement, to at least not use a contaminated tarbal) Since the SR#15232, we're using the upstream QMF version and by extension, dropped the integration. My questions: 1. Is it an architecture team decision? the architecture team normally doesn't pick versions/etc not using libaccount/libsignon would be in the real of the architecture team obviously. will get back on that. 2. Why use an older QMF upstream version? (and introduce epoch) using the latest upstream version would be totally fair game. As to the why the package went away from a contaminated frankenthing to a clean upstream one... that not only sounds like a good idea, it actually is. there were many issues with the frankenpackage, while the upstream one, which is very much better maintained, fixes lots of these. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
