[Bf-committers] Blender developers meeting minutes - February 27, 2016
carlisle.b3d at gmail.com
Sat Feb 27 16:41:29 CET 2016
> IMO the new Sphinx-based solution presents too much of an initial
> barrier to entry.
This may be true and first however, once the environment gets setup
It is really easy especially if you are using a GUI SVN client like Smart
In order to look at this correctly you need to see the arguments from both
These can be found on the new manual . One of the reasons for the wiki
Is that too many people would edit which resulted in some bad content
and over redundant text.
On Sat, Feb 27, 2016 at 10:34 AM, Campbell Barton <ideasman42 at gmail.com>
> On Sat, Feb 27, 2016 at 10:22 PM, Sergey Sharybin <sergey.vfx at gmail.com>
> > Hi,
> > I will strongly suggest to ignore Phabricators Wiki for the following
> > reasons:
> It was mentioned as a possible alternative.
> > - 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
> > _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
> > 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.
> We don't - and think using a wiki for developer docs is reasonable to
> stick with.
> > I do see however bullshit happening on current wiki.b.o, all this
> > 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
> > of the tree navigation, which required hacks all over the code. As for
> > we should evaluate such proposal instead:
> The way we handle Wiki accounts is quite broken,
> for a while I was getting mails from `wiki at blender dot org`,
> and we got regular mails with people who wanted to just learn Blender,
> where I'm not even sure they knew what the wiki account was for.
> Sometimes their English was poor so it wasn't really clear why they
> wanted access.
> > - 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
> > optimized for today's standards and so on)
> > - Install skin which we'll find acceptable (this is the most tedious
> > we'll need someone to work on the skin and it's not so simple for
> > 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
> > than default sphinx/phabricator wikis.
> > In any case, we would _have_ to update wiki sooner than later, and it
> > 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
> > _can not_ be solved in a context of having fresh and working wiki.b.o,
> > will be the benefits of that move and so on.
> +1 (and something we've discussed/agreed on informally).
> > 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
> - Campbell
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers