updated FlightDeck 1.0a3 development plan

[Myk Melez]

Hi all,

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.

https://wiki.mozilla.org/Labs/Jetpack/FlightDeck/1.0a3

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
build addons.

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.

-myk

[Myk Melez]

On 07/26/2010 09:40 AM, Myk Melez wrote:

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.

https://wiki.mozilla.org/Labs/Jetpack/FlightDeck/1.0a3

After further discussions with Piotr, I've revised the plan with two changes:

1. I added a release before the 1.0a3 release (bumping 1.0a3 to 1.0a4) to push the fixes we've landed in the last month as soon as possible.
2. I added a release after the now reversioned 1.0a4 release to incorporate support for SDK 0.7, which will be coming out around that time.
   

The new schedule looks something like this:

	1.0a3	1.0a4	1.0a5
thaw	Monday, June 28	Monday, July 26	Monday, August 9
freeze	Monday, July 26	Monday, August 9	Monday, August 23
candidate	Tuesday, July 27	Tuesday, August 10	Tuesday, August 24
release	Tuesday, August 3	Tuesday, August 17	Tuesday, August 31

The corresponding development plans:

• 1.0a3
• 1.0a4
• 1.0a5

After 1.0a5, the next step will likely be to focus on integrating AOB with AMO to provide a seamless experience for developers to both build and distribute their addons. Once we've worked out that integration, follow-on releases will resume feature development.

How does that sound?

-myk

[Hernan Rodriguez Colmeiro]

> After 1.0a5, the next step will likely be to focus on integrating
> AOB with AMO to provide a seamless experience for developers to both
> build and distribute their addons. Once we've worked out that
> integration, follow-on releases will resume feature development.
>
> How does that sound?
>
> -myk
>

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...

Hernan

[Erik Vold]

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..

E

[Myk Melez]

I hear what you're saying, and I have the same problems figuring out how
to integrate AOB into my desktop-centric development process, where I
typically use Komodo IDE for code editing and Mercurial (with Mozilla
and BitBucket remote repositories) for version control.

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
HTML, JavaScript, and CSS but who aren't professional developers and
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
such features.

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.

-myk

[Hernan Rodriguez Colmeiro]

On Wed, Jul 28, 2010 at 14:05, Myk Melez <m...@mozilla.org> wrote:
> 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.

Hernán

[Myk Melez]

On 07/28/2010 10:12 AM, Hernan Rodriguez Colmeiro wrote:
> 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.

Yup, I agree!

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.

-myk

[Drew]

Piotr might shoot me, but I wrote some scripts that screen-scrape
Add-ons Builder and let you download and upload libraries from the
command line:

http://hg.mozilla.org/users/dwillcoxon_mozilla.com/aobsync

To download a library:

$ mkdir jetpack-core
$ aobsync.py get
https://builder.mozillalabs.com/library/1000000/latest/ jetpack-core

To upload:

$ aobsync.py put -u user -p pass jetpack-core
https://builder.mozillalabs.com/library/edit/1000000/latest/

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.

Drew

P.S. Seriously, back up your stuff before you use.

> Hern�n
>

[Piotr Zalewa]

Thanks, solves a common problem.

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.

Piotr

--
blog http://piotr.zalewa.info
jobs http://webdev.zalewa.info
twit http://twitter.com/zalun
face http://www.facebook.com/zaloon

[Drew]

> Is it uploading it as a new revision if lib already exists? or it cretes
> a new one?

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.

Drew

[Hernan Rodriguez Colmeiro]

On Mon, Aug 2, 2010 at 20:28, Drew <a...@mozilla.com> wrote:
>> 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...

Hernán

[Dietrich Ayala]

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.

[Drew]

I don't follow. Add what to cfx instead of AOB? A server-side AOB API?
That doesn't make sense. VCS integration? git, hg, et al. do a
pretty good job at that already.

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
myks-toolbar-library
simple-toolbars
$ aob install myks-toolbar-library

Drew

> Hern�n
>

[Lloyd Hilaiel]

On Aug 2, 2010, at 3:45 AM, Piotr Zalewa wrote:
> I also think it would be better to create an API ...

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?

lloyd