[Scummvm-devel] WebOS Port: The next steps

[Max Horn]

Hi!

Am 12.04.2011 um 17:01 schrieb Klaus Reimer:

> On 04/12/2011 12:30 PM, Max Horn wrote:
>> after some rebasing and rewording of commit messages, I accepted your
>> pull request. Excellent work :). 
> 
> Now that it has been accepted, what are the next steps? I guess a real
> release will not be possible until ScummVM 1.3 is released, but what
> about releasing snapshot packages so users can test it?

Sure, would be a good idea.

> For beta
> snapshots I see three possibilities:
> 
> 1. Ignore all app catalogs and simply provide an IPK file for download
> on the website. Users must install it with developer tools.
> 
> 2. Publishing it on precentral.net (That's where my old 1.0 port is
> located). Users need the homebrew software "Preware" to install it.
> 
> 3. Using the "Public Beta" channel of the official App Catalog. Software
> can then be installed by clicking a link on some web page (Could be
> placed in the ScummVM Wiki or Website for example). Beta apps are also
> listed in the homebrew software "Preware".


These don't seem mutually exclusive, are they? Just asking, because from my point of view, it would be best to combine 1 and 3: Namely, let's add a WebOS toolchain to our buildbot, then we can provide daily builds from there (assuming you have a simple build rule that generates an .ipk).

But of course for the "regular" user, being able to get the "beta" from the App Catalog sounds much more convenient.


> 
> I recommend using the beta channel of the official App Catalog. But
> question is, who does the upload? I'm a registered WebOS developer so I
> could do this with my account but I read some discussion here about
> using a shared account for the Android port so I guess this is also
> preferred for WebOS? I'm not sure if this is allowed, but I could ask
> Palm what they think about it.

Yes, a shared account would be preferably. As I say so often, we need to make sure our bus factor is not too low: If you ever happen to "vanish" (e.g. don't have time for ScummVM anymore), we'd still want to be able to release WebOS updates. By sharing the account credentials with at least the lead devs, we can more easily setup a new maintainer, should the need ever arise. Also in case of urgent emergencies etc. it's good to have a backup account holder.

Andre suggested for the Android port (in a series of off-list emails that I should still respond to ... :/) that we can use GPG to share and store the key / password; fine by me. Though this still relies on us having shared and validated our mutual GPG keys... ;). So far, I got no reaction at all to my repeated pleas to team members to create and share personal GPG keys, however ... :/
Well, we'll find a solution.


As to the legality of creating a "ScummVM" shared account: Other vendors distinguish between "Teams" and "Developers" and "Products". Products are owned by teams (which could be an organization, company, one-person team, ...); developers are members of teams. Considering that many companies want to publish stuff (and the people behind these app stores *want* companies to publish stuff), they typically all support a variation of this concept... No idea about HP/Palm, though.

I noticed on <https://developer.palm.com/content/resources/distribute/developing_and_distributing_with_hp/developer_program_details.html> that there are special "open source accounts", 

> 
> Some word about WebOS packages in general: Packages are identified by
> their ID and version. The ID is like a Java package name and it was
> already said that this should be "org.scummvm.scummvm"). The version is
> pretty restrictive. It must contain a major, minor and revision number.
> No other characters are allowed. But the numbers can be really large so
> I recommend using the revision number to contain the ScummVM revision
> number plus the package release number. So when releasing ScummVM 1.3.1
> for example then the first package has the version number 1.3.1001 and
> when for some reason a new package must be created while the ScummVM
> version stays the same the version number is then 1.3.1002. What do you
> think about this?

I think it's a bit sad / silly that they put up such restrictions, but if that's how it is, we probably are forced to rely on such a workaround. I am a bit concerned, though, that this will lead to serious user confusion ... ./

> 
> For releasing a beta snapshot I suggest using a package ID like
> "org.scummvm.scummvm-snapshot" or "org.scummvm.scummvm-beta". It's not a
> good idea to use the same package ID for beta versions and releases
> because this will create conflicts.

Sounds logical.

Cheers,
Max