Re: [gentoo-dev] [rfc] Rendering the official Gentoo logo / Blender,2.04, Python 2.2

2015-03-25 Thread Sebastian Pipping
On 07.06.2011 11:15, Mario Bodemann wrote:
 Hi folks,
 
 Sebastian told me about the problem of not being able to render the
 logo in recent blender versions. So this is were I stepped in: I tried
 it and used the geometries from the old .blender file, and the
 yellowish reflecting image.
 
 Problem was to recreate the exact representation of the original logo,
 by new means of rendering and relighting. I tried to solve them by
 creating a new material for the g and carefully adjusting the
 parameters. Also I added a new modifier for the geometry to get rid of
 the ugly seam at the sharp edge. (This does not modify the geometry,
 only the rendering of it)
 
 However, here are my preliminary results:
 
  - the modified .blend-file[1] (tested with blender 2.57b)
  - new rendered logo image [2]
  - original logo image (for comparison)[3]
 
 What do you think?
 
 Greetings, Mario.
 
 [1]
 http://git.goodpoint.de/?p=g-metal-blend.git;a=blob_plain;f=g-metal.blend;hb=master
 [2]
 http://git.goodpoint.de/?p=g-metal-blend.git;a=blob_plain;f=g-metal.png;hb=images
 [3]
 http://git.goodpoint.de/?p=g-metal-blend.git;a=blob_plain;f=g-metal-orig.png;hb=images

For the record, I have resurrected that repository at

  https://github.com/gentoo/blender-gentoo-logo

now.  For the images [2][3], have a look at the images branch:

  https://github.com/gentoo/blender-gentoo-logo/tree/images

Best,



Sebastian




[gentoo-dev] [warning] the bug queue has 108 bugs

2015-03-25 Thread Alex Alexander
Our bug queue has 108 bugs!

If you have some spare time, please help assign/sort a few bugs.

To view the bug queue, click here: http://bit.ly/m8PQS5

Thanks!



Re: [gentoo-dev] collab herd for cooperative pkg maintenance

2015-03-25 Thread Sebastian Pipping
On 23.03.2015 18:22, Tim Harder wrote:
 With that in mind, I think it would be an interesting experiment if
 we had a collaborative herd (probably named collab) that signals
 the status that anyone is generally free to fix, bump, or do sane
 things to the pkgs with the caveat that you fix what you break.

+1

(to any other non-herd marker in metadata.xml to achieve the same
effect, too)



Sebastian




Re: [gentoo-dev] collab herd for cooperative pkg maintenance

2015-03-25 Thread Robin H. Johnson
On Tue, Mar 24, 2015 at 08:41:52AM +0100, Alexis Ballier wrote:
 On Mon, 23 Mar 2015 13:22:25 -0400
 Tim Harder radher...@gentoo.org wrote:
 
  Hey all,
  
  Having been around for a few years I've inherited or added quite a few
  pkgs to the tree that I wouldn't mind other people fixing/bumping/etc
  that don't fall into any current herds.
  
  With that in mind, I think it would be an interesting experiment if we
  had a collaborative herd (probably named collab) that signals the
  status that anyone is generally free to fix, bump, or do sane things
  to the pkgs with the caveat that you fix what you break.
  
  Anyone else interested in such a setup?
 sounds like nmu is what you want:
 https://archives.gentoo.org/gentoo-dev/message/604102ed1392afd3bfe35bfb33da8796
Here's a quick stab at a nmu element for metadata.xml; based on vapier's
comments. I'm not set on the name of 'nmu', something like
'change-policy' might be a cleaner choice.

nmu element, which has machine-readable attributes:
- who:
  - ANYONE - anybody can touch (implicit default)
  - REQUIRES_TEAM - you must be a team member of a team listed
  - REQUIRES_MAINTAINER - you must be an explicitly listed maintainer
specific herds or devs can be explicitly listed if you want to direct
people to ask somebody about your packages (but that person should
probably be listed as a maintainer then).
- timeout:
  this is how long you we suggest you wait for the maintainer/team to
  comment on your change.
  Format should be a short duration specifier per ISO8601
  I'd like to default it to 1 week: 'P1W'.
- scope:
  How big of changes are ok?
  - NONE - (included for completeness)
  - STABLE - you can mark it stable after the normal 30 days
  - VERBUMP-MINOR - strictly a minor version bump, no other changes
  - TRIVIAL - simple, strict bugfixes (implicit default)
  - VERBUMP-MAJOR - a major version bump
  - MAJOR - rewrites, large functionality changes

nmu element may also have human-readable content, to help clarify your
intent if you think you cannot make it sufficiently clear with the
machine attributes.

Under this proposal, I'll be tagging most of my packages with:
nmu who='ANYONE' timeout='P0' scope='TRIVIAL' /

Fragile things might be tagged with:
nmu who='REQUIRES_MAINTAINER' timeout='P2Y' /

It should be valid to have multiple elements; something fragile to patches
(eg qmail), but ok for bumping minor versions, because upstream is very
good about API breakage:
nmu who='ANYONE' timeout='P2W' scope='VERBUMP-MINOR,!STABLE' /
nmu who='REQUIRE_TEAM' timeout='P1W' scope='VERBUMP-MAJOR' /
nmu who='REQUIRE_MAINTAINER' timeout='P0' scope='MAJOR' /

Overall, I suggest that these two elements become the implicit default:
nmu who='ANYONE' timeout='P1W' scope='TRIVIAL' /
nmu who='REQUIRE_TEAM' timeout='P1W' scope='MAJOR' /

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Infrastructure Lead
E-Mail : robb...@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85