Re: Repositories mess: conclusions and actions
On Thu, 2007-11-15 at 07:42, Quim Gil wrote: On Mon, 2007-11-12 at 14:05 +0200, ext Ed Bartosh wrote: I agree with that, but not 100%. We shouldn't wait for Nokia, we can start checking packages from extras-devel for upgradeability. If we manage to do that with our packages only it would help a lot to improve the whole situation with upgrades. One decision to be made (it looks like the sooner = the better) is to close direct access to extras while opening and promoting extras-devel as easy entry point. Otherwise we may risk trying to convince app developers in extras to push out their releases if they don't qualify (although specially at the beginning I would be as soft/hard as until now). I think we should wait for step 2 of Misha's plan to be done first. Without promotion interface there is no way to promote packages from extras-devel to extras. -- Best regards, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
On Nov 15, 2007 9:54 AM, Ed Bartosh [EMAIL PROTECTED] wrote: On Thu, 2007-11-15 at 07:42, Quim Gil wrote: On Mon, 2007-11-12 at 14:05 +0200, ext Ed Bartosh wrote: I agree with that, but not 100%. We shouldn't wait for Nokia, we can start checking packages from extras-devel for upgradeability. If we manage to do that with our packages only it would help a lot to improve the whole situation with upgrades. One decision to be made (it looks like the sooner = the better) is to close direct access to extras while opening and promoting extras-devel as easy entry point. Otherwise we may risk trying to convince app developers in extras to push out their releases if they don't qualify (although specially at the beginning I would be as soft/hard as until now). I think we should wait for step 2 of Misha's plan to be done first. Without promotion interface there is no way to promote packages from extras-devel to extras. -- Best regards, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers So packages already uploaded to extras-devel will stay there unless one won't upload them to extras, is it correct? Luca Donaggio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
On Thu, 2007-11-15 at 11:09, ext Luca Donaggio wrote: One decision to be made (it looks like the sooner = the better) is to close direct access to extras while opening and promoting extras-devel as easy entry point. Otherwise we may risk trying to convince app developers in extras to push out their releases if they don't qualify (although specially at the beginning I would be as soft/hard as until now). I think we should wait for step 2 of Misha's plan to be done first. Without promotion interface there is no way to promote packages from extras-devel to extras. So packages already uploaded to extras-devel will stay there unless one won't upload them to extras, is it correct? Yes, it is. -- Best regards, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
On Mon, 2007-11-12 at 14:05 +0200, ext Ed Bartosh wrote: I agree with that, but not 100%. We shouldn't wait for Nokia, we can start checking packages from extras-devel for upgradeability. If we manage to do that with our packages only it would help a lot to improve the whole situation with upgrades. One decision to be made (it looks like the sooner = the better) is to close direct access to extras while opening and promoting extras-devel as easy entry point. Otherwise we may risk trying to convince app developers in extras to push out their releases if they don't qualify (although specially at the beginning I would be as soft/hard as until now). -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
On Sun, 2007-11-11 at 22:21 +, ext Graham Cobb wrote: On Sunday 11 November 2007 15:11:51 Ed Bartosh wrote: I'd like to discuss possible usage rules of extras-devel. Here is my initial thoughts: - For packages taken from Debian/Ubuntu/whatever package maintainer in debian/control should be changed to uploader's name/e-mail I agree - Packages should be built against latest versions of libraries from correspondent SDK repository and extras-devel I don't think I agree. I am concerned about what will happen when V4.1 is issued. For Bora I currently build my packages against 3.0 so that all releases of Bora can be supported. I would expect that the same thing would happen with Chinook: packages should normally be built against the oldest libraries that will work and which do not conflict with the latest libraries. Otherwise users may experience unexpected (and partial) upgrades of base system components due to installing an application. Will Nokia test all possible combinations of partial OS upgrades when 4.1 comes out? When 4.1 is issued new packages in extras-devel will be built against it by default. If some libraries are required to be updated on the device they should be put into extras-devel and checked for upgradeability. Old packages will be left untouched if they work and will be rebuilt if they don't. I don't support your idea about oldest libraries as a strict rule. If your packages work with old libraries it's up to you to decide if it makes sence to rebuild them against new libs or not. I don't see any problems here. I'm still using old scratcbhox and mistral distro to build openssh packages because they worked on every platform so far. And I will keep doing that until possible just because it's convenient for me to have only one build of package for all platforms. But it doesn't mean that it should become a rule for extras-testing. This is a complex issue which also requires some further thought from the point of view of autobuilder requirements. - extras-devel repository should contain all dependencies for applications except of already installed on the device. It means that users only need to add extras repository to be able to install applications from it. No other repositories should be needed for that, even maemo SDK. I agree for packages which are expected to be installed by end users. However, there are packages which are designed for installation in an SDK or build environment which may depend on the SDK. For example, normally library source packages generate two packages: libfoo and libfoo-dev. libfoo is designed to be installed on the device and should only depend on other extras packages and repositories shipped by Nokia. But libfoo-dev (which is used by developers of applications which use libfoo) may depend on packages in the SDK. Note that the build environment itself has to be able to install libfoo-dev in order to build any applications which depend on libfoo. Agreed. Actually I was speaking about device packages. May be it's a good idea to add info about SDK packages here. - It should be possible to upgrade devices and scratchbox targets from extras-devel with apt-get dist-upgrade and with AM. Developers and testers should upgrade their devices from extras-devel and report possible issues to package uploader/project bug tracking system. That is a good goal but it requires that Nokia make the same commitment for their repositories: apt-get dist-upgrade should be safe. Also, until Nokia can support OS upgrades using apt-get I presume we would limit this to the same major version of the OS. I agree with that, but not 100%. We shouldn't wait for Nokia, we can start checking packages from extras-devel for upgradeability. If we manage to do that with our packages only it would help a lot to improve the whole situation with upgrades. -- Ed Bartosh [EMAIL PROTECTED] Nokia-M/Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
On Mon, 2007-11-12 at 00:03 +, ext Graham Cobb wrote: On Sunday 11 November 2007 22:32:53 Nick Phillips wrote: On 12/11/2007, at 11:21 AM, Graham Cobb wrote: I don't think I agree. I am concerned about what will happen when V4.1 is issued. For Bora I currently build my packages against 3.0 so that all releases of Bora can be supported. I would expect that the same thing would happen with Chinook: packages should normally be built against the oldest libraries that will work and which do not conflict with the latest libraries. Otherwise users may experience unexpected (and partial) upgrades of base system components due to installing an application. Will Nokia test all possible combinations of partial OS upgrades when 4.1 comes out? This is a complex issue which also requires some further thought from the point of view of autobuilder requirements. As I wrote a while ago, I'd recommend people interested in this check out Debian policy (http://www.debian.org/doc/debian-policy/) and Ubuntu's equivalent (not sure where you'd find that), and see how and why Debian and Ubuntu deal with these things. There are differences (e.g. Debian requires a binary on one arch to be uploaded, while Ubuntu allows/prefers autobuilding for all), but there should also be some issues that are pretty firmly resolved one way or the other. Checking out major distributions' policies is a good suggestion but this is one particular area where I think Maemo is likely to diverge from Debian. This is because there is a commercial company supporting the OS. Let's assume, for a moment, that Nokia introduces a V4.1 that updates both libhildon1 and libhildonfm2 to new versions. I presume Nokia would test the old versions of the libraries together, and the new versions of the libraries together but would not expend testing effort on testing the new libhildon1 with the old libhildonfm2. And assume that there is actually a bug and the old libhildonfm2 doesn't work correctly with the new libhildon1. In this case I'd suggest to put both libraries to extras-devel and tested for upgradeability together with applications. If some issues will be found bug will be failed and hopefully fixed. Fixed library will be uploaded to extras-devel and later to extras. Case solved. I understand that this wouldn't work in 100% cases. But it's better than force developers to build against old libraries. New libraries usually bring not only bugs but also useful fixes and it might be that some applications can't go to extras if they don't use new libraries. -- Ed Bartosh [EMAIL PROTECTED] Nokia-M/Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
On Monday 12 November 2007 12:40:42 Ed Bartosh wrote: In this case I'd suggest to put both libraries to extras-devel and tested for upgradeability together with applications. If some issues will be found bug will be failed and hopefully fixed. Fixed library will be uploaded to extras-devel and later to extras. Case solved. I understand that this wouldn't work in 100% cases. But it's better than force developers to build against old libraries. New libraries usually bring not only bugs but also useful fixes and it might be that some applications can't go to extras if they don't use new libraries. So, I think that what you are suggesting is that Nokia effectively Beta test the new release using extras-devel (or maybe some other repos specifically for the task) so that developers can rebuild and test that installing their applications don't cause the sort of problem I have described. That would probably be an effective compromise that would give the advantages of bringing the latest libraries into use as quickly as possible while minimising risk. I like that solution, if Nokia agrees. From a strict support point of view, of course, anyone who installs an application from extras and finds it breaks a Nokia application is on their own anyway. But it would be good to minimise the risk of such problems, particularly with applications installed from the extras repos. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
On Mon, 2007-11-12 at 13:49 +, ext Graham Cobb wrote: On Monday 12 November 2007 12:40:42 Ed Bartosh wrote: In this case I'd suggest to put both libraries to extras-devel and tested for upgradeability together with applications. If some issues will be found bug will be failed and hopefully fixed. Fixed library will be uploaded to extras-devel and later to extras. Case solved. I understand that this wouldn't work in 100% cases. But it's better than force developers to build against old libraries. New libraries usually bring not only bugs but also useful fixes and it might be that some applications can't go to extras if they don't use new libraries. So, I think that what you are suggesting is that Nokia effectively Beta test the new release using extras-devel (or maybe some other repos specifically for the task) so that developers can rebuild and test that installing their applications don't cause the sort of problem I have described. That would probably be an effective compromise that would give the advantages of bringing the latest libraries into use as quickly as possible while minimising risk. I like that solution, if Nokia agrees. Of course it would be nice if Nokia does something like that, but my suggestion wasn't about Nokia, it was about developers, who use extras-devel. I'm not speaking here as a Nokia employee, but just as member of couple of garage projects. From a strict support point of view, of course, anyone who installs an application from extras and finds it breaks a Nokia application is on their own anyway. But it would be good to minimise the risk of such problems, particularly with applications installed from the extras repos. Exactly. And extras-devel can reduce this risk if developers would use it and test packages taken from it. Some issues could be found ealier than they will go to extras and user devices. -- Ed Bartosh [EMAIL PROTECTED] Nokia-M/Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Ed Bartosh [EMAIL PROTECTED] writes: On Mon, 2007-11-12 at 00:03 +, ext Graham Cobb wrote: Let's assume, for a moment, that Nokia introduces a V4.1 that updates both libhildon1 and libhildonfm2 to new versions. I presume Nokia would test the old versions of the libraries together, and the new versions of the libraries together but would not expend testing effort on testing the new libhildon1 with the old libhildonfm2. And assume that there is actually a bug and the old libhildonfm2 doesn't work correctly with the new libhildon1. In this case I'd suggest to put both libraries to extras-devel and tested for upgradeability together with applications. If some issues will be found bug will be failed and hopefully fixed. Fixed library will be uploaded to extras-devel and later to extras. Case solved. One general (and inexpert) thought on such problems: it may not be possible to avoid all possible conflicts and breakages before they happen, but so long as such problems can be quickly fixed once they're noticed, that may be good enough. Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
On Fri, 2007-11-09 at 05:04, ext Ferenc Szekely wrote: On Nov 8, 2007 8:04 PM, Simon Pickering [EMAIL PROTECTED] wrote: Yes, so this means we definitely need extras-devel as a first step then. The extras-devel repo is created with 3 different incoming queues (gregale, bora, chinook). Uploaded a bunch of packages into chinook extras-devel yesterday and it worked just fine for me. Ferenc, thank you very much for your work ! So, step 1 of Misha's plan is done. Great! I really hope that other steps will follow. As far as the repository is ready for uploads I'd recommend developers to upload packages there. Please don't undervalue this step. It's really great that developers have repository to upload their packages to. Now we have chance to test our packages together with other's before giving them to users, which is good, I think. Of course it would work only if people use this chance, so please don't hesitate to upload your packages there. I'd like to discuss possible usage rules of extras-devel. Here is my initial thoughts: - For packages taken from Debian/Ubuntu/whatever package maintainer in debian/control should be changed to uploader's name/e-mail - Packages should be built against latest versions of libraries from correspondent SDK repository and extras-devel - extras-devel repository should contain all dependencies for applications except of already installed on the device. It means that users only need to add extras repository to be able to install applications from it. No other repositories should be needed for that, even maemo SDK. - It should be possible to upgrade devices and scratchbox targets from extras-devel with apt-get dist-upgrade and with AM. Developers and testers should upgrade their devices from extras-devel and report possible issues to package uploader/project bug tracking system. Please, comment. -- Best regards, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
On Sunday 11 November 2007 15:11:51 Ed Bartosh wrote: I'd like to discuss possible usage rules of extras-devel. Here is my initial thoughts: - For packages taken from Debian/Ubuntu/whatever package maintainer in debian/control should be changed to uploader's name/e-mail I agree - Packages should be built against latest versions of libraries from correspondent SDK repository and extras-devel I don't think I agree. I am concerned about what will happen when V4.1 is issued. For Bora I currently build my packages against 3.0 so that all releases of Bora can be supported. I would expect that the same thing would happen with Chinook: packages should normally be built against the oldest libraries that will work and which do not conflict with the latest libraries. Otherwise users may experience unexpected (and partial) upgrades of base system components due to installing an application. Will Nokia test all possible combinations of partial OS upgrades when 4.1 comes out? This is a complex issue which also requires some further thought from the point of view of autobuilder requirements. - extras-devel repository should contain all dependencies for applications except of already installed on the device. It means that users only need to add extras repository to be able to install applications from it. No other repositories should be needed for that, even maemo SDK. I agree for packages which are expected to be installed by end users. However, there are packages which are designed for installation in an SDK or build environment which may depend on the SDK. For example, normally library source packages generate two packages: libfoo and libfoo-dev. libfoo is designed to be installed on the device and should only depend on other extras packages and repositories shipped by Nokia. But libfoo-dev (which is used by developers of applications which use libfoo) may depend on packages in the SDK. Note that the build environment itself has to be able to install libfoo-dev in order to build any applications which depend on libfoo. - It should be possible to upgrade devices and scratchbox targets from extras-devel with apt-get dist-upgrade and with AM. Developers and testers should upgrade their devices from extras-devel and report possible issues to package uploader/project bug tracking system. That is a good goal but it requires that Nokia make the same commitment for their repositories: apt-get dist-upgrade should be safe. Also, until Nokia can support OS upgrades using apt-get I presume we would limit this to the same major version of the OS. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
On 12/11/2007, at 11:21 AM, Graham Cobb wrote: I don't think I agree. I am concerned about what will happen when V4.1 is issued. For Bora I currently build my packages against 3.0 so that all releases of Bora can be supported. I would expect that the same thing would happen with Chinook: packages should normally be built against the oldest libraries that will work and which do not conflict with the latest libraries. Otherwise users may experience unexpected (and partial) upgrades of base system components due to installing an application. Will Nokia test all possible combinations of partial OS upgrades when 4.1 comes out? This is a complex issue which also requires some further thought from the point of view of autobuilder requirements. As I wrote a while ago, I'd recommend people interested in this check out Debian policy (http://www.debian.org/doc/debian-policy/) and Ubuntu's equivalent (not sure where you'd find that), and see how and why Debian and Ubuntu deal with these things. There are differences (e.g. Debian requires a binary on one arch to be uploaded, while Ubuntu allows/prefers autobuilding for all), but there should also be some issues that are pretty firmly resolved one way or the other. Cheers, Nick ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
On Sunday 11 November 2007 22:32:53 Nick Phillips wrote: On 12/11/2007, at 11:21 AM, Graham Cobb wrote: I don't think I agree. I am concerned about what will happen when V4.1 is issued. For Bora I currently build my packages against 3.0 so that all releases of Bora can be supported. I would expect that the same thing would happen with Chinook: packages should normally be built against the oldest libraries that will work and which do not conflict with the latest libraries. Otherwise users may experience unexpected (and partial) upgrades of base system components due to installing an application. Will Nokia test all possible combinations of partial OS upgrades when 4.1 comes out? This is a complex issue which also requires some further thought from the point of view of autobuilder requirements. As I wrote a while ago, I'd recommend people interested in this check out Debian policy (http://www.debian.org/doc/debian-policy/) and Ubuntu's equivalent (not sure where you'd find that), and see how and why Debian and Ubuntu deal with these things. There are differences (e.g. Debian requires a binary on one arch to be uploaded, while Ubuntu allows/prefers autobuilding for all), but there should also be some issues that are pretty firmly resolved one way or the other. Checking out major distributions' policies is a good suggestion but this is one particular area where I think Maemo is likely to diverge from Debian. This is because there is a commercial company supporting the OS. Let's assume, for a moment, that Nokia introduces a V4.1 that updates both libhildon1 and libhildonfm2 to new versions. I presume Nokia would test the old versions of the libraries together, and the new versions of the libraries together but would not expend testing effort on testing the new libhildon1 with the old libhildonfm2. And assume that there is actually a bug and the old libhildonfm2 doesn't work correctly with the new libhildon1. If a user does a dist-upgrade they will get both new libraries, so no problem. However, if the user installs an application which is built against the new libhildon1 (but which doesn't use libhildonfm2) then the AppMgr will kindly install the new libhildon1 without the new libhildonfm2. Which would create a configuration never tested by Nokia and could break existing (Nokia-supplied and supported) applications which use libhildonfm2. Debian doesn't have this problem. The stable release is a single unit and doesn't get any upgrades (except security fixes, which are very limited and tested carefully). If a problem like the one I have described occurs in the testing release the affected user would log a bug or send a request to a mailing list or forum and (eventually) be told this sort of thing is a fact of life using testing: just install the latest libhildonfm2. So, we need to ask Nokia what they want to do about this case. My suggestion is that the autobuilder would always build against the oldest releases of the libraries (the oldest release with the same codename: so the oldest chinook release in my example) so that no partial upgrades would occur just from installing a package. Alternatively they may be able to make all the files in a release depend on some particular version of a pseudo-package and have that depend in turn upon all the packages which form that release, so if one package got upgraded they all would. This still has the disadvantage that installing a (possibly tiny) application could suddenly trigger a full OS upgrade when you are not expecting it. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
On 12/11/2007, at 1:03 PM, Graham Cobb wrote: If a user does a dist-upgrade they will get both new libraries, so no problem. However, if the user installs an application which is built against the new libhildon1 (but which doesn't use libhildonfm2) then the AppMgr will kindly install the new libhildon1 without the new libhildonfm2. Which would create a configuration never tested by Nokia and could break existing (Nokia-supplied and supported) applications which use libhildonfm2. Debian doesn't have this problem. The stable release is a single unit and doesn't get any upgrades (except security fixes, which are very limited and tested carefully). If a problem like the one I have described occurs in the testing release the affected user would log a bug or send a request to a mailing list or forum and (eventually) be told this sort of thing is a fact of life using testing: just install the latest libhildonfm2. Well, I believe one of the reasons Debian requires the use of the latest libraries is to minimise the number of combinations of libraries that will be out there - if you don't build with the latest libraries then there will potentially be all sorts of (untested) combinations of libraries out there being used with the latest version of $my_shiny_app. If you do, then at least you can be sure that $my_shiny_app will work. Another reason is to ensure that the latest versions of the libraries will actually get some use - if new apps aren't built with them, then they'll end up in a stable release without having been adequately tested. Backports.org does follow the system that you suggest; in this case the versions of the libraries being used are likely to be fairly static, and they're not aiming to get new versions of anything tested. So I think it comes down to how you see the release process going. If you think it will predominantly be here's a new app for the stable Maemo then autobuilders should be building against the versions in that stable release. If you think it's going to be a moving target, with Nokia releasing new bits here and there, and everyone else releasing apps to run on whatever that latest is, then you need to follow a process more similar to Debian - probably with unstable testing (where testing eventually becomes stable). It's even possible that we need a combination of both -- autobuilders for stable releases/non-current-hardware building with oldest libs, and autobuilders for latest-greatest building with latest libs. I think the biggest difference between e.g. Debian and Maemo is that some users of Maemo are going to be permanently stuck with old OS versions (on old hardware), and it's likely that app developers will still want their apps to run on them... and builds with latest libs will never percolate through to those users. So, we need to ask Nokia what they want to do about this case. Indeed :-) Cheers, Nick ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Tim Teulings [EMAIL PROTECTED] writes: I think that is the main problem. The discussion is long (and so are its single mails), but the number of participants is rather low (in relation for example to the number of accounts in garage). I getting a increasing bad feeling because I post my assumptions and suggestions, somebody else posts his assumptions an suggestions (and they are all valid and helpful) but in fact we are all searching in the dark. Community feedback is low and no technical help visible. The reason for this is that whenever other participants (me, Simon, Andrew, Graham, ...) raise the real issue - i.e. that what we really want is an autobuilder - you, and Quim, and the other high bandwidth participants in this thread, studiously ignore this point! Want more stuff in extras = set up an autobuilder. It's as simple as that. Once most people are using a single repo, package dependency problems will disappear. Within-package quality can be dealt with by the usual free software mechanisms, and others (such as rating and feedback) that have been discussed. Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
[EMAIL PROTECTED] writes: Sorry, that is not 100% correct. At least I stressed the need for an autobuilder, too. I think I made that very clear in my mails. And I think most other people were in favour of it, too. IMHO Nobody would deny the advantage. Ferenc Szekely [EMAIL PROTECTED] writes: we don't ignore it at all. please follow and commen Misha's thread about the autobuilder. in case you have a solution then please let us know. we will make sure that you can set it up for extras. I'm sorry if I was overly categorical there. I have been following the repositories mess discussion, but I haven't read every word of every post, so I certainly could have missed things. I feel that with a working auto-build system, many of the process issues that are being discussed in fine detail would simply disappear, or at least become less important; therefore it has seemed odd to me that there is so much discussion of those issues, and relatively little (till now) of auto-building. But, as you say, it looks like this is now being addressed. Over to the new auto-builder thread... Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
On Thu, 2007-11-08 at 09:09 +0100, ext Tim Teulings wrote: So far alsmost nobody really followed up with 'yes, that'd be great, [let's] do it!' message :) I think that is the main problem. The discussion is long (and so are its single mails), but the number of participants is rather low (in relation for example to the number of accounts in garage). But this is a known issue in any participative context. Let's move forward. - The creation of extras-devel is a fact. It will come soon. - The consideration of extras as default and main repository for third party software is also a fact in OS2008. - maemo RD and testing is going to include extras (and only extras) in their use cases and requirements. The the quality equation at the end is not so complicated: Nokia is going to pay more attention to the applications getting more visibility at http://maemo.org/downloads . In a perfect world all applications should have perfect quality but hey, if those at the top have gone throough proper checks and tests, then fair enough. At the end these are the ones that are going to be considered by nokia.com, marketing, customer care... If that limited set of selected applications are great and work flawlessly like a charm all the maemo platform will benefit. If they are difficult to install and get them working, if they are poorly designed, not documented, drain batteries, brick devices and so on... the whole maemo platform will suffer from the complaints and bad reports. We will do our best making sure that the apps on the top are in good condition and reflect the best maemo developers have to offer. Wee recommend you to do the best. This is something that can be applied today: just go to Downloads and rate comment up/down what rocks/sucks - providing testing details and opinions to the developers to improve their stuff. In the meantime we can continue working on the tough and technical part of developer tools and quality processes. -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Hello! different. And the main problem with 'extras' is that there're not so many applications in it. I believe it's because of a simple challenge for developers: 'extras' is expected to have good quality software (good is still to be defined :)). I saw quite a few comments (here, ITT, elsewhere) like well, I'm not 100% sure that my software is good enough to be put in 'extras', so I'd rather make my own repo. And as soon as the developer makes her first repo for offering some alpha/beta software, it's gonna be comparatively easy for her to _also_ create a repository next to the first one where the stable/good stuff is made available. As result 'extras' is underused. Correct. The initial aim defined by Quim Gil was: I would like to have for packages in extras instead in far away repositories. I want it to get easier into extras but I do not want to sacrifice quality (and quality is the point that makes it difficult). I own such repository. I'm unsure if my applications are good enough. Making the repository however is not the effort for m (making the repository was easier). My problem is maintaining builds for three OS versions (Would it be wise to drop OS 2007 after the release of OS 2008. Can I assume that everybody will flash its device?). It seems like not all people are for example running OS 2007 HE on their Nokia 770). My problem is maintaining the downloads.maemo.org packages. My problem is missing testers. The point of this plan is to explicitely make available a central place where there's no such a vague restriction as it must be good, so developers instead of learning various tools (dpkg-scanpackages, apt-ftparchive, reprepro, etc) would just learn one -- dput. 'extras' repository is coming pre-configured in Chinook and, since it's disabled by default, the normal user would need to do something to enable it. 'extras-devel' is _not_ pre-configured, so only brave souls would add it to their catalogue list. Ed argumentation (I need a repository for testing and staging together with other people/projects) is valid and I acknowledge it. However his motivation is different. As such I doubt that the first 2 steps will get you more applications into extras, you just make it easier for people that already have extras applications and want to increase their pace. This is a valid reason. I think _some_ of the problems will be solved (see above). Advantages? I do not know. So far alsmost nobody really followed up with 'yes, that'd be great, [let's] do it!' message :) I think that is the main problem. The discussion is long (and so are its single mails), but the number of participants is rather low (in relation for example to the number of accounts in garage). I getting a increasing bad feeling because I post my assumptions and suggestions, somebody else posts his assumptions an suggestions (and they are all valid and helpful) but in fact we are all searching in the dark. Community feedback is low and no technical help visible. I must assume they we by far are not talking about the real problems,we have lost the audience because of the long discussion, or that there are no real problems (form the view of the community) :-/ Scanning some #mameo logs I have seen that some people find a staging approach too complex. Me too, but how do we solve the quality problem instead? Perhaps it is time to make a poll :-) Who is the group? I'd say at the beginning we should forget about groups :) and just make it working on 'I own this package, I move it' basis. That would be OK for me :-) I think I'm able to judge which of my applications are good enough and which are not. But this way we cannot assure the quality aims that were defined by Nokia. Well, my original proposal was to make it better only after we reach a substantial checkpoint :) As said before: If the discussion does not proceed with better aproaches, just do Steps 1 and 2 instead of doing nothing. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Repositories mess: conclusions and actions
I think that is the main problem. The discussion is long (and so are its single mails), but the number of participants is rather low (in relation for example to the number of accounts in garage). Perhaps a wiki page would be the best method then. This discussion is getting rather long and confusing. From my point of view (to add yet more opinion) I'm not overly interested in an extras repo that simply contains arbitrary binaries that have been submitted by people. What I would like to see is an auto-builder to which one can submit build recipes. This has the advantages that if the original submitter gets bored with updates/run over by a bus, the instructions for how to build a package are always available so someone else can use them or update them if needs be. A similar advantage is that if someone builds XX package and decide they want it to use YY package but not ZZ, but I want/need it to use ZZ, I can take the recipe and alter it slightly to do as I want. This saves duplication of effort on my part. The problem still remains of how to check that a package actually works, part of the issue here is the .deb container itself. An autobuilder should be able to check that the .deb is consistent at least as it's the thing doing the packaging. The way I see it, testing the contents could be handled in one of two ways: 1) Put all packages in the main repo and if any get bugs filed against them move them to a -devel repo and inform the package owner that they should fix/address the issue. 2) Place all packages in a -devel repo and then allow them to be upgraded if they don't fail. This assumes that people will rate a package if it's good. I think the first method is more likely to work as people are more likely to complain than to praise (and in the case of some shared libraries they may not even know they are in use unless they fail). This may not sit happily with Nokia though as there may be non-working packages in the extras repo for some time. Cheers, Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
On Thursday 08 November 2007 08:09:09 Tim Teulings wrote: Ed argumentation (I need a repository for testing and staging together with other people/projects) is valid and I acknowledge it. However his motivation is different. As such I doubt that the first 2 steps will get you more applications into extras, you just make it easier for people that already have extras applications and want to increase their pace. This is a valid reason. I am not sure I agree. I think the staging process will increase the number of applications going into extras. I will certainly put GPE into it with the aim of moving it to extras. I would REALLY like an autobuilder -- I have spent many, many hours building and maintaining for myself an environment which can build GPE for four different Maemo releases. I can now use it for automatic nightly builds from the latest SVN and also for building releases which get tested and made available outside the project. Some of those hours (and the ones to come in the future!) could have been spent on fixing bugs instead if there was an autobuilder. I must assume they we by far are not talking about the real problems,we have lost the audience because of the long discussion, or that there are no real problems (form the view of the community) :-/ Scanning some #mameo logs I have seen that some people find a staging approach too complex. Me too, but how do we solve the quality problem instead? Perhaps it is time to make a poll :-) I don't think that the silence of the Maemo community necessarily implies that the discussion has lost the community. From other lists I see people waiting impatiently for this solution. I would take the silence to be more that the points that need to be made have been made, very well, by the existing participants, that the advantages and disadvantages have been highlighted and that we don't have strong views on how these should be reconciled. But almost anything would be an improvement on what we have today. It is disappointing that no one with experience of creating, running (or even using) a production quality autobuilder has participated. That suggest to me that we won't have that any time soon, unless Nokia feels like getting one of their Debian Developers involved. Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Sorry, On Thu, 2007-11-08 at 11:06 +0200, ext Quim Gil wrote: We will do our best making sure that the apps on the top are in good condition and reflect the best maemo developers have to offer. Wee recommend you to do the best. I mean: We recommend you to do the *same*. (I shouldn't be writing fast in mailing lists while dealing with your lovely 900 submissions to the device program...) ;) -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Repositories mess: conclusions and actions
Such Wiki Page exists: http://maemo.org/community/wiki/extrasrepositoryprocessdefinition/ I invite everybody to add, change etc... Thanks for the pointer, I'd not seen that. As told, I'm currently writing a program, to allow people to do rating of their installed applications directly from the device. I'm unsure if this will help, because people still need an account on downloads.maemo.org (I'm just faking a browser), and I fear people will stop at this point. But is nice challenge and a got test for my library code :-) I like to do a similar program for bug reports, but again you would need an account for this, too. I still think the assume it works unless people complain would be the best method, but if your rating app could also track dependencies that would eliminate one of my points against this type of approach (that libraries may get very few positive votes as people don't use them directly so don't know they are being used). Simon ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Hallo! I still think the assume it works unless people complain would be the best method, but if your rating app could also track dependencies that would I'm not against it personally, it is Nokia that stress the Quality aspect. I can understand this, since the Extras Repository is something offcial. In understand Quill in that way, there should not be unstable software in it. Of cozrse the more stability check you can to to the package and the softwar ebefore and automatically, the more you can try to just let them in and the less you need rating. eliminate one of my points against this type of approach (that libraries may get very few positive votes as people don't use them directly so don't know they are being used). You mean: I have installed CoolApp and it worked, and since CoolApp uses CoolLib, CoolLib should automatically be rated, too? I havn't planed that for an initial release. I currently show all packages that are in the group user/* (and by styleguide AFAIK that should not be a library) and where the user has not done any rating for the current version. Then I blindy try to push this rating into the (guessed from package name) project page. This could work for dependent libraries, too. But the library should be in the application catalog (I havn't seen any). Also it would be nice, if we could agree on some package header for the application page/name in the package. This way I do not need to blindly push data on some possibly non-existing web page. Another questoion (I already asked): Can/Should a user rerate an application, if there is a newer version (that would suggest different rating)? -- Gruß... Tim. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
On Nov 8, 2007 8:04 PM, Simon Pickering [EMAIL PROTECTED] wrote: Yes, so this means we definitely need extras-devel as a first step then. The extras-devel repo is created with 3 different incoming queues (gregale, bora, chinook). You need the following entries in your /etc/dput.cf config file: [extras-devel-gregale] login = your maemo.org user name method = scp hash = md5 fqdn = garage allow_unsigned_uploads = 0 incoming = /var/www/extras-devel/incoming/gregale [extras-devel-bora] login = your maemo.org user name method = scp hash = md5 fqdn = garage allow_unsigned_uploads = 0 incoming = /var/www/extras-devel/incoming/bora [extras-devel-chinook] login = your maemo.org user name method = scp hash = md5 fqdn = garage allow_unsigned_uploads = 0 incoming = /var/www/extras-devel/incoming/chinook Check if you have an entry for garage in your ~/.ssh/config file. Below is a skeleton: Host garage HostName garage.maemo.org User your maemo.org user name IdentityFile /home/user_name/.ssh/id_rsa Please also make sure that you __use the right queue__ for uploading packages. Just a reminder about our SDK naming convention: gregale is for OS2006 based development bora is for OS2007 based development chinook is for OS2008 based development I will create a new page about extras-devel in the wiki and will also update the extras page [1] at some point. (This is probably repeating what others have said): Perhaps one way to deal with this is to use an automatic rating application (or simple bug filing) for applications which are placed in the extras-devel repo. If there are no bugs filed, or the ratings are positive, then it's promoted to the main extras repo where normal people will see it and install it. If there are any negative ratings/bugs at that point it's pushed back down into the extras-devel repo. There's still the problem of getting enough people to actually rate an app (in a positive sense), or conversely to file bugs rather than just uninstalling it and moving on. The developers group is (and it is us who would presumably be the ones doing these ratings of things in the extras-devel repo) not all that large, and of that group not everyone will be interested in every app. I like the idea of the automatic app rating based on bugs. IMO it would only work if we agree that all apps use the same bug reporting system, e.g. garage tracker, or maemo bugzilla. If we let the projects to use their own favorite system then setting up automation would be very tricky. To get back onto what to do with regards to repos now. We're all reasonably trustworthy, there's no reason to think we'd produce shoddy .debs on purpose, so why not (until the auto-builder/rating apps/etc. are ready) let people upload (on an individual basis) their .debs to the extras-devel repo. If there's no complaints about a package in some time period (2 weeks for example) then it's automatically pushed into extras. I agree. The uploaders are carefully chosen. I know, since I have been doing that in 99% of the cases so far. I hope this will change now and we can really gather a group of extras maintainers who would actually administrate the repository and also grant rights for others. After all extras was created for contributions. Some of you may remember that 1st time we actually called it contrib repo :) I'm not sure how the complaints would best be handled (or how people could know where to complain about a given library). Perhaps leave it up to the authors to keep an eye on ITT/the mailing lists to see whether anything comes up? Perhaps it is a good practice to keep the maintainer's email address of the package up-to-date. The package maintainer is often not the same person as the developer, but he/she must have contact(s) to the upstream project. Anyway, I'm sure that's gone round in circles and repeated what everyone else has said :) Cheers, Si Please let me know if you have problems with the uploads to extras-devel. Misha, let's test the package promoter UI some day. If we get it work then the next step will be to create a separate garage group (e.g. extras admins or extras promoters) whose members could actually use that tool. Cheers, ferenc [1] http://maemo.org/community/application-catalog/extras_repository.html ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Am Donnerstag, 8. November 2007 22:04 schrieb Ferenc Szekely: gregale is for OS2006 based development bora is for OS2007 based development chinook is for OS2008 based development Would bora/ARM9 and chinook/ARM9 vs. bora/ARM11 chinook/ARM11 make sense? This would allow to support the OS2007HE and OS2008HE. Rainer -- Rainer Dorsch Lärchenstr. 6 D-72135 Dettenhausen 07157-734133 jabber: [EMAIL PROTECTED] GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E Full GPG key: http://pgp.mit.edu/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Hello! I'd like to share a simple 5-step plan :) It seems that the discussion again somehow stopped. The first steps of the plan seem to be quite practical, so hopefully we can start implementing something. And I'd strongly suggest we proceed with step 5 only after having implemented steps 1-4 :) Step 1: Create the repository itself Step 2: Create promotion interface Step 3: Add building facility Step 4: Making promotion interface a bit more sophisticated Step 5: Make it better? :) Wait a minute! Please rethink why we initially wanted a different behavior for the extras repository. By initiating Step 1 and 2 immediately will we have solved any of the problems we initially detected? Is there any advantage to the current extras repository and will give it some momentum to the plan? I'm not against acting with initial steps instead of discussing things to the very end, but I think this suggestion is a too quick one. The solution points to problems which were already be detected and not clearly solved (especially the discussion about who is the group and how will they decide). It also is easy to find people to decide, but we definitely need people who are willing to improve the infrastructure and do the hard work. If we do not get them now, your idea might die a step 3, too :-/ I think there was some agreement on staging repositories similar to debian together with some autobuilder mechanism. I think this is a basis that would be better for start. Isn't there a chance to get such stuff running in short time? We do have a few weeks time to set such stuff up. We do not need a solution tomorrow. OR is there a down striped solution (without staging) that would still give us some benefit? What for example if we use http://mud-builder.garage.maemo.org/index.php instead? The author has planed to use it for rebuilding upstream packages but I think using it would give use more benefit than just switch to totally manually mode (which we already have). It has not much but at least more infrastructure. Can the author of mud please give his opinion on my silly idea :-)? Or isn't there somebody who is able to set up real debian autobuilding? I think that as soon we have autobuilding, evaluating rating and bug systems for staging should be possible. The advantage is, that the information is already there. We have the rating under downloads and we could use the garage bug tracking for each application (which would mean that each application must have at least a garage project page). Please: Any volunteers (Quim can you spend some karma for this ;-)?)? And please don't misunderstand we. I'm not saying don't do this!, it just a good idea, but couldn't we do better with similar efforts?. And if we don't get some autobuilding or rating stuff set up now I'm definitely in favor of your solution. Another question: Sooner or later we need some information and/or active support from the infrastructure. For example it might be helpful to get some CSV reports (or similar) from downloads or statistics from the bug tracking system (bugs.maemo.org or garage). What can we expect? Do you have a one sentence formula about the grade of help Nokia can give in a given time frame? -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
On Wed, 2007-11-07 at 09:26 +0100, ext Tim Teulings wrote: Hello! I'd like to share a simple 5-step plan :) It seems that the discussion again somehow stopped. The first steps of the plan seem to be quite practical, so hopefully we can start implementing something. And I'd strongly suggest we proceed with step 5 only after having implemented steps 1-4 :) Step 1: Create the repository itself Step 2: Create promotion interface Step 3: Add building facility Step 4: Making promotion interface a bit more sophisticated Step 5: Make it better? :) Wait a minute! Please rethink why we initially wanted a different behavior for the extras repository. By initiating Step 1 and 2 immediately will we have solved any of the problems we initially detected? Is there any advantage to the current extras repository and will give it some momentum to the plan? Of course there is big advatage - development repository, where people can upload working but not ready to be released software to. Correct me if I'm wrong, but extras repository is considered as a repository for release quality software. It's not for developers, it's for users to install software from it. For example before releasing mplayer to extras we always had 2-3 weeks of testing it by 'beta testers' which was not so simple to archive without having repository. It's even worse for projects which have more than one package to release (pymaemo/microb/RTComm for example). Another advantage of extras-devel is that developers would be able to test their betas together with other projects's packages. I think many users remember incompatibility issues between RTComm beta and GPE. This kind of things would never happened if developers would upload their packages in one repository and test them together. Unfortunately they didn't have this oppotrunity. I'm not against acting with initial steps instead of discussing things to the very end, but I think this suggestion is a too quick one. The solution points to problems which were already be detected and not clearly solved (especially the discussion about who is the group and how will they decide). It also is easy to find people to decide, but we definitely need people who are willing to improve the infrastructure and do the hard work. If we do not get them now, your idea might die a step 3, too :-/ I think there was some agreement on staging repositories similar to debian together with some autobuilder mechanism. I think this is a basis that would be better for start. Isn't there a chance to get such stuff running in short time? We do have a few weeks time to set such stuff up. We do not need a solution tomorrow. OR is there a down striped solution (without staging) that would still give us some benefit? What for example if we use http://mud-builder.garage.maemo.org/index.php instead? The author has planed to use it for rebuilding upstream packages but I think using it would give use more benefit than just switch to totally manually mode (which we already have). It has not much but at least more infrastructure. Can the author of mud please give his opinion on my silly idea :-)? Or isn't there somebody who is able to set up real debian autobuilding? I think that as soon we have autobuilding, evaluating rating and bug systems for staging should be possible. The advantage is, that the information is already there. We have the rating under downloads and we could use the garage bug tracking for each application (which would mean that each application must have at least a garage project page). Proposed plan also includes autobuilding as a step 3. I don't think autobuiling is a trivial task and people should wait for this to be done before they can actualy use extras-devel. Please, don't misuderstand me. I'm 100% for autobuilding, just don't want to wait for it. I have about 5-10 packages for IT2008 and I badly need development repository for them to put them to and test. Even without autobuilding and voting. And it seems that I'm not alone (http://lists.maemo.org/pipermail//maemo-developers/2007-August/011202.html) -- Ed Bartosh [EMAIL PROTECTED] Nokia-M/Helsinki ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Hi Tim On Wed, Nov 07, 2007 at 09:26:47AM +0100, Tim Teulings wrote: I'd like to share a simple 5-step plan :) It seems that the discussion again somehow stopped. The first steps of the plan seem to be quite practical, so hopefully we can start implementing something. And I'd strongly suggest we proceed with step 5 only after having implemented steps 1-4 :) Step 1: Create the repository itself Step 2: Create promotion interface Step 3: Add building facility Step 4: Making promotion interface a bit more sophisticated Step 5: Make it better? :) Wait a minute! Please rethink why we initially wanted a different behavior for the extras repository. This is probably what I still do not quite grasp. There were a few discussions where people were looking at the 'extras' repository from different points of view, but I'd say those points are way too different. And the main problem with 'extras' is that there're not so many applications in it. I believe it's because of a simple challenge for developers: 'extras' is expected to have good quality software (good is still to be defined :)). I saw quite a few comments (here, ITT, elsewhere) like well, I'm not 100% sure that my software is good enough to be put in 'extras', so I'd rather make my own repo. And as soon as the developer makes her first repo for offering some alpha/beta software, it's gonna be comparatively easy for her to _also_ create a repository next to the first one where the stable/good stuff is made available. As result 'extras' is underused. The point of this plan is to explicitely make available a central place where there's no such a vague restriction as it must be good, so developers instead of learning various tools (dpkg-scanpackages, apt-ftparchive, reprepro, etc) would just learn one -- dput. 'extras' repository is coming pre-configured in Chinook and, since it's disabled by default, the normal user would need to do something to enable it. 'extras-devel' is _not_ pre-configured, so only brave souls would add it to their catalogue list. By initiating Step 1 and 2 immediately will we have solved any of the problems we initially detected? Is there any advantage to the current extras repository and will give it some momentum to the plan? I think _some_ of the problems will be solved (see above). Advantages? I do not know. So far alsmost nobody really followed up with 'yes, that'd be great, [let's] do it!' message :) I'm not against acting with initial steps instead of discussing things to the very end, but I think this suggestion is a too quick one. The solution points to problems which were already be detected and not clearly solved (especially the discussion about who is the group and how will they decide). It also is easy to find people to decide, but we definitely need people who are willing to improve the infrastructure and do the hard work. If we do not get them now, your idea might die a step 3, too :-/ Who is the group? I'd say at the beginning we should forget about groups :) and just make it working on 'I own this package, I move it' basis. As for step 3, it's actually a parallel step. So my idea (and see, it's still my idea, not our idea :)) might die at step 2 already. I think there was some agreement on staging repositories similar to debian together with some autobuilder mechanism. I think this is a basis that would be better for start. Isn't there a chance to get such stuff running in short time? We do have a few weeks time to set such stuff up. We do not need a solution tomorrow. OR is there a down striped solution (without staging) that would still give us some benefit? I do not know. What for example if we use http://mud-builder.garage.maemo.org/index.php instead? I'll need to properly check it out. And please don't misunderstand we. I'm not saying don't do this!, it just a good idea, but couldn't we do better with similar efforts?. Well, my original proposal was to make it better only after we reach a substantial checkpoint :) Cheers, -- Misha signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Hi, this sounds like a good plan. On Mon, 2007-11-05 at 19:05 +0300, ext Mikhail Sobolev wrote: Step 1: Create the repository itself We can consider this agreed already. extras-devel is a good name. Ferenc to decide timing and details. Step 2: Create promotion interface A simple web based interface would allow package owners/dedicated 'administrators' (chosen by community) to promote packages from 'extras-devel' to 'extras'. Basically the idea could be to present a list of packages that are in 'extras-devel' and are not in 'extras', then click on a few checkbox, press Promote button and voila. IMPORTANT: At this stage direct upload to 'extras' might might be limited to a selected people or removed all together. DIFFICULTY: Should not be too difficult, but it requires implementation of such a web (or other) interface. Any takers? The idea overall makes sense but we need to get into details in order to implement. We have different things: - Who are the admins and how they get admin rights. - What are the criteria admins use to promote a package to extras. - What are the tools used to do so. Please agree on a proposal and tell us where we can help. Step 3: Add building facility Also makes sense. Again, what is the specific proposal and how can we help. Once these 3 steps are completed we can discuss more, if you want. -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
On 11/6/07, Quim Gil [EMAIL PROTECTED] wrote: Hi, this sounds like a good plan. On Mon, 2007-11-05 at 19:05 +0300, ext Mikhail Sobolev wrote: Step 1: Create the repository itself We can consider this agreed already. extras-devel is a good name. Ferenc to decide timing and details. We finally got the disk space to garage, so let me just have a pieceful night and I will create the repo. IMHO the repo could be opened asap, we don't have to wait Step 2 to be completed. Right? Step 2: Create promotion interface A simple web based interface would allow package owners/dedicated 'administrators' (chosen by community) to promote packages from 'extras-devel' to 'extras'. Basically the idea could be to present a list of packages that are in 'extras-devel' and are not in 'extras', then click on a few checkbox, press Promote button and voila. IMPORTANT: At this stage direct upload to 'extras' might might be limited to a selected people or removed all together. DIFFICULTY: Should not be too difficult, but it requires implementation of such a web (or other) interface. Any takers? Good idea Misha! The idea overall makes sense but we need to get into details in order to implement. We have different things: - Who are the admins and how they get admin rights. - What are the criteria admins use to promote a package to extras. - What are the tools used to do so. Please agree on a proposal and tell us where we can help. I believe we should stick to the group or project concept of GForge. I can come up with a plugin that is only visible for that special group who are the extras admins. Only garage admins and existing extras admins could grant rights to the group, ie. they could hire new admins. Criteria of promoting apps? Good point, I have no idea atm. Tools: gforge plugin, but by using a special group these guys could have a special playground on maemo.org as well.. Later we can develop a midgard component for repo management, but that's not going to happen soon :) Step 3: Add building facility Also makes sense. Again, what is the specific proposal and how can we help. This is gonna be tough and has been on the garage agenda for years. I would love to see hardcore Debian gurus to setup a nice infra. Once these 3 steps are completed we can discuss more, if you want. Yeah, i agree. Quim Gil - http://maemo.org Br, ferenc ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Hi I'd like to share a simple 5-step plan :) It seems that the discussion again somehow stopped. The first steps of the plan seem to be quite practical, so hopefully we can start implementing something. And I'd strongly suggest we proceed with step 5 only after having implemented steps 1-4 :) NOTE: I still think that at least a few steps can be done for Chinook. -- Misha Proposal: create extras-devel repository Purpose: support developers in distribution alpha/beta/not-stable packages. Step 1: Create the repository itself Make it possible to upload the same way as it's done for extras: dput extras-devel *.changes The repository would accept source and/or binary packages and would just make them available at a predefined URL :) IMPORTANT: If somebody wants to promote packages to 'extras', these promotions are to be made manually, in other words, the same packages need to be uploaded again. DIFFICULTY: As easy as asking Ferenc to create one :) (see his mail at http://lists.maemo.org/pipermail/maemo-developers/2007-August/011202.html) Step 2: Create promotion interface A simple web based interface would allow package owners/dedicated 'administrators' (chosen by community) to promote packages from 'extras-devel' to 'extras'. Basically the idea could be to present a list of packages that are in 'extras-devel' and are not in 'extras', then click on a few checkbox, press Promote button and voila. IMPORTANT: At this stage direct upload to 'extras' might might be limited to a selected people or removed all together. DIFFICULTY: Should not be too difficult, but it requires implementation of such a web (or other) interface. Any takers? Step 3: Add building facility Developers now can just upload source packages that are going to be built against the corresponding Maemo SDK and the content of 'extras-devel'/'extras'. The resulting binary packages will be installed to 'extras-devel'. DIFFICULTY: Unknown. Either adopting something already available elsewhere (mud, Debian) or adopting internal Nokia stuff (may take some time). Step 4: Making promotion interface a bit more sophisticated Make promotion interface a bit more automatic. Perform various QA checks and use the results as input for manual/automatic promotion. DIFFICULTY: unknown. Promotion criteria and QA stuff should be agreed. Step 5: Make it better? :) DIFFICULTY: easy -- it's always possible to make things better (better is the enemy of good :)) signature.asc Description: Digital signature ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Hello! * We must find some clever way to get a response from the user since we cannot trust the masses (our masses are not of equal size then that of debian). * For example: What about the program manager on the device periodically requests a rating from you for newly installed applications. There will of course be a way to switch it off, and the the notification must not violently jump into the middle of the screen swinging its broadsword, disturbing my circles. We might discuss about this feature in the Application Manager. However, if you find this idea useful it would be faster and probably better to start with an installable 3rd party application covering this functionality and targeted to maemo power users. I checked again. It seems like libcurl can do the fake HTTP requests to at ratings to the application catalog. I already have code for browsing package lists. So I should be able to: * Show list of packages (in user-section) that were not rated or where there was a rating for an earlier version (can I re-rate applications if the version changed? Should be possible IMHO = Karma!?). * Request rating (0-5 stars plus free form text). * Initiate upload of rating(s) using curl and fake HTTP form POSTs. But: * There will be no periodic notifications because that would mean to always run in the background... or is there a way to do power-safe-aware cron jobs!? * User still has to have an account and must type in password. * I possibly has to guess the downloads.maemo.org application name from the package name. Here we should definitely try to define a header in the deb file! I also would like to have a bug tracking functionality as part of the applications, since I have a few users that have problems with the package installation. I could let the user choose the package and then collect information about package version, version of dependencies, device model and OS version. I could even look for a .desktop file, start the binary and collect console output. And if the rating fake works one could even make a bugzilla ticket from it... However in this case we likely needs some help from deb headers, too. = I'll do it! Give me some time... -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Hello! * We must find some clever way to get a response from the user since we cannot trust the masses (our masses are not of equal size then that of debian). * For example: What about the program manager on the device periodically requests a rating from you for newly installed applications. There will of course be a way to switch it off, and the the notification must not violently jump into the middle of the screen swinging its broadsword, disturbing my circles. We might discuss about this feature in the Application Manager. However, if you find this idea useful it would be faster and probably better to start with an installable 3rd party application covering this functionality and targeted to maemo power users. I checked this. And in fact using libapt-pkg (no header files in chinnok beta?) it is easy to get the list of installed packages in user sections. Using some application internal configuration file it should be possible to locally track rated and unrated packages (and even packages where one has rated an earlier version). One questions however persists: If I now have a local configuration file containing new, undelivered ratings, how do I get them into the application catalog? Must I really track available/unavailable network connection, popup a dialog (or not) and then fake HTML package changes by sending successive HTML/SSL requests to the application catalog? Isn't/shouldn't there be a simpler solution? I'm willing to develop a GUI for the rating collection task but I happily delegate the upload to somebody else that has knowledge in writing such system service. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Hello! Speaking about decisions. Someone wants to summarize the discussion in a I did that: http://maemo.org/community/wiki/extrasrepositoryprocessdefinition wiki page and call for review? I'd suggest separating the principles from the implementations, since we seem to agree already in the first ones. Stamping a deal on the principles should make easier the agreement on the implementations. I tried to go through the mails in this thread and collect all relevant comments hints. If somebody misses his ideas, simply add them. Please comment, discuss, tear in in two, edit, delete and enhance. At the same time write a comment to this thread :-) Please try to keep your changes withing the existing structure or improve it ;-) -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
On 24/10/2007, Quim Gil [EMAIL PROTECTED] wrote: - Community governance on extras We think the equation would work much better if the maemo community would have control over the extras repository, filtering what has enough quality to be there and what not. Who and how, we are totally open about this. We consider the Quality Awareness documentation as a reference top define quality. We don't want to give away the control of the repository but we are happy discussing and agreeing with you the rules of a common game. These rules would include other topics discussed in the past, like i.e. the sections. How/who decides what shared libraries and applications get into extras? Voting and popularity has been talked about but what if there is a conflict in a shared library and someone needs to make a call. We need community members to check packages that are propsed for extras, help agree on shared packaged etc. Would something like Ubuntu's membership work? Basically something like you demonstrate some involvement with the community and agree to abide by it's rules before you can join, people can vote to kick you out if there's a problem. http://www.ubuntu.com/community/conduct ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Hi, please find my (very biased) comment below. On Mon, 2007-10-29 at 07:42 +0200, ext Quim Gil wrote: Hi, On Sat, 2007-10-27 at 22:41 +0200, ext Tim Teulings wrote: Hmm, you never would get my applications ;-) I'm pretty sure that I won't fulfill all the requirements. Maybe then rephrasing the sentence? This is not an official certification process, it is just a tool to get developers aware about the level of quality expected in extras. But. For example being good at battery time is a tricky thing to test If this is true then we need to provide better documentation and tools to test/debug. At least the big issues should be not difficult to detect (you app is draining the battery in 24h even if running just in the background). I guess any developer can get some help by getting the packages in extras-testing and expressing the will to push them to extras. If a developer is not concerned at all about power management and hasn't got a clue about how his app is treating the battery, then his software shouldn't get so fast in extras. Indeed. We have got already real cases of a popular app getting all kinds of positive comments in one side, and then 'this battery sucks'-like threads here and there. Until someone is able to connect one app A with battery problems B. Developer A is then aware, gets feedback and implement fixes. Doing this before hitting extras instead of after makes a whole difference. I'd like to distinguish between 3 major areas: -kernel this _is_ painful as everybody here can testify, but we ship a SoC, therefore there is only this much of drivers to be developed and there is already a very active OMAP community, so I wouldn't consider maemo as the best place where to discuss OMAP related issues. There is also a linux-pm mailing list for generic power management related discussions. Also the cpufreq ml is a good place where to follow power-related discussions, although we are not very active there. -userspace - infrastructure with this i refer to all the stuff that provides the ecosystem to applications (and probably it is the core of what maemo is at the moment): we are talking about sw that is supposed to run (almost) all the time and can significantly affect the performance of the device. At the moment this sw is only about the ARM core in omap, so the usual 2 rules strictly apply: * make your code have low average CPU usage * try to hit 0% CPU usage as often as you can To elaborate it a bit, it's much better to have high activity bursts than spread the activity over longer time (yes, this seems to clash against our DVFS implementation, but it's better to let the system spread the load, than trying to be smart in every single application). What i have described above is indirect power management through CPU load profiling and is simpler to accomplish (no need to instrument your device with a current meter) and Eero has already provided on these lists eccelent examples of how to monitor the CPU activity. -userspace - applications this case is probably both the more common and at the same time the simpler, if we assume that the application will run for a limited amount of time, possibly as main application on the screen and should be easily associated to the battery running flat. The same techniques described at the previous point are effective in this case as well. I think that having developers clearly stating to which class their code belongs to would significantly improve the perception that the user has of the sw he is installing. I don't want to single out Canola, but it is just the first example that comes to my mind of something that is perceived as plain application, while it also has infrastructure components. To conclude, it shouldn't be too difficult to get power management working, as long as we are talking of developing applications. Unfortunately it is not perceived as a _required_ aspect of a quality application. As much as having a usable UI. OMAP3 will make the requirement even stronger; this is the right time to start changing mindset about power management. Doing CPU profiling is a good step down that road. -- Cheers, Igor Igor Stoppa [EMAIL PROTECTED] (Nokia Multimedia - CP - OSSO / Helsinki, Finland) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Hi, ext Steve Greenland wrote: According to Tim Teulings [EMAIL PROTECTED]: The first one - the one that I think you mean (and that I think is important and must be agreed on to initiate the process) - is the guide that defines the process. Of course an important part of the process is for example packaging. You a right in that we can copy most of such guides from debian. However it is likely that we have to modify this. For example we may need some additional headers for the in parallel discussed bug tracking client application. So here we agree :-) You know that Debian already has a mechanism to support this? Each package can have an Origin: field, and reportbug will lookup the appropriate BTS in /etc/dpkg/origins/*. Unfortunately, my google-fu is inadequate to find the documentation for this...or maybe it doesn't exist. I found this: http://www.hadrons.org/~guillem/debian/docs/origin.proposal - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
According to Quim Gil [EMAIL PROTECTED]: On Sat, 2007-10-27 at 23:13 +0200, ext Murray Cumming wrote: Requiring any quality control before having a place to put the alpha/beta-quality stuff will just stop us from getting much software. Software needs to be released in order to increase its quality. Indeed, see my original proposal at http://lists.maemo.org/pipermail//maemo-developers/2007-October/012192.html where I suggest an unfiltered extras-testing together with the filtered extras. Nitpick: please call it extras-unstable (or -experimental), not extras-testing. Why? Because the Debian testing repository has packages that have already passed some basic quality control. In particular, it is extremely rare to get anything into Debian testing that causes problems with the OS or any other application. Sure, not everybody is going to have that background, but some of us will, and the very different meaning of the testing moniker will be confusing. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
According to Tim Teulings [EMAIL PROTECTED]: The first one - the one that I think you mean (and that I think is important and must be agreed on to initiate the process) - is the guide that defines the process. Of course an important part of the process is for example packaging. You a right in that we can copy most of such guides from debian. However it is likely that we have to modify this. For example we may need some additional headers for the in parallel discussed bug tracking client application. So here we agree :-) You know that Debian already has a mechanism to support this? Each package can have an Origin: field, and reportbug will lookup the appropriate BTS in /etc/dpkg/origins/*. Unfortunately, my google-fu is inadequate to find the documentation for this...or maybe it doesn't exist. Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
On Mon, 2007-10-29 at 19:13 +, ext Steve Greenland wrote: Nitpick: please call it extras-unstable (or -experimental), not extras-testing. We are as ok with extras-unstable as we probably would be ok with any sensible proposal the maemo community comes up to. Your decision. Speaking about decisions. Someone wants to summarize the discussion in a wiki page and call for review? I'd suggest separating the principles from the implementations, since we seem to agree already in the first ones. Stamping a deal on the principles should make easier the agreement on the implementations. -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Repositories mess: conclusions and actions
On Sat, 2007-10-27 at 23:13 +0200, ext Murray Cumming wrote: Requiring any quality control before having a place to put the alpha/beta-quality stuff will just stop us from getting much software. Software needs to be released in order to increase its quality. Indeed, see my original proposal at http://lists.maemo.org/pipermail//maemo-developers/2007-October/012192.html where I suggest an unfiltered extras-testing together with the filtered extras. This would allow us to promote extras to pure end users shamelessly, leaving extras-testing (as explicit as this name can be) to power users and others going there at their own risk. -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Hi, On Sat, 2007-10-27 at 22:41 +0200, ext Tim Teulings wrote: Hmm, you never would get my applications ;-) I'm pretty sure that I won't fulfill all the requirements. Maybe then rephrasing the sentence? This is not an official certification process, it is just a tool to get developers aware about the level of quality expected in extras. But. For example being good at battery time is a tricky thing to test If this is true then we need to provide better documentation and tools to test/debug. At least the big issues should be not difficult to detect (you app is draining the battery in 24h even if running just in the background). I guess any developer can get some help by getting the packages in extras-testing and expressing the will to push them to extras. If a developer is not concerned at all about power management and hasn't got a clue about how his app is treating the battery, then his software shouldn't get so fast in extras. Indeed. We have got already real cases of a popular app getting all kinds of positive comments in one side, and then 'this battery sucks'-like threads here and there. Until someone is able to connect one app A with battery problems B. Developer A is then aware, gets feedback and implement fixes. Doing this before hitting extras instead of after makes a whole difference. We would have some kind of (hopefully small) checklist that precisely tells the potential application user what he can expect and what risks he will take. All this sounds to testing quality and power user audience. Why don't put a little more effort in extras to have decent quality (not perfect, nobody is perfect), targeting all the tablet owners. If an app kills a device (and the developer knows that) that there is possibly already some criminal minimal mind behind - and then the checkbox would not help either. Killing a device is a extreme case with a computable end result. Asking for good quality is different because both good and quality are very subjective terms. Quality Awareness just tries to define what are the quality levels expected in stable software for maemo. OK, but to what benefit? To sue the developer ;-)? What is the real effect of such a checkbox (see above)? Whoever is in charge of extras can push out to extras-testing a package based in a checklist the developer is supposed to know and has acknowledged. We can avoid the checkbox by having Quality Awareness and whatever else we decide (i.e. maemo packaging policy) as guidelines anyway as a reference, filing critical bugs against apps compromising the system and putting those critical bugs as obstacle that won't let you get to extras. As you see I'm only trying to make clear the principle, once the principles are clear we can discuss better the implementations. I'm not involved in debian internals (I'm only an interested user), but it looks like most of the time the human side is not that involved, Perhaps, but I guess in part becuse a lot of 'human side' is put when filtering who gets the rights of a Debian maintainer. Maybe I'm wrong, but if we set lower filters for access then perhaps we need more human reviewing and decisions. Where do you see requirements for human interaction? Not sure. I only know that people will ask/rely on us Nokia if they don't find anybody behind extras. If extras will be ruled by the community people will expect community people there. As said, ultimately someone will need to have the right to say 'you get in / you go out'. Perhaps this someone can be a community message in the form of good/bad feedback and filed/fixed bugs and perhaps this in/out can be automated. But anyway, not that relevant at this point. We have still principles and implementations to discuss. -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Hello! * Since Nokia holds most of the infrastructure I fear Nokia has the burden to supply the technical infrastructure while the community will support the daily work, the rating and the quality assurance. Fear? If this doesn't sound like a fair exchange then please suggest fair proposals. Er, I think you misunderstood him: he used that word (fear) projecting it to Nokia, not to himself... Something like I fear it will be Nokia to have the heavy burden of maintaining the technical infrastracture; instead the community will Does it sounds good? Or maybe it's me misunderstanding him :) Correct. There was no criticism (especially towards Nokia) in my words. It it just that for a join aproach between Nokia and the community one would expect that both parties would do nearly the same amount of work. Regarding infrastructure this will likely not work. Since Nokia will (likely) host the infrastructure they have to do most of the work. So I said: Sorry Nokia, it seems like you will have to do more work than we. On the other hand it is likely that the every-day job may require more efforts for the community. If both sides can live with that, thats OK. -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
I'm sorry, this is a long one, but I've done my best to be as clear as possible in order to avoid readers having to go on website and study a new system just to follow what I wanted to say, if the same concepts were written with few words as I could have done ;) So, please go with this last effort, I'll never bother you again with Zero Install advocacy after this one ;D If someone can see the benefits, I gladly transfer this task to him/her. If there's no follow, maybe my worries are not a problem for anyone, so that's ok for me. Now: I'd like to underline another important benefit for tablets which has not been mentioned: No waste of storage (or we can call it optimized usage of limited storage). I think it's not necessary to say (but I'll say it to be sure!) this is especially useful on tablets because of their limited amount of storage space (no matter how big your card is, it will soon become too much small ;) The current system can't provide simple and no-effort-from-user ways to put on storage just what *I* want of an application, so the developer/packager makes some guess and in a few questions install I'll find on my tablet lots of files that will never be accessed. Never. Well, saying I'll find them really is a little optimistic with the current approach, or at least it will require some poweruser skills, and some waste of time - not to say the danger! - to erase them manually (with Midnight Commander just to speedup the work a bit ;) of course praying everything will work anyway, whatever function of the app I'll use in future. Zero Install solves this problem, allowing to execute storage conservative (or network intensive, which is not a problem for an Internet Tablet device - and I'm speaking from south of Italy, were wifi hotspots are a rarity on the go, but that's our fault) zero-installations: this means that if I zero launch an application for the first time, the system downloads just the stuff required to execute it, filling only the minimal space on the card; when I try to use a component of that application which has not yet been downloaded, the system transparently downloads it and its dependencies (only those not already in), and the next time I'll use that with no wait for download. E.g. if I don't want to install my locale files for the app because I like to use it in English, Zero Install fits this need allowing me to change my idea whenever I want, simply downloading them the first time I need to change the language from my app. Same thing for docs. So, summying up: * current approach is to put on storage what maybe I and other users will probably need, which often is very close to everything - too bad! * Zero install approach allows user to emulate the current approach, but it also allows to put on storage only what I (and not other users) do really need, flawlessly managing the lack of stuff in case it seems I need it. From a user point of view, installing means download + press ok + wait a moment + go. It looks like the user experience wouldn't change, and in any case isn't bad at the moment (if the app works and the dependencies are satisfied etc). It's true, but your sentence in parenthesis makes a big difference from a problem and a no problem scenario. What if the app does not work, or dependencies are not satisfied, or - especially - etc. ? :) An example of bad user experience due to current system is the impossibility for me to update my Python runtime (2.5 - 0.4-8), if I not reflash the device (which I won't do by now, because the restore process is not the quick one which would be possible with Zero Install ;) The Python for Maemo I think we'll agree is not an example of a bad mantained project, probably there are no problems at all from their side, but still problems arise for some reason, or for some other app's fault. The project maintainer, L. M. Wolf (who seems a talented one), kindly analyzed some reports from me and another user crying for my same problem, but his best help for us was: Everything seems ok with repositories. I think the problem is some installed application that requires an exact version of python (e.g.: 2.5.0). And this may be blocking the update process. The error message shown when you try to update python2.5-runtime doesn't mention anything about this? I did some tests, installing an old python2.5 version and doing the update. No problems at all. Luciano I think this message underlines well some of the problems I'm trying to address. Of course the reply to his answer was no and so I continued using the old Python runtime. Probably L. M. Wolf with my tablet in his hands could solve the problem without refalshing, but I have no clue and I suspect the average user would be in no better position. As explained by N. Hoglund in point 2. of his last message, Zero Install could easily overcome this issue, because one of
Re: Repositories mess: conclusions and actions
Errata: [...] Of course the reply to his question (The error message shown when you try to update python2.5-runtime doesn't mention anything about this?) was no and so I continued using the old Python runtime. [...] [...] Of course the reply to his answer was no and so I continued using the old Python runtime. [...] -- Antonio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Hello! - Nokia: We want to centralize the development to just make things easier, simpler and add service - without compromising the open source idea. (Simplicity, centric) Centralization doesn't compete with 'the open source idea'. We are I did meant that (it was meant exactly they way you define it, too). Centralisation can mean control (upto totalitraianism). In the context Nokia IMHO explicitly stated that they want control for good and want to take control together with the community. proposing it not because we are Nokia but because we are running maemo on top of GNU/Linux and .deb packages. Just look at how your preferred open source software distribution is organized, it is almost a paradox that most if not all of them are in fact more centralized than maemo. Right. It sound easier to take part at the extras process than to get a debian developer ;-) For small communities it is important to be open. - Nokia: We want to multiply by delegating task to the community (Scalability) Delegating is not accurate enough. We want to empower the community to push and promote the software they think is good enough for that. OK. * Definition of the meaning quality in a community that consists of Nokia and the open source community. The Quality Awareness document is open to improvements and contributions. We don't want/need to have different docs to define measure quality, so whatever idea you have please check it against the current doc and suggest improvements to it. The question is not the quality of the Quality awareness document which likely could be improved. The question is, if such a document is the right way to control quality? How would we guarantee the quality defined by this document? This can only be done by manual test (at least definitely if we would further improve the document ;-)). The test have to be done by the developer first. However since you cannot (always) trust the developer, somebody has to test the application again. So what we then would need, is a in-queue with new packages and every package has to be manually testes. This would assure quality on a very high level, but likely would not scale (and possibly would not work with a small community). Note that debian FTP master as far as I know only check license stuff and similar - they do not check the application itself (and they are sometimes still slow (for whatever reasons)). This kind of quality assurance is the classic way for companies. I doubt this is the right way to go. The Linux community distributions handle quality differently. They use same small initial checks and then a staged repository. Debian still has a policy and style guides and similar and tries to do automatic checks that guarantee compliance with these guides. However most the actual crashes bugs are notices after the software initially entered the repository. In this case a guide is still good (and you always get your bugs fixes if it violates the guide ;-)) but quality get a much more diffuse meaning. I'm sure that debian has a number of applications, that don't fulfill all the requirement in the guide. In the case we do not need a guide first, but the process will come first and then the guide will develop. The problem is: How to assure that still no important bug (that for example kills my device) gets through. In this case I would still suggest using the three holy kings (bug tracking, staged repository, application catalog) but at this point would not concentrate on the holy guide but on the holy process. For a small community with with high quality requirements (and debian has also high requirements for their community is bigger, so they have a very high trust that no bug get trough the process) I would still suggest: * A packages does not get into the stable repository if its bugs are over the limit (and debian has a precise definition for limit :-)). * A packages does not get into the stable extras repository if there are not at least X successful installation and behavior reports. * A package needs some average ranking to enter the stable repository. * We must find some clever way to get a response from the user since we cannot trust the masses (our masses are not of equal size then that of debian). * For example: What about the program manager on the device periodically requests a rating from you for newly installed applications. There will of course be a way to switch it off, and the the notification must not violently jump into the middle of the screen swinging its broadsword, disturbing my circles. * Also it might be very effective to collect and submit regular crash reports from the device to the application catalog (of course delivery must again be optional and not the microsoft way). * Also we need a very easy way to get bug reports (and feature requests) directly from the device into the bug tracking system. This all requires some very fine, polity and
RE: Repositories mess: conclusions and actions
Alright, so we seem to agree in the general concepts. Let's go into details. The question is not the quality of the Quality awareness document which likely could be improved. The question is, if such a document is the right way to control quality? Alright, what about leaving the role of this document in a checkbox developers check in order to get upload rights to extras, à la terms conditions. Something like I'm aware of the maemo Quality Awareness criteria and I have tested my applications against them before uploading them to extras. Of course developers might check the box after having gone through the 100%, 50% or 0% of cases and his software might or might not contain major bugs, but at least nobody can say - 'sorry guys, I didn't know my app could brick the device'. So what we then would need, is a in-queue with new packages and every package has to be manually testes. This would assure quality on a very high level, but likely would not scale (and possibly would not work with a small community). Agreed. In this case I would still suggest using the three holy kings (bug tracking, staged repository, application catalog) but at this point would not concentrate on the holy guide but on the holy process. Sounds good. * A packages does not get into the stable repository if its bugs are over the limit (and debian has a precise definition for limit :-)). Any requirement about where these bugs should be filed? The minimum requirement would be a public bug tracking system and responsiveness from the developers. * A packages does not get into the stable extras repository if there are not at least X successful installation and behavior reports. * A package needs some average ranking to enter the stable repository. http://maemo.org/downloads can serve well this purpose. * We must find some clever way to get a response from the user since we cannot trust the masses (our masses are not of equal size then that of debian). * For example: What about the program manager on the device periodically requests a rating from you for newly installed applications. There will of course be a way to switch it off, and the the notification must not violently jump into the middle of the screen swinging its broadsword, disturbing my circles. We might discuss about this feature in the Application Manager. However, if you find this idea useful it would be faster and probably better to start with an installable 3rd party application covering this functionality and targeted to maemo power users. * Also it might be very effective to collect and submit regular crash reports from the device to the application catalog (of course delivery must again be optional and not the microsoft way). Good point. * Also we need a very easy way to get bug reports (and feature requests) directly from the device into the bug tracking system. It is clear the convenience of having an automated way to send crash reports with traces, but what else would be needed other than that? Do you mean an option inside the application saving you the effort to find the right bugtracker/product/component? This all requires some very fine, polity and well though out additional applications and internal workflows but I think it Looks like a pretty feasible set of points to start working in the right direction. More criteria or is this enough? What about the human side? Who has the authority to say 'you get in', 'you go out'? Quim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
According to Eero Tamminen [EMAIL PROTECTED]: Even better would be if it could build Debian source package on request. Just by giving it the package name it would fetch the sources from Debian repository and (try to) build them for Maemo. While I understand the appeal, this is a really bad idea. Debian packages contain lots of assumptions and content that is not suitable for a quality N800 (N700, N810, whatever) package. Just a few: - documentation files, manpages, changelogs, licenses, etc. Admittedly, this could be filtered out by the autobuilder. - assumptions about default users and groups - creation of users and groups - install scripts doing unnecessary things, and bringing in extra dependencies that are unneeded. - log fiies, which lead to log rotation. - assumptions about file system layout that the N800 et. al. do not obey - Oh, and the control fields such as Maintainer and Section are probably wrong. Basically, even if a Debian source package would be fine on the N800, it needs someone to look at it and confirm. You could automate some of this, but I don't think a total automation is feasible, or even worth working on. Regards, Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
According to Tim Teulings [EMAIL PROTECTED]: Note that debian FTP master as far as I know only check license stuff and similar - they do not check the application itself True. The Linux community distributions handle quality differently. They use same small initial checks and then a staged repository. Debian still has a policy and style guides and similar and tries to do automatic checks that guarantee compliance with these guides. However most the actual crashes bugs are notices after the software initially entered the repository. In this case a guide is still good (and you always get your bugs fixes if it violates the guide ;-)) but quality get a much more diffuse meaning. I'm sure that debian has a number of applications, that don't fulfill all the requirement in the guide. Depends. The guide (aka the Debian Policy Document, aka policy) distinguishes between musts and shoulds. Violations of musts are considered Release Critical bugs, violations of shoulds are non-RC bugs. Specific exceptions for specific packages have been made, when justified. In the case we do not need a guide first, but the process will come first and then the guide will develop. Arg. No. The guide is critical. That doesn't mean the first release has to be perfect, and that it will not evolve, but you need guidelines. There's a lot of stuff in Debian policy that isn't directly related to good or bad, but simply choices. Consistency is an extremely valuable quality, and there's simply no way to encourage it (must less enforce it) without documented policy. And while there's quite a lot in Debian Policy that may not apply, or needs to be reconsidered for the tablet environment, there's a lot that could be adopted as is. It's certainly better than starting from scratch. And gratuitous differences should be avoided like the plague. The problem is: How to assure that still no important bug (that for example kills my device) gets through. You'll never ensure this. What you can hope is that packages that move from whatever-we-call-unstable to whatever-we-call-testing have had at least a few testers before the move. (I'm specifically using testing and not stable because I think the Debian idea of the testing repo is more apropos to the tablet needs.) I also want to point out the classic the perfect is enemy of the good enough. The processes and documents can, and should, evolve as the needs of the audience and developers evolve. But almost anything would be an improvement to the existing situation. In particular, the current situation of encouraging random repositories has absolutely no protection against bad packages (or malicious packages). Just getting the all the current .debs, no matter what the source, into the same repo would be an improvement, because you could remove the bad package from distribution immediately, rather than having to somehow spread the word that package foo in repo bar should be avoided. Regards, Steve -- Steve Greenland The irony is that Bill Gates claims to be making a stable operating system and Linus Torvalds claims to be trying to take over the world. -- seen on the net ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
* Also we need a very easy way to get bug reports (and feature requests) directly from the device into the bug tracking system. It is clear the convenience of having an automated way to send crash reports with traces, but what else would be needed other than that? Do you mean an option inside the application saving you the effort to find the right bugtracker/product/component? This would be great: the best place I can think for that is the Application Manager (with its list of available and installed software), but a separate app (retrieving the same list) would be fine as well. It could be a report problem entry in the context menu for the selected item, which opens a panel similar to that of bugzilla (or easier), with the button Send. And some way to let every user know there is that menu entry available in case of problems, when installing every software: that should not be a somehow hidden feature, it has to be discovered without searching for it. -- Antonio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
On 10/27/07, Steve Greenland [EMAIL PROTECTED] wrote: I also want to point out the classic the perfect is enemy of the good enough. The processes and documents can, and should, evolve as the needs of the audience and developers evolve. But almost anything would be an improvement to the existing situation. In particular, the current situation of encouraging random repositories has absolutely no protection against bad packages (or malicious packages). Just getting the all the current .debs, no matter what the source, into the same repo would be an improvement, because you could remove the bad package from distribution immediately, rather than having to somehow spread the word that package foo in repo bar should be avoided. That is one of my main concerns. and a very good reason to use a centralized process greetings ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Hello! Alright, what about leaving the role of this document in a checkbox developers check in order to get upload rights to extras, à la terms conditions. Something like I'm aware of the maemo Quality Awareness criteria and I have tested my applications against them before uploading them to extras. Hmm, you never would get my applications ;-) I'm pretty sure that I won't fulfill all the requirements. For example being good at battery time is a tricky thing to test (it possibly that my applications do not stop cursor blink when the device tries to sleep (I'm not using Gtk)). and I'm sure that for my application that isn't really a problem. So possibly there should be more than one checkbox so that I can say: * Stable * Installs well * Deinstalls without problems and does not leave anything on the device. * ...but possibly does not handle power management that well. We would have some kind of (hopefully small) checklist that precisely tells the potential application user what he can expect and what risks he will take. But thinks are getting possibly too complex in that direction. I have visions of a number of strange symbols behind each application name in the application catalog (like a battery for power management aware applications and similar) and some users might get information overflow and are in the end not able to make the right decision. Btw., (de)installation checking can be automatized (much better than testing it manually). Somebody already has some script for that. That should be definitely part of the solution! So that part fo the checlist could already be dropped. Does that really lead us in the right direction? What realm harm could be avoided by that checkbox? I think that checkbox can only avoid installation harm that possibly can also be avoided be automatic testing. If an app kills a device (and the developer knows that) that there is possibly already some criminal minimal mind behind - and then the checkbox would not help either. Of course developers might check the box after having gone through the 100%, 50% or 0% of cases and his software might or might not contain major bugs, but at least nobody can say - 'sorry guys, I didn't know my app could brick the device'. OK, but to what benefit? To sue the developer ;-)? What is the real effect of such a checkbox (see above)? * A packages does not get into the stable repository if its bugs are over the limit (and debian has a precise definition for limit :-)). Any requirement about where these bugs should be filed? The minimum requirement would be a public bug tracking system and responsiveness from the developers. I already mentioned a central bug tracking system for the whole system or at least for all applications in the bug tracking system. So that would be OK for me. * A packages does not get into the stable extras repository if there are not at least X successful installation and behavior reports. * A package needs some average ranking to enter the stable repository. http://maemo.org/downloads can serve well this purpose. That I also already proposed. Agreed, too. [...] * For example: What about the program manager on the device periodically requests a rating from you for newly installed applications. [...] We might discuss about this feature in the Application Manager. However, if you find this idea useful it would be faster and probably better to start with an installable 3rd party application covering this functionality and targeted to maemo power users. I would love to implement such stuff (and I'm sure I could, if there are the necessary interfaces) :-)). But since I have my own GUI library (so the result would not be a GTK application) and no knowledge of apt I would step aside for somebody else ;-) I also think this would require some nice interface in the applications manager, else somebody has to fiddle with faking SSL HTTP requests :-/ * Also it might be very effective to collect and submit regular crash reports from the device to the application catalog (of course delivery must again be optional and not the microsoft way). Good point. See Gnome (and Windows Vista :-/). * Also we need a very easy way to get bug reports (and feature requests) directly from the device into the bug tracking system. It is clear the convenience of having an automated way to send crash reports with traces, but what else would be needed other than that? Do you mean an option inside the application saving you the effort to find the right bugtracker/product/component? I would not propose in-application solutions - simply because not all people use Gtk for development (especially me;-)). Collecting crashes is technically solved by the application starter process (wait for SIGCHLD). It would make sense to integrate (or at least base it on information from) this in the application manager, because he can read the necessary
Re: Repositories mess: conclusions and actions
Hello! Depends. The guide (aka the Debian Policy Document, aka policy) distinguishes between musts and shoulds. Violations of musts are considered Release Critical bugs, violations of shoulds are non-RC bugs. Specific exceptions for specific packages have been made, when justified. In the case we do not need a guide first, but the process will come first and then the guide will develop. Arg. No. The guide is critical. That doesn't mean the first release has to be perfect, and that it will not evolve, but you need guidelines. There's a lot of stuff in Debian policy that isn't directly related to good or bad, but simply choices. Consistency is an extremely valuable quality, and there's simply no way to encourage it (must less enforce it) without documented policy. I was possibly not that clear in my formulations. I think that we may still share the same opinion. IMHO we are talking about two different aspects of such a guide. The first one - the one that I think you mean (and that I think is important and must be agreed on to initiate the process) - is the guide that defines the process. Of course an important part of the process is for example packaging. You a right in that we can copy most of such guides from debian. However it is likely that we have to modify this. For example we may need some additional headers for the in parallel discussed bug tracking client application. So here we agree :-) If you look at the said guide Quim mentioned however this guide does not define the process and the framing rules for the extra repository and its uses, but is is a (in future :-)) detailed list of test cases to determinate the quality of an application (of course Quim might have planed something different, but this is my interpolation into thefuture). Part of it is packaging (which overlaps with the rules) but some part might develop in a check list for a tester. Such checklist is not required now, because the process does hopefully handle quality without explicit quality assurance by a trusted person. We currently would require only general requirements (which could be part of the guide) but again the process will find its own (possibly surprising) requirements - the requirements of the people that install and vote. For example we may find out,that fine power management is not important to (wild guess) 50% of the people. So who are we to forbid battery killing applications their march into the repository (hmm, however the other 50% may like to know...). And while there's quite a lot in Debian Policy that may not apply, or needs to be reconsidered for the tablet environment, there's a lot that could be adopted as is. It's certainly better than starting from scratch. And gratuitous differences should be avoided like the plague. Totally agree. For example the staging stuff and the packaging system seem to have general agreement by nearly all participants in this discussion. You'll never ensure this. What you can hope is that packages that move from whatever-we-call-unstable to whatever-we-call-testing have had at That process is completely OK and I never spoke against that. However I think we must tweak it a little bit for our purposes and framing conditions: * We have a much smaller user base. So we must make feedback as easy as possible. * We have mostly GUI applications which may make things easier in some situations. * We have that nice application catalog :-) * Or desktop is much simpler and thus we can better integrate our process into the desktop. I also want to point out the classic the perfect is enemy of the good enough. The processes and documents can, and should, evolve as [...] Security, quality, central approach - all part oft my initial claims :-) -- Gruß... Tim ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Repositories mess: conclusions and actions
On Sat, 2007-10-27 at 21:17 +0300, [EMAIL PROTECTED] wrote: but at least nobody can say - 'sorry guys, I didn't know my app could brick the device'. Requiring any quality control before having a place to put the alpha/beta-quality stuff will just stop us from getting much software. Software needs to be released in order to increase its quality. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
RE: Repositories mess: conclusions and actions
Sorry my friend, but Quim jest right. There is a number of applications ported to Nokia Tablet, in my case comoiled for N770, crashing my maemo. The only solution proposed to me at http://www.internettablettalk.com/forums/ was to reflash my N770 with non-certified OS2007HE. Having installed 3 plugins, showing icons in upper bar maemo-bt-plugin has been covered by icon of take screenshot plugin and I can't run maemo-bt-plugin to use my bt gps device for navigation. At the same time crashed Application manager and I get Operation failed message each time I run it. copy of log file osso-application-installer 4.22.1, UI version 1 E: Encountered a section with no Package: header E: Problem with MergeList /var/lib/dpkg/status E: The package lists or status file could not be parsed or opened. status file is about 0,5M in size. Any chance to repair it not having to reflash my N770 ? Tried hard to make an application based on Kismet + GPS. No chance as gps doesn't work for Kismet on N770. Tried to to multiplex 2 bt gps devices. No chance. bt pyton code doesn't work for N770. I am aware Nokia is not providing any support for N770 so I have ordered 2 N800 units. But with new N810 coming soon I can expect not getting any support for my N800 very soon. As a number of application ported and compiled for N770 is not greater than 100, I see no challenge to install and test any and every one to see if it works ok or not, crashing Nokia Tablet. At http://www.internettablettalk.com/forums/ I proposed setting up a network of Nokia Tablet N770, N800, N810 user's clubs world-wide, providing support to new users by local Nokia Tablet gurus and I can continue run this project, as there is great interest in having Nokia Tablet guru living in local community. So I would really appreciate your advice if Nokia provides any form of an interactive support to new users of Nokia Tablets and at what address and place and whom should a new user contact. Thanks. Darius Murray Cumming [EMAIL PROTECTED] wrote: On Sat, 2007-10-27 at 21:17 +0300, [EMAIL PROTECTED] wrote: but at least nobody can say - 'sorry guys, I didn't know my app could brick the device'. Requiring any quality control before having a place to put the alpha/beta-quality stuff will just stop us from getting much software. Software needs to be released in order to increase its quality. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers Send instant messages to your online friends http://uk.messenger.yahoo.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Just some comments to be more precise in the mentions to Nokia. On Thu, 2007-10-25 at 21:42 +0200, ext Laurent GUERBY wrote: (Thanks for the interesting and generous offer) Then may be someone Nokia can get an account to and copy (scp/rsync) built packages meeting their validation criteria to extra (all at the hand of Nokia people). I can't insist more that we don't want Nokia deciding what goes to extras. If the community wants us to take part we will be part, but not leaders and definitely not the single ones deciding. On the other hand, Nokia wouldn't have either any responsibility over the people getting accounts, as we are not getting it for the software hosted in extras. On Thu, 2007-10-25 at 20:25 +0200, ext Tim Teulings wrote: (thanks for the long email, interesting summary) - Nokia: We want to centralize the development to just make things easier, simpler and add service - without compromising the open source idea. (Simplicity, centric) Centralization doesn't compete with 'the open source idea'. We are proposing it not because we are Nokia but because we are running maemo on top of GNU/Linux and .deb packages. Just look at how your preferred open source software distribution is organized, it is almost a paradox that most if not all of them are in fact more centralized than maemo. - Nokia: We want to multiply by delegating task to the community (Scalability) Delegating is not accurate enough. We want to empower the community to push and promote the software they think is good enough for that. * Definition of the meaning quality in a community that consists of Nokia and the open source community. The Quality Awareness document is open to improvements and contributions. We don't want/need to have different docs to define measure quality, so whatever idea you have please check it against the current doc and suggest improvements to it. * Since Nokia holds most of the infrastructure I fear Nokia has the burden to supply the technical infrastructure while the community will support the daily work, the rating and the quality assurance. Fear? If this doesn't sound like a fair exchange then please suggest fair proposals. -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
On Thu, 2007-10-25 at 20:03 +0100, ext Niklas Höglund wrote: I fully agree that Zero Install is a good fit for this device. I know nothing about this technology but let me be stupid and say that it looks like Zero Install is a good solution for a problem we don't have in the tablets. http://0install.net/ Anyone can install software You don't have to be the administrator (root) just to install a word-processor [ more ] This is not a problem since by default anybody with a tablet in the hands can install software. Anyone can distribute software You don't need to be blessed by a distribution (or anyone else) to be part of Zero Install; The system is completely decentralised [ more ] This is not a problem since any web page can point to a one-click install hosted anywhere calling deb packages hosted anywhere (else). It doesn't matter whether software is installed or not You just run it. Zero Install handles the rest (downloading and caching as needed) [ more ] From a user point of view, installing means download + press ok + wait a moment + go. It looks like the user experience wouldn't change, and in any case isn't bad at the moment (if the app works and the dependencies are satisfied etc). Security If one user downloads a malicious program, other users aren't affected; Users can share downloads without having to trust each other; Installation does not execute any of the downloaded code; Digital signatures are always checked before new software is run [ more ] The other users is not a problem since the main use case of the tablet is a single user system. Digital signatures should be also in place for packages in extras. Some kind of review to avoid malicious software in extras would be in place. Of course people can download software from somewhere else, but I guess they could also step out of the Zero Install process anyway and get whatever software they found. -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
On Wed, 2007-10-24 at 14:49 +0300, Quim Gil wrote: This is an invitation to resume all previous discussions about the repository mess and come up with conclusions and actions. Please read this through and have a say, specially if you are maintaining a repository with maemo packages out of maemo.org [snip] Does this need to be in place for Chinook, or just for Chinook+X? Or, will the addition of new packages to Chinook's extras repository block on these policies being in place? I'd like to get some beta (alpha, maybe) Glom packages in to Chinook's extras, to get things moving. They wouldn't pass quality tests. But I don't really want to set up my own repository. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
On Fri, 2007-10-26 at 10:24 +0200, ext Murray Cumming wrote: Does this need to be in place for Chinook, or just for Chinook+X? No changes for Chinook, too late for that. It would be good to discuss and agree something that would be gradually implemented and working when welcoming Diablo (2008). -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
I know nothing about this technology but let me be stupid and say that it looks like Zero Install is a good solution for a problem we don't have in the tablets. http://0install.net/ That's nice: I agree it addresses also some problems which we don't have in the tablets, good for it. But I must say that the spot summary in the web page doesn't convey the fact that it addresses also problems that we do have in the tablets. At least: - it takes the system clean: user runs apps without installing them, and the eventual removal is a real purge without residuals chance; why on a modern super-connected and internet-based device should we go into an installation step to use *every* application, even a little gtk tris game, if a way to avoid it already exist and is free to adopt? I agree in some special cases it would be required (infact I've proposed Zero Install as a supplement to the other more dirty way), but it should not be the rule; - it takes the system easy to clean, as everything has its own dir; nice for desktops, but very good (maybe I should put an exclamation mark) for consumer tablets; - it makes an effortless and 99.9% probability of success the system backup and restore task, with all applications and settings, especially after a reflash; it would be also possible to selectively choose what apps to backup, or to backup just the settings and data and the list of feeds for later redownload, or... (just fly with imagination, everything's possible here because everything is there in its cache dir ;) Maybe (I hope) these problems will be addressed in some future in some way, no matter if through Zero Install or another solution, but I just want to say that they were solvable yesterday with the Zero Install way. Of course they will, it's a matter of time (as long as someone else cares about these problems - gulp I'm not sure enough :) Btw, thanks for the evaluation, it is already good you've gone into the trouble of reading something about it, as said it seems it's a rather unknown and undervalued system (maybe due to similarity to badly designed systems - but it's just my guess). -- Antonio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Quim Gil wrote: On Thu, 2007-10-25 at 20:03 +0100, ext Niklas Höglund wrote: I fully agree that Zero Install is a good fit for this device. I know nothing about this technology but let me be stupid and say that it looks like Zero Install is a good solution for a problem we don't have in the tablets. [ snipped ] From a user point of view, installing means download + press ok + wait a moment + go. It looks like the user experience wouldn't change, and in any case isn't bad at the moment (if the app works and the dependencies are satisfied etc). I agree that the current scheme is pretty good. The Zero Install is also only really suitable for applications, not system services, etc, so the current system would have to be kept. It's probably not worth the effort to add this as a second system, IMO, but a few of the benefits it would have are: 1. Assuming some application menu integration was done, and that the backup tool would back up the list of application groups, application names and their URL:s (for 0install apps), and then restored them, they would automatically be back after a reflash. Sure, you'd get a dialog and have to wait a bit extra the first time you launch it again, but you wouldn't have to hunt up the web page you installed it from. Also, if applications are portable, you could have the same list of applications on your tablet as on your laptop and your desktop. (Maemo-specific unportable stuff such as HildonWindow, etc. make that a bit harder, though, but definitely doable.) 2. I quote from http://linuxtogo.org/~florian/maemo/index.html: The GPE pacakges in this repository use a different versioning scheme. Before you install one of this packages you have to remove all installed GPE application and library packages from other repositories. If you launch an application using one URL, it would use the libraries from URLs in the feed file on that URL, so different incompatible versions would not conflict. You could even run incompatible versions from different sites at the same time. They'd be cached and run from different directories. You'd just waste some memory and disk space, but it would work perfectly. When you know which version is best, you could purge the other one from the cache to save space. 3. Also: Note that some dependencies are in the Maemo SDK repository, so before you install the packages you need to add the SDK feed. There is an install file for this below. Programs depending on libraries can seamlessly use them whatever URL they come from, but I've read that the application manager will be fixed to allow .install files to add multiple repositories. 4. The packages are easier to create then .deb packages. -- Niklas ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
The GPE pacakges in this repository use a different versioning scheme. Before you install one of this packages you have to remove all installed GPE application and library packages from other repositories. If you launch an application using one URL, it would use the libraries from URLs in the feed file on that URL, so different incompatible versions would not conflict. You could even run incompatible versions from different sites at the same time. They'd be cached and run from different directories. You'd just waste some memory and disk space, but it would work perfectly. When you know which version is best, you could purge the other one from the cache to save space. Hello it sounds like zero install has its advantages. However after reading this comment I would say that such a scheme would not be beneficial to the developers community/sharing . the reason why there are 3 sdk's is becasue there are apparently 3 different kind of incompatible apis I can't imagine zero install fixing that problem :p To be honest I think that zero install would be better than the current installer for end user programs provided that the apps would be end-user things and not libraries. if you start zero packaging python that would not be such a good idea. Disclaimer:I am not hindered by any knowledge about zero install :p Note that I am not happy with the current install files that are in use with regards to dependencies I think they should at least tell from what repositories the different dependencies must come from. 3. Also: Note that some dependencies are in the Maemo SDK repository, so before you install the packages you need to add the SDK feed. There is an install file for this below. How would zero install handle this(my imaginary programs require python and pygame)? 4. The packages are easier to create then .deb packages. That was an easy one. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
3. Also: Note that some dependencies are in the Maemo SDK repository, so before you install the packages you need to add the SDK feed. There is an install file for this below. How would zero install handle this(my imaginary programs require python and pygame)? This one gives clues (stolen from a message written by the system creator [1]): [...] It uses the 'dependency injection' model (AKA 'inversion of control'). Instead of each component finding its dependencies [...], each component is told where to find its dependencies. [...] [1] http://www.mail-archive.com/[EMAIL PROTECTED]/msg02152.html -- Antonio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
* Since Nokia holds most of the infrastructure I fear Nokia has the burden to supply the technical infrastructure while the community will support the daily work, the rating and the quality assurance. Fear? If this doesn't sound like a fair exchange then please suggest fair proposals. Er, I think you misunderstood him: he used that word (fear) projecting it to Nokia, not to himself... Something like I fear it will be Nokia to have the heavy burden of maintaining the technical infrastracture; instead the community will Does it sounds good? Or maybe it's me misunderstanding him :) -- Antonio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Hello! IMHO this discussion is important, but needs some kick to start discussing real concrete solutions in more detail and to agree on suggested behavior. I would suggest to continue discussing but in the end of each of you mails define short statements, that summarize your idea and ideally are a patch to this or a similar list (especially my conclusion could be more concrete and shorter :-)) and especially agree or disagree explicitly on points already suggested to get a common opinion. So I try to summarize and extract the key points already mentioned. Problem === - Nokia: There are many applications that would increase the wealth of our product, but me must guaranty + Quality (Quality) + Ease of use (Simplicity) - Nokia: We want to centralize the development to just make things easier, simpler and add service - without compromising the open source idea. (Simplicity, centric) - Nokia: We want to multiply by delegating task to the community (Scalability) - Nokia: We must keep security in mind - nobody must be able to inject bad packages etc... (Security, Control) - Nokia: We want to attract new developers and give them a guided testing bed (Iterative) - User: There are a huge number of applications. Most of the applications would promote the devices and the platform, but it is difficult to + find the application (Locate) + judge, if the application has quality (Quality) - Developer: Developers have problems to promote their software (Promote) - Developer: It is difficult to assure that the application is installing and running well on all devices (Quality assurance) - Developer: There are multiple platforms and I need to do building for them all manually (Build management). - Developer: Not every developer is similar. The process must support + Garage + External projects but local packaging + External projects (Flexible) Claims == This results in solving problems that can be described by the following key points (I admit that these are very common problems when working in the software development process ;-)): We need a process that... - Defines Quality - Assures Quality - Is simple - Is somewhat centric - Is scalable - Assures security and control over the process - Is iterative for developers - Helps user finding a application - Helps promoting software - Eases building packages - Must be flexible regarding package sources Comments So some comments on some of the key topics. Quality: Quim quoted http://maemo.org/development/documentation/how-tos/4-x/quality_awareness.html but this is only a start. But Quim itself admits that there already software that is promoted while not fulfilling all criteria (and this is IMHO the right thing). So we need a better definition on quality like: * Number of users installed must be significant. * Number of bugs (= Debian) * Rating (as a soft criteria that signals requirement for further investigation). (= Application Catalog) There is also the question about who decides the quality? The process (= Debian)? The user itself based on some numbers? Nokia? To assure quality the process must react very quickly (more quickly like in Debian staging repositories). Simple: Simple for me means that it must be automatic. Things like auto building, evaluation of open tickets and application catalog integration are IMHO a must. Centric: * Means that there is one official repository (which may be split into stable, testing..), one application catalog, one ticketing system. There is no way around this if we want to guarantee security and quality at the same time. Scalable: = Automation and having a = group of people. At least part of the team should by non-Nokia people. Security and control: So we need signing, secure process injection protocols and a clearly defined process. I thing Debian has a number of additional mechanism that could detect problems with Copyright and similar by scanning packages and differences between package versions etc... Iterative: We need staging repositories and a rating system that has more states than good. Finding Applications: We have the application catalog which might need improvement but I see no other solution. Promotion: We could automatically generate high scores from the download numbers from the catalog and also from the rating. Promotion should be part of the catalog (and the home page). There is already something like that there but could of course bee improved. Eases building/Flexible: Tools, examples and Autobuilder/autoinstaller. fetching external repositories is IMHO no go, because of the security reasons mentioned by Nokia. Having an external project page myself, I see the problems but also see the problems supporting me. IMHO garage should be able to delegate parts of a project (web page, source repository) to external (trusted) resources. Building however cannot be externalized, so I still have to drop
Repositories mess: conclusions and actions
I fully agree that Zero Install is a good fit for this device. I use a lot of different machines, and setting up software on all of them is a lot of administration work. The idea with Zero Install is that you just have applications bookmarked and then downloaded and cached on demand. This way you just have to copy your bookmarks to a new machine. The applications take a bit longer to start the first time, of course, since it needs to download them. I did a quick and dirty port of 0launch back in 2006. It was a bit slow, mostly to start Python and PyGTK. And I didn't put in the effort to automatically turn the network on, and change some dialogs that should really be full-screen on this device. The web page I put up is still available at http://web.telia.com/~u86012345/nokia770/ As to the security aspect, I don't think it is any less secure to have a program download a GnuPG-signed application automatically than if I click on a deb file on a web page. A nice thing about this system is that you can run two different applications that link to different versions of the same library without stepping on interfering. This will only be done if the libraries are accessed from different sites or if the applications restrict the acceptable versions. Normally you'd want to use the newest version available, but this system sandboxes different applications so that they cannot mess with each other. -- Niklas ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
On Wed, 2007-10-24 at 13:52 +0100, Neil Jerram wrote: Quim Gil [EMAIL PROTECTED] writes: This is an invitation to resume all previous discussions about the repository mess and come up with conclusions and actions. Please read this through and have a say, specially if you are maintaining a repository with maemo packages out of maemo.org This all sounds very positive to me. The only thing I'd add is that Nokia/Maemo should consider providing a auto-builder service for Maemo packages, such that - developers could upload source code packages - the autobuilder would attempt to build them, for all supported platforms (gregale, bora and chinook) - if everything built successfully, the auto-builder would automatically submit through to the extras-testing repository - if there were problems, the auto-builder would email those back to the developer. Hi, I'm an admin of the GCC Compile Farm (3 bi-dual opteron running debian etch amd64): http://gcc.gnu.org/wiki/CompileFarm I'd be pleased to create ssh accounts for known maemo contributors on the farm (for free software development only), especially if someone contributes an auto-builder or patch tester (as someone did for GCC). You can send emails and set crontab on the farm machines, as long as bandwitdh usage stays low (no web server / exports). Then may be someone Nokia can get an account to and copy (scp/rsync) built packages meeting their validation criteria to extra (all at the hand of Nokia people). This would provide a common standard building environment and a path to maemo repository without Nokia having the need to open and administrate a build farm and ssh account for non employees. (I can also provide a web server in another data center but that's not the point here :). Let me know if this is of interest for the maemo community. Laurent PS: if you're a free software developper and like to play with various GCC versions on your software you can also get an account, instructions are given on the web page referenced above. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Am Donnerstag, 25. Oktober 2007 schrieb Tim Teulings: Hello! IMHO this discussion is important, but needs some kick to start discussing real concrete solutions in more detail and to agree on suggested behavior. I would suggest to continue discussing but in the end of each of you mails define short statements, that summarize your idea and ideally are a patch to this or a similar list (especially my conclusion could be more concrete and shorter :-)) and especially agree or disagree explicitly on points already suggested to get a common opinion. So I try to summarize and extract the key points already mentioned. Problem === - Nokia: There are many applications that would increase the wealth of our product, but me must guaranty + Quality (Quality) + Ease of use (Simplicity) - Nokia: We want to centralize the development to just make things easier, simpler and add service - without compromising the open source idea. (Simplicity, centric) - Nokia: We want to multiply by delegating task to the community (Scalability) - Nokia: We must keep security in mind - nobody must be able to inject bad packages etc... (Security, Control) - Nokia: We want to attract new developers and give them a guided testing bed (Iterative) - User: There are a huge number of applications. Most of the applications would promote the devices and the platform, but it is difficult to + find the application (Locate) + judge, if the application has quality (Quality) - Developer: Developers have problems to promote their software (Promote) - Developer: It is difficult to assure that the application is installing and running well on all devices (Quality assurance) - Developer: There are multiple platforms and I need to do building for them all manually (Build management). - Developer: Not every developer is similar. The process must support + Garage + External projects but local packaging + External projects (Flexible) Claims == This results in solving problems that can be described by the following key points (I admit that these are very common problems when working in the software development process ;-)): We need a process that... - Defines Quality - Assures Quality - Is simple - Is somewhat centric - Is scalable - Assures security and control over the process - Is iterative for developers - Helps user finding a application - Helps promoting software - Eases building packages - Must be flexible regarding package sources Comments So some comments on some of the key topics. Quality: Quim quoted http://maemo.org/development/documentation/how-tos/4-x/quality_awareness.ht ml but this is only a start. But Quim itself admits that there already software that is promoted while not fulfilling all criteria (and this is IMHO the right thing). So we need a better definition on quality like: * Number of users installed must be significant. * Number of bugs (= Debian) * Rating (as a soft criteria that signals requirement for further investigation). (= Application Catalog) There is also the question about who decides the quality? The process (= Debian)? The user itself based on some numbers? Nokia? To assure quality the process must react very quickly (more quickly like in Debian staging repositories). Simple: Simple for me means that it must be automatic. Things like auto building, evaluation of open tickets and application catalog integration are IMHO a must. Centric: * Means that there is one official repository (which may be split into stable, testing..), one application catalog, one ticketing system. There is no way around this if we want to guarantee security and quality at the same time. Scalable: = Automation and having a = group of people. At least part of the team should by non-Nokia people. Security and control: So we need signing, secure process injection protocols and a clearly defined process. I thing Debian has a number of additional mechanism that could detect problems with Copyright and similar by scanning packages and differences between package versions etc... Iterative: We need staging repositories and a rating system that has more states than good. Finding Applications: We have the application catalog which might need improvement but I see no other solution. Promotion: We could automatically generate high scores from the download numbers from the catalog and also from the rating. Promotion should be part of the catalog (and the home page). There is already something like that there but could of course bee improved. Eases building/Flexible: Tools, examples and Autobuilder/autoinstaller. fetching external repositories is IMHO no go, because of the security reasons mentioned by Nokia. Having an external project page myself, I see the problems but also see the problems supporting me. IMHO garage should be able to delegate parts of a project (web page,
Repositories mess: conclusions and actions
This is an invitation to resume all previous discussions about the repository mess and come up with conclusions and actions. Please read this through and have a say, specially if you are maintaining a repository with maemo packages out of maemo.org MISSION To provide the simplest interface for end users to get good quality third party software that downloads and installs flawlessly, without compromising their default system. To provide maemo tools and infrastructure to developers so they can check the quality of their software, offer it to end users and promote it. STEPS (the ones involving repositories) - Cleaning old stuff We plan to keep the repositories for Bora and Chinook (N800/N810) and Gregale (770) and delete the older ones to avoid confusion (Scirocco, Mistral...) - Powering extras for 3rd party software We encourage developers using the extras repository. extras is pre-configured in the OS2008 Application Manager and users only need to activate it manually (like i.e. Universe in Ubuntu). Nokia.com and Tableteer are going to promote preferably applications with packages available in extras. We plan to start testing new releases including test cases with third party applications installed. The seamless software update feature (upgrades via deb packages) will be also tested considering upgrades of packages in extras... - Improving the service around extras There must be reasons why people have been creating their own repos instead of joining extras. We have discussed about this in the past. Now, make sure that whatever is missing is filed either as bug or enhancement request in bugs.maemo.org (product Website, component Repository). The objective is to leave you almost no excuses to keep having your own repos, or at least no excuses to have your stable packages in extras. - Community governance on extras We think the equation would work much better if the maemo community would have control over the extras repository, filtering what has enough quality to be there and what not. Who and how, we are totally open about this. We consider the Quality Awareness documentation as a reference top define quality. We don't want to give away the control of the repository but we are happy discussing and agreeing with you the rules of a common game. These rules would include other topics discussed in the past, like i.e. the sections. - extras-testing for experimentation and stabilization If you think the previous idea makes sense, we could open then extras-testing just to any developer having beta quality software and willing to use the maemo infrastructure. Any developer willing to have their packages in extras should go first through extras-testing for review. No deadlines, but the sooner we agree on a plan the sooner we can execute it and the sooner it will benefit to users and developers. -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Quim Gil [EMAIL PROTECTED] writes: This is an invitation to resume all previous discussions about the repository mess and come up with conclusions and actions. Please read this through and have a say, specially if you are maintaining a repository with maemo packages out of maemo.org This all sounds very positive to me. The only thing I'd add is that Nokia/Maemo should consider providing a auto-builder service for Maemo packages, such that - developers could upload source code packages - the autobuilder would attempt to build them, for all supported platforms (gregale, bora and chinook) - if everything built successfully, the auto-builder would automatically submit through to the extras-testing repository - if there were problems, the auto-builder would email those back to the developer. Technically this is separate from the repository issue, but (i) I think it is needed, in addition to your repository proposals, in order to dramatically improve the availability and quality of 3rd party packages, and (ii) it would be a major incentive for developers to use extras and extras-testing instead of starting up their own repositories. Please note that, if such an auto-builder existed, this does not mean that developers should stop building the code themselves - because it would be wrong to upload to the auto-builder before having some confidence that the package will build. It would be reasonable, however, for a developer to have only the current SDK (e.g. chinook) installed, to do their development using that, and to check that their package builds in that SDK's rootstrap, and then to use the auto-builder to handle building (and publishing packages) under the other platform SDKs. In some cases, of course, it will be impossible to make an application work on the older platforms. Such cases could be handled by allowing a Platforms: chinook or Platforms: chinook, bora declaration in the source package upload. As regards implementation, note that the mud-builder project in garage has already done some useful work here - but in any case I don't think this auto-builder would be technically difficult; it's more a matter of whether you agree that this service would be a good idea and could invest the management resource to make it available. Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
On 10/24/07, Neil Jerram [EMAIL PROTECTED] wrote: This all sounds very positive to me. The only thing I'd add is that Nokia/Maemo should consider providing a auto-builder service for Maemo packages, [...] Agreed, and as you reference mud-builder later on, I've *no* problem in the Maemo team providing a proper auto-builder and destroying some aspects of mud. In fact, it'd be better as mud could concentrate on repackaging upstream tarballs etc. to source bundles necessary for the Maemo autobuilder, and not have to worry about the boring auto-build stuff. As regards implementation, note that the mud-builder project in garage has already done some useful work here - but in any case I don't think this auto-builder would be technically difficult; it's more a matter of whether you agree that this service would be a good idea and could invest the management resource to make it available. Agreed. Personally, I think it'd help enormously with getting stuff into extras, and improving the general Maemo landscape. Instead of mud-builder, it'd almost certainly be worth using the Debian/Ubuntu infrastructure designed for this kind of thing: mud-builder is still at a much lower scale than this'd need to be (with queues, error handling/emailing etc.) Cheers, Andrew -- Andrew Flegg -- mailto:[EMAIL PROTECTED] | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Hi, ext Neil Jerram wrote: Quim Gil [EMAIL PROTECTED] writes: This is an invitation to resume all previous discussions about the repository mess and come up with conclusions and actions. Please read this through and have a say, specially if you are maintaining a repository with maemo packages out of maemo.org This all sounds very positive to me. The only thing I'd add is that Nokia/Maemo should consider providing a auto-builder service for Maemo packages, such that - developers could upload source code packages - the autobuilder would attempt to build them, for all supported platforms (gregale, bora and chinook) - if everything built successfully, the auto-builder would automatically submit through to the extras-testing repository - if there were problems, the auto-builder would email those back to the developer. Technically this is separate from the repository issue, but (i) I think it is needed, in addition to your repository proposals, in order to dramatically improve the availability and quality of 3rd party packages, and (ii) it would be a major incentive for developers to use extras and extras-testing instead of starting up their own repositories. This doesn't necessarily need to be provided by Nokia, autobuild could be also provided by some external party. Even better would be if it could build Debian source package on request. Just by giving it the package name it would fetch the sources from Debian repository and (try to) build them for Maemo. Please note that, if such an auto-builder existed, this does not mean that developers should stop building the code themselves - because it would be wrong to upload to the auto-builder before having some confidence that the package will build. It would be reasonable, however, for a developer to have only the current SDK (e.g. chinook) installed, to do their development using that, and to check that their package builds in that SDK's rootstrap, and then to use the auto-builder to handle building (and publishing packages) under the other platform SDKs. In some cases, of course, it will be impossible to make an application work on the older platforms. Such cases could be handled by allowing a Platforms: chinook or Platforms: chinook, bora declaration in the source package upload. As regards implementation, note that the mud-builder project in garage has already done some useful work here - but in any case I don't think this auto-builder would be technically difficult; it's more a matter of whether you agree that this service would be a good idea and could invest the management resource to make it available. - Eero ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Eero Tamminen [EMAIL PROTECTED] writes: This doesn't necessarily need to be provided by Nokia, autobuild could be also provided by some external party. True. Perhaps, as this thread develops, Nokia will indicate whether or not they might look at doing this. Then, if the indication is no, I guess the ball is in the community's court. Regards, Neil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
MISSION To provide the simplest interface for end users to get good quality third party software that downloads and installs flawlessly, without compromising their default system. [...] I know I'm adding something a bit out-of-the-rails, but I think this subject is very important, and I can't avoid giving my two cents here. I'm speaking as a user who's scared whenever it comes to install new stuff on the 770, always fearing some mess after installation and rejecting reflash need to death. My proposal is to do whatever you think is the good approach, but it would be at least *nice* (or a great working solution for the problem) to join Thomas Leonard's approach, as a promoted by maemo complimentary alternative, along with the other more standard solution you'll come across. I'm speaking of his Zero Install system, of course. For those who don't know (or who have briefly tagged it as an insecure or inadequate thing for some reason) it's a very well working project which (imho) deserves much more attention than the current one; I can't imagine what's the reason for this situation: maybe it's too much easy to use? ;) This is an interview with the project leader (feb 2007), which can give a quick go in understanding why I think at Zero Install as a worth suggestion to this post; his words are surely better than could be mine, so please spend 3 minutes reading it: http://www.linux.com/articles/114230 The list of completed features can also be useful for a quick glance: http://0install.net/roadmap.html As you can read in the interview, the greatest obstacle seems to be getting Zero Install accepted by distributions. [...] All the same, Leonard cites 'apathy' from distributions as a major problem for Zero Install's acceptance. So, my suggestion is: why not giving users a nice and secure way to run stuff (I cannot say install :) on their shiny portable linux device, simply by spinning the Zero Install system a bit, through an official adoption from the maemo side? It would require that developers wanting to offer maemo apps to public, should arrange them in order to be retrieved through a Zero Install client working on the device (it could be integrated in the Application Manager!). If you don't like it (why?), ok it could be an option, maybe something like a Test Applications panel in the Application Manager, where the user could read a simplified version of this message: From here, you can test the application before installing it: if it happens to fit your needs after some usage, we suggest to install it the normal way. The files won't be downloaded again, just load the Application Manager again and click it in the Install panel: in a few seconds you'll have the tested application installed the normal way; otherwise, come back here in the Test Applications panel, click on the Please Purge button on the left of its name to remove everything (i.e. simply the zero install cache folder for that app! ;) the orrible/stinky/broken application has ever put on your beloved device. Please note that your maemo device will be grateful if you find the time to perform the test before installing the normal way. -- Antonio ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
On 10/24/07, Neil Jerram [EMAIL PROTECTED] wrote: Quim Gil [EMAIL PROTECTED] writes: This is an invitation to resume all previous discussions about the repository mess and come up with conclusions and actions. Please read this through and have a say, specially if you are maintaining a repository with maemo packages out of maemo.org This all sounds very positive to me. The only thing I'd add is that Nokia/Maemo should consider providing a auto-builder service for Maemo packages, such that - developers could upload source code packages - the autobuilder would attempt to build them, for all supported platforms (gregale, bora and chinook) - if everything built successfully, the auto-builder would automatically submit through to the extras-testing repository - if there were problems, the auto-builder would email those back to the developer. Hello Neil, I agree with your points. I also know we have discussed this all before it is a sbox2/sbox/mud/oe and the standard debian build tools disc. As far as I am concern I would only thrust packages that where compiled by somebody trusted by/in the community. Next to your points I guess there is a huge need for simple packaging of for example python Apps. There are also requirement from the open-source/GPL side of things where you have to be able to deliver the sources of the packages you distribute. For most problems encountered different people found a solutions The latest and greatest thing I tried was the mamona project. It shows that it's possible to create a bleeding edge/open-source distro without the sbox/vmware for the nokia devices. http://dev.openbossa.org/trac/mamona (oe based distro) http://mud-builder.garage.maemo.org/index.php (mud builder) http://khertan.net/softwares/pypackager.php (PyPackager is a small gui tool to create debian package on a maemo device) http://raemo.garage.maemo.org/ (Access a device to perform testing) greetings ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
Am Mittwoch, 24. Oktober 2007 schrieb Quim Gil: This is an invitation to resume all previous discussions about the repository mess and come up with conclusions and actions. Please read this through and have a say, specially if you are maintaining a repository with maemo packages out of maemo.org MISSION To provide the simplest interface for end users to get good quality third party software that downloads and installs flawlessly, without compromising their default system. To provide maemo tools and infrastructure to developers so they can check the quality of their software, offer it to end users and promote it. STEPS (the ones involving repositories) ... - Community governance on extras We think the equation would work much better if the maemo community would have control over the extras repository, filtering what has enough quality to be there and what not. Who and how, we are totally open about this. We consider the Quality Awareness documentation as a reference top define quality. We don't want to give away the control of the repository but we are happy discussing and agreeing with you the rules of a common game. These rules would include other topics discussed in the past, like i.e. the sections. - extras-testing for experimentation and stabilization If you think the previous idea makes sense, we could open then extras-testing just to any developer having beta quality software and willing to use the maemo infrastructure. Any developer willing to have their packages in extras should go first through extras-testing for review. Sounds good. What kind of rules do you have in mind yet? How would the whole process look like? Krischan ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Repositories mess: conclusions and actions
On Thu, 2007-10-25 at 00:00 +0200, ext Krischan Keitsch wrote: What kind of rules do you have in mind yet? Almost no rules in mind. We'd prefer community minds to come up with the process. This includes community developers that also happen to work at Nokia (this is the case for some authors of some apps widely used and appreciated by users). Up to them. The very basic rules would be: - The core maemo team facilitates the discussion and needs to bless the conclusions, specially in those aspects requiring their actions (i.e. changing the access policy to extras). Whatever is proposed needs to be approved by Ferenc (*.maemo.org admin), Marius (Application Manager owner) and myself (maemo product manager). - Security is one strong aspect to consider, looking at the server infrastructure and the tablets. - Nokia ownership/control is another important aspect. Nokia owns the infrastructure and is responsible of it. Nokia will not be responsible of the software available in extras but will be recommending it to their customers. How would the whole process look like? The core mission is to guarantee the quality of the software hosted in the extras repository. There is no gold rule for quality but a good start could be http://maemo.org/development/documentation/how-tos/4-x/quality_awareness.html The details to achieve this are up to you. The process proposed will be ok for us as far as it follows the mentioned basic rules, it's open and agreed by the maemo community. -- Quim Gil - http://maemo.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
