Per our conversation in last week's project status meeting, I updated
the FlightDeck 1.0a3 development plan with the set of work I think we
should endeavor to accomplish in this next development cycle.
The primary focus is to fix the major issues testers of the existing
preview release have encountered as they have tried to use the site to
I know there are a number of issues that didn't make the list, and
almost every issue is a major one for someone. But I'd like to get this
release out sooner than later, so I think it's important to focus it on
the most significant issues for the largest numbers of users.
That said, I may well have missed something important, so take a look at
the list, and let me know if there's anything that you think should be
on it that isn't (or shouldn't be on it that is). Feedback is welcome
both here and in tomorrow's project status meeting, after which I'd like
to finalize this plan so we can move forward on it.
Per our conversation in last week's project status meeting, I updated the FlightDeck 1.0a3 development plan with the set of work I think we should endeavor to accomplish in this next development cycle.
||Monday, June 28
||Monday, July 26
||Monday, August 9
||Monday, July 26
||Monday, August 9
||Monday, August 23
||Tuesday, July 27
||Tuesday, August 10
||Tuesday, August 24
||Tuesday, August 3
||Tuesday, August 17
||Tuesday, August 31
I don't kow who exactly is targeted the AOB, but the lack of
importing/exporting to some VCS like github, bitbucket or google code
really pushes back developers to add stuff to it. I personally had to
copy /paste manually every file from my addon when I tested the AOB,
and I'm sure I won't do it again...
There doen't appear to be any plan to do any of this, although every user seems to agree that copying&pasting for every revision sucks..
At the same time, it's important to keep in mind that the primary target
audience for AOB are "casual developers," folks with some knowledge of
don't have an existing toolchain (editor, VCS, etc.) with which they are
already familiar and prefer to work. Think power bloggers, first year CS
students, technology tinkerers, etc.
For that audience, the simple editor and VCS built into AOB is
sufficient (or will be, with a few enhancements), and it isn't necessary
to provide a feature for importing code from another VCS (or exporting
it back out), because they don't tend to use such tools.
We do also target an audience of "professional developers", people who
make a living building web sites and applications and who have assembled
a toolchain for doing so, including a preferred editor and VCS. But we
target them with the SDK rather than AOB, since it allows them to work
in their desktop environment with all their local tools.
Now, I recognize that there is an audience of developers who reside
somewhere between these two other groups. These are folks who have
developed some familiarity with desktop tools, and would like to keep
using them, but are also familiar with web-centric tools like github and
like the idea of being able to move some or most of their development
work online. Advanced CS students and newer professional developers may
fit into this category.
And there are also bound to be some professional developers who are
developing libraries locally but would like to interface with AOB in
order to distribute those libraries to developers.
For both those groups, it would be useful to build out some additional
functionality in AOB for doing things like synchronization with external
VCSes. However, we have got to make sure that we do not do so in a way
that complicates the experience for casual developers who don't need
And our primary focus for AOB has to remain on those casual developers,
since that is the way for AOB to have the greatest impact in terms of
enabling hundreds of thousands of people to build Firefox addons who
weren't previously able to do so, resulting in perhaps tens of thousands
of new addons that wouldn't otherwise be created and that make Firefox
users' web experiences much better.
Ok, but if you want developers to contribute cool modules to the
ecosystem, so that the folks interested in using only AOB can take
advantage of them, you need something to avoid manual copy/paste.
That's my point, casual users won't add much value to the ecosystem,
and people who would won't do it because is troublesome to add your
module to AOB.
I just want to make sure we continue to keep the broader vision, target
audience, and goals for the application in mind as we go about
identifying, specifying, and implementing such features.
To download a library:
$ mkdir jetpack-core
$ aobsync.py get
$ aobsync.py put -u user -p pass jetpack-core
Run aobsync.py by itself to see full usage.
It's not exactly VCS integration, but you can do your VCS stuff locally
and just sync to AOB whenever you want. It's by no means perfect. It
only handles your JS modules and not package.json for instance.
WARNING: This is really untested and unpolished, so it might destroy
your computer or something. Back up your code before using.
P.S. Seriously, back up your stuff before you use.
Is it uploading it as a new revision if lib already exists? or it cretes
a new one?
I also think it would be better to create an API ...
I'm happy to test/merge if someone would do it.
It can do both. If you don't specify an existing library on Add-ons
Builder, it makes a new library. If you do, it makes new revisions to
that library. (Unfortunately, each time you add or remove a module you
create a new revision, so you can end up with lots of revisions that
aren't really necessary.)
> I also think it would be better to create an API ...
Absolutely. If there were a nice simple server-side API, other people
could come along and build tools separate from AOB that satisfy whatever
needs they have.
It wouldn't be mad to think about adding this functionality to the cfx
instead of the AOB. People that would like to export/import stuff from
their VCS would be likely using the command line anyways so...
I think it's not true that all of these devs will use the command line
tool. I'm imagining things like developers writing tools to sync
GitHub to AOB via the API.
I think first build the API, and then update cfx to use it. We get the
best of both worlds that way.
AOB as a front-end should stay focused on casual developers as Myk has
said, but there's a real opportunity to expose its back-end (mmmm) as
the central Jetpack package repository that it is. Do all your
development on Github or however you normally do and publish your
releases on AOB so others can find them and you can become famous.
If I need a toolbar libray, I'd like to be able to search for and
install one via some package management command-line tool:
$ aob search toolbar
$ aob install myks-toolbar-library
Scuse' me if this has already been discarded, but previously it was mentioned "building AOB on top of a VCS", which seemed a great idea.
What if, rather than creating an API, an embeddable DVCS was used as the backing store for all entries on AOB and the native protocol of the DVCS were exposed (think gist.github.com). Some conventions would need to be invented in terms of repository layout, but given they were adhere'd to it could become very simple to move commits in and out and the maintenance overhead would be mitigated.
As far as implementation, I see several different python-git binding libraries (and given the existence of hg-git, that covers a significant percentage of preferences of DVCS users).
Are the storage requirements of AOB such that using a DVCS as a backing store would be too clumsy from an implementation perspective? Not being too familiar with the implementation, am I overlooking something obvious?