[Bf-committers] Blender developers meeting minutes - February 27, 2016
sergey.vfx at gmail.com
Sat Feb 27 12:22:02 CET 2016
I will strongly suggest to ignore Phabricators Wiki for the following
- 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
- Migrate the content to a new Wiki
- Re-evaluate state of the documents in there, wipe out-of-date ones
- 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>
> Hi, here are the notes from today's meeting in irc.freenode.net
> 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.
> - @Blendify proposes to migrate developer documentation to new system
> (and help with the migration),
> 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
With best regards, Sergey Sharybin
More information about the Bf-committers