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
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
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
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
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
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
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
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
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,
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).
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
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
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.
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
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
[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]
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
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,
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
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
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
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
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
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:
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
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
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
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
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
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
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 :)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
* 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
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
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
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
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
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
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
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.
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
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).
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
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
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
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
* 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
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
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
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
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
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
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
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
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
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
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
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
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
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
77 matches
Mail list logo
