+1. Exactly what I think.
On Fri, Mar 11, 2011 at 7:54 PM, Michael Jennings <m...@kainx.org> wrote:
> On Friday, 11 March 2011, at 18:36:37 (+0100),
> Leif Middelschulte wrote:
>
> > Fair enough. Many of the said things are already part of the commit
> guidlines.
> >
> > Cases to sort out:
> > - In cases where the maintainer and the community e.g. ML disagree:
> > who has the last word?
>
> For the specific product, the original author/maintainer has the last
> word. For the E project as a whole, raster does. If those conflict,
> raster wins (and the project may need to "move out").
>
> The understanding that I always had based on how we set things up:
> - Any E-related project may go in E SVN. Nothing outside of E's SVN
> repo is officially part of the project.
> - All E-related projects must follow the general technology (Imlib,
> Imlib2, and now EFL) and philosophy of E (choice, power, apperance,
> performance).
> - The author/maintainer has control over their own project.
> - raster has final say ("veto power") over the project and the repo.
> If you disagree, you can either try to convince him or take your code
> elsewhere. Both have been done successfully. ;-)
> - Anyone with commit access can change your code. If you don't like
> their changes, revert them and say why. If there's still
> disagreement, discuss. Major changes should be discussed first.
>
> If any of this has changed, raster needs to be the one to change it.
>
> > - What's the often cited 'spirit' of the enlightenment project?
> > People were arguing the spirit of e is (besides following the
> guidlines):
> > - Fix! Don't workaround!
> > - Improve where you can
>
> People saying those things have specific reasons they want to believe
> those are the "E spirit," but they're not. They're very good
> principles to live by, but that's not the guiding philosophy that the
> project has had throughout its lifetime. The main philosophy has
> been:
>
> 1. Choice -- As much power and flexibility in the hands of the user
> as possible. Everything is configurable (options, themes, etc.).
> 2. Power -- Feature-rich, not lean and incapable.
> 3. Appearance -- It needs to look good. Better than good.
> Mind-bogglingly good.
> 4. Performance -- It needs to be fast and optimized, but not at the
> expense of features or looks.
>
> Sure, things change over time, but I think those guiding principles
> are still present and still evident in the products being produced to
> this day.
>
> Michael
>
> --
> Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <m...@kainx.org>
> Linux Server/Cluster Admin, LBL.gov Author, Eterm (www.eterm.org)
> -----------------------------------------------------------------------
> "A little learning is a dangerous thing; Drink deep, or taste not
> the Pierian spring: There shallow draughts intoxicate the brain,
> And drinking largely sobers us again."
> -- Alexander Pope, "An Essay on Criticism"
>
>
> ------------------------------------------------------------------------------
> Colocation vs. Managed Hosting
> A question and answer guide to determining the best fit
> for your organization - today and in the future.
> http://p.sf.net/sfu/internap-sfd2d
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
--
Tom.
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
