Re: [E-devel] Private projects in svn.e.org

[Stephen H. <uni...@gm...>]

Obviously the maintainer has the last word since he/she has the ability to
pull it out of svn whenever.
Yes the spirit is fix and improve. Not rewrite or remove!!!!!!!!!!!!!!!!!

On Fri, Mar 11, 2011 at 11:36 AM, Leif Middelschulte <
lei...@gm...> wrote:

> 2011/3/11 Tom Hacohen <to...@st...>:
> > That's the idea.
> >
> > On Fri, Mar 11, 2011 at 6:57 PM, Stephen Houston <uni...@gm...>
> > wrote:
> >>
> >> I think that anything goes as long as it keeps the spirit and direction
> of
> >> the project in mind, and if it doesn't or is a major change or rewrite,
> the
> >> maintainer really should be consulted, or at least, the mailing list to
> >> which the maintainer belongs.
> 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?
> - 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
>
> Thanks for participation,
>
> Leif
> >>
> >> On Fri, Mar 11, 2011 at 10:50 AM, Leif Middelschulte
> >> <lei...@gm...> wrote:
> >>>
> >>> I am sorry. I did not intend to make people feel "I was not asked!".
> >>> So please everyone feel free to articulate your very own oppinion on
> >>> that and we'll try to come up with an agreement later.
> >>>
> >>> BR,
> >>>
> >>> Leif
> >>>
> >>> 2011/3/11 Tom Hacohen <to...@st...>:
> >>> > +1. Sachiel is always right.
> >>> > I also disagree with those rules. Take a look at what I wrote at:
> >>> > "(Re)moving stuff from SVN without author knowledge.".
> >>> > On Fri, Mar 11, 2011 at 6:42 PM, Iván Briano (Sachiel)
> >>> > <sac...@gm...>
> >>> > wrote:
> >>> >>
> >>> >> 2011/3/11 Leif Middelschulte <lei...@gm...>:
> >>> >> > Hello everyone,
> >>> >> >
> >>> >> > As of recent events, I want to poll the developers' perception on
> >>> >> > "Private projects in e.svn.org".
> >>> >> > Some developers were suprised that their projects (which were in
> >>> >> > trunk) were (re)moved/rewritten/majorly changed by other
> developers
> >>> >> > of
> >>> >> > our community.
> >>> >> > Both sides came up with reasonable arguments, I don't want to
> >>> >> > discuss
> >>> >> > here.
> >>> >> >
> >>> >> > I'll just propose two basic and simple ideas of how code (in e's
> >>> >> > central svn, except for the dev's directories) is to be treated by
> >>> >> > other developers. The already available guidlines for commits
> apply
> >>> >> > for both proposals:
> >>> >> >
> >>> >> > 1.) Code in e.svn.org is free for (entire, including remove)
> change
> >>> >> > by
> >>> >> > anyone with commit access. People who put their code there aggree
> >>> >> > with
> >>> >> > this. The mailinglist shall be consulted in cases of 'major'
> >>> >> > changes.
> >>> >> > - Leif (T_UNIX)
> >>> >> >
> >>> >> > 2.) If a developer changes (adds/(re)moves/changes to almost
> >>> >> > rewrite)
> >>> >> > code in e.svn.org he or she has to consult the respective
> project's
> >>> >> > maintainer.
> >>> >> >
> >>> >> > Put your name under which idea you see suits your oppinion best.
> >>> >> > Please don't make this a flamewar and stay _on_ topic. Make sure
> you
> >>> >> > don't put annything in your answer besides your name/signature.
> This
> >>> >> > mail is not a discussion thread. If you think a different policy
> >>> >> > should be discussed feel free to open another thread so people
> might
> >>> >> > comment if necessary.
> >>> >> >
> >>> >>
> >>> >> So we can't discuss without opening an infinite amount of threads
> >>> >> with different proposals that will all get lost in the sea if "fuck,
> >>> >> too
> >>> >> many
> >>> >> mails and I have work to do"?
> >>> >>
> >>> >> I don't agree with any of those options, but I'll stay out of it
> >>> >> anyway.
> >>> >>
> >>> >> > BR,
> >>> >> >
> >>> >> > Leif
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> >
> ------------------------------------------------------------------------------
> >>> >> > 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
> >>> >> > enl...@li...
> >>> >> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >>> >> >
> >>> >>
> >>> >>
> >>> >>
> >>> >>
> ------------------------------------------------------------------------------
> >>> >> 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
> >>> >> enl...@li...
> >>> >> 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
> >>> enl...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >>
> >
> >
> >
> > --
> > Tom.
> >
>