Active Topics
-
Is there a section to talk about Java ME? Apps, etc. (3)
to General by Kalatti - 14 hrs, 7 mins ago - more...
| The Following 3 Users Say Thank You to X-Fade For This Useful Post: | ||
|
2009-07-29
, 14:33
|
|
Posts: 152 |
Thanked: 620 times |
Joined on Mar 2008
@ Netherlands
|
#12
|
Originally Posted by qgil
I think we should not show any app which is not in Extras (or equivalent) in Downloads. Downloads should in my point of view be for end-user level users. Having packages from various repositories is the road to pain.
Let me elaborate a bit more:
- A developer is just playing with some packages in extras-devel: no Downloads page.
- A developer thinks the app is in a shape good enough to be promoted to -testing: Page created with Alpha label.
- An app makes it to extras-testing, ideally the page would be automatically updated to Beta within a week. Otherwise the change would be made manually.
- An apps makes it to Extras, ideally geta automatically updated to Stable quality. Otherwise the change is done manually.
Keep in mind that Downloads clicks automatically get an .install and thus can enable these unstable repositories.
The reason why I haven't enabled Downloads for Fremantle yet, is because there are no packages in Fremantle Extras yet.
We should market the extras-testing queue for community testers and developers, but really keep this separate from what end-users see. The testing queue has commenting and favouriting, so even if there is no central bugtracker, people can leave their comments about the package there.
__________________
http://maemo.org/profile/view/xfade/ - maemo.org webmaster Apps.formeego.org (Apps for N9)
http://maemo.org/profile/view/xfade/ - maemo.org webmaster Apps.formeego.org (Apps for N9)
 |
|
2009-07-29
, 14:54
|
|
Posts: 3,105 |
Thanked: 11,088 times |
Joined on Jul 2007
@ Mountain View (CA, USA)
|
#13
|
Originally Posted by X-Fade
True, true, true!
I think we should not show any app which is not in Extras (or equivalent) in Downloads. Downloads should in my point of view be for end-user level users. Having packages from various repositories is the road to pain.
That was proposed when someone like me could not dream of pages like http://maemo.org/packages/view/bluemaemo/
Let's drop then the criteria of having a Downloads page. Good package description visible in the Application Manager is enough.
We will still need to find a way to check that an app willing to make it to Extras will have a proper Downloads page in place, but this belong to the discussion about promoting apps from -testing to Extras.
 |
|
2009-07-29
, 15:04
|
|
Posts: 1,070 |
Thanked: 1,604 times |
Joined on Sep 2008
@ Helsinki
|
#14
|
Originally Posted by qgil
Just as a side note, this package won't work in Fremantle, this is the normal BlueMaemo version for Diablo, I think Jeremiah built and sent it to Fremantle extras-devel by mistake, and also a lot of the BlueMaemo dependencies aren't satisfied yet in Fremantle
True, true, true!
That was proposed when someone like me could not dream of pages like http://maemo.org/packages/view/bluemaemo/
(python-efl), seems that the builder don't check for the dependencies in the right place, don't know if this is already fixed.
|
|
2009-07-29
, 16:09
|
|
Posts: 605 |
Thanked: 137 times |
Joined on Nov 2005
@ La Rochelle, France
|
#15
|
trying to promote package but cannot do it because it depends on a user package that should be promoted ... but I have promoted it ...
packages gnokii-gconf, libgnokii4-dev, libgnokii4
packages gnokii-gconf, libgnokii4-dev, libgnokii4
|
|
2009-07-29
, 21:01
|
|
Posts: 152 |
Thanked: 620 times |
Joined on Mar 2008
@ Netherlands
|
#16
|
Originally Posted by fredoll
This is because I need to run the first few promotions manually, so I can see if everything goes the way it is supposed to go. The promotion and dependency checking code I wrote is quite large and complex, problems will probably only pop-up in real life testing. So please bear with me
trying to promote package but cannot do it because it depends on a user package that should be promoted ... but I have promoted it ...
packages gnokii-gconf, libgnokii4-dev, libgnokii4
Oh, btw. Please don't put libraries as section(category) user/*, gnokii seems to do that. End-users should not have to see the lib in their AM.
__________________
http://maemo.org/profile/view/xfade/ - maemo.org webmaster Apps.formeego.org (Apps for N9)
http://maemo.org/profile/view/xfade/ - maemo.org webmaster Apps.formeego.org (Apps for N9)
 |
|
2009-07-29
, 21:21
|
|
Posts: 2,535 |
Thanked: 6,681 times |
Joined on Mar 2008
@ UK
|
#17
|
Originally Posted by qgil
Apart from the earlier comments about difficulties in getting any app stabilised enough, I think there are three things necessary:
Let me say BIG THANK YOU to Jeremiah, Niels and whoever else has been involved in the development of the maemo.org packages interface - http://communitizer.blogspot.com/200...-packages.html
Now... let's have a look to the queue of apps that have been pushed from extras-devel to extras-testing:
http://maemo.org/packages/repository...ng_free_armel/
Zero! OK, makes sense. How do we get started, though?
- Clearer communication on what's required from app authors (there's a process doc which is the output of the earlier task. Not directly suitable for package maintainers.
- Technology in place (maemian etc.) to do some basic automated checks (big warnings which have to be specifically overruled for any lib* package in section: user/..., for example)
- Instructions for how to promote when you want to.
The last point is particularly important: I just went to my package and couldn't see a "Promote" button anywhere; despite looking.
Of course, with a bit of thought, it's obvious I have to promote an individual version - but then I have to promote the armel & x86 versions separately: a step back from the earlier extras-devel -> extras promotion interface, IMHO.
I think it's likely a developer will want to promote all the architectures, and OS versions, for the latest version of a package. Perhaps some kind of checkbox & promote button on a package; or a "Promote latest" button would help?
So what about starting the process of developers pushing the packages that they think are ready to extras-testing?
__________________
Andrew Flegg -- mailto:andrew@bleb.org | http://www.bleb.org
Andrew Flegg -- mailto:andrew@bleb.org | http://www.bleb.org
|
|
2009-07-30
, 07:24
|
|
Posts: 152 |
Thanked: 620 times |
Joined on Mar 2008
@ Netherlands
|
#18
|
Originally Posted by Jaffa
Agreed, I could really use some help on this part. I spent and am still spending a lot of hours on getting all related scripts/services into shape, so I didn't have time to write up any documentation yet. Or even start a discusssion...
Apart from the earlier comments about difficulties in getting any app stabilised enough, I think there are three things necessary:
- Clearer communication on what's required from app authors (there's a process doc which is the output of the earlier task. Not directly suitable for package maintainers.
- Technology in place (maemian etc.) to do some basic automated checks (big warnings which have to be specifically overruled for any lib* package in section: user/..., for example)
- Instructions for how to promote when you want to.
Originally Posted by Jaffa
When promotion is requested for the armel version for instance, we will promote the related source and i386 packages at the same time. This obviously needs to be documented. When I remove the manual step of promotion, you will see that the other package will be updated at the same time.
The last point is particularly important: I just went to my package and couldn't see a "Promote" button anywhere; despite looking.
Of course, with a bit of thought, it's obvious I have to promote an individual version - but then I have to promote the armel & x86 versions separately: a step back from the earlier extras-devel -> extras promotion interface, IMHO.
The promotion link actually only shows when all conditions for a package instance have been satisfied. This means that currently all dependencies must be available and you are maintainer of the package (and when in testing, karma value must be > 5). This way we prevent accidental promotions and also prevent packages with missing dependencies from entering the repository.
__________________
http://maemo.org/profile/view/xfade/ - maemo.org webmaster Apps.formeego.org (Apps for N9)
http://maemo.org/profile/view/xfade/ - maemo.org webmaster Apps.formeego.org (Apps for N9)
|
|
2009-07-30
, 09:12
|
|
Posts: 605 |
Thanked: 137 times |
Joined on Nov 2005
@ La Rochelle, France
|
#19
|
Originally Posted by X-Fade
No problemo, thanks for the good work
This is because I need to run the first few promotions manually, so I can see if everything goes the way it is supposed to go. The promotion and dependency checking code I wrote is quite large and complex, problems will probably only pop-up in real life testing. So please bear with me
I thought I'll try to promote just to help test the process so here you are
Originally Posted by X-Fade
You're right : I changed it
Oh, btw. Please don't put libraries as section(category) user/*, gnokii seems to do that. End-users should not have to see the lib in their AM.
|
|
2009-07-30
, 10:07
|
|
Posts: 152 |
Thanked: 620 times |
Joined on Mar 2008
@ Netherlands
|
#20
|
Originally Posted by fredoll
I've added a check + warning to prevent this now:
No problemo, thanks for the good work
I thought I'll try to promote just to help test the process so here you are
You're right : I changed it
http://maemo.org/packages/package_in...6.28cvs-maemo2
I will remove the first promotion from the queue manually, so you can promote the proper one.
__________________
http://maemo.org/profile/view/xfade/ - maemo.org webmaster Apps.formeego.org (Apps for N9)
http://maemo.org/profile/view/xfade/ - maemo.org webmaster Apps.formeego.org (Apps for N9)
| The Following User Says Thank You to X-Fade For This Useful Post: | ||
PS. It is Fremantle and Niels
http://maemo.org/profile/view/xfade/ - maemo.org webmaster Apps.formeego.org (Apps for N9)