Re: [MeeGo-dev] Architecture decisions
ext Thiago Macieira writes: > Em sexta-feira, 25 de março de 2011, às 08:30:43, Arjan van de Ven escreveu: >> my concern is based on the (lack of) progress around QSparql in MeeGo. >> I'm sure it's all great in Harmattan, >> but a solid story for MeeGo has so far been lacking. Ideally QSparql >> becomes a real, full and open source member of the Qt family of APIs. >> (a solid story also includes proper moving away from older APIs) >> >> Until that's there color me a bit skeptical... it's been promised >> for a long time and hasn't really materialized very well yet. > > I don't know what's holding back its opensourcing. It already is opensource, AFAIK, with the Qt license: https://maemo.gitorious.org/maemo-af/qsparql ___ 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 Accounts&SSO, 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 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 Accounts&SSO, 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 03/27/2011 07:06 PM, John Veness wrote: > On 27/03/11 09:59, Alberto Mardegan wrote: >> Luckily, at least for Accounts&SSO, 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 27/03/11 09:59, Alberto Mardegan wrote: The biggest problem I can see with these Nokia-maintained packages (MeeGo QMF, Accounts&SSO 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 Accounts&SSO, this is going to change starting from tomorrow. :-) Interesting. What is happening tomorrow? Cheers, John ___ 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) modified QMF has is own repository: https://meego.gitorious.org/meego-middleware/messagingframework I'm creating tarball from the git repository. We could have used upstream QMF and applied a patch for the libaccounts/libsignon integration. > > 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 realm of the architecture > team obviously. > will get back on that. OK. > > 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. I submitted SR#15289 as it's the result I expect if you want to switch to upstream QMF. Cheers, Fathi ___ 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, Accounts&SSO 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 Accounts&SSO, 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
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, Accounts&SSO 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 Accounts&SSO, 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
