[Bf-committers] developer.blender.org status

Mon Nov 11 16:20:07 CET 2013

Read through the part about git 1.8.2 twice but the description is
still fuzzy to me,

>From reading this it seems like we can use submodules to track master
and not have to do any manual updates.
http://stackoverflow.com/questions/9189575/git-submodule-tracking-latest

I'm really against having to manually update some SHA1 just so addons
are up to date if it can be at all helped.

When developing FBX import for example - I could ask a user if their
build was <2 days old and be sure they had a fixed version.

For translations its less of an issue because you dont experience bugs
when its a little behind,
but getting complaints on bugs fixed for a week already is bad. if
something is broken but nobody notices for a week its equally bad.

On Tue, Nov 12, 2013 at 12:32 AM, Dalai Felinto <dfelinto at gmail.com> wrote:
>> - Manually update submodule's SHA regularly, like once a week.
> I think this is reasonable, and how we do for translations already.
>
> Apart from that I think it's a nice workflow.
>
> Cheers,
> Dalai
> --
> blendernetwork.org/dalai-felinto
> www.dalaifelinto.com
>
>
> 2013/11/11 Sergey Sharybin <sergey.vfx at gmail.com>
>
>> Notes about git submodules.
>>
>> Intention is to use git submodules as a replacement for svn:externals which
>> we used for "integrating" translations and addons into main tree.
>>
>> Tricky part about submodules is that submodules in git are poiting to a
>> specific SHA revision of external repository. So if you want to use latest
>> addons you'll need to update blender's repository to use latest SHA
>> revision from from adons repository.
>>
>> This is what we'll want for release tags. Basically, we'll create tag in
>> addons/translations repositories and make release tag in blender repository
>> track submodules with given tag name.
>>
>> This is done by adding/modifying "branch" setting in .submodules file.
>>
>> Now, how to deal with regular development. It is possible to update
>> submodules to their latest SHA:
>>
>> git submodule update --remote
>>
>> --remote means submodules will be updated to latest HEAD of an external
>> repo instead of hash stored in parent repository.
>>
>> Bad thing about this is that this marks parent repository as changed with
>> uncommited changes (because submodule update modifies SHA of submodule
>> stored in parent repository). We don't want such changes to be commited by
>> an accident, and seems there's a workaround for this.
>>
>> If you add ignore=all to .gitmodules, then parent repository will ignore
>> all the changes made to submodule, ingcluding modifying/adding files there
>> or updating HEAD of submodule. This way doing `git submodule update
>> --remote` will pull all the changes from submodule's repository but
>> wouldn't mark parent repository as changes. Roughly speaking, `git commit
>> -a` invoked from parent repo will say "no changes to commit" which is nice.
>>
>> Fortunately, if you make changes to submodule itself (like, fix bug in an
>> addon) you still able to commit changes to addons repository directly from
>> submodule. To do this you just cd to addons submodule and do regular git
>> commit followed by push.
>>
>> As a sideeffect of such approach, you owuldn't be able to commit changes
>> made to submodule together with changes made to parent repository. But in
>> fact, this is also rather good. Generally speaking, you would NOT want to
>> commit chnages to submodule and parent repo with the same commit and will
>> want to commit changes to submodule first and then update parent
>> repository. Otherwise you'll run into all sorts of possible issues.
>>
>> So, the proposal is:
>> - Attach blender-addons, blender-addons-contrib and blender-translations to
>> main git's tree as a submodule (`git submodule add git://
>> git.blender.org/blender-addons/ ./release/scripts/addons` and so on)
>> - Add ignore=all to .gitsubmodules. This will be stored in blender's
>> repository, so you only need to do this once. No need for all the
>> develoeprs to modify their .gitsubmodules.
>> - To checkout checkout the repository: `git clone --recursive git://
>> git.blender.org/blender`. This will also download all the submodules. You
>> would need to `run git submodule update --remote` after this manually, coz
>> submodule's SHA might not be updated in blender repo yet.
>> - To update the checkout: `git pull && git submodules update --remote`.
>> This will pull all the changes made to blender itself and changes made to
>> all the external repos. This will NOT add changes from submodules to parent
>> repository,
>> - Commits from blender repo would NOT include changes made to addons
>> - To commit changes made to addons you simply cd to
>> ./release/scripts/addons and do git commit and push from there
>>
>> There's one weak aspect still, which is it's not clear which SHA submodules
>> should point to. This doesn't affect workflow proposed above, but would be
>> nice to have some trict policy about when and how to update submodule's
>> SHA. Couple of ways:
>> - Submodule's SHA will point to previous release's tag during current
>> development cycle. All the changes made to those repos will be pulled with
>> `git remote update --remote`, so not a bit isue wor dveelopers/regular
>> users.
>> - Update submodules's SHA with commit hook of external repositories. This
>> will clutter our main repo's history with bunch of "update submodule SHA"
>> commits.
>> - Manually update submodule's SHA regularly, like once a week.
>>
>> And one last note about changes made to git 1.8.2 about tracking tip of a
>> branch. Those change only makes ti so `git remore add --branch` will add
>> branch=xxx to .gitsubmodules, which would make git remote --update follow
>> the branch specified to git submodule add command. You might do the same
>> change manually and there's no need to use brand-new git. And this is only
>> needed when one initialized submodules to blender repo, after this it
>> doesn't matter whether you use git 1.8.2 r older one.
>>
>>
>> On Sat, Nov 9, 2013 at 12:06 AM, Brecht Van Lommel <
>> brechtvanlommel at pandora.be> wrote:
>>
>> > Latest Update:
>> >
>> > * Contrib Addons will be in a separate repository from Release Addons
>> > * Translations repository will contain only .po files, with binary .mo
>> > files generated as part of build
>> >
>> > * Documentation is being written:
>> >
>> >
>> http://wiki.blender.org/index.php/Dev:Ref/Proposals/Migration_to_Git_Phabricator#Documentation
>> > http://wiki.blender.org/index.php/Dev:Doc/Tools/Phabricator
>> > http://wiki.blender.org/index.php/Dev:Doc/Tools/Git
>> > http://wiki.blender.org/index.php/Dev:Doc/Tools/Code_Review
>> > http://wiki.blender.org/index.php/Dev:Doc/Process/Addons
>> >
>> > * We aim for migration somewhere next week, perhaps wednesday
>> >
>> >
>> > On Thu, Nov 7, 2013 at 7:33 PM, Brecht Van Lommel
>> > <brechtvanlommel at pandora.be> wrote:
>> > > The bf-extensions trackers have been migrated for testing as well now.
>> > >
>> > >
>> >
>> http://wiki.blender.org/index.php/Dev:Doc/Tools/Phabricator/Migration#Addons
>> > > http://developer.blender.org/project/view/3/
>> > >
>> > >
>> > > On projects.blender.org there is an bf-extensions project with various
>> > > trackers that not only store bug reports, but also an entry for each
>> > > addon. This is confusing however, and there is already a wiki page for
>> > > each addon with this information duplicated. We will simplify the
>> > > process as follows:
>> > >
>> > > * There is an Addons project
>> > > * The authoritative list of addons and their information is on the
>> > > wiki (a page here was already required)
>> > > * We will have Submit an Addon and Report a Bug forms for the Addons
>> > > project, similar to regular Blender bug reporting and patch submission
>> > > * Based on the wiki page information, bug reports can be assigned to
>> > > the relevant addon maintainer when they are triaged
>> > >
>> > > The only remaining open reports are:
>> > >
>> > > * Bugs reported to the tracker
>> > > * Patches in Py Scripts Upload (so, not committed to svn)
>> > > * Everything else is closed as archived
>> > >
>> > > The addon/extensions workflow documentation will be updated in the wiki
>> > later.
>> > >
>> > >
>> > > Feedback on this is welcome.
>> > >
>> > > Thanks,
>> > > Brecht.
>> > >
>> > >
>> > >
>> > > On Wed, Nov 6, 2013 at 6:46 PM, Brecht Van Lommel
>> > > <brechtvanlommel at pandora.be> wrote:
>> > >> Hi all,
>> > >>
>> > >> As you may have noticed, we now have a test version of phabricator and
>> > >> git running:
>> > >> http://developer.blender.org/
>> > >> http://developer.blender.org/diffusion/B/
>> > >>
>> > >> These are both test versions and work is ongoing, so don't base any
>> > >> actual work on them yet. You will have to redownload the git repo and
>> > >> recreate any data on developer.blender.org when the final thing goes
>> > >> live. As we are planning to switch to them next week, now seems a good
>> > >> time to get some feedback from other developers.
>> > >>
>> > >> Migration status:
>> > >>
>> http://wiki.blender.org/index.php/Dev:Ref/Migration_to_Git_Phabricator
>> > >> Phabricator docs:
>> > http://wiki.blender.org/index.php/Dev:Doc/Tools/Phabricator
>> > >>
>> > >> You can basically go to developer.blender.org and check things out,
>> > >> your username and password from projects.blender.org will still work.
>> > >>
>> > >> There's still a bunch of incomplete things that we are working on,
>> > mainly:
>> > >> * Addon and translation repositories
>> > >> * Patch / code review submission clarity
>> > >> * Migrating bf-extensions trackers
>> > >> * Documentation for git, arc, building, ..
>> > >>
>> > >> Feedback is welcome!
>> > >>
>> > >> Thanks,
>> > >> Brecht.
>> > _______________________________________________
>> > Bf-committers mailing list
>> > Bf-committers at blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-committers
>> >
>>
>>
>>
>> --
>> With best regards, Sergey Sharybin
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

-- 
- Campbell