[LibX] FireFox 3?

LibX Project libx.org at gmail.com
Fri Feb 15 11:33:23 PST 2008


On Fri, Feb 15, 2008 at 1:22 PM, Adam Brin <abrin at brynmawr.edu> wrote:
> Are there plans to update LibX to support Firefox 3?  It's in beta, but
>  requires a different (secure) install/update method.
>

We haven't looked at this yet, but obviously, LibX will work with
Firefox 3. Would you be willing to help test it on FF3?  If so,
contact us off-list.

This may be a good time to ask the list's feedback on how updates like
this should be handled.

In the past, we have adopted the philosophy that edition maintainers
are responsible that their edition works properly. Maintainers test
and build their editions, and once they make them live, we do not
touch them anymore, and we prevent any further changes to the
configuration of the live revision. This procedure has the advantage
that what your users download is *exactly* what you tested. Since
users do not receive any updates unless you build a new live revision,
there is no possibility that your users will be confronted with
updates that could break their toolbar, or updates that are untested
by you. You fully control what your users get. This allows us to
follow an extremely agile software development process in which we
publish software updates immediately even as we develop them.

However, the disadvantage of this procedure is that, well, end users
will not receive any updates (any new revisions) unless their edition
maintainer has created a new build and tested it.

Making LibX compatible with FF3.0 requires a new build of each
edition. If we stick to the current model, the update process would go
as follows:  Once we make LibX compatible with FF3.0, every edition
maintainer would have to log on, build a new revision, test that it
works with FF 3.0, then make it live. Afterwards, when your end users
update Firefox to Version 3, their LibX version will be automatically
updated.  If an edition maintainer fails to build a version of LibX
that supports FF3, end users using that edition would see the edition
disabled.

There are good arguments in favor of this approach: if a maintainer is
no longer interested in maintaining an edition, it should just "die" -
software that isn't actively maintained and tested tends to rot, and
we rather have LibX disabled than have users associate buggy behavior
or functionality with LibX. Instead - as in all open source projects -
we rely on the contributions of our user community to the software
testing process.

There are good arguments against this approach. First and foremost, it
requires that all edition maintainers take the time and follow the
above process between when we make LibX FF3 compatible and when
Mozilla publishes FF 3.0. To avoid that, we could automatically create
new, FF3 compatible revisions for all editions that have been made
live.  We could give the edition maintainers x days time to test those
revisions (we'd send you an email if you provided a valid email
address during the registration process), and you could make them live
during that time period if they test ok.  After x days have passed, we
would then, for instance

- remove the edition (preventing new downloads, and leading to the
edition being disabled when FF updates to 3.0)
- leave it as is (allow downloads, but let FF disable it when 3.0
comes since the build hasn't been made live.)
- make the new revision live automatically (which means that FF 3.0
will automatically update to a new revision, which may not have been
tested by the edition maintainer.)

We're a bit torn between making it as easy as possible on you and
ensuring that LibX continues to be associated with producing
functional software with a low bug count.

We'd like to hear your thoughts/feedback.

 - Godmar for LibX


More information about the Libx mailing list