I've re-opened two JIRA tickets associated with lost commits:
https://jira.sakaiproject.org/browse/KERN-2796
https://jira.sakaiproject.org/browse/KERN-2759
KERN-2796 ("Migrated basiclti widget displays ltisecret cannot be null")
presents UC Berkeley with a particularly urgent problem. After the 1.2.0
fixes were committed (but never copied to "master"), conflicting changes
were made to DocMigrator code. As a result, a simple merge leaves us
with a compilation error.
Berkeley is trying to update our pilot system from 1.1-based code to
1.3-based code. Therefore I'm reluctant to throw away migration fixes
that were considered essential to the 1.2.0 release. Can we get some
help on resolving this?
Thanks,
Ray
On 7/2/12 1:27 PM, Ray Davis wrote:
> While helping prepare our local branches for a 1.3.0-based upgrade, I
> ran into a couple of "lost" commits that were included in OAE 1.2.0 but
> never in "master" (and therefore not in 1.3.0). [1] The end result is
> that Nakamura 1.2.0 had a couple of test files that don't appear
> anywhere else:
>
> bundles/files/migrator/src/test/resources/KERN2759Redux.json
> bundles/files/migrator/src/test/resources/StructureWithBasicLti.json
>
> and a couple of changed lines in the release scripts at:
> tools/release_post_process_files.sh
> tools/release_pre_process_files.sh
>
> Obviously no one found these to be blockers but they do muddy history a
> bit. More generally, we've found that the OAE teams' current handling of
> releases makes it surprisingly difficult to keep our local production
> branches aligned with central development.
>
> As background, one of the more dubious advantages of Git over Subversion
> is its tags approach. Rather than referring to a particular point on a
> branch, a tag has its own completely independent history. It's like an
> unnamed branch with a named end-point. Project teams can still use tags
> in a familiar way by being disciplined about keeping all commits (and
> therefore all tags) on the "master" branch. Unfortunately (from our
> point of view), the OAE team has taken full advantage of tag
> independence, and a given tag rarely corresponds to a commit on "master".
>
> If this wasn't a thoroughly considered team policy but instead
> just-sorta-happened, could the project team reconsider it?
>
> Best,
> Ray
>
> [1] nakamura> git log central..nakamura-1.2.0
> ...
> commit b05040f0d309628e3eb41a271fc356cac4f9a0eb
> Author: Zach A. Thomas <[email protected]>
> Date: Tue Apr 24 16:02:31 2012 -0500
> NOJIRA tweak the way version numbers are replaced in list.xml
>
> commit d657ef8ed68d20029706ef6bc52a8bd5aa5c19f3
> Merge: 0811f4f 972c292
> Author: Carl Hall <[email protected]>
> Date: Tue Apr 24 11:56:02 2012 -0700
> Merge pull request #761 from zathomas/kern-2759
> fixed the 'width' property for fractional widths
>
> commit 0811f4fc52c79888a3a5076a444962877ec64bf3
> Merge: 1b20f3f 00131ee
> Author: Carl Hall <[email protected]>
> Date: Tue Apr 24 08:33:54 2012 -0700
> Merge pull request #759 from mrvisser/kern-2796
> Migrated basiclti widget displays ltisecret cannot be null (500)
>
> commit 00131ee2a97a5005869129774b3da721373afa75
> Author: Branden Visser <[email protected]>
> Date: Mon Apr 23 18:14:41 2012 -0400
> KERN-2796 Read source content as admin to ensure ltiKeys node is
> migrated. Also, lock down ltiKe
>
> commit 972c2924519142c5b16f2a7e9bbb225f7d4a9ee9
> Author: Zach A. Thomas <[email protected]>
> Date: Mon Apr 23 11:30:03 2012 -0500
> KERN-2759 fix the output of 'width' for fractional column widths
> _______________________________________________
> oae-dev mailing list
> [email protected]
> http://collab.sakaiproject.org/mailman/listinfo/oae-dev
>
_______________________________________________
oae-dev mailing list
[email protected]
http://collab.sakaiproject.org/mailman/listinfo/oae-dev
