Re: "Opt-in" betas in the Application Manager (was Re: Application Manager and Extras-devel: Dealing with unstable software)
On Sat, Feb 7, 2009 at 6:17 AM, Ryan Abel wrote: > On Jan 23, 2009, at 12:05 PM, Guillem Jover wrote: > >> And this is already solved in Debian, by just marking experimental as >> to not be used to automatically upgrade packages from there. Apt will >> pin it down to priority 1, while unstable has normally priority 500. >> The only needed thing is to add an "NotAutomatic: yes" field in the >> Release file for experimental. > > OK, this is good (yet again betraying my ignorance of proper > Debian ;)), now, how should this be implement in the Application > Manager? Assuming the version of apt in Maemo supports "NotAutomatic: yes" - and that App Mgr leaves all the available upgrade decisions to apt (I can't remember having looked at that bit of code yet, I *think* it does), it should just be a case of adding the "NotAutomatic: yes" to: http://repository.maemo.org/extras-devel/dists/diablo/Release I'm not sure if this alone results in apt pinning it at 1, or whether we'll therefore need another trick (a default /etc/apt/preferences would do) to reduce it's priority. There'll also need to be some testing to see what happens in the App Mgr's package view when there are two versions available to install, and the lower priority version is higher. It might make assumptions which override apt. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ Maemo Community Council member ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
"Opt-in" betas in the Application Manager (was Re: Application Manager and Extras-devel: Dealing with unstable software)
On Jan 23, 2009, at 12:05 PM, Guillem Jover wrote:
>> Those issues aside, what can we do at an application level to improve
>> the user experience here? An opt-in system for Extras-devel updates
>> and installs might be useful (rather than offering the Extras-devel
>> version, the user has to request it specifically), visual cues to a
>> packages origin (color coding, a small icon) and notices might also
>> help ("this package is unstable software, and may contain many
>> significant bugs, are you sure you want to install it?"), or even
>> some
>> sort of apt pinning system to ignore certain updates.
>
> And this is already solved in Debian, by just marking experimental as
> to not be used to automatically upgrade packages from there. Apt will
> pin it down to priority 1, while unstable has normally priority 500.
> The only needed thing is to add an “NotAutomatic: yes” field in the
> Release file for experimental.
>
> So, with this, one can select to upgrade to a specific version from
> experimental, but this needs to be explicit. Otherwise no other
> package
> will be upgraded from there.
OK, this is good (yet again betraying my ignorance of proper
Debian ;)), now, how should this be implement in the Application
Manager?
(Related, I've filled http://bugs.maemo.org/show_bug.cgi?id=4081 for
ignoring specific updates)
--
Ryan Abel
Maemo Community Council chair
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application Manager and Extras-devel: Dealing with unstable software
Hi,
On Tue, 2008-11-25 at 16:38:08 -0500, ext Ryan Abel wrote:
> Let's say you've got a user, and this user wants to get to something
> shiny, but the only place this something shiny is available is from an
> unstable testing repository. Normally this unstable testing repository
> would not be the sort of place this user would venture into, but the
> application is only there because a few minor packaging issues have to
> be wrapped up (maybe the l10n is split up into a bunch of separate
> packages); or there's just a few more bugs they want to stomp out; or
> they want to give it a week or two of testing before they push it to
> the unstable repository--whatever, so the user decides (perhaps with
> the encouragement of some of their peers) to dive in, add the unstable
> repository and install the application.
[ Long description of highly unstable repostory usage removed. ]
This is what in Debian is called «experimental».
> Those issues aside, what can we do at an application level to improve
> the user experience here? An opt-in system for Extras-devel updates
> and installs might be useful (rather than offering the Extras-devel
> version, the user has to request it specifically), visual cues to a
> packages origin (color coding, a small icon) and notices might also
> help ("this package is unstable software, and may contain many
> significant bugs, are you sure you want to install it?"), or even some
> sort of apt pinning system to ignore certain updates.
And this is already solved in Debian, by just marking experimental as
to not be used to automatically upgrade packages from there. Apt will
pin it down to priority 1, while unstable has normally priority 500.
The only needed thing is to add an “NotAutomatic: yes” field in the
Release file for experimental.
So, with this, one can select to upgrade to a specific version from
experimental, but this needs to be explicit. Otherwise no other package
will be upgraded from there.
regards,
guillem
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application Manager and Extras-devel: Dealing with unstable software
Perhaps easy regular backups and an SD install be good enough for most "shiny new stuff, oops." gary liquid wrote: > Graham > > seems reasonable enough. > I just worry that testers are not as clear headed. > > gary > > On Tue, Dec 2, 2008 at 12:01 AM, Graham Cobb > <[EMAIL PROTECTED]<[EMAIL PROTECTED]> >> wrote: > >> On Wednesday 26 November 2008 18:34:17 gary liquid wrote: >> I don't agree. I, personally, run with extras-devel enabled all the time. >> But then I don't ever click on "Upgrade All" and I don't say "oh, a shiny >> new >> version of Canola -- must upgrade". However, when I install something new >> it >> often comes from extras-devel, and I do upgrade things sometimes (because I >> want the upgrade, or it has been around a while, or I suspect that it might >> interact in some important way with one of my apps). >> >> For beta releases, I announce them on ITT and I tell beta testers to >> temporarily set up extras-devel in order to load the upgrade, and then >> disable it again. >> >> Basically, I hope and expect developers to run with extras-devel enabled -- >> it >> helps us all if we are each keeping reasonably up to date with each others >> apps (and, hopefully, finding interaction problems before our users do). >> >> And I expect power users to have extras-devel configured (because they have >> participated in someone's beta test) but disabled (so they don't pick up >> stuff by mistake). >> >> Graham >> ___ >> maemo-developers mailing list >> maemo-developers@maemo.org >> https://lists.maemo.org/mailman/listinfo/maemo-developers >> > > > > > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application Manager and Extras-devel: Dealing with unstable software
Graham seems reasonable enough. I just worry that testers are not as clear headed. gary On Tue, Dec 2, 2008 at 12:01 AM, Graham Cobb <[EMAIL PROTECTED]<[EMAIL PROTECTED]> > wrote: > On Wednesday 26 November 2008 18:34:17 gary liquid wrote: > > i don't think I follow with this extremely limited -devel testing cycle > > route, especially since *anyone* (even seasoned professionals) who > connect > > to -devel at this point for however short a period run the overriding > risk > > of screwing up their system. > > I don't agree. I, personally, run with extras-devel enabled all the time. > But then I don't ever click on "Upgrade All" and I don't say "oh, a shiny > new > version of Canola -- must upgrade". However, when I install something new > it > often comes from extras-devel, and I do upgrade things sometimes (because I > want the upgrade, or it has been around a while, or I suspect that it might > interact in some important way with one of my apps). > > For beta releases, I announce them on ITT and I tell beta testers to > temporarily set up extras-devel in order to load the upgrade, and then > disable it again. > > Basically, I hope and expect developers to run with extras-devel enabled -- > it > helps us all if we are each keeping reasonably up to date with each others > apps (and, hopefully, finding interaction problems before our users do). > > And I expect power users to have extras-devel configured (because they have > participated in someone's beta test) but disabled (so they don't pick up > stuff by mistake). > > Graham > ___ > maemo-developers mailing list > maemo-developers@maemo.org > https://lists.maemo.org/mailman/listinfo/maemo-developers > ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application Manager and Extras-devel: Dealing with unstable software
On Wednesday 26 November 2008 18:34:17 gary liquid wrote: > i don't think I follow with this extremely limited -devel testing cycle > route, especially since *anyone* (even seasoned professionals) who connect > to -devel at this point for however short a period run the overriding risk > of screwing up their system. I don't agree. I, personally, run with extras-devel enabled all the time. But then I don't ever click on "Upgrade All" and I don't say "oh, a shiny new version of Canola -- must upgrade". However, when I install something new it often comes from extras-devel, and I do upgrade things sometimes (because I want the upgrade, or it has been around a while, or I suspect that it might interact in some important way with one of my apps). For beta releases, I announce them on ITT and I tell beta testers to temporarily set up extras-devel in order to load the upgrade, and then disable it again. Basically, I hope and expect developers to run with extras-devel enabled -- it helps us all if we are each keeping reasonably up to date with each others apps (and, hopefully, finding interaction problems before our users do). And I expect power users to have extras-devel configured (because they have participated in someone's beta test) but disabled (so they don't pick up stuff by mistake). Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application Manager and Extras-devel: Dealing with unstable software
> The user has the options: > > 1. Wait until it is officially promoted to Extras > > 2. Learn to deal with having Extras-Devel active (maybe a FAQ or HOWTO > > would help) > > 3. Blow themselves up. > > So, basically, your solution is 'do nothing because people should know > better'? It doesn't matter what you tell people, they'll leave it enabled > anyway. > > Why WOULDN'T you do something if there's a reasonably simple software > solution? Because there is no reasonably simple software solution. Extras-devel is already for unstable beta. But it has to be complete (e.g. if I have the main user stuff plus dependent libraries or utilities). Trying to make it both a real repository and not-a-real repository at the same time isn't simple. Even if you do something like this, users will turn on, or ignore, or whatever it takes to bypass the safeties to get to the shiny bit of unstable code. Putting extra layers simply impedes those who know what they are doing. If the solution is simple and easy, it is simply and easily bypassed which is the current problem (and changing infrastructure and programs is usually not as simple as advertised and I have a large list of things which should be addressed first). If the solution makes things hard or tedious, it does so for everyone. If it isn't something very close to userland (e.g. another "red-pill mode), it won't be a valid test of loadability. Even now it isn't trivial to add extras-devel. Another theoretical way is one repository per project or group or whatever (which is probably worse - e.g. when updating python-runtime, you need all those packages in one place). extras-devel-myproject, extras-devel-yourproject... Each with their own packages, subdirectories... But again, you're getting away from using the Application Manager much as the user would use it and creating a special, safe, developer-only mode. So things will work after the special unlocks and the DANGER! confirmation dialogs, but not when promoted to Extras. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application Manager and Extras-devel: Dealing with unstable software
"ext gary liquid" <[EMAIL PROTECTED]> writes:
> i don't think I follow with this extremely limited -devel testing
> cycle route, especially since *anyone* (even seasoned professionals)
> who connect to -devel at this point for however short a period run the
> overriding risk of screwing up their system.
Looking from the outside, and again judging from the way extras-devel is
setup, I would expect extras-devel to contain packages of high quality
that only rarely cause trouble. Otherwise, extras-devel loses its value
as a testing ground because nobody uses it regularily.
This is the problem that Ryan has brought up, and I think the answer is
that extras-devel must be of sufficient quality that enough people
(roughly the same that are subscribed here) feel confident to use it
instead of extras.
The difference between extras-devel and extras is the difference between
I-think-it's-good-because-it-works-perfectly-for-me and
I-am-quite-sure-it's-good-because-some-hundred-people-didn't-have-any-problems-with-it.
In my view, at least.
> If I push it via -devel at this point a seasoned professional
> developer can screw up his system with one idle update ("oh cool, new
> canola").
This would be the core of the problem, I'd say. There really
shouldn't be anything lingering in extras-devel that is known to kill
people's systems.
If you put something into extras-devel that turns out to cause problems,
you need to fix it "immediately".
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application Manager and Extras-devel: Dealing with unstable software
- Original message - First, I assume you mean before pushing it into the STABLE repository. No. Extras-Devel is for betas, unstable, and things which aren't ready for the general user to access. If I have something there I usually if not always leave a note to TURN THE REPOSITORY OFF after grabbing my code or doing any updates. Trying to recurse to extras-devel-devel extras-devel-devel-devel by other names is not going to help. If bleeding edge user is not willing to wait one or two weeks for the software to be promoted to extras and is not willing to invest the time and effort of dealing with active pre-release repositories (consider MS service pack betas or Ubuntu alphas or nonstandard updates) there is nothing reasonable to be done. Extras-devel is already a safety system, and an effective one when used properly. The user has the options: 1. Wait until it is officially promoted to Extras 2. Learn to deal with having Extras-Devel active (maybe a FAQ or HOWTO would help) 3. Blow themselves up. So, basically, your solution is 'do nothing because people should know better'? It doesn't matter what you tell people, they'll leave it enabled anyway. Why WOULDN'T you do something if there's a reasonably simple software solution?___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application Manager and Extras-devel: Dealing with unstable software
First, I assume you mean before pushing it into the STABLE repository. No. Extras-Devel is for betas, unstable, and things which aren't ready for the general user to access. If I have something there I usually if not always leave a note to TURN THE REPOSITORY OFF after grabbing my code or doing any updates. Trying to recurse to extras-devel-devel extras-devel-devel-devel by other names is not going to help. If bleeding edge user is not willing to wait one or two weeks for the software to be promoted to extras and is not willing to invest the time and effort of dealing with active pre-release repositories (consider MS service pack betas or Ubuntu alphas or nonstandard updates) there is nothing reasonable to be done. Extras-devel is already a safety system, and an effective one when used properly. The user has the options: 1. Wait until it is officially promoted to Extras 2. Learn to deal with having Extras-Devel active (maybe a FAQ or HOWTO would help) 3. Blow themselves up. On Tue, Nov 25, 2008 at 3:38 PM, Ryan Abel <[EMAIL PROTECTED]> wrote: > Let's say you've got a user, and this user wants to get to something > shiny, but the only place this something shiny is available is from an > unstable testing repository. Normally this unstable testing repository > would not be the sort of place this user would venture into, but the > application is only there because a few minor packaging issues have to > be wrapped up (maybe the l10n is split up into a bunch of separate > packages); or there's just a few more bugs they want to stomp out; or > they want to give it a week or two of testing before they push it to > the >>>unstable<<< repository--whatever, so the user decides (perhaps with > the encouragement of some of their peers) to dive in, add the unstable > repository and install the application. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application Manager and Extras-devel: Dealing with unstable software
i don't think I follow with this extremely limited -devel testing cycle
route, especially since *anyone* (even seasoned professionals) who connect
to -devel at this point for however short a period run the overriding risk
of screwing up their system.
we are trying to find a way for best of both worlds so developers don't have
extra work and extremely important testers don't screwup their systems
trying to follow the open source ethos (early/often)
Bringing this closer to home for me I am now confused about which direction
I should go for testing the next iteration of liqbase.
Even if I release an incremental version I would want a solid period of
testing and it will go through many iterations between first public call for
assistance and actually promoting it (build numbers skyrocket as tweaks and
modifications are made according to all important feedback).
There are a core set of users who are happy to install and test and
reinstall my application and understand that problems may occur with this
application alone, but those same users would not expect to be beta testing
every application in -devel.
If I push it via -devel at this point a seasoned professional developer can
screw up his system with one idle update ("oh cool, new canola").
This would not be a problem with my own private repository, but I do not
want to go down this route.
If we could whitelist -devel so that the user says "i would like to test
liqbase" it removes this problem and developers and betatesters alike
continue as they were before but without having complexities of multiple
updated applications.
gary
On Wed, Nov 26, 2008 at 6:07 PM, Marius Vollmer <[EMAIL PROTECTED]>wrote:
> "ext gary liquid" <[EMAIL PROTECTED]> writes:
>
> > [ beta versions in their own repo ]
> > this worked nicely for a large number of applications but its major
> > disadvantages were dependencies and bitrot.
>
> Yes, this is the "repository mess" situation. I'd say it is not an
> option for the reasons you state.
>
> > as a maemo developer I cannot easily compile other peoples packages from
> > source.
>
> Yes, this is the "distribution mess" (or "SDK mess") that we haven't
> seriously attacked yet, but we should.
>
> > The point of testing is also testing the package itself, if a
> > developer has to create 2 distinct packages, one for testing and one
> > for real how does the developer test that his live package includes
> > everything required and installs and uninstalls cleanly?
>
> There are two kinds of testing: the beta testing over a long period with
> selected users, maybe even while new features are implemented, and the
> smoke testing of new stable releases that is mostly a sanity check
> before your package hits Joe Sixpack.
>
> Extras-devel is good for smoke testing of new releases. You are sure
> that the package works for you, but you would like wider exposure to
> test it in more environments.
>
> > The only real way to ensure its valid is to allow a user to beta-test
> > the actual package.
>
> You don't need to redo your packaging when moving out of beta if you
> plan for this. Thus, instead of naming it "foo-beta", you can name it
> "foo-2". This means that the betaness of your package should be
> signalled in some other way, via the description, its category, the
> icon, or maybe with a new feature of the Application manager.
>
> If you do want to redo the packaging, you can use the smoke test in
> extras-devel to catch bugs introduced by it. At that point, you really
> have stopped releasing updates to the old stable version, and there is
> no problem if the new stable version stays in extras-devel a bit longer
> to iron out the kinks introduced by the renaming.
>
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Fwd: Application Manager and Extras-devel: Dealing with unstable software
"ext gary liquid" <[EMAIL PROTECTED]> writes: > what follows is the mails between myself and Marius, sorry for the confusion: And this is my reply to Gary's last mail: > [ beta versions in their own repo ] > this worked nicely for a large number of applications but its major > disadvantages were dependencies and bitrot. Yes, this is the "repository mess" situation. I'd say it is not an option for the reasons you state. > as a maemo developer I cannot easily compile other peoples packages from > source. Yes, this is the "distribution mess" (or "SDK mess") that we haven't seriously attacked yet, but we should. > The point of testing is also testing the package itself, if a > developer has to create 2 distinct packages, one for testing and one > for real how does the developer test that his live package includes > everything required and installs and uninstalls cleanly? There are two kinds of testing: the beta testing over a long period with selected users, maybe even while new features are implemented, and the smoke testing of new stable releases that is mostly a sanity check before your package hits Joe Sixpack. Extras-devel is good for smoke testing of new releases. You are sure that the package works for you, but you would like wider exposure to test it in more environments. > The only real way to ensure its valid is to allow a user to beta-test > the actual package. You don't need to redo your packaging when moving out of beta if you plan for this. Thus, instead of naming it "foo-beta", you can name it "foo-2". This means that the betaness of your package should be signalled in some other way, via the description, its category, the icon, or maybe with a new feature of the Application manager. If you do want to redo the packaging, you can use the smoke test in extras-devel to catch bugs introduced by it. At that point, you really have stopped releasing updates to the old stable version, and there is no problem if the new stable version stays in extras-devel a bit longer to iron out the kinks introduced by the renaming. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Fwd: Application Manager and Extras-devel: Dealing with unstable software
hmmm, I inadvertently sent mails directly to Marius instead of to the list by default. I had intended to send them via the ML in general. what follows is the mails between myself and Marius, sorry for the confusion: # marius, what a lot of work, people have been developing and beta testers have been using those development packages in private repositories for years now. You are right that users on desktop systems might be more willing to undertake a configure/make/make install cycle from source because everything is ready and prepared on their device. on maemo this simply isnt the case and the number of people with active stable development environments is a LOT less than the number of people willing to test out and report back on software. in the past this wasnt a problem, because a developer could ask users to come onboard their private repository (like repository.liqbase.net - fake doesnt exist yet) and test a packaged version of an app without conflicting with canola or xournal or anything else. Now, we have been nicely asked to close these private repositories and now its indicated for us to make a complete brainfuck of a sidestep and force willing participants to either completely install scratchbox and mess their head up doing stuff, or we lose their valuable assistance. i think thats unacceptable and we need to find a way to allow best of both worlds, I respect and value the help of any beta testers and we want to make life easy for them to get involved. gary (lcuk on #maemo) # "ext gary liquid" <[EMAIL PROTECTED]> writes: > [...] and now its indicated for us to make a complete brainfuck of a > sidestep and force willing participants to either completely install > scratchbox and mess their head up doing stuff, or we lose their > valuable assistance. That's not what I was proposing. It's just one of the options. In order of increasing work for the developer: - Let users compile the devel branch from source (Wont work for Maemo applications, but maybe for libraries) - Make separate packages for the devel branch that replace the packages from the stable branch (The sweet spot for Maemo, I'd say) - Make separate packages for the devel branch that can be installed and used in parallel with the packages from the stable branch (Lot's of trouble for little gain in a single user system) There is also: - Stop releasing stable versions until the devel branch is released as stable (Not nice for users of your stable version and has all the problems that Ryan mentioned in his original mail) > i think thats unacceptable and we need to find a way to allow best of both > worlds, I respect and value the help of any beta testers and we want to make > life easy for them to get involved. I think the sweet spot mentioned above is it. I didn't say that clearly because I wanted people to make up their own minds about the relative merits. Let's discuss this on the list. # agreed marius, but the fact remains that until recently the accepted way for a developer to allow beta testers to come on board was to build their standard package as they do anyway and have it available on their own personal repository, the only work for a beta tester was clicking an .install file or updating from h-a-m. this worked nicely for a large number of applications but its major disadvantages were dependencies and bitrot. as a maemo developer I cannot easily compile other peoples packages from source. I build and compile on the 810 itself and whilst it works perfectly for me, it does not include ./configure so most packages are not available to me. I have got scratchbox locked away on a rarely touched vmware image, its possible for me to dig it out whenever i hear aobut an update, but certainly not practical. The point of testing is also testing the package itself, if a developer has to create 2 distinct packages, one for testing and one for real how does the developer test that his live package includes everything required and installs and uninstalls cleanly? The only real way to ensure its valid is to allow a user to beta-test the actual package. quite simply, if we cannot use -devel to allow beta testers to test our actual software why are we recommending developers use it? gary ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application Manager and Extras-devel: Dealing with unstable software
"ext gary liquid" <[EMAIL PROTECTED]> writes: > If I *choose* to get involved in the xournal beta testing and want to > obtain it from -devel this should not effect the testing status of > other applications which I am not focusing upon nor testing. As far as I understand it from the way it is set up, extras-devel is the staging area for extras, it is not the place to for long running beta testing or wild experiments. If you upload a version of a package to extras-devel that will not be good enough to be promoted to extras for a long time, you have cut off your users from updates to your package for that long time. That's not good. Thus, if you have two branches of your software: a released one that gets updated from time to time with bug fixes, and a development one where new features are implemented, then extras and extras-devel would _both_ contain the released branch. When a update comes out for the released branch, it first enters extras-devel, and is promoted to extras after a short time. I would expect that everybody subscribed to maemo-developers is using extras-devel, not extras. A package should only stay a short time in extras-devel, say a week or two, so that people here have a chance to catch new bugs. In other words, packages should probably be promoted to extras automatically unless someone explicitly blocks them. Now, where should the development branch go? The development branch might not be distributed as packages at all, and everybody who wants to check it out has to get the source and compile it him/herself. This is not unreasonable, especially for libraries. Most of Open Source is developed this way; GNOME is only packaged for Debian once it is released, AFAIK. (Foresight might package the unreleased GNOME development platform, but that would be an exception.) If you do want to package your development branch, you should do it so that the resulting packages can be installed in parallel with the packages from the released branch. Then people opt-in to your beta testing by installing the development packages. Making two versions of a library or program installable and useable at the same time requires some non-trivial extra work and adds complexity to your software in general. But it might be worth doing. If you don't want to do that extra work, you should still produce a second set of packages for your development branch, but make them conflict with the ones from the release branch. Then opting-in to your beta test means stopping to use the released version. People can still opt-out by uninstalling the development version and installing the released version instead. If you have packages for your development version, they can be released via extras-devel and extras like any other package. They need to be clearly labeled as a "beta version" or similar. Putting this into the name might be enough, or the Application manager could help with that by using different colors for different kinds of packages. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application Manager and Extras-devel: Dealing with unstable software
>> what can we do to protect users from the full fury of Extras-devel >> while still giving them reasonable access to some of the stabler >> applications in the repository? > > Another ugly trick would be to have dynamic repositories. There be dragons, similarly with a package "whitelist" for extras devel. By adding another layer of abstraction which is outside of the user's control you're asking for additional confusion when a package that someone wants is "masked out" by some other package's whitelist/dynamic repo function. If we really want to do this "right", look at how Smart Package Manager [1] handles multiple repositories. It uses a combination of: - Repository labeling while browsing for packages, so that when you're looking at a package you might want to install, you know where it's coming from. - Repository preference weights to ensure that packages are always preferred from your stable core repository, even if newer packages are available from less preferred repos. - Package by package preference weights, to ensure that you can resolve any corner cases that arise in repository preferences. - Package pinning, so you can just lock something down from changing if you've got a stable combo for a tricky set of packages. Because App Manager currently deals with a small number of packages (compared to most of the desktop distros, anyway), I think we could get away with simply labeling the repository source in the various package views (but especially the upgrade view) and simply leveraging App Manager's existing capability to upgrade packages one at a time to allow users to pick and choose which ones they want. The Alpha/Beta color scheme could add additional context as to how stable users should expect a package to be, as long as the debtags were compatible with upstream. Thanks, Mike Lococo [1] http://labix.org/smart ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application Manager and Extras-devel: Dealing with unstable software
On Nov 26, 2008, at 5:00 AM, Sarah Newman wrote: > Disclaimer: I have little practice with pinning packages. If Maemo > doesn't support this feature from Debian (haven't tried it yet,) then > maybe it should. It does, it just lacks UI support in h-a-m. -- Ryan Abel Maemo Community Council chair ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application Manager and Extras-devel: Dealing with unstable software
Hi, Disclaimer: I have little practice with pinning packages. If Maemo doesn't support this feature from Debian (haven't tried it yet,) then maybe it should. It seems to me that explicitly installed packages from extras-devel could be pinned at a higher priority than extras. The extras repository could have a priority of 1001 - high enough to downgrade installed pacakges. extras-devel has some lower priority. When downgrading from extras-devel to extras, remove the pin on the extras-devel version and reinstall. By default, when installing or upgrading packages, they should come from extras and not extras-devel since extras has a higher priority. Unfortunately I don't know what apt will do with the dependencies of the explicitly pinned extras-devel packages. Might try this in scratchbox later and see what happens. Presumably there would be another screen in AM with a list of pinned packages, what they were pinned to, and the option to remove the pin. References: http://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html http://wiki.debian.org/AptPinning http://debian-book-bg.openfmi.net/queue/apt-pinning.html gary liquid wrote: > i do not think there is ever a perfect way for anything. > there are many points which intersect and by discussion we will find that > common ground :) > > using the .install file to opt-in to a testing program is great, > opting back out is trickier, it would have to be something on the update > information screen itself. > > there is also the problem with dependencies, but they could be handled in a > similar manner. > > gary ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application Manager and Extras-devel: Dealing with unstable software
On Tue, Nov 25, 2008 at 11:46 PM, gary liquid <[EMAIL PROTECTED]> wrote: > i do not think there is ever a perfect way for anything. > there are many points which intersect and by discussion we will find that > common ground :) Another ugly trick (hey, it's what I'm good at, coming up with dirty ideas) would be to have dynamic repositories. Now I know, it sounds crazy, just bear with me. This would only require server side scripting (mostly), and would allow for content updates directly to the end user, without having to manually check for the .install files. The way I see it, user lambda wants to see what's flying in the latest version of xournal, he adds the -devel repository for xournal. He gets the updates, no problems with dependencies (provided they are available from his current list of repositories). In case he wants to go back to the stable version, he simply removes the -devel repository, and after a refresh, his tablet is stable again. Obviously, most users would only use the standard Maemo repository, the "dynamic" repositories only need to be updated when a package goes through one of the builders, and can be part of the compilation process. This does impose as constraint that each and every package will have its own repository, unless we make the builders "project aware", so that a specific project can tag multiple packages to be part of one single repository. Hey, I warned you, I'm dirty. My 2p, S. -- question = ( to ) ? be : ! be; -- Wm. Shakespeare ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application Manager and Extras-devel: Dealing with unstable software
i do not think there is ever a perfect way for anything.
there are many points which intersect and by discussion we will find that
common ground :)
using the .install file to opt-in to a testing program is great,
opting back out is trickier, it would have to be something on the update
information screen itself.
there is also the problem with dependencies, but they could be handled in a
similar manner.
gary
On Tue, Nov 25, 2008 at 11:40 PM, Aniello Del Sorbo <[EMAIL PROTECTED]>wrote:
> This could be a way.
>
> One could also think about using a new keyword for the .install file, i.e.
> for ex. "stability_level = ", that can be set to:
>
> 0 "alpha" (marked red)
> 1 "beta" (marked yellow)
> 2 "stable" (marked green)
>
> And AM can be configured to show only levels from 0, from 1 or from 2
> (default).
>
> There are plenty of ways...
> Perhaps a mix of them hides the perfect solution.
>
> Aniello
>
>
> On Tue, Nov 25, 2008 at 11:22 PM, gary liquid <[EMAIL PROTECTED]> wrote:
>
>> There should be a whitelist of applications to use from -devel with a
>> method to add or select packages from within it.
>>
>> If I *choose* to get involved in the xournal beta testing and want to
>> obtain it from -devel this should not effect the testing status of other
>> applications which I am not focusing upon nor testing.
>>
>> This way only xournal will be listed as coming from -devel and nothing
>> else.
>>
>> If at a later date I also wish to test out another cool application I
>> could simply add that as well, but at no time would I get unexpected
>> dangerous updates.
>>
>> gary (lcuk on #maemo)
>>
>> On Tue, Nov 25, 2008 at 11:04 PM, Aniello Del Sorbo <[EMAIL PROTECTED]>wrote:
>>
>>> Hi.
>>>
>>> There's no way to avoid developers setting up their own repositories if
>>> they want to do it for whatever
>>> reason they might have.
>>> Having a "temporary repository" flag or keyword in the install file,
>>> would help as these
>>> developers could use a .install file that adds the temporary
>>> repositories, install the application,
>>> then removes the repository.
>>>
>>> Also "external" repositories or application that comes from external
>>> ones, could be colored
>>> in yellow (warning), not installable ones (AM knows that) in red and
>>> installable ones (from known
>>> repositories) in green.
>>> An External repository can be anything that is not from Nokia and not
>>> from Maemo.
>>>
>>> I have my Xournal diablo alpha version in the Extras-devel since a long
>>> time now and I had many users
>>> that installed it as they found the update when another application
>>> required the extras-devel repository,
>>> added it and left it there.
>>>
>>> AM could also implement filters. Show All applications, Applications from
>>> known repositories, Applications
>>> from external repositories.
>>>
>>> Sorry for not exposing the ideas in a better way, too late and tired. :)
>>>
>>> Aniello
>>>
>>>
>>>
>>> On Tue, Nov 25, 2008 at 10:16 PM, Simon Pickering <
>>> [EMAIL PROTECTED]> wrote:
>>>
> the unstable repository--whatever, so the user decides (perhaps with
> the encouragement of some of their peers) to dive in, add the unstable
> repository and install the application.
Use an install file to install the application in question? Assuming
the application needs libraries which are contained in the
extras-devel repo, you'd need to temporarily enable that repo. My
feeling is that the repos enabled/added as part of install files
should be disabled immediately after the app in question has been
added in any case, so I suggest this change is made to the way
Application Manager handles the install files.
Would that achieve the desired goal? It would require that a list of
application install files are available (perhaps auto-generated from
the contents of the repo, or perhaps by the author in question?)
> packages origin (color coding, a small icon) and notices might also
> help ("this package is unstable software, and may contain many
> significant bugs, are you sure you want to install it?"), or even some
> sort of apt pinning system to ignore certain updates.
I also like the idea of flagging applications that come from somewhere
other than Extras, and I suppose it would be possible to have an
Updates section with Stable and Unstable candidates in it (or perhaps
allow updates to be sorted by their origin repo - and have Extras as
the default origin). But these are still more for power users, simply
disabling the repo immediately after use is imo a better bet for
unskilled "users".
Cheers,
Simon
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
>>>
>>>
>>>
>>> --
>>> anidel
>>>
>>>
Re: Application Manager and Extras-devel: Dealing with unstable software
This could be a way.
One could also think about using a new keyword for the .install file, i.e.
for ex. "stability_level = ", that can be set to:
0 "alpha" (marked red)
1 "beta" (marked yellow)
2 "stable" (marked green)
And AM can be configured to show only levels from 0, from 1 or from 2
(default).
There are plenty of ways...
Perhaps a mix of them hides the perfect solution.
Aniello
On Tue, Nov 25, 2008 at 11:22 PM, gary liquid <[EMAIL PROTECTED]> wrote:
> There should be a whitelist of applications to use from -devel with a
> method to add or select packages from within it.
>
> If I *choose* to get involved in the xournal beta testing and want to
> obtain it from -devel this should not effect the testing status of other
> applications which I am not focusing upon nor testing.
>
> This way only xournal will be listed as coming from -devel and nothing
> else.
>
> If at a later date I also wish to test out another cool application I could
> simply add that as well, but at no time would I get unexpected dangerous
> updates.
>
> gary (lcuk on #maemo)
>
> On Tue, Nov 25, 2008 at 11:04 PM, Aniello Del Sorbo <[EMAIL PROTECTED]>wrote:
>
>> Hi.
>>
>> There's no way to avoid developers setting up their own repositories if
>> they want to do it for whatever
>> reason they might have.
>> Having a "temporary repository" flag or keyword in the install file, would
>> help as these
>> developers could use a .install file that adds the temporary repositories,
>> install the application,
>> then removes the repository.
>>
>> Also "external" repositories or application that comes from external ones,
>> could be colored
>> in yellow (warning), not installable ones (AM knows that) in red and
>> installable ones (from known
>> repositories) in green.
>> An External repository can be anything that is not from Nokia and not from
>> Maemo.
>>
>> I have my Xournal diablo alpha version in the Extras-devel since a long
>> time now and I had many users
>> that installed it as they found the update when another application
>> required the extras-devel repository,
>> added it and left it there.
>>
>> AM could also implement filters. Show All applications, Applications from
>> known repositories, Applications
>> from external repositories.
>>
>> Sorry for not exposing the ideas in a better way, too late and tired. :)
>>
>> Aniello
>>
>>
>>
>> On Tue, Nov 25, 2008 at 10:16 PM, Simon Pickering <
>> [EMAIL PROTECTED]> wrote:
>>
>>>
>>> > the unstable repository--whatever, so the user decides (perhaps with
>>> > the encouragement of some of their peers) to dive in, add the unstable
>>> > repository and install the application.
>>>
>>> Use an install file to install the application in question? Assuming
>>> the application needs libraries which are contained in the
>>> extras-devel repo, you'd need to temporarily enable that repo. My
>>> feeling is that the repos enabled/added as part of install files
>>> should be disabled immediately after the app in question has been
>>> added in any case, so I suggest this change is made to the way
>>> Application Manager handles the install files.
>>>
>>> Would that achieve the desired goal? It would require that a list of
>>> application install files are available (perhaps auto-generated from
>>> the contents of the repo, or perhaps by the author in question?)
>>>
>>> > packages origin (color coding, a small icon) and notices might also
>>> > help ("this package is unstable software, and may contain many
>>> > significant bugs, are you sure you want to install it?"), or even some
>>> > sort of apt pinning system to ignore certain updates.
>>>
>>> I also like the idea of flagging applications that come from somewhere
>>> other than Extras, and I suppose it would be possible to have an
>>> Updates section with Stable and Unstable candidates in it (or perhaps
>>> allow updates to be sorted by their origin repo - and have Extras as
>>> the default origin). But these are still more for power users, simply
>>> disabling the repo immediately after use is imo a better bet for
>>> unskilled "users".
>>>
>>> Cheers,
>>>
>>>
>>> Simon
>>>
>>>
>>> ___
>>> maemo-developers mailing list
>>> maemo-developers@maemo.org
>>> https://lists.maemo.org/mailman/listinfo/maemo-developers
>>>
>>
>>
>>
>> --
>> anidel
>>
>> ___
>> maemo-developers mailing list
>> maemo-developers@maemo.org
>> https://lists.maemo.org/mailman/listinfo/maemo-developers
>>
>>
>
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>
>
--
anidel
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application Manager and Extras-devel: Dealing with unstable software
There should be a whitelist of applications to use from -devel with a method
to add or select packages from within it.
If I *choose* to get involved in the xournal beta testing and want to obtain
it from -devel this should not effect the testing status of other
applications which I am not focusing upon nor testing.
This way only xournal will be listed as coming from -devel and nothing else.
If at a later date I also wish to test out another cool application I could
simply add that as well, but at no time would I get unexpected dangerous
updates.
gary (lcuk on #maemo)
On Tue, Nov 25, 2008 at 11:04 PM, Aniello Del Sorbo <[EMAIL PROTECTED]>wrote:
> Hi.
>
> There's no way to avoid developers setting up their own repositories if
> they want to do it for whatever
> reason they might have.
> Having a "temporary repository" flag or keyword in the install file, would
> help as these
> developers could use a .install file that adds the temporary repositories,
> install the application,
> then removes the repository.
>
> Also "external" repositories or application that comes from external ones,
> could be colored
> in yellow (warning), not installable ones (AM knows that) in red and
> installable ones (from known
> repositories) in green.
> An External repository can be anything that is not from Nokia and not from
> Maemo.
>
> I have my Xournal diablo alpha version in the Extras-devel since a long
> time now and I had many users
> that installed it as they found the update when another application
> required the extras-devel repository,
> added it and left it there.
>
> AM could also implement filters. Show All applications, Applications from
> known repositories, Applications
> from external repositories.
>
> Sorry for not exposing the ideas in a better way, too late and tired. :)
>
> Aniello
>
>
>
> On Tue, Nov 25, 2008 at 10:16 PM, Simon Pickering <
> [EMAIL PROTECTED]> wrote:
>
>>
>> > the unstable repository--whatever, so the user decides (perhaps with
>> > the encouragement of some of their peers) to dive in, add the unstable
>> > repository and install the application.
>>
>> Use an install file to install the application in question? Assuming
>> the application needs libraries which are contained in the
>> extras-devel repo, you'd need to temporarily enable that repo. My
>> feeling is that the repos enabled/added as part of install files
>> should be disabled immediately after the app in question has been
>> added in any case, so I suggest this change is made to the way
>> Application Manager handles the install files.
>>
>> Would that achieve the desired goal? It would require that a list of
>> application install files are available (perhaps auto-generated from
>> the contents of the repo, or perhaps by the author in question?)
>>
>> > packages origin (color coding, a small icon) and notices might also
>> > help ("this package is unstable software, and may contain many
>> > significant bugs, are you sure you want to install it?"), or even some
>> > sort of apt pinning system to ignore certain updates.
>>
>> I also like the idea of flagging applications that come from somewhere
>> other than Extras, and I suppose it would be possible to have an
>> Updates section with Stable and Unstable candidates in it (or perhaps
>> allow updates to be sorted by their origin repo - and have Extras as
>> the default origin). But these are still more for power users, simply
>> disabling the repo immediately after use is imo a better bet for
>> unskilled "users".
>>
>> Cheers,
>>
>>
>> Simon
>>
>>
>> ___
>> maemo-developers mailing list
>> maemo-developers@maemo.org
>> https://lists.maemo.org/mailman/listinfo/maemo-developers
>>
>
>
>
> --
> anidel
>
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>
>
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application Manager and Extras-devel: Dealing with unstable software
Hi.
There's no way to avoid developers setting up their own repositories if they
want to do it for whatever
reason they might have.
Having a "temporary repository" flag or keyword in the install file, would
help as these
developers could use a .install file that adds the temporary repositories,
install the application,
then removes the repository.
Also "external" repositories or application that comes from external ones,
could be colored
in yellow (warning), not installable ones (AM knows that) in red and
installable ones (from known
repositories) in green.
An External repository can be anything that is not from Nokia and not from
Maemo.
I have my Xournal diablo alpha version in the Extras-devel since a long time
now and I had many users
that installed it as they found the update when another application required
the extras-devel repository,
added it and left it there.
AM could also implement filters. Show All applications, Applications from
known repositories, Applications
from external repositories.
Sorry for not exposing the ideas in a better way, too late and tired. :)
Aniello
On Tue, Nov 25, 2008 at 10:16 PM, Simon Pickering
<[EMAIL PROTECTED]>wrote:
>
> > the unstable repository--whatever, so the user decides (perhaps with
> > the encouragement of some of their peers) to dive in, add the unstable
> > repository and install the application.
>
> Use an install file to install the application in question? Assuming
> the application needs libraries which are contained in the
> extras-devel repo, you'd need to temporarily enable that repo. My
> feeling is that the repos enabled/added as part of install files
> should be disabled immediately after the app in question has been
> added in any case, so I suggest this change is made to the way
> Application Manager handles the install files.
>
> Would that achieve the desired goal? It would require that a list of
> application install files are available (perhaps auto-generated from
> the contents of the repo, or perhaps by the author in question?)
>
> > packages origin (color coding, a small icon) and notices might also
> > help ("this package is unstable software, and may contain many
> > significant bugs, are you sure you want to install it?"), or even some
> > sort of apt pinning system to ignore certain updates.
>
> I also like the idea of flagging applications that come from somewhere
> other than Extras, and I suppose it would be possible to have an
> Updates section with Stable and Unstable candidates in it (or perhaps
> allow updates to be sorted by their origin repo - and have Extras as
> the default origin). But these are still more for power users, simply
> disabling the repo immediately after use is imo a better bet for
> unskilled "users".
>
> Cheers,
>
>
> Simon
>
>
> ___
> maemo-developers mailing list
> maemo-developers@maemo.org
> https://lists.maemo.org/mailman/listinfo/maemo-developers
>
--
anidel
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Application Manager and Extras-devel: Dealing with unstable software
> the unstable repository--whatever, so the user decides (perhaps with
> the encouragement of some of their peers) to dive in, add the unstable
> repository and install the application.
Use an install file to install the application in question? Assuming
the application needs libraries which are contained in the
extras-devel repo, you'd need to temporarily enable that repo. My
feeling is that the repos enabled/added as part of install files
should be disabled immediately after the app in question has been
added in any case, so I suggest this change is made to the way
Application Manager handles the install files.
Would that achieve the desired goal? It would require that a list of
application install files are available (perhaps auto-generated from
the contents of the repo, or perhaps by the author in question?)
> packages origin (color coding, a small icon) and notices might also
> help ("this package is unstable software, and may contain many
> significant bugs, are you sure you want to install it?"), or even some
> sort of apt pinning system to ignore certain updates.
I also like the idea of flagging applications that come from somewhere
other than Extras, and I suppose it would be possible to have an
Updates section with Stable and Unstable candidates in it (or perhaps
allow updates to be sorted by their origin repo - and have Extras as
the default origin). But these are still more for power users, simply
disabling the repo immediately after use is imo a better bet for
unskilled "users".
Cheers,
Simon
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
Application Manager and Extras-devel: Dealing with unstable software
Let's say you've got a user, and this user wants to get to something
shiny, but the only place this something shiny is available is from an
unstable testing repository. Normally this unstable testing repository
would not be the sort of place this user would venture into, but the
application is only there because a few minor packaging issues have to
be wrapped up (maybe the l10n is split up into a bunch of separate
packages); or there's just a few more bugs they want to stomp out; or
they want to give it a week or two of testing before they push it to
the unstable repository--whatever, so the user decides (perhaps with
the encouragement of some of their peers) to dive in, add the unstable
repository and install the application.
So the application installs and runs fine. Perhaps they encounter a
few of those small bugs that are still being worked on, but nothing
serious. A few weeks pass without issue, and they see a notification
for some new updates to a few of their favorite applications, go to
install them and BAM! one wont install due to a messed up postinst,
the next now crashes on start and the last now randomly loses data.
What happened? Developers using that unstable testing repository as an
unstable testing repository uploaded some new unstable versions of
their applications for some testing, and our poor user ended up as
collateral damage. So the question is, what can we do to protect users
from the full fury of Extras-devel while still giving them reasonable
access to some of the stabler applications in the repository?
Clearly there are a few issues at play here: developers moving
software to Extras-devel before it's ready (critical crasher or data-
lose bugs, etc), developers leaving applications in Extras-devel for
too long (no real bugs, just sitting there unpromoted), and Extras
lacking a finer granularity of stability levels. The first two can be
dealt with (up to a point) through developer education, but the last
can't really be addressed (although I'd be interested if there's any
history or particular inertia behind the 2-tier setup we have now).
Simple user education will also have a large effect (yes, you can
install this, but disable this repository when you're done).
Those issues aside, what can we do at an application level to improve
the user experience here? An opt-in system for Extras-devel updates
and installs might be useful (rather than offering the Extras-devel
version, the user has to request it specifically), visual cues to a
packages origin (color coding, a small icon) and notices might also
help ("this package is unstable software, and may contain many
significant bugs, are you sure you want to install it?"), or even some
sort of apt pinning system to ignore certain updates.
What are your ideas?
--
Ryan Abel
Maemo Community Council chair
___
maemo-developers mailing list
maemo-developers@maemo.org
https://lists.maemo.org/mailman/listinfo/maemo-developers
