[Bf-committers] Blender developers meeting minutes - February 27, 2016

Brecht Van Lommel brechtvanlommel at pandora.be
Sat Feb 27 21:13:11 CET 2016


I mentioned the phabricator wiki since wiki.blender.org seems to be
only used for developer docs now, and so it could be potentially be
replaced entirely. But as I said in the task, I'm not arguing that
someone should spend the significant effort to do such a migration,
and of course there would be various issues to work out.

On Sat, Feb 27, 2016 at 12:22 PM, Sergey Sharybin <sergey.vfx at gmail.com> wrote:
> Hi,
>
> I will strongly suggest to ignore Phabricators Wiki for the following
> reasons:
>
> - It is not nearly as comprehensive as Mediawiki
> - Editing policies in Phabricator are still quite limiting, meaning
> granting someone's editing role for Wiki would either mean we manually
> control this (which is same as current "Please mail us if you need Wiki
> access" bullshit), or we'll effectively allow everyone to edit any object
> in our tracker which is not acceptable.
> - There's no comprehensive anti-spam tools in Phabricator.
> - Search is kinda pathetic
>
> Only argument for the Phabricator's wiki i currently see is that you only
> need one developer account to do the code and documentation. The truth is:
> _any_ current developer has a Wiki account, yet it does not help keeping
> documentation in an up-to- state. So the issue of out-of-date documentation
> is clearly somewhere else. (and if it's really an account issue, we can
> teach wiki.b.o to login with dev.b.o accounts).
>
> Let me ask this question: why would we keep diverging documentation from
> one single place (which is wiki.b.o) to a multiple ones (currently it's
> b.o/manual, and also proposed move of developer's documentation somewhere
> else)? I don't see such a diverge making documentation any easier to find
> or any easier to maintain.
>
> I do see however bullshit happening on current wiki.b.o, all this anti-spam
> things which are done in really lazy way. But that only means our wiki
> itself is to be changed. Truth here is, it's a _really_ old mediawiki
> install which is just getting rotten. We can not upgrade it easily because
> of the tree navigation, which required hacks all over the code. As for me,
> we should evaluate such proposal instead:
>
> - Re-consider navigation in Wiki, avoid having hacks to try support
> navigation which was barely useful
> - Prepare fully fresh install of Wiki (new engine, new web server settings
> optimized for today's standards and so on)
> - Install skin which we'll find acceptable (this is the most tedious work,
> we'll need someone to work on the skin and it's not so simple for Mediawiki
> i've heard)
> - Migrate the content to a new Wiki
> - Re-evaluate state of the documents in there, wipe out-of-date ones
>
> Benefits:
>
> - This keeps use of documentation the same as it always was
> - This does not scare actual editors with wither fully offline editing
> - Let's everyone (new developers, old develeoprs, non-developers) to have
> project/design proposals in there, which are then simple to move to an
> actual documentation/release notes
> - Keeps release notes, release cycle, ongoing projects, personal
> notes/design proposal/drafts in a single place.
>
> Simplified proposal: we can just ignore all history in existing Wiki and
> simply start a new one. Even with a default skin it will not be less usable
> than default sphinx/phabricator wikis.
>
> In any case, we would _have_ to update wiki sooner than later, and it will
> bring it back to an usable state. Now, please stop for a moment from all
> your "let's split stuff apart" proposal and outline _actual_ problems which
> _can not_ be solved in a context of having fresh and working wiki.b.o, what
> will be the benefits of that move and so on.
>
>
> On Sat, Feb 27, 2016 at 2:26 AM, Campbell Barton <ideasman42 at gmail.com>
> wrote:
>
>> Hi, here are the notes from today's meeting in irc.freenode.net
>> #blendercoders.
>>
>> 1) Upcoming release
>>
>> So far things go smooth with 2.77rc1, reminder that release notes need
>> attention still.
>>
>> - Mike Erwin will do OpenGL release notes.
>>
>>
>> 2) Current projects
>>
>> - Developers confirm that after 2.77 we should *stop* focusing
>>   on 2.7x and move attention to bigger 2.8x projects.
>>   However discussion shows we still need more concrete planning.
>>
>> - UI team will start having its own meetings,
>>   current plan is to hold after next developer meeting.
>>   Will be announced on the bf-committers mailing list.
>>
>> - UI project has _many_ open tasks with discussion and no conclusion,
>>   these tasks could use some decisions from UI design leads.
>>   (or archive if theirs no clear outcome and nobody has time for them).
>>
>>
>> 3) Other Projects
>>
>> - Kevin Dietrich has begun work on the DwarfLabs Alembic patch,
>>   plans to move development to a branch and update to support
>>   import/export based on suggested changes in review.
>>   https://developer.blender.org/D1783
>>
>> - @Blendify proposes to migrate developer documentation to new system
>>   (and help with the migration),
>>   https://developer.blender.org/T47563
>>
>>   However others in meeting prefer further discussion
>>   on mailing list before going ahead and making changes
>>   (evaluate Phabricator's Wiki for developer docs for eg).
>>
>> --
>> - Campbell
>> _______________________________________________
>> 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


More information about the Bf-committers mailing list