Re: Testing marathon QA Feedback
Hi, In general I think that new apps should tend to get all ratings reseted if they go back to extras-devel because of a blocker, while app updates would keep their current positive ratings through new extras-testing iterations. This way we are conservative with new apps but more liberal with updates. Makes sense? ext Ville Reijonen wrote: Hi, But the time should be better split. The basic feedback I got from busy Nokia employees with devices, professional experience and willingness to help is that the thumbs up/down should be applied to each QA criteria. Yap, this I suggested. Good that this is verified. So, it should be possible to give thumbs up for single item on the QA list. This of course means that current 10 upvotes system does not work as is. Proposal below (feel free to hack): -Every package has minimum 10 days of quarantee. -Package overstaying over a month is booted back to devel. (If it is not accepted by then, it will never be) -Package retains its history for later viewing. (Nice to see what has happened before) -Every package has QA list. (Based the current wiki list - the testing criteria) -Every item on the QA list has to be examined before acceptance. (The procedure should be the same for all) -A person can check one or multiple QA items. (Do what you are good at or what you have time for) -Same QA list item can be checked by multiple persons. (Never trust a single person, or do we? High karma - power of two) -Some QA items can be checked automatically. (optification for example) -Bugfix will reset the quarantee timer. (The quarantine was clearly working, some more is therefore needed) -Bugfix will remove the second upvote for every QA item. (Bugfix can introduce other bugs, better to be sure) -A qualified application is released to extras. Looks good overall. - If something can be checked automatically then it must be moved to the jump between extras-devel to extras-testing, where the automated tests are done. - Maybe it would be good to present user karma next to their thumbs? It would be useful to have an approximate idea of the experience put in an evaluation, or at least it could be useful when someone is trying to game the system creating a bunch of virtual users. - Maybe 3 thumbs up in each criteria is enough? I mean, if someone with high karma (read community reputation) says in the Power Management entry I have run powertop and this app is fine next to his thumbs up... most of us will give thumbs up only after checking that indeed our battery is not drained after installing the app. - If an app is dumped back to extras-devel because of a blocker in one row, the karma there should be reseted but the other rows could just stay. As said, feel free to modify. First is always rough.. :) ditto -- Quim Gil open source advocate Maemo Devices @ Nokia ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
UX meets Code hackfest in December @ Barcelona: confirmed!
Hi all, Quim just confirmed the UX hackfest in Barcelona for 4, 5, 6 december: http://talk.maemo.org/showthread.php?t=33719 What is UX hackfest? It's a three days meeting for Maemo developers, UX experts and people who want to learn about designing good user interfaces. When? On 4, 5, 6 december 2009 Where? Barcelona, Spain. The exact location has still to be confirmed, but it should be http://citilab.eu How many people invited? About 50 people invited (Maemo developers, UX experts, ecc) If you are a Maemo developer and you have good user interface designer skills, this is the place for you. If you are a Maemo developer and you are not a UX expert, this IS anyway the place for you: you'll have the possibility to talk with experts and improve your knowledge about UI design. Anyone interested, please join the discussion here: http://talk.maemo.org/showthread.php?t=33719 -- Andrea Grandi email: a.grandi [AT] gmail [DOT] com website: http://www.andreagrandi.it PGP Key: http://www.andreagrandi.it/pgp_key.asc ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder repository priority ?
2009/11/3 Graham Cobb g+...@cobb.uk.net: On Monday 02 November 2009 21:52:48 Jeremiah Foster wrote: On Nov 2, 2009, at 10:27, Ed Bartosh wrote: 2009/11/2 Jeremiah Foster jerem...@jeremiahfoster.com: On Nov 1, 2009, at 18:05, Ed Bartosh wrote: Idea of having separate queue for Extras updates sounds more promising to me. Developers might become confused with all this set of repositories, queues and processes, but the idea is good. I support this. What about this? Can we have separate queue for updates? Any other ideas? Can you explain how this might work and it's advantages? I am not against it aside from the fact that I think another repo is confusing. Is the proposal to create a repo called extras-updates which would hold only updates to software that has already existed in the repos? I don't see how that is different from just updating the existing package with new software. If you want to pull in different version numbers than what exists why would you need a separate repo? Sorry, like Jeremiah I am now a bit confused. Can you, Ed, please summarise what this proposal is? You mention separate queue but which queue are you referring to? Does the suggestion involve additional repositories? And/or does it involve differnet rules for which repositories will be in scope during a build? Or what. As I understood Attila he proposed to create separate autobulder incoming queue for Extras updates. If packages are uploaded to this queue they're built using only Extras and SDK repos and put into extras-devel. As a result they won't depend on unstable packages from Extras-devel and can go to extras-testing and then to Extras faster. As I already mentioned I'm also a bit afraid of extra complexity and possible confusion, but I think this idea at least worth to be discussed. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
2009/11/3 Graham Cobb g+...@cobb.uk.net: On Monday 02 November 2009 12:16:57 Ed Bartosh wrote: 2009/11/2 Marius Vollmer marius.voll...@nokia.com: The buildbot would need to run apt-get install maemo-optify at the right time. Any idea of how to do that? Right way to do it is to include it into SDK rootstrap. Other ways I can think of look hackish. Can't we have the hacked dpkg-buildpackage add (if optification is turned on) maemo-optify to the build dependencies? Then it will get installed automatically. We can avoid changing rootstraps if we use this. The idea looks a bit hackish, but I like it anyway. It is essential that it is in a repository (and preferably not the SDK repository -- I would like to see it in extras-devel) so that it can be updated very quickly if we need to fix bugs or change its behaviour. Particularly while Ed is on holiday! It's already there: http://repository.maemo.org/extras-devel/pool/fremantle/free/m/maemo-optify/ -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
ext Graham Cobb g+...@cobb.uk.net writes: On Monday 02 November 2009 12:16:57 Ed Bartosh wrote: 2009/11/2 Marius Vollmer marius.voll...@nokia.com: The buildbot would need to run apt-get install maemo-optify at the right time. Any idea of how to do that? Right way to do it is to include it into SDK rootstrap. Other ways I can think of look hackish. Can't we have the hacked dpkg-buildpackage add (if optification is turned on) maemo-optify to the build dependencies? No, dpkg-buildpackage does not install build dependencies, it just checks whether they are satisfied. What the buildbot could do (and maybe does), is to run apt-get upgrade at one point. This is important to get the target into a current state in general. If it does, we could just upload a newer version of build-essential into extras-devel that depends on maemo-optify. This is quite a correct way to go about this, I'd say. The mess results from the SDK repo not being identical to extras-devel (which I would call a bug in itself). To reduce the mess, we should probably first put a version of maemo-optify and the modified build-essential into the sdk repo and make a SDK release. We can then still put newer versions of maemo-optify into extras-devel. So, does the auto-builder run apt-get upgrade? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
ext Jeremiah Foster jerem...@jeremiahfoster.com writes: To beat the horse dead; foo_1.0-1maemo0 - bug fix - foo_1.0-1maemo1 = All karma retained foo_1.0-1maemo0 - feature - foo_1.1-1maemo0 = Karma set to zero Nitpick: 1.0 - 1.1 might well be a bug fix release as well. Also, I think that many packages in Extras are native and don't use a Maemo revision in their version. Or did we redefine the meaning of the part of a version after the dash? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
2009/11/3 Marius Vollmer marius.voll...@nokia.com: ext Graham Cobb g+...@cobb.uk.net writes: On Monday 02 November 2009 12:16:57 Ed Bartosh wrote: 2009/11/2 Marius Vollmer marius.voll...@nokia.com: The buildbot would need to run apt-get install maemo-optify at the right time. Any idea of how to do that? Right way to do it is to include it into SDK rootstrap. Other ways I can think of look hackish. Can't we have the hacked dpkg-buildpackage add (if optification is turned on) maemo-optify to the build dependencies? No, dpkg-buildpackage does not install build dependencies, it just checks whether they are satisfied. True. I've missed it, my bad. We can hack dpkg-checkbuilddeps to unconditionally add maemo-optify to the list of build dependencies. It will allow to have maemo-optify installed together with other build deps. What the buildbot could do (and maybe does), is to run apt-get upgrade at one point. This is important to get the target into a current state in general. If it does, we could just upload a newer version of build-essential into extras-devel that depends on maemo-optify. This is quite a correct way to go about this, I'd say. The mess results from the SDK repo not being identical to extras-devel (which I would call a bug in itself). To reduce the mess, we should probably first put a version of maemo-optify and the modified build-essential into the sdk repo and make a SDK release. We can then still put newer versions of maemo-optify into extras-devel. So, does the auto-builder run apt-get upgrade? Nope. Sbdmock does it. Sbdmock is a separate tool, which is run from autobuilder. And I really doubt that sbdmock author will accept our hacks. And I really don't like to fork it either. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
ext Ed Bartosh bart...@gmail.com writes: We can hack dpkg-checkbuilddeps to unconditionally add maemo-optify to the list of build dependencies. Ouch. That's very desperate. What about changing dpkg-buildpackage to run apt-get install maemo-optify if necessary? That concentrates the hacks in one place and is thus less magical. (This wouldn't normally work since dpkg-buildpackage is not run as root, but in Scratchbox, it does.) So, does the auto-builder run apt-get upgrade? Nope. Sbdmock does it. Sbdmock is a separate tool, which is run from autobuilder. Hmm, so is apt-get upgrade being executed at one point before calling dpkg-buildpackage? If so, that's enough; no need to change sbdmock. If not, I think it would be a good idea to do it in general, not just for Maemo. It's not really a hack to keep your build environment up-to-date, or is it? ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
2009/11/3 Marius Vollmer marius.voll...@nokia.com: ext Ed Bartosh bart...@gmail.com writes: We can hack dpkg-checkbuilddeps to unconditionally add maemo-optify to the list of build dependencies. Ouch. That's very desperate. May be. But not as desperate as calling apt-get install from dpkg-buildpackage :) What about changing dpkg-buildpackage to run apt-get install maemo-optify if necessary? That concentrates the hacks in one place and is thus less magical. What if developer doesn't have internet connection open during the build? Remember, we're going to put this into devkit, so not only autobuilder will use it. (This wouldn't normally work since dpkg-buildpackage is not run as root, but in Scratchbox, it does.) So, does the auto-builder run apt-get upgrade? Nope. Sbdmock does it. Sbdmock is a separate tool, which is run from autobuilder. Hmm, so is apt-get upgrade being executed at one point before calling dpkg-buildpackage? Yes it is. If so, that's enough; no need to change sbdmock. If not, I think it would be a good idea to do it in general, not just for Maemo. It's not really a hack to keep your build environment up-to-date, or is it? Well, from my point of view all /opt-related changes are hacks, so I don't want to even propose them to general purpose tool. It would be the same as if you would decide to send your patch for dpkg-buildpackage to Debian. -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
ext Ed Bartosh bart...@gmail.com writes: 2009/11/3 Marius Vollmer marius.voll...@nokia.com: ext Ed Bartosh bart...@gmail.com writes: We can hack dpkg-checkbuilddeps to unconditionally add maemo-optify to the list of build dependencies. Ouch. That's very desperate. May be. But not as desperate as calling apt-get install from dpkg-buildpackage :) Yeah, I have to agree, actually. Luckily, with apt-get upgrade being run during build, we don't need to change dpkg-checkbuilddeps and we can just update build-essential. (Unless I am missing something. Do I?) What about changing dpkg-buildpackage to run apt-get install maemo-optify if necessary? That concentrates the hacks in one place and is thus less magical. What if developer doesn't have internet connection open during the build? Remember, we're going to put this into devkit, so not only autobuilder will use it. Yes, good point. (This wouldn't normally work since dpkg-buildpackage is not run as root, but in Scratchbox, it does.) So, does the auto-builder run apt-get upgrade? Nope. Sbdmock does it. Sbdmock is a separate tool, which is run from autobuilder. Hmm, so is apt-get upgrade being executed at one point before calling dpkg-buildpackage? Yes it is. Cool, then that's our ticket to get maemo-optify into the build environment, I would say. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
On Tue, Nov 3, 2009 at 08:43, Marius Vollmer marius.voll...@nokia.com wrote: ext Jeremiah Foster jerem...@jeremiahfoster.com writes: To beat the horse dead; foo_1.0-1maemo0 - bug fix - foo_1.0-1maemo1 = All karma retained foo_1.0-1maemo0 - feature - foo_1.1-1maemo0 = Karma set to zero Nitpick: 1.0 - 1.1 might well be a bug fix release as well. Also, I think that many packages in Extras are native and don't use a Maemo revision in their version. Or did we redefine the meaning of the part of a version after the dash? Agreed. -maemo0 to -maemo1 is supposed to be a Maemo-specific change or a packaging change (AIUI). Native packages (such as Hermes, Attitude etc.) don't have that suffix and use a traditional x.y.z numbering scheme. Minor bug fixes increment 'z', new features increment 'y' and major milestones increment 'x'. So, according to this the packages interface would need a heuristic to detect a change in just the least significant part of the number. Something like, in Perl: my ($base, $lsb) = $oldVersion =~ /^(.*?)(\d+)$/; my $minor = $newVersion eq $base.($lsb + 1); resetPackageKarma() unless $minor; This'd handle: 2.0 - 2.1 2.0.0- 2.0.1 (but not 2.0.0 - 2.1.0) 2.0.0-maemo1 - 2.0.0-maemo2 (but not - 2.0.1-maemo1) Thoughts? Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
2009/11/3 Marius Vollmer marius.voll...@nokia.com: ext Ed Bartosh bart...@gmail.com writes: 2009/11/3 Marius Vollmer marius.voll...@nokia.com: ext Ed Bartosh bart...@gmail.com writes: We can hack dpkg-checkbuilddeps to unconditionally add maemo-optify to the list of build dependencies. Ouch. That's very desperate. May be. But not as desperate as calling apt-get install from dpkg-buildpackage :) Yeah, I have to agree, actually. Luckily, with apt-get upgrade being run during build, we don't need to change dpkg-checkbuilddeps and we can just update build-essential. (Unless I am missing something. Do I?) rootstrap is used as a build-essentials by sbdmock. The initial idea was to put maemo-optify in there, but now we're trying to avoid that. Hmm, so is apt-get upgrade being executed at one point before calling dpkg-buildpackage? Yes it is. Cool, then that's our ticket to get maemo-optify into the build environment, I would say. The only problem left is were to put 'apt-get install' :) -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder repository priority ?
On Nov 3, 2009, at 1:17, Attila Csipa wrote: A bit short on time, so could not reply to many good posts, but would not like to drop out of the discussion... This is a very important discussion I feel, you have raised some important issues and there has been some insightful feedback from people like Ed Bartosh who really know the build toolchain well. On Monday 02 November 2009 23:24:12 Jeremiah Foster wrote: Attila was asking us to solve problem with updates. And he proposed good solution. Shell we implement it right now or you propose to wait until we have Maemo distro and all this great things? No, let's try and solve his proposal now. I am open to whatever people think is best, I don't want to stand in the way of a new repository if others think it is the right path to choose. Just to clarify things a bit - the additional repo was a suggested solution to deeper problem(s) of overlapping repositories and fixed devel- testing-extras promotion path. I'd much rather have those solved at the origin (cleanly separated SDK/extras and ways to update them without one polluting the other), Yes. As I see it, this might be the core of the problem: overlapping repositories preventing package promotion. For example, if python2.5- dbus is a 'depends', you cannot build the package for Extras. Am I understanding this correctly? Can you use another dependency to get the same functionality? Can you declare in your control file that a specific version of python2.5-dbus be used? Can we change the conflict that is preventing python2.5-dbus from being used? My hunch is that there may be a way to solve this specific case with the tools we now have. If we can't we have to look at how we fix it and like Graham says we may be able to find our own path and maybe an update repository is the way to go. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder repository priority ?
On Nov 3, 2009, at 2:26, Attila Csipa wrote: 1) The fact that something builds in the pristine final SDK does not guarantee that it will go through the autobuilder (as extras-devel might contain non- backwards compatible updates to the SDK packages). So the SDK and Extras-devel need to be in synch, they need to be identical. Couldn't this be solved by having the SDK team update the SDK repos? Instead of having a new repo? 2) We seem to have an 'interesting' possibility, where, due to current repo layout and promotion policies, you can get into a situation in which you are not able to promote your own application update to Extras because of other people's development activity in Extras-devel (especially nasty if you were to make an important security fix). One solution to this might be to make Extras-devel more static by not allowing developers to ship updated libs and dependencies but instead forcing them to develop against existing libraries. When a library is outdated, the maintainer of that lib (which I suspect is often Nokia or Pymaemo for example) needs to upgrade that library. Pros: Developers know what is in Extras-devel and they can be certain that their software will build if they develop against it The repository is in a 'known state' and easier to manage for users and maemo.org Greater opportunity to create stable repositories with fewer bugs in libraries and few bugs in packages Cons: Developers can't use the version of the libraries they want, with the functionality they want Newer software takes longer to get to users There may be incentive for developers to create their own repos for shipping software At this point, I think the cons outweigh the pros, how do other people feel? Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder repository priority ?
On Nov 3, 2009, at 9:25, Ed Bartosh wrote: You mention separate queue but which queue are you referring to? Does the suggestion involve additional repositories? And/or does it involve differnet rules for which repositories will be in scope during a build? Or what. As I understood Attila he proposed to create separate autobulder incoming queue for Extras updates. Ah, a separate build queue. If packages are uploaded to this queue they're built using only Extras and SDK repos and put into extras-devel. So no extra repository needed? As a result they won't depend on unstable packages from Extras-devel and can go to extras-testing and then to Extras faster. That sounds like an elegant solution. As I already mentioned I'm also a bit afraid of extra complexity and possible confusion, but I think this idea at least worth to be discussed. I completely agree. :) Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
On Nov 3, 2009, at 12:16, Andrew Flegg wrote: On Tue, Nov 3, 2009 at 08:43, Marius Vollmer marius.voll...@nokia.com wrote: ext Jeremiah Foster jerem...@jeremiahfoster.com writes: To beat the horse dead; foo_1.0-1maemo0 - bug fix - foo_1.0-1maemo1 = All karma retained foo_1.0-1maemo0 - feature - foo_1.1-1maemo0 = Karma set to zero Nitpick: 1.0 - 1.1 might well be a bug fix release as well. Also, I think that many packages in Extras are native and don't use a Maemo revision in their version. Or did we redefine the meaning of the part of a version after the dash? Agreed. -maemo0 to -maemo1 is supposed to be a Maemo-specific change or a packaging change (AIUI). Native packages (such as Hermes, Attitude etc.) don't have that suffix and use a traditional x.y.z numbering scheme. Minor bug fixes increment 'z', new features increment 'y' and major milestones increment 'x'. So, according to this the packages interface would need a heuristic to detect a change in just the least significant part of the number. Something like, in Perl: my ($base, $lsb) = $oldVersion =~ /^(.*?)(\d+)$/; my $minor = $newVersion eq $base.($lsb + 1); resetPackageKarma() unless $minor; This'd handle: 2.0 - 2.1 2.0.0- 2.0.1 (but not 2.0.0 - 2.1.0) 2.0.0-maemo1 - 2.0.0-maemo2 (but not - 2.0.1-maemo1) Thoughts? This is what I had in mind but skipped on elaborating in an effort to keep things as clear as possible. I think this solution is excellent and perhaps we can implement it if there is consensus? Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
On Nov 3, 2009, at 12:16, Andrew Flegg wrote: Agreed. -maemo0 to -maemo1 is supposed to be a Maemo-specific change or a packaging change (AIUI). Native packages (such as Hermes, Attitude etc.) don't have that suffix and use a traditional x.y.z numbering scheme. Not necessarily. There is no official version numbering sceme for native Maemo packages. For example, some packages are using date, like 20091019. Jeremiah Foster wrote: This is what I had in mind but skipped on elaborating in an effort to keep things as clear as possible. I think this solution is excellent and perhaps we can implement it if there is consensus? It is nice to see that there is a strong push to make changes into the way karma is handled in QA. However, I suggest that you do not try to guess anything from a version number - unless you want to make a new requirement for a package as a side effect. Forcing developers to use a specific version numbering scheme would make Maemo even more different than other Linux distributions (see, for example [1]). Packages are promoted with the web interface. Simple checkbox there is enough to implement this feature. BR, Henrik [1] http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to get a transparent GtkWindow (fremantle)
I'm still banging my head against a wall with this:
why without reparenting the popup undecorated window to the main app window
it becomes transparent but the app menu doesn't work (it starts to be drawn
but immediately disappears) and viceversa?
The final version of my function is this:
void create_image_details(GtkWidget *callerobj,app_data_t *myapp) {
GdkScreen *screen;
PangoLayout *textbuff;
cairo_t *cr;
gint offset, padding, txtwidth, txtheight;
offset = 20;
padding = 10;
/* For the widget itself let's use a GtkWindow */
if ((myapp-imgparamwin != NULL) GTK_IS_WINDOW(myapp-imgparamwin))
draw_image_details(myapp-imgparamwin,NULL,myapp);
else {
myapp-imgparamwin = gtk_window_new(GTK_WINDOW_POPUP);
gtk_window_set_decorated(GTK_WINDOW (myapp-imgparamwin),FALSE);
gtk_widget_set_app_paintable(myapp-imgparamwin,TRUE);
screen = gtk_widget_get_screen(myapp-imgparamwin);
gtk_widget_set_colormap(myapp-imgparamwin,gdk_screen_get_rgba_colormap(screen));
gtk_window_set_transient_for(GTK_WINDOW
(myapp-imgparamwin),GTK_WINDOW (myapp-mainwin));
gtk_window_set_destroy_with_parent(GTK_WINDOW
(myapp-imgparamwin),TRUE);
gtk_widget_realize(myapp-imgparamwin);
/* Get the Cairo context and the overall dimensions of the text to
be displayed */
cr = gdk_cairo_create(GDK_DRAWABLE (myapp-imgparamwin-window));
textbuff = pango_cairo_create_layout(cr);
pango_layout_set_markup(textbuff,myapp-imgparam,-1);
pango_layout_get_pixel_size(textbuff,txtwidth,txtheight);
cairo_destroy(cr);
g_object_unref(textbuff);
/* Show the widget */
gtk_widget_set_size_request(myapp-imgparamwin,txtwidth +
padding,txtheight + padding);
gtk_window_set_resizable(GTK_WINDOW (myapp-imgparamwin),FALSE);
gtk_window_set_accept_focus(GTK_WINDOW (myapp-imgparamwin),FALSE);
/*
gdk_window_set_override_redirect(myapp-imgparamwin-window,TRUE);
gdk_window_reparent(myapp-imgparamwin-window,gtk_widget_get_window(GTK_WIDGET
(myapp-mainwin)),offset,offset); */
gtk_window_move(GTK_WINDOW (myapp-imgparamwin),offset,offset);
gtk_widget_show(myapp-imgparamwin);
/* Actual drawing needs to take place when the widget is exposed */
g_signal_connect_after(myapp-imgparamwin,expose-event,
G_CALLBACK (draw_image_details),myapp);
}
}
--
Luca Donaggio
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
On Tue, Nov 3, 2009 at 13:58, Henrik Hedberg henrik.hedb...@innologies.fi wrote: On Nov 3, 2009, at 12:16, Andrew Flegg wrote: Agreed. -maemo0 to -maemo1 is supposed to be a Maemo-specific change or a packaging change (AIUI). Native packages (such as Hermes, Attitude etc.) don't have that suffix and use a traditional x.y.z numbering scheme. Not necessarily. There is no official version numbering sceme for native Maemo packages. For example, some packages are using date, like 20091019. True. Packages are promoted with the web interface. Simple checkbox there is enough to implement this feature. Except how do you try to prevent abuse (whether intentional or accidental)? At least with the version number you've got some safety check (although it is in no way comprehensive). It also requires more changes at more levels (I bet), so harder to implement. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to get a transparent GtkWindow (fremantle)
On Tue, 2009-11-03 at 15:06 +0100, ext Luca Donaggio wrote: I'm still banging my head against a wall with this: why without reparenting the popup undecorated window to the main app window it becomes transparent but the app menu doesn't work (it starts to be drawn but immediately disappears) and viceversa? I think this is not the way to go. This is way too hacky and ugly. Also, the window manager has not been tested for this kind of reparenting cases (which cause unmaps and remapping of windows), and it's likely that it's buggy in handling those. Home applet windows are transparent, so clearly there is some way to do it depending on the window type. Do you have a stand-alone program showing transparent dialog (without reparenting hacks), so I could spend some time to see if it can be made to work? -Kimmo ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
On Tue, Nov 3, 2009 at 8:06 AM, Andrew Flegg and...@bleb.org wrote: On Tue, Nov 3, 2009 at 13:58, Henrik Hedberg henrik.hedb...@innologies.fi wrote: On Nov 3, 2009, at 12:16, Andrew Flegg wrote: Agreed. -maemo0 to -maemo1 is supposed to be a Maemo-specific change or a packaging change (AIUI). Native packages (such as Hermes, Attitude etc.) don't have that suffix and use a traditional x.y.z numbering scheme. Not necessarily. There is no official version numbering sceme for native Maemo packages. For example, some packages are using date, like 20091019. True. Packages are promoted with the web interface. Simple checkbox there is enough to implement this feature. Except how do you try to prevent abuse (whether intentional or accidental)? At least with the version number you've got some safety check (although it is in no way comprehensive). It also requires more changes at more levels (I bet), so harder to implement. I don't see the difference between the safety of version numbers or check boxes on the promotion page since I control both. Frank ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
On Tue, Nov 3, 2009 at 14:34, Frank Banul frank.ba...@gmail.com wrote: On Tue, Nov 3, 2009 at 8:06 AM, Andrew Flegg and...@bleb.org wrote: Except how do you try to prevent abuse (whether intentional or accidental)? At least with the version number you've got some safety check (although it is in no way comprehensive). It also requires more changes at more levels (I bet), so harder to implement. I don't see the difference between the safety of version numbers or check boxes on the promotion page since I control both. Version numbers are more visible? It's easier to lie when no-one will know about it (unless we percolate this is a minor upgrade over 0.2.2 all through the website). It's easier to check a checkbox for a semi-major release whereas version numbers are something more sacrosanct (at least to me). However, as I said, bigger reason is that it'll be easier to implement :-) Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Testing nonsense
Hi, there's another problem with the testing i am facing with gpxview: Nonsense ratings. GPXView got a thumbs down for needing lots of porting to match the maemo6 gui. Yes, harmattan! Why the heck should a fremantle program not be forwarded to extras due to the fact that it will be hard to port it to qt (which is what that guy is imho trying to say)? I am considering to entirely ignore the test process until this testing/promotion thing has actually proven to be useful. Dealing with people that just rate nonsense issues is a) a waste of time and b) frustrating. My proposals: - Add links to the apps changelogs to the package rating page - Add a small text telling the people what they are supposed to test (not harmattan gui portability!!) - Add a link to the bug tracker, so people can file appropriate bugs which can then be processed in a useful manner Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Testing nonsense
Till, I totally agree, it is not part of the testing regime itself and as long as an app is technically capable it passes the test. the checklist has been defined here: http://wiki.maemo.org/Extras-testing/QA_Checklist Maemo 5 offers stock icons covering most regular use cases, but developers can use the icons they prefer as long as they respect copyrights. Broken icons can be a major bug stopping a release to Extras *but discussions about beauty/ugliness of a UI are out of scope in the QA process*. I hope the testing interface can be adjusted to explain the purpose because I see a lot of ui/feature creep suggestion in the comments. Whilst the specific apps may not look/feel/perform exactly as we would like it is wrong to block access because of this. Use outside methods, discuss patches and changes with the developer for future versions but we need to work together to get as many stable apps into extras as possible. (Incidentally, in the specific example you cite, I think its a typo for the version) Gary On Tue, Nov 3, 2009 at 2:59 PM, Till Harbaum li...@harbaum.org wrote: Hi, there's another problem with the testing i am facing with gpxview: Nonsense ratings. GPXView got a thumbs down for needing lots of porting to match the maemo6 gui. Yes, harmattan! Why the heck should a fremantle program not be forwarded to extras due to the fact that it will be hard to port it to qt (which is what that guy is imho trying to say)? I am considering to entirely ignore the test process until this testing/promotion thing has actually proven to be useful. Dealing with people that just rate nonsense issues is a) a waste of time and b) frustrating. My proposals: - Add links to the apps changelogs to the package rating page - Add a small text telling the people what they are supposed to test (not harmattan gui portability!!) - Add a link to the bug tracker, so people can file appropriate bugs which can then be processed in a useful manner Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Testing nonsense
2009/11/3 Till Harbaum li...@harbaum.org: Hi, there's another problem with the testing i am facing with gpxview: Nonsense ratings. GPXView got a thumbs down for needing lots of porting to match the maemo6 gui. Yes, harmattan! Why the heck should a fremantle program not be forwarded to extras due to the fact that it will be hard to port it to qt (which is what that guy is imho trying to say)? I am considering to entirely ignore the test process until this testing/promotion thing has actually proven to be useful. Dealing with people that just rate nonsense issues is a) a waste of time and b) frustrating. My proposals: - Add links to the apps changelogs to the package rating page - Add a small text telling the people what they are supposed to test (not harmattan gui portability!!) - Add a link to the bug tracker, so people can file appropriate bugs which can then be processed in a useful manner Till Well he didn't say he thunbed it down because of what he said in the comment. Maybe he thumbed it down for a reason and ALSO commented that it'll be hard to adapt it to Maemo 6 later on. -- anidel Sent from London, Eng, United Kingdom ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder repository priority ?
On Sat, Oct 31, 2009 at 7:45 AM, Attila Csipa ma...@csipa.in.rs wrote: I have a small issue with the autobuilder. The whole thing started out by having a package that compiled nice in the SDK but not in the autobuilder due to a versioning mismatch (in my case python-dbus, but it's a generic problem as you'll see). After some snooping around, I realized the problem was that the SDK had 0.83.0-1maemo1 in fremantle/tools/free (and that's what got used when compiling in the SDK), however, the autobuilder insists on using 0.83.0-1maemo3 from fremantle/free (-devel). The problem is IMHO that the repository priorities seem to be wrong. The autobuilder should be using the highest version in the TOP PRIORITY repository that satisfies a dependency to avoid breakage because of unstable stuff in -devel and because otherwise a package can't be promoted without dragging other folks' packages with them. Thoughts ? I'm interested to know what problems you are having with python-dbus. Can you please fill a bug report under https://bugs.maemo.org/enter_bug.cgi?product=PyMaemo ? As you might know, Python is not officially supported on Maemo. The PyMaemo team provides most of the Python components used by Python development on Maemo. Some Python packages happen to be present on the SDK, but that does not mean that they are officially supported. They are there to satisfy dependencies for some *SDK* tools, which are not present on the N900 device. Also note that the python packages that are on the SDK were packaged by the PyMaemo team (the -1maemo1 version was packaged by myself and other PyMaemo team members, as you can see on the debian/changelog). The Maemo developers just took the packages and integrated into the SDK to satisfy the dependencies mentioned below. But the PyMaemo team is still responsible for providing upgrades and fixes for these packages through the extras-devel/extras-testing repositories, and the user applications that use packages like python-dbus, when promoted, will automatically promote the dependencies. It *seems* to be the correct way of handling the promotion for packages not under user/* sections, like all PyMaemo components. And last but not the least, the python-dbus version you are referring (-1maemo3) is not supposed to be unstable. We had no bug reports about it, so if you are having problems with it, please report a bug so we can fix it ASAP. Thanks, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Testing nonsense
Till Harbaum wrote: there's another problem with the testing i am facing with gpxview: Nonsense ratings. GPXView got a thumbs down for needing lots of porting to match the maemo6 gui. Yes, harmattan! Why the heck should a fremantle program not be forwarded to extras due to the fact that it will be hard to port it to qt (which is what that guy is imho trying to say)? I am considering to entirely ignore the test process until this testing/promotion thing has actually proven to be useful. Dealing with people that just rate nonsense issues is a) a waste of time and b) frustrating. In addition, testers - whether they rate nonsense issues or not - even get positive karma! It feels little unfair. I really would like to see a discussion about the responsibilities and ethics of a tester, and possible procedures to make sure that a tester is behaving as expected. BR, Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder repository priority ?
On Tue, Nov 3, 2009 at 11:30 AM, Anderson Lizardo anderson.liza...@openbossa.org wrote: But the PyMaemo team is still responsible for providing upgrades and fixes for these packages through the extras-devel/extras-testing repositories, and the user applications that use packages like python-dbus, when promoted, will automatically promote the dependencies. It *seems* to be the correct way of handling the promotion for packages not under user/* sections, like all PyMaemo components. That also means you MUST have at least the extras-testing repository enabled on your scratchbox targets for any Python development under Maemo, otherwise you will use very outdated versions of some Python packages, which lack important fixes. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Testing nonsense
Am Dienstag, den 03.11.2009, 15:59 +0100 schrieb Till Harbaum: - Add a link to the bug tracker, so people can file appropriate bugs which can then be processed in a useful manner Possible already - add a Bugtracker field to the control file if I remember correctly. Also see http://wiki.maemo.org/Extras-testing/QA_Checklist#Lack_of_bug_reporting_database andre -- Andre Klapper (maemo.org bugmaster) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: How to get a transparent GtkWindow (fremantle)
2009/11/3 Kimmo Hämäläinen kimmo.hamalai...@nokia.com On Tue, 2009-11-03 at 15:06 +0100, ext Luca Donaggio wrote: I'm still banging my head against a wall with this: why without reparenting the popup undecorated window to the main app window it becomes transparent but the app menu doesn't work (it starts to be drawn but immediately disappears) and viceversa? I think this is not the way to go. This is way too hacky and ugly. Also, the window manager has not been tested for this kind of reparenting cases (which cause unmaps and remapping of windows), and it's likely that it's buggy in handling those. Home applet windows are transparent, so clearly there is some way to do it depending on the window type. Do you have a stand-alone program showing transparent dialog (without reparenting hacks), so I could spend some time to see if it can be made to work? -Kimmo Hi Kimmo, my project is pretty simple, you can have a look at its sources here: [1]. The relevant code is in interface.c (create_image_details) and callbacks.c (draw_image_details). I don't think either that reparenting should be the way to go (I think I've seen it done for the first time in some example, don't remember where now), I just found that with it the app menu did work and window's transparency didn't! [1] https://garage.maemo.org/plugins/scmsvn/viewcvs.php/trunk/src/?root=mrawviewer -- Luca Donaggio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder repository priority ?
Anderson Lizardo wrote: But the PyMaemo team is still responsible for providing upgrades and fixes for these packages through the extras-devel/extras-testing repositories, and the user applications that use packages like python-dbus, when promoted, will automatically promote the dependencies. It *seems* to be the correct way of handling the promotion for packages not under user/* sections, like all PyMaemo components. Why is that? You do not feel scary that you cannot push, for example, a security fix for your components? Let's say that I am using one application (user/* package) that depends on python. For some reason it is not maintained anymore, and thus not updated. How do I get new versions of python libraries? Another thing to consider is that should _every_ application (user/* package) that depends on python be updated to just have a new version number in their dependencies when a new version of python libraries is released? (May be not, if they are working with the earlier version too, but what about those security fixes, for example.) There will be a lot of unnecessary megabytes to download just for that. For Microfeed backend (libraries and applications that are not visible to user directly) I decided to create one user/* package that depends on the latest library packages. Applications using the backend are encouraged to depend on that package. When a library, for example, is updated, there will be a new version of the user/* package that pulls the library package. How do you see that option? BR, Henrik -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Testing nonsense
2009/11/3 Till Harbaum li...@harbaum.org: there's another problem with the testing i am facing with gpxview: Nonsense ratings. GPXView got a thumbs down for needing lots of porting to match the maemo6 gui. Yes, harmattan! Why the heck should a fremantle program not be forwarded to extras due to the fact that it will be hard to port it to qt (which is what that guy is imho trying to say)? Aniello Del Sorbo wrote: Well he didn't say he thunbed it down because of what he said in the comment. Maybe he thumbed it down for a reason and ALSO commented that it'll be hard to adapt it to Maemo 6 later on. The instructions for testers [1] says: Whenever you decide to vote an application down, please leave a comment describing what issues you found. The best feedback is a bug number, since this allow to track and discuss better the problems. Voting thumbs down without any explanation doesn't help the developer getting better software for you and the end users. There is a long list of blockers (must) for packages that developers provide. Why are the instructions for testers just advices (please, not even should). I think it should read: Whenever you decide to vote an application down, you MUST leave a comment describing what issues you found. The best feedback is a bug number, since this allow to track and discuss better the problems. or even better (the commenting feature in packages interface is overlapping thing with bugs.maemo.org): Whenever you decide to vote an application down, you MUST provide a link to a bug report with severity major or higher. Actually, I read some early postings about the subject (since April). There were many good ideas (like linking into Bugzilla), but for some reason we got this separate playground. BR, Henrik [1] http://wiki.maemo.org/Extras-testing#Thumbs_Down -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Testing nonsense
I am quite unhappy with the testing, too. My package vncviewer has a blocking issue (Bugtracker field), which should be marked on the package page! http://maemo.org/packages/package_instance/view/fremantle_extras-testing_free_armel/vncviewer/0.6.3-fremantle2 Not every developer is following the dev-list all the time. To me it is not transparent, how to get into extras now. If I get ten thumb ups, because no tester checked bugtracker it gets in? Now I prepared a changed debian/control file, but if I upload to testing I loose my 9 thumb ups. It is quite complicated for a developer to test this application, as he needs a vnc server to access. Probably this is the reason, why it takes a lot of time. On the other hand it is totally to transparent, what is tested. An other problem are security issues: How do you think a tester could find a security issue in such an application? It is totaly impossible, if you do not have access to a prepared vnc server. Should we assume the vnc server to be prepared? Should we warn a user that prepared vnc servers are not tested, so only use thrusted ones, or ... I have the feeling, that the process is quite slow, without being much better than having less testers. OK, enough for now:-) Am Dienstag, den 03.11.2009, 17:32 +0200 schrieb Henrik Hedberg: Till Harbaum wrote: there's another problem with the testing i am facing with gpxview: Nonsense ratings. GPXView got a thumbs down for needing lots of porting to match the maemo6 gui. Yes, harmattan! Why the heck should a fremantle program not be forwarded to extras due to the fact that it will be hard to port it to qt (which is what that guy is imho trying to say)? I am considering to entirely ignore the test process until this testing/promotion thing has actually proven to be useful. Dealing with people that just rate nonsense issues is a) a waste of time and b) frustrating. In addition, testers - whether they rate nonsense issues or not - even get positive karma! It feels little unfair. I really would like to see a discussion about the responsibilities and ethics of a tester, and possible procedures to make sure that a tester is behaving as expected. BR, Henrik ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Testing nonsense
Am Dienstag, den 03.11.2009, 17:05 +0100 schrieb ds: An other problem are security issues: How do you think a tester could find a security issue in such an application? It is totaly impossible, if you do not have access to a prepared vnc server. Should we assume the vnc server to be prepared? Should we warn a user that prepared vnc servers are not tested, so only use thrusted ones, or ... This has been discussed here already a few days ago. See for example http://lists.maemo.org/pipermail/maemo-developers/2009-October/021861.html andre -- Andre Klapper (maemo.org bugmaster) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder repository priority ?
On Tuesday 03 November 2009 16:30:26 you wrote: I'm interested to know what problems you are having with python-dbus. Can you please fill a bug report under https://bugs.maemo.org/enter_bug.cgi?product=PyMaemo ? And last but not the least, the python-dbus version you are referring (-1maemo3) is not supposed to be unstable. We had no bug reports about it, so if you are having problems with it, please report a bug so we can fix it ASAP. No, not unstable as in buggy, there is nothing 'wrong' with python-dbus per se, it's the policies in combination with the changes that trigger the problem. You changed some paths in -1maemo3 compared to -1maemo0. That's not really a bug, but it *is* a non-backwards compatible change, as a debian/mypackage.install can fail miserably if it refers to the wrong paths. If I use the paths from -1maemo0, the autobuilder fails. If I use the paths from -1maemo3, autobuilder is OK, but I can't promote the package. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder repository priority ?
On Tuesday 03 November 2009 14:23:10 Jeremiah Foster wrote: As I understood Attila he proposed to create separate autobulder incoming queue for Extras updates. Ah, a separate build queue. If packages are uploaded to this queue they're built using only Extras and SDK repos and put into extras-devel. So no extra repository needed? Well, if we can guarantee that a trivial error causing a bad build does not wipe out the package to be updated and wreak havoc on it's dependencies + we don't need a staging repo that would serve as a base for promote (maybe after a cursory glance at a diff/changelog of powers that be ?), then a queue is just as fine. Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Testing nonsense
On Tue, 2009-11-03 at 15:59 +0100, Till Harbaum wrote: there's another problem with the testing i am facing with gpxview: Nonsense ratings. GPXView got a thumbs down for needing lots of porting to match the maemo6 gui. Yes, harmattan! Why the heck should a fremantle program not be forwarded to extras due to the fact that it will be hard to port it to qt (which is what that guy is imho trying to say)? It was a typo. I meant maemo 5. -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Promoting packages not under user/* sections, e.g. libraries (was: Re: Autobuilder repository priority ?)
On Tue, Nov 3, 2009 at 12:03 PM, Henrik Hedberg henrik.hedb...@innologies.fi wrote: Anderson Lizardo wrote: But the PyMaemo team is still responsible for providing upgrades and fixes for these packages through the extras-devel/extras-testing repositories, and the user applications that use packages like python-dbus, when promoted, will automatically promote the dependencies. It *seems* to be the correct way of handling the promotion for packages not under user/* sections, like all PyMaemo components. Why is that? You do not feel scary that you cannot push, for example, a security fix for your components? Let's say that I am using one application (user/* package) that depends on python. For some reason it is not maintained anymore, and thus not updated. How do I get new versions of python libraries? I can understand your concern regarding not getting e.g. a security fix for a Python component (or any other librart FWIW) ASAP, but let's look the other way: How can we guarantee that this new fixed package does not introduce a regression that breaks user applications in extras? I think doing QA for a library is too difficult, because there is no user interaction to test it. So the only way to do it is to test the applications that depend on it. The current approach (automatically promoting dependencies of packages that passed QA) does something like that, the problem is that it does not avoid the case where some dependency works for application A, but breaks application B, but is still promoted to extras because application A was promoted (thus breaking B). Another thing to consider is that should _every_ application (user/* package) that depends on python be updated to just have a new version number in their dependencies when a new version of python libraries is released? (May be not, if they are working with the earlier version too, but what about those security fixes, for example.) There will be a lot of unnecessary megabytes to download just for that. Certainly that's not the way. I think the package does not need to be updated just to pull the new dependency version, as long as the current version works for this package. For Microfeed backend (libraries and applications that are not visible to user directly) I decided to create one user/* package that depends on the latest library packages. Applications using the backend are encouraged to depend on that package. When a library, for example, is updated, there will be a new version of the user/* package that pulls the library package. How do you see that option? PyMaemo already has a similar meta-package (called maemo-python-device-env), but it was not meant for this purpose. I think it might work for security critical fixes or other updates that require being available on extras ASAP, but in my opinion this is just exploiting a limitation that I explained earlier (and thus might break other packages already in extras that depend on these new versions) My two cents, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Testing nonsense
On Tue, 2009-11-03 at 15:21 +, Gary Birkett wrote: I totally agree, it is not part of the testing regime itself and as long as an app is technically capable it passes the test. the checklist has been defined here: http://wiki.maemo.org/Extras-testing/QA_Checklist Assuming that you are talking about ignoring UI issues, rather than just being outraged (outraged!!) that I apparently wanted the app to be ready for Maemo _6_: I don't claim to know what the aims of the testing are. But I did see this on the main testing page: http://wiki.maemo.org/Extras-testing#The_extras-testing_QA_queue_.26_you Offering good quality community software to owners of Maemo devices is a top priority. We have a chance to show the world that open source software developed by community projects can match commercial software in terms of features, usability, reliability and fun. But we also face the risk of getting maemo.org Extras associated with beta quality software made by geeks for geeks only, without the last mile of polishing. So I've been a) assuming that an application can't be impressive if if doesn't use Maemo 5 widgets and generally follow the Maemo 5 UI layout. b) assuming that the application maintainer would like some feedback. (Note that the wiki is generally verbose, fragmented, repetitive and hard to navigate around. That's not because it's a wiki.) -- murr...@murrayc.com www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Testing nonsense
2009/11/3 Murray Cumming murr...@murrayc.com: I don't claim to know what the aims of the testing are. But I did see this on the main testing page: http://wiki.maemo.org/Extras-testing#The_extras-testing_QA_queue_.26_you Offering good quality community software to owners of Maemo devices is a top priority. We have a chance to show the world that open source software developed by community projects can match commercial software in terms of features, usability, reliability and fun. But we also face the risk of getting maemo.org Extras associated with beta quality software made by geeks for geeks only, without the last mile of polishing. I missed this point while reading it. And it convinced me to push to Extras Testing a new release of Xournal no matter if it loses the 7 thumbs up it already got (plus the 3 it got for a previous version) :( Oh well.. at least it'll be as much bug free as possible when it'll finally land Extras :) Thanks. -- anidel Sent from London, Eng, United Kingdom ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Testing nonsense
On Tue, Nov 3, 2009 at 16:56, Aniello Del Sorbo ani...@gmail.com wrote: I missed this point while reading it. And it convinced me to push to Extras Testing a new release of Xournal no matter if it loses the 7 thumbs up it already got (plus the 3 it got for a previous version) I also think that the delay for new features is a good thing now, it gives me at least 10 days whilst Hermes goes on its way to Extras of waiting and not developing until 1am in the morning :-) 10 days off: woohoo! Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Testing nonsense
On Nov 3, 2009, at 9:59 AM, Till Harbaum wrote: snip/ I'd just like to interject that any new process like this is going to have growing pains. You have two options to deal with the kinks that inevitably appear in an untried process, help to smooth them out (See the QA process = bug fixing disincentive? thread) or drop into rant- mode and succeed mostly in irritating and polarizing people while doing little to assist with improving the process. I see a lot of people picking the later method right now and find it a bit disheartening. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder repository priority ?
On Tue, Nov 3, 2009 at 12:20 PM, Attila Csipa ma...@csipa.in.rs wrote: On Tuesday 03 November 2009 16:30:26 you wrote: I'm interested to know what problems you are having with python-dbus. Can you please fill a bug report under https://bugs.maemo.org/enter_bug.cgi?product=PyMaemo ? And last but not the least, the python-dbus version you are referring (-1maemo3) is not supposed to be unstable. We had no bug reports about it, so if you are having problems with it, please report a bug so we can fix it ASAP. No, not unstable as in buggy, there is nothing 'wrong' with python-dbus per se, it's the policies in combination with the changes that trigger the problem. You changed some paths in -1maemo3 compared to -1maemo0. That's not really a bug, but it *is* a non-backwards compatible change, as a debian/mypackage.install can fail miserably if it refers to the wrong paths. If I use the paths from -1maemo0, the autobuilder fails. If I use the paths from -1maemo3, autobuilder is OK, but I can't promote the package. Can you be more specific? Which paths are those? How does this affect your package? Did you mean -1maemo1 instead of -1maemo0? (there is no maemo0 IIRC) Why can't you promote the package using -1maemo3? Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
Hello! Except how do you try to prevent abuse (whether intentional or accidental)? At least with the version number you've got some safety check (although it is in no way comprehensive). It also requires more changes at more levels (I bet), so harder to implement. I think it is time to decide (again?) if we trust developers in their atempt to get their software/package into extras or not. There are some points in the decussion about handling of extras-testing extras propagation for which we should find a simple solution for - once we have finally (for some time ;-)) decided about trust. It looks to me that currently we are randomly hopping form the trust to the as stable as possible road back and forth and have to discuss/find (implicitely) the road we are on for every sub problem again and again. We likely agree that either extreme is not good for different reasons, but we havn't a clear definition for the middle way either (it is dark out there even in the night on the highway). We defined some criteria for extras which I find astonishly lax in some parts (but since I likely will have advantages for my software because of this I will not complain ;-)) and on the other hand sometimes it looks like we are defining fort knox. Perhaps we have different definitions for the trust and stability of one package and trust and stability of the repository in whole (breaking dependencies etc...) but then lets clearify that. Breaking a package is not nice but not really a drama for the community, breaking the repository or large parts of it will be a far bigger problem. (Perhaps we should also define what we expect the average user to be able to handle. Since such assumptions have consequences, too). Again: What is our vision for extras? P.S.: Don't trust my version numbers! Trust my checkbox choice! -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Autobuilder repository priority ?
Foreword: My particular problem is not that big of an issue, in the end I went for extras-devel compatibility, no big deal, it's not yet for end users anyway. It's the generic approach that is at question here - tomorrow someone else will fall through the same manhole and it might become a recurring issue. On Tuesday 03 November 2009 18:58:04 Anderson Lizardo wrote: Did you mean -1maemo1 instead of -1maemo0? (there is no maemo0 IIRC) Yes, indeed, -1maemo1. To add to the confusion there *IS* a python2.5-0maemo0 in *extras-testing* (see http://maemo.org/packages/view/python2.5-dbus/ ) Can you be more specific? Which paths are those? How does this affect your package? Okay, I backtracked my steps as far as I could, and it *seems* the actual source of the problem is python-support (which I pull in through python-dbus). 1maemo1 (from the SDK) pulls in python-support 0.6.4 (from the SDK). 1maemo3, on the other hand, pulls in python-support 1.0.2maemo1 (from extras-devel). Depending on which python-support module got pulled in, the paths for the dbus module change: The sdk version's /var/lib/python-support/python2.5/dbus in extras-devel becomes /usr/lib/pymodules/python2.5/dbus This affects my package as I have a .install file that looks like this (inherited from upstream): debian/python2.5-qt4-dbus.install: var/lib/python-support/python2.5/dbus And since the paths change, the .so will go (or rather won't go, as the autobuilder bombs) to the wrong path. Yes, I know, I can introduce a downstream patchset and start depending on python-support myself, but that is not the point here. :) Why can't you promote the package using -1maemo3? See the path problem above. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: maemo-optify, autobuilder /opt
Dammit, why won't modest do proper quoting... Marius (I think) wrote... ext Graham Cobb g+...@cobb.uk.net writes: On Monday 02 November 2009 12:16:57 Ed Bartosh wrote: 2009/11/2 Marius Vollmer marius.voll...@nokia.com: The buildbot would need to run apt-get install maemo-optify at the right time. Any idea of how to do that? Right way to do it is to include it into SDK rootstrap. Other ways I can think of look hackish. Can't we have the hacked dpkg-buildpackage add (if optification is turned on) maemo-optify to the build dependencies? No, dpkg-buildpackage does not install build dependencies, it just checks whether they are satisfied. What the buildbot could do (and maybe does), is to run apt-get upgrade at one point. This is important to get the target into a current state I don't object to the autobuilder running apt-get upgrade but I would object very strongly if dpkg-buildpackage were to do an upgrade! Don't go messing around with my scratchbox development environment whenever i build something! I have many strange repositories in my scratchbox sources.list at various times and I NEVER, EVER do an apt-get upgrade in my development scratchbox targets! When I am developing, and particularly when I am debugging, I need to be able to control exactly which versions of various libraries are being used for that particular build including, sometimes, old versions. And I often have different targets with different library versions deliberately installed. I am not sure anyone was proposing that dpkg-buildpackage would do an upgrade but wanted to point out that it can't before anyone suggested it. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
On Tue, Nov 3, 2009 at 9:52 PM, Jeremiah Foster jerem...@jeremiahfoster.com wrote: snip And despite various complaints, many are saying that the process will in fact produce better software. So we are in the right area anyway. here here. teething troubles and getting used to a different stance. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
On Nov 3, 2009, at 20:36, Henrik Hedberg wrote: Tim Teulings wrote: Except how do you try to prevent abuse (whether intentional or accidental)? At least with the version number you've got some safety check (although it is in no way comprehensive). It also requires more changes at more levels (I bet), so harder to implement. I think it is time to decide (again?) if we trust developers in their atempt to get their software/package into extras or not. Currently, we trust ten random testers rather than one well-known developer. Please note that many of the people who have tested your app are developers, maemo staff, or longtime members of the community. They have a stake in your success since they use your application. No one needs to be rude or harsh, but the criticism they pass along is only meant to make Mauku better, it is not directed at you personally. Why could not we trust well-known developers who have track record of producing high-enough quality software? I don't think anyone does not want to trust the developers. I most adamantly have stated that we should, in fact we must, trust devs implicitly. They may have their own methods for testing, like couple of active and skilful dedicated testers for the application domain. I see that more trustful than those random testers who vote subjectively based on their opinions of an user interface. One of the lessons of any QA process is that testing and development should be separate. This leads to greater ability in finding bugs and often shortens the development cycle because developers are developing based on user requests and doing more Test Driven Design. We could have a group of accredited developers who have access to the Extras. They are committed to release only validated and verified packages. When a new developer wants to upload a package of his own, an accredited developer could sponsor him, i.e. act like a gatekeeper. But now it is you who doesn't trust people. Sounds familiar? See Debian New Maintainers Process [1]. This is unfortunately not an example I would like to follow. Becoming a debian developer takes at least a year, and many developers go MIA. Debian's founder Ian Murdoch calls debian 'process run amok'. I don't think we need to replicate that here. Furthermore, I think Nokia would loathe to participate in a program that excludes anyone who paid good money to buy a device. I see no reason to do so and I think any barrier to entry for testers, power users, users and devs is a non- starter. Another possibility is to have the team of accredited testers, who can make the final decision of their own. To become an accredited tester required commiting to write sane bug reports and to make decisions on generally agreed checks, among others. Then there would not be a need for ten random strangers and ten day delays. Again - no accreditation, no background checks, no process. Rather, we adjust the process so that trust is granted to everyone and we put up with occasional misuse. I think this is an excellent community and I trust the developers here to do the right thing. Let's not forget this is designed to be a QA process - to make software better. That is the goal. If we are not reaching that goal, we have to change, I think everyone is aware from the maemo.org side that if this isn't working, it will get fixed to the satisfaction of all. And despite various complaints, many are saying that the process will in fact produce better software. So we are in the right area anyway. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
Tim Teulings wrote: Except how do you try to prevent abuse (whether intentional or accidental)? At least with the version number you've got some safety check (although it is in no way comprehensive). It also requires more changes at more levels (I bet), so harder to implement. I think it is time to decide (again?) if we trust developers in their atempt to get their software/package into extras or not. Currently, we trust ten random testers rather than one well-known developer. Why could not we trust well-known developers who have track record of producing high-enough quality software? They may have their own methods for testing, like couple of active and skilful dedicated testers for the application domain. I see that more trustful than those random testers who vote subjectively based on their opinions of an user interface. We could have a group of accredited developers who have access to the Extras. They are committed to release only validated and verified packages. When a new developer wants to upload a package of his own, an accredited developer could sponsor him, i.e. act like a gatekeeper. Sounds familiar? See Debian New Maintainers Process [1]. Another possibility is to have the team of accredited testers, who can make the final decision of their own. To become an accredited tester required commiting to write sane bug reports and to make decisions on generally agreed checks, among others. Then there would not be a need for ten random strangers and ten day delays. BR, Henrik [1] http://www.debian.org/devel/join/newmaint.en.html -- Henrik Hedberg - http://www.henrikhedberg.net/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
On Nov 3, 2009, at 19:25, Tim Teulings wrote: P.S.: Don't trust my version numbers! Trust my checkbox choice! That is totally fine with me. I thought a version number was less intrusive, developers didn't have to do anything, just remember which part of their version to change. But as version numbers are so invariant an excellent argument against this has been presented. Shall we put a checkbox by the package promotion page, or somewhere where we remember, which keeps all accrued karma? Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: QA process = bug fixing disincentive?
Jeremiah wrote: On Nov 3, 2009, at 19:25, Tim Teulings wrote: P.S.: Don't trust my version numbers! Trust my checkbox choice! That is totally fine with me. I thought a version number was less intrusive, developers didn't have to do anything, just remember which part of their version to change. But as version numbers are so invariant an excellent argument against this has been presented. Agreed. It seemed like a nice hack, but isn't going to work in practice. Shall we put a checkbox by the package promotion page, or somewhere where we remember, which keeps all accrued karma? That's probably a good first step, however I wonder if long term something like Marius suggested might be better: remaining karma for an app is... * proportional to current app karma * proportional to developer's karma * proportional to testers' karma * inversely proportional to the time between last build and this build. This'd mean that if I released an app and had it voted up by Ryan, Tim, Daniel, Quim and a few others on the first karma page; and I released a new version the next day (short time = probable bug fix); my app might only lose one or two points. Maybe this works for time too (or vote by high roller reduces time?) Or maybe it's just too complicated? Thoughts welcome. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
