[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Moving WebGL Khronos related stuff to GitHub


Any further thoughts on the desired repository structure?

Cedric, would you be willing to own the tasks of:

 - Working with James and Gregg to come up with a final repository structure
 - Working with James to update the Khronos side shell scripts
populating the directories under
 - Creating the repo and making the Subversion repo read-only

Ideally we'd do a test run, make sure the new shell scripts are
working, and then cut everything over during a weekend to minimize



On Fri, May 11, 2012 at 3:01 PM, Kenneth Russell <kbr@google.com> wrote:
> On Fri, May 11, 2012 at 2:57 PM, Kenneth Russell <kbr@google.com> wrote:
>> On Wed, May 9, 2012 at 7:54 PM, Cedric Vivier <cvivier@mozilla.com> wrote:
>>> On Thu, May 10, 2012 at 10:40 AM, David Sheets <kosmo.zb@gmail.com> wrote:
>>>> If each version is moved into a separate branch, the HTTP POST agent
>>>> on khronos.org that receives post-commit messages will need to perform
>>>> "git pull" against the various version branches to continue serving
>>>> individual spec and test suite versions (which I believe is necessary
>>>> for reference purposes and link maintenance). I don't think this is a
>>>> big deal but it will make the post-commit mechanism more complicated
>>>> than simply "if (HTTP POST from allowed_ips[]) then git pull"
>>>> (mirroring).
>>> Yes, not a big deal imho to rather "git fetch" then loop all version
>>> branches (v*) to generate the reference snapshots on khronos.org.
>>> Otoh this would simplify the repository model for day-to-day
>>> development and allow nice git(hub)-based diff'ing between snapshots.
>> Cedric,
>> Conceptually, using Git branches for the spec and conformance suite
>> revisions sounds nice. However, I'm concerned about a couple of
>> things:
>> 1. Having all snapshots of the conformance suite available in a flat
>> checkout has some maintenance advantages. It's possible to commit
>> updates to multiple versions of the conformance tests simultaneously.
>> This has come in handy during the stabilization of the 1.0.1 suite,
>> where changes go into the top-of-tree test suite as well as the 1.0.1
>> version.
>> 2. With the current repository structure, checking out portions of the
>> branches on the server side would be fairly complicated. For example,
>>  http://www.khronos.org/registry/webgl/specs/[number]
>> would need to be populated with the contents of the git checkout of
>> specs/latest/ at branch [number]. Separately,
>>  http://www.khronos.org/registry/webgl/conformance-suites/[number]
>> would need to be populated with the contents of the git checkout of
>> sdk/tests/ at branch [number].
> Another concern is that it might be more difficult to revise the
> conformance suite independently of the spec. We need to anticipate the
> need for version 1.0.1a, 1.0.1b, etc. of the conformance tests,
> without necessarily revising the spec.
> -Ken
>> In other words, the server-side
>> checkout would not be as simple as just checking out the branch --
>> unless we do that into a side directory on the server and set up the
>> URLs above using symlinks. (James, would that be possible?)
>> If you think that the advantages of using branches outweigh any
>> disadvantages, that's fine -- please work with Gregg and James to get
>> the server-side scripts updated appropriately.
>> I'm strongly in favor of preserving the "sdk" directory, including the
>> demos, which demonstrate some canonical code patterns such as recovery
>> from lost context. Gregg's debugging utilities are also there.
>> Splitting these into a separate repository will only make it more
>> difficult to find them and won't simplify ongoing development.
>> -Ken

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl