LWN: Comments on "Interesting times for Linux Flash support"

Controvery over commit styles

epa — Tue, 01 Jun 2010 16:17:44 +0000

Well, there's the distributed side, and there's the 'make branches and merge them without going insane' side. If your version control system supports easy branching and merging, you can commit your stuff to an unstable branch or a personal work branch, where they are visible to everyone but don't break things for others until you're ready to push them to the main branch.

Flash creator

nikanth — Sun, 30 May 2010 07:21:50 +0000

Flash is popular due the ease of creating it using Adobe/Macromedia tools. As long as there is going to be no competing easy to use tools for HTML5, flash will live on. But I guess the Adobe/Macromedia tools are getting a export as HTML5 + SVG option. So...

Controvery over commit styles

giraffedata — Sat, 29 May 2010 03:20:17 +0000

Isn't the point of "commit early and often" to get your code in front of everybody? Using a distributed version control system does that only insignificantly better than just keeping it in your CVS working directory. (Better, I guess, because someone sufficiently motivated could see your work early).

Breaking things for everybody is the acknowledged downside of commit early and often. Obviously, there's a difference of opinion in this project over whether the upside outweighs that.

Automated test suites that are part of a quality control strategy don't seem to me consistent with commit early and often, which admits that the code is going to be broken a lot.

Controvery over commit styles

marcH — Fri, 28 May 2010 09:20:40 +0000

If your changes are so disruptive that they need to break the test suite then you should simply work in a isolated branch, so other developers can keep working. Distributed version control makes that easier but is not strictly required.

That such engineering basics are unknown to the Gnash developers says a lot about the project.

There is LESS pressure in distributed revision control to make sure each commit is a working piece of code, since it is much easier to rewrite history and get rid of such "breaking" commits later.

Interesting times for Linux Flash support

hadess — Thu, 27 May 2010 17:21:02 +0000

Huh? swfdec was already dead when Benjamin Otte joined the Red Hat desktop team. Him joining Red Hat has nothing to do with the projects being abandoned.

His focus before joining Red Hat was already on video acceleration in GStreamer and in the X.org stacks, and that focus hasn't shifted.

Controvery over commit styles

hmh — Thu, 27 May 2010 17:01:33 +0000

Yes, you're correct. On the other hand, there are already numerous tested and proven workflows to implement both the bissectability and clean history, AND allow for the work-in-progress dirty history.

In the simpler one, you use at least two work branches, plus the mainline branches. You move the ready-and-tested work from the dirty work branch to the mainline through an intermediate cleanup branch. The no-mess, no-regression, clean history for bissectability requirements exist only in the mainline and intermediate cleanup branches.

Micro-commits versus non-regressive commits

alex — Thu, 27 May 2010 16:33:08 +0000

Sure the pressure for good working atomic commits is high when you can have working bisection in a DVCS. This is a good thing.

However I've often noticed with central VCS systems the pressure to commit before your set of disparate changes become too extensive.

Using a DVCS can alleviate that pressure by allowing you to develop locally with multiple small commits. Once you've fixed your regressions you can re-base into nice tidy commits, re-test and then push to the public repository.

AIUI Gnash is already using Bazaar so it really should be possible to have a clean commit history without breaking stuff on the way.

Controvery over commit styles

JohnLenz — Thu, 27 May 2010 15:14:03 +0000

IMO for a distributed revision control there is even more pressure to make sure each commit is a working piece of code. The reason is bisection: once you switch to a distributed revision control you can start to use bisection to find problems, but bisection fails (or at least makes your life more complicated) if there are intermediate commits which are broken in some way.

Especially the test suite breaking in a commit, because the test suite failures would be what you probably would be bisecting.

Interesting times for Linux Flash support

iabervon — Thu, 27 May 2010 15:14:00 +0000

On the other hand, Lightspeed seems like an interesting architecture regardless of the particular language specification being used. I could imagine having Lightspeed in place being valuable in making W3C standards more real. That is, if Lightspeed ends up efficient, open-source, and portable, it should be relatively straightforward to start thinking about replacing front ends from it to make something that does Javascript, HTML5 Canvas, and DOM instead of Flash, and then proposals for accelerated graphics in Canvas can come with making Lightspeed implement them, which would avoid the issue that the W3C often has where they work out a spec and some parts of it never get implemented by anyone.

Interesting times for Linux Flash support

NAR — Thu, 27 May 2010 13:46:18 +0000

I'm not familiar with the current web technologies, so I don't know if it's possible to reimplement Flash-based online games in some other tool, but I think that there might be more players of the various Flash games on Facebook than Linux desktop users...

Interesting times for Linux Flash support

bleakgadfly — Thu, 27 May 2010 12:02:59 +0000

Instead of trying to comply with Flash, FLOSS community should rather try and create something new and unique which have the same functionality. I am not sure exactly what HTML5 will be able to do (except playing videos and audio), but I think Flash has better functionality. And that is a negative thing. I am looking forward to when the Flash "era" is over.

I have been reading a bit about these "Telepresence" robots that can be controlled and streamed through a website with Flash installed, is this something that HTML5 could also achieve?

Controvery over commit styles

epa — Thu, 27 May 2010 11:52:03 +0000

Did anyone suggest the obvious answer of moving to a distributed version control system? Then any developer can commit as often as they want to their own tree (or branch), and only push (or merge) when the changes are stable.

You hopes are unjustified....

khim — Thu, 27 May 2010 08:14:34 +0000

Flash is still the only way to use webcam or P2P from browser. Standards are evolving to make it possible to do that without Flash, but they are not even stabilized, let alone deployed!

So Flash is needed for the next 2-3 years at least...

Interesting times for Linux Flash support

alstrup — Thu, 27 May 2010 08:00:47 +0000

There is also Gordon:

http://wiki.github.com/tobeytailor/gordon/

This is a Flash interpreter written in JavaScript, running directly in the browser and using SVG to render things.

Interesting times for Linux Flash support

bronson — Thu, 27 May 2010 04:41:49 +0000

Will anybody still have a need for Flash in a year? Personally, I'm hoping not.