[Bf-committers] Rigify addon causes error, error, error,....

[Nathan Vegdahl]

>> Consider, for example, someone having two different
>> versions of an external renderer installed, and they want to be able
>> to use either/or in different projects (maybe one is more stable, but
>> the other has more features).  I think there are meaningful use-cases
>> outside of Rigify and the current situation.
>
> Agree, did you check on adding support for this?
> if you wanted some help investigating ways to implement we could
> continue discussion on bf-python.

Sounds good.  And yeah, I'd be happy to attempt to tackle this after
some discussion. :-)

>> This is a use-case that should be better supported anyway, IMHO.
>
> Not sure how we would better support this - you can install an addon
> from a zipfile, that parts fairly straightforward.

I meant better supporting multiple different co-installed versions of
an addon, as per my example of external renderers.

> Whats inconvenient about maintaining an addon in svn?

The situation that just came up is a good example: doing contract work
on the addon during pre-release freeze.  It puts me in the position of
having to choose between two bad options: committing significant
changes during pre-release freeze, or doing major work without the
safety (and documentation) of incremental commits.  Having a separate
development repo (as I'm doing on github now) is a good way around
this, though.

Also, collaborating with others who are also doing significant
development work on it.  Emailing patches back and forth isn't so
nice, and you lose good commit logs that way.  DVCS makes this much
nicer.  Again, using github or similar for unstable development works
well to resolve this.  It's easy for people to branch and share work.
In short, by hosting with DVCS, I get the benefits of DVCS.

Finally, addons are still very poorly supported in the Blender bug
tracker, with one mega-issue assigned to each.  Granted, this is not
related to SVN per se.  But I've been annoyed by this for quite some
time, and I'm _very_ keen to skirt around it until it is addressed.
By hosting somewhere else I can point people to the tracker there (in
this case on github) and I then have proper bug/issue/todo tracking
for Rigify.

> So if you can keep whats in trunk stable, maintained and update fixes
> for release, this works, I just want to avoid fragmentation.

I don't think that will be a problem.  I'll consider the Rigify in SVN
the official supported stable version, and I'll backport bug fixes
etc.

--Nathan


On Mon, Feb 25, 2013 at 2:36 PM, Campbell Barton <ideasman42 at gmail.com> wrote:
> On Tue, Feb 26, 2013 at 8:29 AM, Nathan Vegdahl <cessen at cessen.com> wrote:
>>> Would prefer addon devs don't do this, some do already but it means we
>>> can't be sure the addon in SVN is really the latest one, have to
>>> contact devs before release to make sure we pull the latest version
>>> in, and it won't be tested as much (or not and have older addons in
>>> which miss features/fixes),
>>
>> While I understand the inconvenience this can pose, there is already
>> too much inconvenience for me the other way around.
>
> Whats inconvenient about maintaining an addon in svn?
>
>> So for the time
>> being, at least, I'm going to do primary development of Rigify on
>> github (http://github.com/cessen/rigify), and merge stable changes
>> during the appropriate BCon stages.  If the development model for
>> addons included with Blender changes at some point, I'll reconsider.
>> But I don't think that model necessarily needs to change.
>
> Don't blame you, I've been using git for development too (then moving
> into svn when ready).
>
> So if you can keep whats in trunk stable, maintained and update fixes
> for release, this works, I just want to avoid fragmentation.
>
>> I treat (and want to treat) Rigify as an independent project, and
>> would really prefer a less centralized development model for it, and
>> inclusion as an officially supported addon hinders both those things
>> by design.  So this seems like a decent compromise: it lets me develop
>> it independently as needed/wanted, but it can still be included as an
>> official addon for those who want it to be so.  We can think of the
>> github repo as something like a development branch.
>
> Ok, as a dev branch I see where your coming from, I still worry a bit
> that changes wont be tested as well in our development builds.
>
>> I would also be perfectly happy for Rigify to not be included as an
>> official addon, but I think there may be others that would object to
>> that.  For example, there was a certain someone that argued in favor
>> of its inclusion after Sintel. ;-)
>
> It's a shame if we can't provide users good tools by default (even
> though they need to be enabled).
> If rigify is fairly small and kept working with current blender
> releases, I don't see why not include it.
>
>>> users who want to test latest version need
>>> to manually grab it. - just becomes a hassle IMHO, ...makes conflicts
>>> more likely too.
>>
>> This is a use-case that should be better supported anyway, IMHO.
>
> Not sure how we would better support this - you can install an addon
> from a zipfile, that parts fairly straightforward.
> The hassle is mostly that users need to know what to search for in the
> first place, trust the script isn't malicious, check the version
> matches their blender and manually update it from the authors web
> site.
>
>> Obviously if two conflicting versions of an addon are enabled
>> simultaneously, we can't expect that to work.  But simply having two
>> different versions of an addon present... not sure why that needs be
>> an issue.
>
> Not sure what your getting at here, it shouldn't be an issue, I'm
> quite sure it can be added.
>
>> Consider, for example, someone having two different
>> versions of an external renderer installed, and they want to be able
>> to use either/or in different projects (maybe one is more stable, but
>> the other has more features).  I think there are meaningful use-cases
>> outside of Rigify and the current situation.
>
> Agree, did you check on adding support for this?
> if you wanted some help investigating ways to implement we could
> continue discussion on bf-python.
>
>> --Nathan
>
> --
> - Campbell
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers