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 develope
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 f
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
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 wit
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 to
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
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
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
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/cont
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
> i
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 su
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
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
> - Packag
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, chin
[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 PROTECTE
Hallo!
> 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!
Sorry
On Nov 9, 2007 10:26 AM, Neil Jerram <[EMAIL PROTECTED]> wrote:
> 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
"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 pos
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
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 f
>> 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 somethin
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 someth
> 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 applicatio
Hello!
> Perhaps a wiki page would be the best method then. This discussion is getting
> rather long and confusing.
Such Wiki Page exists:
http://maemo.org/community/wiki/extrasrepositoryprocessdefinition/
I invite everybody to add, change etc...
> 1) Put all packages in the main repo and
> 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 l
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 applicati
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 w
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 rathe
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, I
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
> > st
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
> > s
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 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 detail
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
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 insta
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!
> 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
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 insta
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 op
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
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.
>
> May
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
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
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 i
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
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
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 plug
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.
Softwar
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
> just
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 uploadin
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
> >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).
I think that a lot should really "just" be automa
>> * 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 op
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 st
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 ba
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
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 exact
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
> u
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
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
>>
>> * 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.
>> 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
> " 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
>
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
> 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
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).
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 o
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 t
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://0i
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 d
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 ma
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 yo
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
2007/10/24, Neil Jerram <[EMAIL PROTECTED]>:
> Quim Gil <[EMAIL PROTECTED]> writes:
>
> 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 packa
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
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 ma
> 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
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 maint
> 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, a
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"
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 wit
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
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
T
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
84 matches
Mail list logo
