[maemo-developers] Application Manager and Extras-devel: Dealing with unstable software

[From: gary liquid]

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 <marius.vollmer at nokia.com>wrote:

> "ext gary liquid" <liquid at gmail.com> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maemo.org/pipermail/maemo-developers/attachments/20081126/7bb0d848/attachment.htm