Enlightenment

Thats what I did

still this message ...

On Sat, 17 Mar 2001, you wrote:
> On Sat, Mar 17, 2001 at 04:29:49PM -0500, Mathieu Dube wrote:
> > (Logging in to anonymous@...)
> > CVS password: 
> > Fatal error, aborting.
> > anonymous: no such user
> > cvs login: authorization failed: server cvs.enlightenment.sourceforge.net rejected access to /cvsroot/enligthenment for user anonymous
> > 
> > What can I do?
> 
> just hit enter at the password prompt. after you get your local prompt back
> then do "cvs -z3 co e17" for the initial checkout.
> i> 
> > -Mat
> > 
> > On Sat, 17 Mar 2001, you wrote:
> > > * Mathieu Dube (mathieu_dube@...) wrote:
> > > > Hey guys,
> > > >          What is the cvs repository, what login should I use?
> > > > 
> > > >          I loved E for so long its time I chip in :-)
> > > > -- 
> > > 
> > > Take a look at:
> > > 
> > > http://www.enlightenment.org/cvs.html
> > > 
> > > --
> > > Martin Sarajervi <martin@...>
> > > 
> > > _______________________________________________
> > > Enlightenment-devel mailing list
> > > Enlightenment-devel@...
> > > http://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > -- 
> > Mathieu Dube
> > Mondo-Live
> > http://www.flipr.com
> > 
> > _______________________________________________
> > Enlightenment-devel mailing list
> > Enlightenment-devel@...
> > http://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 
> -- 
> 
> Got Root?                    http://www.linux-mandrake.com/en      
> -------------------------------------------------------------
> Phil Morris <marmot>                   morrispe@...
> Systems Administrator Advanced         EDS http://www.eds.com
> -------------------------------------------------------------
> Phil's Linux PPP HOWTO http://www.vennercs.com/users/morrispe
> 
> _______________________________________________
> Enlightenment-devel mailing list
> Enlightenment-devel@...
> http://lists.sourceforge.net/lists/listinfo/enlightenment-devel

-- 
Mathieu Dube
Mondo-Live
 http://www.flipr.com

export CVSROOT=3D":pserver:anonymous@...=
vsroot/enlightenment"
cvs login

is working perfectly for me ....

On Sun, 18 Mar 2001 00:48:46 Mathieu Dube wrote:
>=20
> Thats what I did
>=20
> still this message ...
>=20
> On Sat, 17 Mar 2001, you wrote:
> > On Sat, Mar 17, 2001 at 04:29:49PM -0500, Mathieu Dube wrote:
> > > (Logging in to anonymous@...)
> > > CVS password:=20
> > > Fatal error, aborting.
> > > anonymous: no such user
> > > cvs login: authorization failed: server
> cvs.enlightenment.sourceforge.net rejected access to
> /cvsroot/enligthenment for user anonymous
> > >=20
> > > What can I do?
> >=20
> > just hit enter at the password prompt. after you get your local promp=
t
> back
> > then do "cvs -z3 co e17" for the initial checkout.
> > i>=20
> > > -Mat
> > >=20
> > > On Sat, 17 Mar 2001, you wrote:
> > > > * Mathieu Dube (mathieu_dube@...) wrote:
> > > > > Hey guys,
> > > > >          What is the cvs repository, what login should I use?
> > > > >=20
> > > > >          I loved E for so long its time I chip in :-)
> > > > > --=20
> > > >=20
> > > > Take a look at:
> > > >=20
> > > > http://www.enlightenment.org/cvs.html
> > > >=20
> > > > --
> > > > Martin Sarajervi <martin@...>
> > > >=20
> > > > _______________________________________________
> > > > Enlightenment-devel mailing list
> > > > Enlightenment-devel@...
> > > > http://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> > > --=20
> > > Mathieu Dube
> > > Mondo-Live
> > > http://www.flipr.com
> > >=20
> > > _______________________________________________
> > > Enlightenment-devel mailing list
> > > Enlightenment-devel@...
> > > http://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >=20
> > --=20
> >=20
> > Got Root?                    http://www.linux-mandrake.com/en     =20
> > -------------------------------------------------------------
> > Phil Morris <marmot>                   morrispe@...
> > Systems Administrator Advanced         EDS http://www.eds.com
> > -------------------------------------------------------------
> > Phil's Linux PPP HOWTO http://www.vennercs.com/users/morrispe
> >=20
> > _______________________________________________
> > Enlightenment-devel mailing list
> > Enlightenment-devel@...
> > http://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>=20
> --=20
> Mathieu Dube
> Mondo-Live
> http://www.flipr.com
>=20
> _______________________________________________
> Enlightenment-devel mailing list
> Enlightenment-devel@...
> http://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>=20
-------------------------------------
-[ Jean Collonvill=E9 ]-[ICQ: 10205857]
-(home)-(http://cjean.cjb.net)
-(gproc)-(http://gproc.sourceforge.net)

Patch to build on Darwin which doesn't have LC_MESSAGES - the configure 
script checks for them but doesn't seem to fix it up properly :)

diff -ru enlightenment-0.16.5/dox/file.c 
enlightenment-0.16.5-patched/dox/file.c
--- enlightenment-0.16.5/dox/file.c     Thu Jun 29 21:29:04 2000
+++ enlightenment-0.16.5-patched/dox/file.c     Sat Feb 24 11:52:06 2001
@@ -966,7 +966,11 @@
     char               *tmp, *lang, *p[3];
     int                 i;

+#ifdef HAVE_LC_MESSAGES
     if (!(lang = setlocale(LC_MESSAGES, NULL)))
+#else
+   if (!(lang = setlocale(LC_ALL, NULL)))
+#endif
       return 0;

     tmp = strdup(fname);
diff -ru enlightenment-0.16.5/src/file.c 
enlightenment-0.16.5-patched/src/file.c
--- enlightenment-0.16.5/src/file.c     Fri Jul 28 21:13:13 2000
+++ enlightenment-0.16.5-patched/src/file.c     Sat Feb 24 11:27:23 2001
@@ -1087,7 +1087,11 @@
     char               *tmp, *lang, *p[3];
     int                 i;

+#ifdef HAVE_LC_MESSAGES
     if (!(lang = setlocale(LC_MESSAGES, NULL)))
+#else
+   if (!(lang = setlocale(LC_ALL, NULL)))
+#endif
        return 0;

     tmp = strdup(fname);
diff -ru enlightenment-0.16.5/src/menus.c 
enlightenment-0.16.5-patched/src/menus.c
--- enlightenment-0.16.5/src/menus.c    Fri Jul 28 19:23:35 2000
+++ enlightenment-0.16.5-patched/src/menus.c    Sat Feb 24 11:27:49 2001
@@ -1694,7 +1694,11 @@

     EDBUG(5, "CreateMenuFromGnome");

+#ifdef HAVE_LC_MESSAGES
     if ((lang = setlocale(LC_MESSAGES, NULL)) != NULL)
+#else
+   if ((lang = setlocale(LC_ALL, NULL)) != NULL)
+#endif
        Esnprintf(name_buf, sizeof(name_buf), "Name[%s]=", lang);
     else
        name_buf[0] = '\0';

I was testing latest cvs wonderfull Evas test in Hardware accelerated way=
=2E

I've got Geforge2 with newest nVidia drivers.
Mandrake 8.0
 and I was running .....Kde.   ooops ;-)

Anyway when I tryed to close the application ( more than 500 fph )
all system hanged and I was obliged to hard reset.

Need more detail ???

Let me know.
cu,
    /kiuma



____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=3D=
1

On  5 May, kiuma scribbled:
>  I was testing latest cvs wonderfull Evas test in Hardware accelerated way.
>  
>  I've got Geforge2 with newest nVidia drivers.
>  Mandrake 8.0
>   and I was running .....Kde.   ooops ;-)
>  
>  Anyway when I tryed to close the application ( more than 500 fph )
>  all system hanged and I was obliged to hard reset.
>  
>  Need more detail ???

send this to nvidia. this is NOT an evas bug. i repeat NOT and evas
bug. they will want debugging info though so what u have is rather
useless without more information. you might want to update to the
latest nvidia drivers first - and then tell nvidia what set of hardware
you have (what kernel, smp or not, Xserver version, what you were
running  etc.) i know markv at nvidia will be interested in fixing it -
i think he has a fix for this kind of stuff in the pipeline but its an
architectural change andmay take a little bit :)

>  
>  Let me know.
>  cu,
>      /kiuma
>  
>  
>  
>  ____________________________________________________________________
>  Get free email and a permanent address at http://www.netaddress.com/?N=1
>  
>  _______________________________________________
>  Enlightenment-devel mailing list
>  Enlightenment-devel@...
>  http://lists.sourceforge.net/lists/listinfo/enlightenment-devel

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@...     raster@...
VA Linux Systems                    raster@...
Mobile Phone: +1 408 887 3163	    Work Phone: +1 510 687 7069

*pls disregard if i am sending to the wrong list*
I am new to unix and X windows and in search of documentation to get 
enlightenment working.
I am using openbsd 2.9 , I have setup X and is working fine. I have 
installed enlightenment from the ports tree and this too seems to have 
completed succesfully but i cannot determine where to go  from here.  'man 
enlightenment' assumes i am allready running it. > If anyone can point me in 
the right direction, I am much appreciative!
Cheers -
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com

* benny hill (org123@...) wrote:
> *pls disregard if i am sending to the wrong list*
> I am new to unix and X windows and in search of documentation to get 
> enlightenment working.
> I am using openbsd 2.9 , I have setup X and is working fine. I have 
> installed enlightenment from the ports tree and this too seems to have 
> completed succesfully but i cannot determine where to go  from here.  'man 
> enlightenment' assumes i am allready running it. > If anyone can point me in 
> the right direction, I am much appreciative!
> Cheers -
there should be a script in your path called enlightenment.install run that.
it should setup your .xinitrc and .xsession to launch E when you start X or
login from gdm or whatever.  Sometimes your path to enlightenment(haha) can 
be wrong in ~/.xinitrc, you can edit it with vi or whatever and it should
either be /usr/X11R6/bin/enlightenment or /usr/local/bin/enlightenment then
logging in should reveal the elusive enlightenment window manager.  For some
reason the past couple tiems I've used that script it's set the path wrong,
the script might work all by itself though.
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com
> 
> 
> _______________________________________________
> Enlightenment-devel mailing list
> Enlightenment-devel@...
> http://lists.sourceforge.net/lists/listinfo/enlightenment-devel
__
Corey Donohoe
atmos@...
cdonohoe@...

I am trying to build CVS e17 on Debian sid. I fails as follows:

make[2]: Entering directory `/home/kofman/e17/libs/imlib2/src'
/bin/sh ../libtool --mode=compile @AS@  @ASFLAGS@ -c -o asm_blend.lo `test -f asm_blend.S || echo './'`asm_blend.S
rm -f .libs/asm_blend.lo
@AS@ @ASFLAGS@ -c asm_blend.S  -fPIC -DPIC -o .libs/asm_blend.lo
../libtool: @AS@: command not found
make[2]: *** [asm_blend.lo] Error 1
make[2]: Leaving directory `/home/kofman/e17/libs/imlib2/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/kofman/e17/libs/imlib2'
make: *** [all] Error 2


Not knowing much about the autoconf stuff which is involved I am not sure how to make it
work.  Any ideas?  
(I have as etc..)

ik
-- 
-------------------------------------------------------------------------------
kofman@... 		       GPG Public Key: http://www.tambuka.net/key.html
 http://www.tambuka.net   	Key Signature: ED872B110DBF4EC8FE280350FF9E0C810792EA1D
-------------------------------------------------------------------------------

* Igor Kofman (kofman@...) wrote:
> 
> I am trying to build CVS e17 on Debian sid. I fails as follows:
> 
> make[2]: Entering directory `/home/kofman/e17/libs/imlib2/src'
> /bin/sh ../libtool --mode=compile @AS@  @ASFLAGS@ -c -o asm_blend.lo `test -f asm_blend.S || echo './'`asm_blend.S
> rm -f .libs/asm_blend.lo
> @AS@ @ASFLAGS@ -c asm_blend.S  -fPIC -DPIC -o .libs/asm_blend.lo
> ../libtool: @AS@: command not found
> make[2]: *** [asm_blend.lo] Error 1
> make[2]: Leaving directory `/home/kofman/e17/libs/imlib2/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/home/kofman/e17/libs/imlib2'
> make: *** [all] Error 2
> 
> 
> Not knowing much about the autoconf stuff which is involved I am not sure how to make it
> work.  Any ideas?  
> (I have as etc..)


Hmm, try deleting configure.ac if it's there. 
(doesn't autoconf tell you something about this?)
make distclean

and try again.


- Martin Sarajervi

After reading Martin's post about Eterm, I saw the same autoconf error: 
"automake: src/Makefile.am: Assembler source seen but `ASFLAGS' not defined in `configure.in'"
adding:
AC_SUBST(AS)
AC_SUBST(ASFLAGS)
to configure.in fixes that error but then:

as -c asm_blend.S -fPIC -DPIC -o .libs/asm_blend.lo
as: unrecognized option `-c'

where are the flags missconfigured?

ik

On Sun, 7 Oct 2001 16:48:02 +0200
Martin Sarajervi <ms@...> wrote:

> * Igor Kofman (kofman@...) wrote:
> > 
> > I am trying to build CVS e17 on Debian sid. I fails as follows:
> > 
> > make[2]: Entering directory `/home/kofman/e17/libs/imlib2/src'
> > /bin/sh ../libtool --mode=compile @AS@  @ASFLAGS@ -c -o asm_blend.lo `test -f asm_blend.S || echo './'`asm_blend.S
> > rm -f .libs/asm_blend.lo
> > @AS@ @ASFLAGS@ -c asm_blend.S  -fPIC -DPIC -o .libs/asm_blend.lo
> > ../libtool: @AS@: command not found
> > make[2]: *** [asm_blend.lo] Error 1
> > make[2]: Leaving directory `/home/kofman/e17/libs/imlib2/src'
> > make[1]: *** [all-recursive] Error 1
> > make[1]: Leaving directory `/home/kofman/e17/libs/imlib2'
> > make: *** [all] Error 2
> > 
> > 
> > Not knowing much about the autoconf stuff which is involved I am not sure how to make it
> > work.  Any ideas?  
> > (I have as etc..)
> 
> 
> Hmm, try deleting configure.ac if it's there. 
> (doesn't autoconf tell you something about this?)
> make distclean
> 
> and try again.
> 
> 
> - Martin Sarajervi
> 
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
-------------------------------------------------------------------------------
kofman@... 		       GPG Public Key: http://www.tambuka.net/key.html
 http://www.tambuka.net   	Key Signature: ED872B110DBF4EC8FE280350FF9E0C810792EA1D
-------------------------------------------------------------------------------

On Sun, 7 Oct 2001 12:49:53 -0500 Igor Kofman <kofman@...> babbled
profusely:

> 
> After reading Martin's post about Eterm, I saw the same autoconf error: 
> "automake: src/Makefile.am: Assembler source seen but `ASFLAGS' not defined in
> `configure.in'"
> adding:
> AC_SUBST(AS)
> AC_SUBST(ASFLAGS)

that's not the problem. debian's libtool and/or automake package is putting
these in expecting them to get substituted and they aren't. it shouldnt' be
doing this as i shouldn not HAVE to AC_SUBST the ASFLAGS and AS variables - just
like CFLAGS and CC. basically things suddenly broke due to an upgrade on your
system - due to debian's upgrading t a new version of software that may not have
ben fully tested or may hav eincompatible changes made. simple: downgrade your
system.

> to configure.in fixes that error but then:
> 
> as -c asm_blend.S -fPIC -DPIC -o .libs/asm_blend.lo
> as: unrecognized option `-c'
> 
> where are the flags missconfigured?
> 
> ik
> 
> On Sun, 7 Oct 2001 16:48:02 +0200
> Martin Sarajervi <ms@...> wrote:
> 
> > * Igor Kofman (kofman@...) wrote:
> > > 
> > > I am trying to build CVS e17 on Debian sid. I fails as follows:
> > > 
> > > make[2]: Entering directory `/home/kofman/e17/libs/imlib2/src'
> > > /bin/sh ../libtool --mode=compile @AS@  @ASFLAGS@ -c -o asm_blend.lo `test
> -f asm_blend.S || echo './'`asm_blend.S
> > > rm -f .libs/asm_blend.lo
> > > @AS@ @ASFLAGS@ -c asm_blend.S  -fPIC -DPIC -o .libs/asm_blend.lo
> > > ../libtool: @AS@: command not found
> > > make[2]: *** [asm_blend.lo] Error 1
> > > make[2]: Leaving directory `/home/kofman/e17/libs/imlib2/src'
> > > make[1]: *** [all-recursive] Error 1
> > > make[1]: Leaving directory `/home/kofman/e17/libs/imlib2'
> > > make: *** [all] Error 2
> > > 
> > > 
> > > Not knowing much about the autoconf stuff which is involved I am not sure
> how to make it
> > > work.  Any ideas?  
> > > (I have as etc..)
> > 
> > 
> > Hmm, try deleting configure.ac if it's there. 
> > (doesn't autoconf tell you something about this?)
> > make distclean
> > 
> > and try again.
> > 
> > 
> > - Martin Sarajervi
> > 
> > _______________________________________________
> > enlightenment-devel mailing list
> > enlightenment-devel@...
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 
> 
> -- 
>
-------------------------------------------------------------------------------
> kofman@... 		       GPG Public Key: http://www.tambuka.net/key.html
> http://www.tambuka.net   	Key Signature: ED872B110DBF4EC8FE280350FF9E0C810792EA1D
>
-------------------------------------------------------------------------------
> 
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@...
Unemployed Bum                      raster@...
Mobile Phone: +61 (0)408 363 984    Home Phone: 02 9386 9362

* raster@... (raster@...) wrote:
> On Sun, 7 Oct 2001 12:49:53 -0500 Igor Kofman <kofman@...> babbled
> profusely:
> 
> > 
> > After reading Martin's post about Eterm, I saw the same autoconf error: 
> > "automake: src/Makefile.am: Assembler source seen but `ASFLAGS' not defined in
> > `configure.in'"
> > adding:
> > AC_SUBST(AS)
> > AC_SUBST(ASFLAGS)
> 
> that's not the problem. debian's libtool and/or automake package is putting
> these in expecting them to get substituted and they aren't. it shouldnt' be
> doing this as i shouldn not HAVE to AC_SUBST the ASFLAGS and AS variables - just
> like CFLAGS and CC. basically things suddenly broke due to an upgrade on your

Actually (although I know you are happy to have another chance to dig at
debian :)), I believe you _do_ have to set them. Here's the entry:

"automake: src/Makefile.am: Assembler source seen but `ASFLAGS' not
defined in `configure.in'"

i.e. if you have assembler source, automake expects you to define
ASFLAGS. It's in the automake docs too, so don't throw too much poo at
debian :)

Tom.
-- 
   .^.    .-------------------------------------------------------.
   /V\    | Tom Gilbert, London, England | http://linuxbrit.co.uk |
 /(   )\  | Open Source/UNIX consultant  | tom@...    |
  ^^-^^   `-------------------------------------------------------'

On Mon, 8 Oct 2001 05:38:12 +0100 Tom Gilbert <tom@...> babbled
profusely:

> * raster@... (raster@...) wrote:
> > On Sun, 7 Oct 2001 12:49:53 -0500 Igor Kofman <kofman@...> babbled
> > profusely:
> > 
> > > 
> > > After reading Martin's post about Eterm, I saw the same autoconf error: 
> > > "automake: src/Makefile.am: Assembler source seen but `ASFLAGS' not
> defined in
> > > `configure.in'"
> > > adding:
> > > AC_SUBST(AS)
> > > AC_SUBST(ASFLAGS)
> > 
> > that's not the problem. debian's libtool and/or automake package is putting
> > these in expecting them to get substituted and they aren't. it shouldnt' be
> > doing this as i shouldn not HAVE to AC_SUBST the ASFLAGS and AS variables -
> just
> > like CFLAGS and CC. basically things suddenly broke due to an upgrade on
> your
> 
> Actually (although I know you are happy to have another chance to dig at
> debian :)), I believe you _do_ have to set them. Here's the entry:
> 
> "automake: src/Makefile.am: Assembler source seen but `ASFLAGS' not
> defined in `configure.in'"
> 
> i.e. if you have assembler source, automake expects you to define
> ASFLAGS. It's in the automake docs too, so don't throw too much poo at
> debian :)

as i said in the above - it's debians package that changed - and it broke
compatability. automake/conf/libtool have no problems here.. andi'm hapily
sticking with 2.13 that has worked for a long time.. and still does.

now as for being in the docs:
[- 3:25PM /usr/share/info -]zcat auto* libtool.info* | grep ASFLAGS
[- 3:25PM /usr/share/info -]

even better:
(from the docs)
 - Variable: AS
     Program to use rather than checking for `as'.  Only meaningful for
     Cygwin/MS-Windows.

this is the only reference to it. it doesnt say its compulsory :) remember as i
said above the berakeage is due to the new packages that debian has started
using in unstable. as a matter of prinicple i try keep my host system as stabel
as possible whenevr working on code - that way stuff under doesnt change and
your'e not always having to deal with bugs & problems that aren't your own
whilst your'e busy enough with your own code :) i did say he shoudl downgrade
his packages - that may mean not using dbeian unstabel anymroe and reverting his
system to somehting older, or explcitly downgrading just those packages, or a
host of other options.

i'm not throwing poo at debain - i was saying its debians package that has made
this build cease workign on his debian system - the same source still works and
compiles 100% fine on my stable, not changing underneath me rh 7.1 system.

as i have said before - theres lots of debian people here - but it is as a
result of his distribution and his use of it that this stopped working all fo a
sudden - not a result of any code/build changes this end of things. :)


-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@...
Unemployed Bum                      raster@...
Mobile Phone: +61 (0)408 363 984    Home Phone: 02 9386 9362

On Monday, 08 October 2001, at 05:38:12 (+0100),
Tom Gilbert wrote:

> Actually (although I know you are happy to have another chance to
> dig at debian :)), I believe you _do_ have to set them. Here's the
> entry:
>
> "automake: src/Makefile.am: Assembler source seen but `ASFLAGS' not
> defined in `configure.in'"
> 
> i.e. if you have assembler source, automake expects you to define
> ASFLAGS. It's in the automake docs too, so don't throw too much poo
> at debian :)

Er, no.  ASFLAGS is not mentioned anywhere in any of the automake 1.4
info pages.  This indicates that the ASFLAGS requirement is new in
automake 1.5, which creates an incompatibility with older packages
(since automake 1.4 and older used the compiler to assemble, at least
on Linux).

I will not blame Debian for incompatibilities in software.  However,
historically Debian has given users a choice between unstable
(bleeding edge) and stable (so old as to be damn near useless).
Therefore, Debian users were essentially forced to use unstable and
were thus the source of countless complaints.

The fact is, Debian unstable is bleeding edge, and any complaints by
users living on that bleeding edge should be directed at Debian
developers, not software developers.  There is no reasonable
justification to expect software developers to use software which is
obviously neither commonplace nor ready for widespread use simply
because someone somewhere thought they'd upgrade a whole slew of
unsuspecting users.

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej@...>
n+1, Inc., http://www.nplus1.net/         Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
 "It is possible to commit no mistakes and still lose.  That is not a
  weakness; that is life."       -- Captain Picard, "Peak Performance"

* raster@... (raster@...) wrote:
> as i said in the above - it's debians package that changed - and it broke
> compatability. automake/conf/libtool have no problems here.. andi'm hapily
> sticking with 2.13 that has worked for a long time.. and still does.

Let's not have this same argument again please :

Debian is using the current stable release of auto* and you still have
really old packages. That's not a fault with debian, nor is the fact
that some small changes in recommended automake useage have occurred
between stable releases.

> now as for being in the docs:
> [- 3:25PM /usr/share/info -]zcat auto* libtool.info* | grep ASFLAGS
> [- 3:25PM /usr/share/info -]

Those are obviously docs for the old version you have raster.

> i'm not throwing poo at debain - i was saying its debians package that
> has made this build cease workign on his debian system - the same
> source still works and compiles 100% fine on my stable, not changing
> underneath me rh 7.1 system.

And again (this is the same as the last automake discussion we had),
that's because you have a butt old automake and the new version has some
changes. Someone already sent you a backwards compatible fix (use
AC_SUBST) that you can apply now and make it work, so stop trolling
about debian, realise the problem is a new version of the auto tools
which you don't have, and accept the change someone already sent you :)

Tom.
-- 
   .^.    .-------------------------------------------------------.
   /V\    | Tom Gilbert, London, England | http://linuxbrit.co.uk |
 /(   )\  | Open Source/UNIX consultant  | tom@...    |
  ^^-^^   `-------------------------------------------------------'

On Mon, 8 Oct 2001 06:49:24 +0100 Tom Gilbert <tom@...> babbled
profusely:

> * raster@... (raster@...) wrote:
> > as i said in the above - it's debians package that changed - and it broke
> > compatability. automake/conf/libtool have no problems here.. andi'm hapily
> > sticking with 2.13 that has worked for a long time.. and still does.
> 
> Let's not have this same argument again please :
> 
> Debian is using the current stable release of auto* and you still have
> really old packages. That's not a fault with debian, nor is the fact
> that some small changes in recommended automake useage have occurred
> between stable releases.

it's not that old - and works well. most distributions still use it.

> > now as for being in the docs:
> > [- 3:25PM /usr/share/info -]zcat auto* libtool.info* | grep ASFLAGS
> > [- 3:25PM /usr/share/info -]
> 
> Those are obviously docs for the old version you have raster.

yup :)

> > i'm not throwing poo at debain - i was saying its debians package that
> > has made this build cease workign on his debian system - the same
> > source still works and compiles 100% fine on my stable, not changing
> > underneath me rh 7.1 system.
> 
> And again (this is the same as the last automake discussion we had),
> that's because you have a butt old automake and the new version has some
> changes. Someone already sent you a backwards compatible fix (use
> AC_SUBST) that you can apply now and make it work, so stop trolling
> about debian, realise the problem is a new version of the auto tools
> which you don't have, and accept the change someone already sent you :)

they didnt seem to help him as u may have noticed :) still didnt compile. :)

> 
> Tom.
> -- 
>    .^.    .-------------------------------------------------------.
>    /V\    | Tom Gilbert, London, England | http://linuxbrit.co.uk |
>  /(   )\  | Open Source/UNIX consultant  | tom@...    |
>   ^^-^^   `-------------------------------------------------------'


-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@...
Unemployed Bum                      raster@...
Mobile Phone: +61 (0)408 363 984    Home Phone: 02 9386 9362

* Michael Jennings (e-devel@...) wrote:
> The fact is, Debian unstable is bleeding edge, and any complaints by
> users living on that bleeding edge should be directed at Debian
> developers, not software developers.  There is no reasonable
> justification to expect software developers to use software which is
> obviously neither commonplace nor ready for widespread use simply
> because someone somewhere thought they'd upgrade a whole slew of
> unsuspecting users.

*sigh.

Read this carefully.

The version of auto* in debian is EXACTLY the version you would get if
you went to gnu.org, clicked "download current version", and installed
it.

It's not a cvs release (in debian these always have a foobar-cvs package
name) or an unauthorised beta release (for example redhat's last
compiler). It's the current stable version of the software. Stop
misunderstanding the reasoning for debian's "unstable" monicker.

"There is no reasonable justification to expect software developers to
use software which is obviously neither commonplace nor ready for
widespread use".

Is just horseshit because this is a stable release of the software :)

Tom.
-- 
   .^.    .-------------------------------------------------------.
   /V\    | Tom Gilbert, London, England | http://linuxbrit.co.uk |
 /(   )\  | Open Source/UNIX consultant  | tom@...    |
  ^^-^^   `-------------------------------------------------------'

* raster@... (raster@...) wrote:
> > > i'm not throwing poo at debain - i was saying its debians package that
> > > has made this build cease workign on his debian system - the same
> > > source still works and compiles 100% fine on my stable, not changing
> > > underneath me rh 7.1 system.
> > 
> > And again (this is the same as the last automake discussion we had),
> > that's because you have a butt old automake and the new version has some
> > changes. Someone already sent you a backwards compatible fix (use
> > AC_SUBST) that you can apply now and make it work, so stop trolling
> > about debian, realise the problem is a new version of the auto tools
> > which you don't have, and accept the change someone already sent you :)
> 
> they didnt seem to help him as u may have noticed :) still didnt compile. :)

This is because configure was using gcc flags for as - again because of
the way the new automake ASFLAGS stuff works.

Could you fix your mailer so that it doesn't add two "From" lines and
two "To" lines to every mail please? It's a wonder your emails get where
you send them at all :)p

Tom.
-- 
   .^.    .-------------------------------------------------------.
   /V\    | Tom Gilbert, London, England | http://linuxbrit.co.uk |
 /(   )\  | Open Source/UNIX consultant  | tom@...    |
  ^^-^^   `-------------------------------------------------------'

On Monday, 08 October 2001, at 07:14:08 (+0100),
Tom Gilbert wrote:

> The version of auto* in debian is EXACTLY the version you would get
> if you went to gnu.org, clicked "download current version", and
> installed it.

Yes, I'm aware of that.  That is irrelevant.

> It's not a cvs release (in debian these always have a foobar-cvs
> package name) or an unauthorised beta release (for example redhat's
> last compiler). It's the current stable version of the
> software.

It is the current release of the software, yes.  Whether or not it is
"stable" is a matter of opinion.  Just because a release is made
doesn't make it stable.

> Stop misunderstanding the reasoning for debian's "unstable"
> monicker.

I haven't.  Many Debian developers will agree that Debian unstable is
subject to breakage at their whim.  Case in point:  Brandon Robinson.
'Nuff said.

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej@...>
n+1, Inc., http://www.nplus1.net/         Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
 "I don't mind the sun sometimes, the images it shows.  I can taste
  you on my lips and smell you in my clothes.  Cinnamon-and-sugary and
  softly-spoken lies.  You never know just how you look through other
  people's eyes."                        -- Butthole Surfers, "Pepper"

On Mon, 8 Oct 2001 07:14:08 +0100 Tom Gilbert <tom@...> babbled
profusely:

> It's not a cvs release (in debian these always have a foobar-cvs package
> name) or an unauthorised beta release (for example redhat's last
> compiler). It's the current stable version of the software. Stop
> misunderstanding the reasoning for debian's "unstable" monicker.
> 
> "There is no reasonable justification to expect software developers to
> use software which is obviously neither commonplace nor ready for
> widespread use".

but mej is right. it is not commonplace. it's new. as of a few motnhs ago not
one "stable" (ie on a cd or downloadable/installable) dsitribution used it. mej
is right. if there were a godo reaosn to use it (ie the previous version had
problems we've encountered and had to just live with and the new one magically
solves it) then there'd be a good reaosn to move. but right now its a new
version just for the sake of it - as far as development here is concerned. and
new versions for the sake fo it from a developers poitn of view is not good -
ESPECIALLy if they break what u already have. :)

> Is just horseshit because this is a stable release of the software :)

a new stable release. windows xp is a new stabel release. does this mean u'll
use it the moment it coems out? or every version of anything? no - i generally
liek tpo let it mature. i only use brand spanking new thing sif i NEED their
funtionality - or fixes... or it'm my own stuff and i can kick my own bum for
any problems i might have :)


-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@...
Unemployed Bum                      raster@...
Mobile Phone: +61 (0)408 363 984    Home Phone: 02 9386 9362

* Michael Jennings (e-devel@...) wrote:
> On Monday, 08 October 2001, at 07:14:08 (+0100),
> Tom Gilbert wrote:
> 
> > The version of auto* in debian is EXACTLY the version you would get
> > if you went to gnu.org, clicked "download current version", and
> > installed it.
> 
> Yes, I'm aware of that.  That is irrelevant.

Hardly, it's why I wrote the email - raster was trolling debian again
when the problem is the new automake release :

> > It's not a cvs release (in debian these always have a foobar-cvs
> > package name) or an unauthorised beta release (for example redhat's
> > last compiler). It's the current stable version of the
> > software.
> 
> It is the current release of the software, yes.  Whether or not it is
> "stable" is a matter of opinion.  Just because a release is made
> doesn't make it stable.

It's a "stable release", i.e. not an alpha or "test" release, that's
simply the point I was making. Of course that doesn't mean "bug free",
but there's a world of difference between, say, packagain the latest
version of something from the GNU website, or checking the latest
version out of CVS and releasing it as stable without their consent.
Ring any bells? :
 
> > Stop misunderstanding the reasoning for debian's "unstable"
> > monicker.
> 
> I haven't.  Many Debian developers will agree that Debian unstable is
> subject to breakage at their whim.  Case in point:  Brandon Robinson.
> 'Nuff said.

Of course, it's the staging point for the next debian version - big
changes happen from time to time. That said, "unstable" refers to it
constantly changing, it doesn't mean "includes unstable versions of all
software", as some people seem to think.

People who use debian unstable _do_ take a risk that a bug in a new
"stable" release of some piece of software could cause problems with
their system (there was a pam thing a while ago). But those people also
perform an invaluable service to the community, as most testing of new
software happens here, not when redhat include it a year later.

All I ask is that when a debian user gives you a heads up on a problem
you redhat users may face in a year or two (whenever you catch up), that
you don't tell him "bugger off, it's debian's fault", as raster does -
every time. Okay? :)

Tom.
-- 
   .^.    .-------------------------------------------------------.
   /V\    | Tom Gilbert, London, England | http://linuxbrit.co.uk |
 /(   )\  | Open Source/UNIX consultant  | tom@...    |
  ^^-^^   `-------------------------------------------------------'

On Mon, 8 Oct 2001 07:18:07 +0100 Tom Gilbert <tom@...> babbled
profusely:

> * raster@... (raster@...) wrote:
> > > > i'm not throwing poo at debain - i was saying its debians package that
> > > > has made this build cease workign on his debian system - the same
> > > > source still works and compiles 100% fine on my stable, not changing
> > > > underneath me rh 7.1 system.
> > > 
> > > And again (this is the same as the last automake discussion we had),
> > > that's because you have a butt old automake and the new version has some
> > > changes. Someone already sent you a backwards compatible fix (use
> > > AC_SUBST) that you can apply now and make it work, so stop trolling
> > > about debian, realise the problem is a new version of the auto tools
> > > which you don't have, and accept the change someone already sent you :)
> > 
> > they didnt seem to help him as u may have noticed :) still didnt compile. :)
> 
> This is because configure was using gcc flags for as - again because of
> the way the new automake ASFLAGS stuff works.
> 
> Could you fix your mailer so that it doesn't add two "From" lines and
> two "To" lines to every mail please? It's a wonder your emails get where
> you send them at all :)p

yeah.. i need to fix that... eventually :) they get ther because the lines are
the same... and well.. smtp doenst really care much :)

> Tom.
> -- 
>    .^.    .-------------------------------------------------------.
>    /V\    | Tom Gilbert, London, England | http://linuxbrit.co.uk |
>  /(   )\  | Open Source/UNIX consultant  | tom@...    |
>   ^^-^^   `-------------------------------------------------------'
> 
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@...
Unemployed Bum                      raster@...
Mobile Phone: +61 (0)408 363 984    Home Phone: 02 9386 9362

* raster@... (raster@...) wrote:
> > Could you fix your mailer so that it doesn't add two "From" lines and
> > two "To" lines to every mail please? It's a wonder your emails get where
> > you send them at all :)p
>=20
> yeah.. i need to fix that... eventually :) they get ther because the line=
s are
> the same... and well.. smtp doenst really care much :)

To: tom@..., enlightenment-devel@...
To: Tom Gilbert <tom@...>
From: raster@...
From: Carsten Haitzler (The Rasterman) <raster@...>

No raster, they aren't the same. One goes to the list and the other
doesn't, one says who you are and the other doesn't.

I would say you that in the "To:" case, you are lucky that whatever bug
or misconfiguration is causing it makes the line you intended be at the
top. However you are out of luck on the latter case, methinks :)

Tom.
--=20
   .^.    .-------------------------------------------------------.
   /V\    | Tom Gilbert, London, England | http://linuxbrit.co.uk |
 /(   )\  | Open Source/UNIX consultant  | tom@...    |
  ^^-^^   `-------------------------------------------------------'

* raster@... (raster@...) wrote:
> On Mon, 8 Oct 2001 07:14:08 +0100 Tom Gilbert <tom@...> babbled
> profusely:
> 
> > It's not a cvs release (in debian these always have a foobar-cvs package
> > name) or an unauthorised beta release (for example redhat's last
> > compiler). It's the current stable version of the software. Stop
> > misunderstanding the reasoning for debian's "unstable" monicker.
> > 
> > "There is no reasonable justification to expect software developers to
> > use software which is obviously neither commonplace nor ready for
> > widespread use".
> 
> but mej is right. it is not commonplace. it's new. as of a few motnhs ago not
> one "stable" (ie on a cd or downloadable/installable) dsitribution used it. mej
> is right. if there were a godo reaosn to use it (ie the previous version had
> problems we've encountered and had to just live with and the new one magically
> solves it) then there'd be a good reaosn to move. but right now its a new
> version just for the sake of it - as far as development here is concerned. and
> new versions for the sake fo it from a developers poitn of view is not good -
> ESPECIALLy if they break what u already have. :)

No but what I am saying is that if it's the current release, you have to
expect users to go and download it. Whether you decide to fix your setup
for the changes in the new version, or tell people to downgrade, I don't
much care. As ever, I object to you trolling about distributions, not
you sticking with old versions of development tools. "Nuff said" :)

Tom.
-- 
   .^.    .-------------------------------------------------------.
   /V\    | Tom Gilbert, London, England | http://linuxbrit.co.uk |
 /(   )\  | Open Source/UNIX consultant  | tom@...    |
  ^^-^^   `-------------------------------------------------------'

On Mon, 8 Oct 2001 08:08:13 +0100 Tom Gilbert <tom@...> babbled
profusely:

> No but what I am saying is that if it's the current release, you have to
> expect users to go and download it. Whether you decide to fix your setup

aaaah! here is where we differ. these are not users. if u get code form cvs and
use automake, autoconf etc. to build configure scritp and makefile.in's.. you
are no longer a user. you are now a developer. those tools are not required and
should nto be needed on any end-user system at all- thats the idea of them. they
are developer tools only. when we finally are ready we build the configure critp
and makefile.in's  here and then throw out a tarball. at this point the .in's
and .am's arent actually needed anymore (i actually shoudl strip them out of the
final tar.gz as they are packager/relase moaintainer files only - as well as
autogen.sh).

anyway.. thats where we differ :)  yes - as far as end users.. yes - i shoudl
definitely (aroudn nearing time of release) make sure to the greatest extent the
package will build form the TARBALL on as many systems as possible (given they
meet the requirments) and make sure the tarball tells u what requirements you
fail to meet.

> for the changes in the new version, or tell people to downgrade, I don't
> much care. As ever, I object to you trolling about distributions, not
> you sticking with old versions of development tools. "Nuff said" :)

my facts were still correct. i didnt troll - i stated facts - and they still
stand. :)

> Tom.
> -- 
>    .^.    .-------------------------------------------------------.
>    /V\    | Tom Gilbert, London, England | http://linuxbrit.co.uk |
>  /(   )\  | Open Source/UNIX consultant  | tom@...    |
>   ^^-^^   `-------------------------------------------------------'
> 
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@...
Unemployed Bum                      raster@...
Mobile Phone: +61 (0)408 363 984    Home Phone: 02 9386 9362

On Monday, 08 October 2001, at 07:52:57 (+0100),
Tom Gilbert wrote:

> Hardly, it's why I wrote the email - raster was trolling debian
> again when the problem is the new automake release :

No, the problem is neither the new automake release nor Debian.  The
problem is that Debian developers use unstable as a platform for
diving whole-hog into hot-off-the-presses software, and users come
bitching to *us* when things unexpectedly change behind their backs.

> It's a "stable release", i.e. not an alpha or "test" release, that's
> simply the point I was making. Of course that doesn't mean "bug
> free", but there's a world of difference between, say, packagain the
> latest version of something from the GNU website, or checking the
> latest version out of CVS and releasing it as stable without their
> consent.  Ring any bells? :

I would just like to state that I was extremely vocal against RedHat
for releasing the clusterfuck of gcc that came with 7.0.  I'm not some
die-hard religious pro-RedHat zealot.  All distributions have their
problems.  This particular situation happens to highlight one of
Debian's flaws:  the difference between users' expectations and
Debian's reality.

> Of course, it's the staging point for the next debian version - big
> changes happen from time to time. That said, "unstable" refers to it
> constantly changing, it doesn't mean "includes unstable versions of
> all software", as some people seem to think.

I believe "testing" is now the staging point for release.  It's what
Debian came up with when they finally realized what I and others like
me have been saying for *ages*; that Debian needed a middle ground
between "old as ass" and "meat so fresh it's still mooing."

> People who use debian unstable _do_ take a risk that a bug in a new
> "stable" release of some piece of software could cause problems with
> their system (there was a pam thing a while ago).

Not always knowingly.

> But those people also perform an invaluable service to the
> community, as most testing of new software happens here, not when
> redhat include it a year later.

One could make the same argument about RH putting out that gcc 2.96
package.  I'd wager the pre-3.0 gcc got far more testing from that
than from Debian users.

As for the distro argument you've turned this into, I would just like
to point out that RedHat's Rawhide is essentially the same as Debian's
unstable, and those who want to live on the bleeding edge are free to
use it.  RedHat releases are intended to be stable, production-quality
platforms.  Of course, their *.0 releases often don't provide this,
but then again, RedHat releases multiple times a year, whereas Debian
releases happen less than even once a year.

> All I ask is that when a debian user gives you a heads up on a problem
> you redhat users may face in a year or two (whenever you catch up),

You mean when it's been proven stable and had the initial bugs
resolved? :)

> that you don't tell him "bugger off, it's debian's fault", as raster
> does - every time. Okay? :)

No, it's his/her own fault for using Debian unstable.  If someone were
bitching about problems with RedHat Rawhide, I'd make the same
argument.  It just so happens that more Debian users choose unstable
than RedHat users choose Rawhide, primarily due to historical lack of
options.

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej@...>
n+1, Inc., http://www.nplus1.net/         Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
 "Would you know my name if I saw you in heaven?  Would it be the same
  if I saw you in heaven?  I must be strong and carry on, 'cause I
  know I don't belong here in heaven."
                                    -- Eric Clapton, "Tears in Heaven"

You guys argue way too much, makes me wonder how e16 ever got written.. :)   
But the screenshots Brian posted keep me hopefull... 
Adding:

ASFLAGS="$ASFLAGS -I../"
AM_PROG_AS

to configure.in will fix the problem with automake1.5 .  Hope it doesn't brake
anything elsewhere... there you go making me start to learn auto*. Argh.

ik
-- 
-------------------------------------------------------------------------------
kofman@... 		       GPG Public Key: http://www.tambuka.net/key.html
 http://www.tambuka.net   	Key Signature: ED872B110DBF4EC8FE280350FF9E0C810792EA1D
-------------------------------------------------------------------------------

On Mon, Oct 08, 2001 at 06:49:24AM +0100, Tom Gilbert muttered...
: * raster@... (raster@...) wrote:
: > as i said in the above - it's debians package that changed - and it broke
: > compatability. automake/conf/libtool have no problems here.. andi'm hapily
: > sticking with 2.13 that has worked for a long time.. and still does.
: 
: Let's not have this same argument again please :
: 
: Debian is using the current stable release of auto* and you still have
: really old packages. That's not a fault with debian, nor is the fact
: that some small changes in recommended automake useage have occurred
: between stable releases.
: 
: > now as for being in the docs:
: > [- 3:25PM /usr/share/info -]zcat auto* libtool.info* | grep ASFLAGS
: > [- 3:25PM /usr/share/info -]
: 
: Those are obviously docs for the old version you have raster.

chris@...:~> cd /usr/share/info/
chris@...> zcat auto* libtool.info* | grep ASFLAGS
libtool.info*.gz: No such file or directory
chris@...> 

And i am on debian unstable with 2.5 installed (well strictly speaking 2.52)

: > i'm not throwing poo at debain - i was saying its debians package that
: > has made this build cease workign on his debian system - the same
: > source still works and compiles 100% fine on my stable, not changing
: > underneath me rh 7.1 system.
: 
: And again (this is the same as the last automake discussion we had),
: that's because you have a butt old automake and the new version has some
: changes. Someone already sent you a backwards compatible fix (use
: AC_SUBST) that you can apply now and make it work, so stop trolling
: about debian, realise the problem is a new version of the auto tools
: which you don't have, and accept the change someone already sent you :)

I think flamers should stop defusing their argument with a smiliy face at the
end of the rant. It makes it so much more tame.

Regards,

Chris
-- 
Chris Ross (boris) [ chris@..., http://www.darkrock.co.uk ]
                   [ (chris|boris)@ferite.org, http://www.ferite.org ]
"If speed scares you, try Windows..."

* raster@... (raster@...) wrote:
> On Mon, 8 Oct 2001 08:08:13 +0100 Tom Gilbert <tom@...> babbled
> profusely:
> 
> > No but what I am saying is that if it's the current release, you have to
> > expect users to go and download it. Whether you decide to fix your setup
> 
> aaaah! here is where we differ. these are not users. if u get code
> form cvs and use automake, autoconf etc. to build configure scritp and
> makefile.in's.. you are no longer a user. you are now a developer.
> those tools are not required and should nto be needed on any end-user
> system at all- thats the idea of them. they are developer tools only.
> when we finally are ready we build the configure critp and
> makefile.in's  here and then throw out a tarball. at this point the
> .in's and .am's arent actually needed anymore (i actually shoudl strip
> them out of the final tar.gz as they are packager/relase moaintainer
> files only - as well as autogen.sh).

Then stop doing interviews telling _users_ how cool the stuff in CVS is,
stop pointing to it on the website and stop raving about it in IRC :)p

> > for the changes in the new version, or tell people to downgrade, I don't
> > much care. As ever, I object to you trolling about distributions, not
> > you sticking with old versions of development tools. "Nuff said" :)
> 
> my facts were still correct. i didnt troll - i stated facts - and they still
> stand. :)

No I'm sorry you did troll. "It's debian's fault", "they shipped an
unstable version of automake", these things aren't facts :)

Tom.
-- 
   .^.    .-------------------------------------------------------.
   /V\    | Tom Gilbert, London, England | http://linuxbrit.co.uk |
 /(   )\  | Open Source/UNIX consultant  | tom@...    |
  ^^-^^   `-------------------------------------------------------'

* Michael Jennings (e-devel@...) wrote:
> On Monday, 08 October 2001, at 07:52:57 (+0100),
> > that you don't tell him "bugger off, it's debian's fault", as raster
> > does - every time. Okay? :)
> 
> No, it's his/her own fault for using Debian unstable.  If someone were
> bitching about problems with RedHat Rawhide, I'd make the same
> argument.  It just so happens that more Debian users choose unstable
> than RedHat users choose Rawhide, primarily due to historical lack of
> options.

So if the user has gone to gnu.org and got the current version of the
software, it's their fault too? That logic escapes me :)

Tom.
-- 
   .^.    .-------------------------------------------------------.
   /V\    | Tom Gilbert, London, England | http://linuxbrit.co.uk |
 /(   )\  | Open Source/UNIX consultant  | tom@...    |
  ^^-^^   `-------------------------------------------------------'

On Mon, 8 Oct 2001 11:33:28 +0100 Tom Gilbert <tom@...> babbled
profusely:

> * raster@... (raster@...) wrote:
> > On Mon, 8 Oct 2001 08:08:13 +0100 Tom Gilbert <tom@...> babbled
> > profusely:
> > 
> > > No but what I am saying is that if it's the current release, you have to
> > > expect users to go and download it. Whether you decide to fix your setup
> > 
> > aaaah! here is where we differ. these are not users. if u get code
> > form cvs and use automake, autoconf etc. to build configure scritp and
> > makefile.in's.. you are no longer a user. you are now a developer.
> > those tools are not required and should nto be needed on any end-user
> > system at all- thats the idea of them. they are developer tools only.
> > when we finally are ready we build the configure critp and
> > makefile.in's  here and then throw out a tarball. at this point the
> > .in's and .am's arent actually needed anymore (i actually shoudl strip
> > them out of the final tar.gz as they are packager/relase moaintainer
> > files only - as well as autogen.sh).
> 
> Then stop doing interviews telling _users_ how cool the stuff in CVS is,
> stop pointing to it on the website and stop raving about it in IRC :)p

peoelp as q's - i answer them. so do i say "i wont talk abotu anything i'm
doing" to peoel asking for interviews? i think not.

> > > for the changes in the new version, or tell people to downgrade, I don't
> > > much care. As ever, I object to you trolling about distributions, not
> > > you sticking with old versions of development tools. "Nuff said" :)
> > 
> > my facts were still correct. i didnt troll - i stated facts - and they still
> > stand. :)
> 
> No I'm sorry you did troll. "It's debian's fault", "they shipped an
> unstable version of automake", these things aren't facts :)

i didnt say that.. here is my mail:
...
that's not the problem. debian's libtool and/or automake package is putting
these in expecting them to get substituted and they aren't. it shouldnt' be
doing this as i shouldn not HAVE to AC_SUBST the ASFLAGS and AS variables - just
like CFLAGS and CC. basically things suddenly broke due to an upgrade on your
system - due to debian's upgrading t a new version of software that may not have
ben fully tested or may hav eincompatible changes made. simple: downgrade your
system.
...
that is the exact quote. i stick by what i said.

> Tom.
> -- 
>    .^.    .-------------------------------------------------------.
>    /V\    | Tom Gilbert, London, England | http://linuxbrit.co.uk |
>  /(   )\  | Open Source/UNIX consultant  | tom@...    |
>   ^^-^^   `-------------------------------------------------------'
> 
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@...
Unemployed Bum                      raster@...
Mobile Phone: +61 (0)408 363 984    Home Phone: 02 9386 9362

* raster@... (raster@...) wrote:
> On Mon, 8 Oct 2001 11:33:28 +0100 Tom Gilbert <tom@...> babbled
> profusely:
> 
> > * raster@... (raster@...) wrote:
> > > On Mon, 8 Oct 2001 08:08:13 +0100 Tom Gilbert <tom@...> babbled
> > > profusely:
> > > 
> > > > No but what I am saying is that if it's the current release, you have to
> > > > expect users to go and download it. Whether you decide to fix your setup
> > > 
> > > aaaah! here is where we differ. these are not users. if u get code
> > > form cvs and use automake, autoconf etc. to build configure scritp and
> > > makefile.in's.. you are no longer a user. you are now a developer.
> > > those tools are not required and should nto be needed on any end-user
> > > system at all- thats the idea of them. they are developer tools only.
> > > when we finally are ready we build the configure critp and
> > > makefile.in's  here and then throw out a tarball. at this point the
> > > .in's and .am's arent actually needed anymore (i actually shoudl strip
> > > them out of the final tar.gz as they are packager/relase moaintainer
> > > files only - as well as autogen.sh).
> > 
> > Then stop doing interviews telling _users_ how cool the stuff in CVS is,
> > stop pointing to it on the website and stop raving about it in IRC :)p
> 
> peoelp as q's - i answer them. so do i say "i wont talk abotu anything i'm
> doing" to peoel asking for interviews? i think not.
> 
> > > > for the changes in the new version, or tell people to downgrade, I don't
> > > > much care. As ever, I object to you trolling about distributions, not
> > > > you sticking with old versions of development tools. "Nuff said" :)
> > > 
> > > my facts were still correct. i didnt troll - i stated facts - and they still
> > > stand. :)
> > 
> > No I'm sorry you did troll. "It's debian's fault", "they shipped an
> > unstable version of automake", these things aren't facts :)
> 
> i didnt say that.. here is my mail:
> ...
> that's not the problem. debian's libtool and/or automake package is putting
> these in expecting them to get substituted and they aren't. it shouldnt' be
> doing this as i shouldn not HAVE to AC_SUBST the ASFLAGS and AS variables - just
> like CFLAGS and CC. basically things suddenly broke due to an upgrade on your
> system - due to debian's upgrading t a new version of software that may not have
> ben fully tested or may hav eincompatible changes made. simple: downgrade your
> system.
> ...
> that is the exact quote. i stick by what i said.

And here's the exact quote from automake 1.5-1 info file:

`AM_PROG_AS'
     Use this macro when you have assembly code in your project.  This
     will choose the assembler for you (by default the C compiler),
     and will set `ASFLAGS' if required.

So what? Either it's time to correct configure.in and/or configure.ac
(both in Eterm and Imlib2), either you should put somewhere that
automake < 1.5 is a requirement to compile Imlib2 and Eterm.

I solved my compile problems by downgrading to automake 1.4-p4-1
(Debian/Sid) but I think this new macro in automake 1.5 is much more a
feature than a bug.

Regards,
Jerome

-- 
+-------------------------------------------------------------------+
|               'the panorama of the city is wrong                  |
|               in fact the city seems to be gone!'                 |
|                 the clash, stop the world, 1980                   |
+-------------------------------------------------------------------+

Jerome De Greef wrote:
> 
> And here's the exact quote from automake 1.5-1 info file:
> 
> `AM_PROG_AS'
>      Use this macro when you have assembly code in your project.  This
>      will choose the assembler for you (by default the C compiler),
>      and will set `ASFLAGS' if required.
> 
> So what? Either it's time to correct configure.in and/or configure.ac
> (both in Eterm and Imlib2), either you should put somewhere that
> automake < 1.5 is a requirement to compile Imlib2 and Eterm.
> 
> I solved my compile problems by downgrading to automake 1.4-p4-1
> (Debian/Sid) but I think this new macro in automake 1.5 is much more a
> feature than a bug.

Right. Raster, to save us from threads like this one and "You said
Debian sucks" -- "No I didn't" -- "You said that I said that you said it
sucks" in the future, please invest those 2.5 minutes to upgrade and
then this issue is over for good, okay? I'm tired of this. Thanks :D
 
Regards,
-- Christian.
________________________________________________________________________
                                                    http://www.whoop.org

> ... but then again, RedHat releases multiple times a
> year, whereas Debian releases happen less than even
> once a year.

Those are *marketing* department decisions as to when a new
'release' should be put out. Look at how different software
jumps in release numbers in order to catch up with others.
Didn't Slackware jump from a relatively low number up to v7.x
about a year ago ?? Suse, Mandrake, and others were up around
that version, so Slackware doesn't want to be perceived as
"'x' versions behind...".

Pick some versions of packages that are included in Redhat's
latest release and see what version is currently in Debian
'testing'. Plenty of people will argue that Redhat's releases
often can't be considered real stable...


Hall

* Christian Kreibich (kreibich@...) wrote:
> Jerome De Greef wrote:
> > 
> > And here's the exact quote from automake 1.5-1 info file:
> > 
> > `AM_PROG_AS'
> >      Use this macro when you have assembly code in your project.  This
> >      will choose the assembler for you (by default the C compiler),
> >      and will set `ASFLAGS' if required.
> > 
> > So what? Either it's time to correct configure.in and/or configure.ac
> > (both in Eterm and Imlib2), either you should put somewhere that
> > automake < 1.5 is a requirement to compile Imlib2 and Eterm.
> > 
> > I solved my compile problems by downgrading to automake 1.4-p4-1
> > (Debian/Sid) but I think this new macro in automake 1.5 is much more a
> > feature than a bug.
> 
> Right. Raster, to save us from threads like this one and "You said
> Debian sucks" -- "No I didn't" -- "You said that I said that you said it
> sucks" in the future, please invest those 2.5 minutes to upgrade and
> then this issue is over for good, okay? I'm tired of this. Thanks :D

What? You said that I said that Giblet said that Raster said that Debian
sucks ;)

I suck too because I posted a mail about this yesterday without even
noticing that there was already a thread on the topic... Sorry.

Jerome

-- 
+-------------------------------------------------------------------+
|               'the panorama of the city is wrong                  |
|               in fact the city seems to be gone!'                 |
|                 the clash, stop the world, 1980                   |
+-------------------------------------------------------------------+

* Christian Kreibich (kreibich@...) wrote:
> Right. Raster, to save us from threads like this one and "You said
> Debian sucks" -- "No I didn't" -- "You said that I said that you said it
> sucks" in the future, please invest those 2.5 minutes to upgrade and
> then this issue is over for good, okay? I'm tired of this. Thanks :D

I can't agree more.

I also can't believe we're still arguing about this like it has anything
to do with a distribution. And no one reply saying it does, please -- I
don't agree with you, 300 pages of email isn't going to make me agree
with your indefensible desire to attack a distribution about an API
change in a piece of ubiquitous software that they have no direct
control over, and I really have no interest in reading it. Instead,
someone just make me read a commits email fixing it, or tell me where I
make the changes that will produce one.

term

On Monday, 08 October 2001, at 09:00:23 (-0400),
Hall Stevenson wrote:

> Those are *marketing* department decisions as to when a new
> 'release' should be put out.

Not entirely.  If the marketing department were calling all the shots,
RH 7.2 would've been released for LinuxWorld back in August.

> Look at how different software jumps in release numbers in order to
> catch up with others.

RedHat did no such thing.

> Didn't Slackware jump from a relatively low number up to v7.x about
> a year ago ?? Suse, Mandrake, and others were up around that
> version, so Slackware doesn't want to be perceived as "'x' versions
> behind...".

So what's your point?

> Pick some versions of packages that are included in Redhat's latest
> release and see what version is currently in Debian 'testing'.

Again, if you're trying to make a point here, please make it.

> Plenty of people will argue that Redhat's releases often can't be
> considered real stable...

I'm not sure who these "plenty of people" are, but having worked with
RedHat over several release cycles, I can say that RedHat 7.0 was
certainly an awful release, but 6.2 and 7.1 were both quite solid.  I
run RH-VALE 7.1.1 on all my systems, and it was proven quite reliable.

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej@...>
n+1, Inc., http://www.nplus1.net/         Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
 "Who are you people?"  "We're writers."  "What are you striking for?"
 "More money."  "How much do you earn?"  "$350,000."
                -- conversation with striking Writer's Guild member as
                   reported by Bernard Weintraub in the New York Times

On Mon, 08 Oct 2001 16:40:30 +1000, raster@... said:

> a new stable release. windows xp is a new stabel release. does this mean u'll
> use it the moment it coems out? or every version of anything? no - i generally
> liek tpo let it mature. i only use brand spanking new thing sif i NEED their
> funtionality - or fixes... or it'm my own stuff and i can kick my own bum for
> any problems i might have :)

Amen.  The 4 machines in my office are usually riding close to the
bleeding edge - that's what they are FOR.  I had AIX 5.0 in my office,
which was a 'developer only' early release.  On the other hand, the IBM
machines across the hall will probably *start* seeing AIX 5.1 in May
or so....

Of course, I end up doing my share of bitching about compatability issues
as well.  Sometimes it's fairly easy to support the bleeding edge and still
work under the old stuff.  Sometimes it's a bitch.  And I'll leave it at that. 

/Valdis

On Mon, 08 Oct 2001 16:55:55 +1000, raster@... said:

> yeah.. i need to fix that... eventually :) they get ther because the lines are
> the same... and well.. smtp doenst really care much :)

Yes, but some software does.  I know for a *fact* that LSoft's Listserv
product will piss and moan vehemently if it finds duplicate headers,
broken headers, or missing headers.  I should know, enough of them bounce
back to my mailbox. ;)

(For the curious, the biggest offenders are older Eudora's injecting a
duplicate Message-ID: header, broken/duplicate From: lines (hi raster ;),
and spamware and others that send old RFC822 'To: multiple-groups: ;'
group syntax)
-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

So when I boot e17 I get as far as the background coming up and then things die:
e17: relocation error: e17: undefined symbol efsd_cleanup_event
efsd crashes and gdb comes up but it complains that it can't get a stack trace because
connection was reset by peer and it suddenly can't find the child proceess.
Did I miss something, fam's up, efsd's up and I just start with .xinitrc having only
e17.
Let me know why I'm being stupid :),

ik
-- 
-------------------------------------------------------------------------------
kofman@... 		       GPG Public Key: http://www.tambuka.net/key.html
 http://www.tambuka.net   	Key Signature: ED872B110DBF4EC8FE280350FF9E0C810792EA1D
-------------------------------------------------------------------------------

Igor Kofman schrieb:
> 
> So when I boot e17 I get as far as the background coming up and then things die:
> e17: relocation error: e17: undefined symbol efsd_cleanup_event

You have a broken build I'd say :) make install for efsd again, and
rebuild e17.

> efsd crashes and gdb comes up but it complains that it can't get a stack trace because

Eh? It shouldn't. Did you successfully make install for efsd?

> Did I miss something, fam's up, efsd's up and I just start with .xinitrc having only
> e17.

Again, I do not recommend starting e17 from startup scripts. Run it from
a terminal to see the output, and launch efsd separetely so that you can
start it as efsd -f -d.

-- Christian.
________________________________________________________________________
                                                    http://www.whoop.org

make install on efd works without any complaints. i did as you suggested but still
have the same problem here's the efsd output when i run e17:

efsd [1024]: New connection -- client 0.
efsd [1024]: Read timed out... 4
efsd [2051]: Handling STARTMON_FILE
efsd [2051]: Looking up /home/kofman, as dir: 0
efsd [2051]: Looking up /home/kofman in stat cache
efsd [2051]: Looking up /home/kofman, as dir: 0
efsd [2051]: Comparing /home/kofman 0 -- /home/kofman 0
efsd [2051]: Returning 0
efsd [2051]: /home/kofman is monitored, dir requested: 0, monitored as dir: 0
efsd [2051]: Incrementing internal use count for monitoring file /home/kofman, now (1/1).
efsd [2051]: Starting monitoring file /home/kofman.
efsd [1026]: Handling FAM event 8 for file /home/kofman
efsd [1026]: Handling FAM event 9 for file /home/kofman
Efsd [12154] received signal 11, attempting stack trace.
Launching /usr/bin/gdb -x /usr/local/share/efsd/gdb.scr /home/kofman/code/e17/apps/efsd/efsd 12154
Error: Connection reset by peer
efsd [1024]: Closing connection 0
efsd [1024]: Client 0 found monitoring /home/kofman, use count now (1/0)
efsd [1024]: Removing client 0 from monitor for /home/kofman
GNU gdb 5.0.90-cvs (MI_OUT)
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-linux"..."/home/kofman/code/e17/apps/efsd/efsd": not in executable format: Is a directory

//12154: No such file or directory.
Attaching to process 12154
Child process unexpectedly missing: No child processes.

here's what e says:
kofman@...:~$ e17 
e_view_file_added(1, "/home/kofman");
e17: relocation error: e17: undefined symbol: efsd_cleanup_event
kofman@...:~$ 

ideas?

ik
--

Around Wed, 10 Oct 2001 11:55:54 +0200
Christian Kreibich <kreibich@...> did say:

> 
> 
> Igor Kofman schrieb:
> > 
> > So when I boot e17 I get as far as the background coming up and then things die:
> > e17: relocation error: e17: undefined symbol efsd_cleanup_event
> 
> You have a broken build I'd say :) make install for efsd again, and
> rebuild e17.
> 
> > efsd crashes and gdb comes up but it complains that it can't get a stack trace because
> 
> Eh? It shouldn't. Did you successfully make install for efsd?
> 
> > Did I miss something, fam's up, efsd's up and I just start with .xinitrc having only
> > e17.
> 
> Again, I do not recommend starting e17 from startup scripts. Run it from
> a terminal to see the output, and launch efsd separetely so that you can
> start it as efsd -f -d.
> 
> -- Christian.
> ________________________________________________________________________
>                                                     http://www.whoop.org
> 
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
-------------------------------------------------------------------------------
kofman@... 		       GPG Public Key: http://www.tambuka.net/key.html
 http://www.tambuka.net   	Key Signature: ED872B110DBF4EC8FE280350FF9E0C810792EA1D
-------------------------------------------------------------------------------

Igor Kofman wrote:
> 
> make install on efd works without any complaints. i did as you suggested but still
> have the same problem here's the efsd output when i run e17:
> 
> efsd [1024]: New connection -- client 0.
> efsd [1024]: Read timed out... 4
> efsd [2051]: Handling STARTMON_FILE
> efsd [2051]: Looking up /home/kofman, as dir: 0
> efsd [2051]: Looking up /home/kofman in stat cache
> efsd [2051]: Looking up /home/kofman, as dir: 0
> efsd [2051]: Comparing /home/kofman 0 -- /home/kofman 0
> efsd [2051]: Returning 0
> efsd [2051]: /home/kofman is monitored, dir requested: 0, monitored as dir: 0
> efsd [2051]: Incrementing internal use count for monitoring file /home/kofman, now (1/1).
> efsd [2051]: Starting monitoring file /home/kofman.
> efsd [1026]: Handling FAM event 8 for file /home/kofman
> efsd [1026]: Handling FAM event 9 for file /home/kofman
> Efsd [12154] received signal 11, attempting stack trace.
> Launching /usr/bin/gdb -x /usr/local/share/efsd/gdb.scr /home/kofman/code/e17/apps/efsd/efsd 12154
> Error: Connection reset by peer
> efsd [1024]: Closing connection 0
> efsd [1024]: Client 0 found monitoring /home/kofman, use count now (1/0)
> efsd [1024]: Removing client 0 from monitor for /home/kofman
> GNU gdb 5.0.90-cvs (MI_OUT)
> Copyright 2001 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-linux"..."/home/kofman/code/e17/apps/efsd/efsd": not in executable format: Is a directory
> 
> //12154: No such file or directory.
> Attaching to process 12154
> Child process unexpectedly missing: No child processes.
> 
> here's what e says:
> kofman@...:~$ e17
> e_view_file_added(1, "/home/kofman");
> e17: relocation error: e17: undefined symbol: efsd_cleanup_event
> kofman@...:~$
> 
> ideas?

Okay. I still think that the relocation error is evil, make sure your
e17 build is okay.

The efsd crash looks like a real segfault. Since it appears to be
reproducible, just run efsd from gdb and send me the backtrace, please.

-- Christian.
________________________________________________________________________
                                                    http://www.whoop.org

On Wed, 10 Oct 2001 04:48:54 -0500 Igor Kofman <kofman@...> babbled
profusely:

> 
> So when I boot e17 I get as far as the background coming up and then things
> die:
> e17: relocation error: e17: undefined symbol efsd_cleanup_event
> efsd crashes and gdb comes up but it complains that it can't get a stack trace
> because
> connection was reset by peer and it suddenly can't find the child proceess.
> Did I miss something, fam's up, efsd's up and I just start with .xinitrc
> having only
> e17.
> Let me know why I'm being stupid :),

sounds liek you maye have multiepl libefsd's installed and the prog has linked
to one link tim and to another runtime... ?

> ik
> -- 
>
-------------------------------------------------------------------------------
> kofman@... 		       GPG Public Key: http://www.tambuka.net/key.html
> http://www.tambuka.net   	Key Signature: ED872B110DBF4EC8FE280350FF9E0C810792EA1D
>
-------------------------------------------------------------------------------
> 
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel


-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@...
Unemployed Bum                      raster@...
Mobile Phone: +61 (0)408 363 984    Home Phone: 02 9386 9362

Hi, been running cvs e for about a week now, the first time i installed it
everything runs okay.. until i updated 2days ago.. eveything still installs 
fine, but now im gettin this prob

libefsd: connect() error.
launch efsd... 12443
libefsd: connect() error.

e still load up, but most of the times i can't close any window or load up 
programs

running RedHat 7.2 , any help would be appreciated!  thanks


_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

On Thu, Nov 08, 2001 at 07:26:54PM -0500, Van Bui wrote:
> 
>   Hi, been running cvs e for about a week now, the first time i installed it
> everything runs okay.. until i updated 2days ago.. eveything still installs 
> fine, but now im gettin this prob
> 
> libefsd: connect() error.
> launch efsd... 12443
> libefsd: connect() error.
> 
> e still load up, but most of the times i can't close any window or load up 
> programs
> 
> running RedHat 7.2 , any help would be appreciated!  thanks
> 
Sounds like fam is not running. 7.2 has fam rpms. I have the following
installed
fam-devel-2.6.4-11
fam-2.6.4-11

Also make sure that fam is running.
rpcinfo -p | grep fam will tell you if it is. 
the redhat fam package should be starting fam from
/etc/xinetd.d/sgi_fam. Make sure the service is not disabled and 
is running correctly. 

Phil, 

> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
> 
> 
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

subscribe

ermm....

just downloaded the CVS eterm
running autogen resulted to this :

creating cache ./config.cache
./configure: line 575: syntax error near unexpected token
`AM_INIT_AUTOMAKE(Eterm,'
./configure: line 575: `AM_INIT_AUTOMAKE(Eterm, 0.9.2)'

saywhat????

This is just a little one-line patch to adjust the
length of a text field. On my system, the text field
was so big that it didn't allow the executable browse
button  to even be displayed. I also added a line in
the README listing gdbm as a dependency. 



__________________________________________________
Do You Yahoo!?
Yahoo! Greetings - Send FREE e-cards for every occasion!
http://greetings.yahoo.com

> On 12 Apr 2002 02:40:57 -0400 Raster babbled back:

> and what would this configure script that you modified be fore? as the
> ones i'm looking at explicitly add -lX11 to the link line to detect 
> xext.

I'm just reporting what I saw, and what I had to do to get it to compile
-- on some packages, the generic autogen.sh worked just fine, created
all library dependancies just right... but for ecore and one other in
that tree (forgetting which since I just pounced on it, fixed it and
forgot it) I had to add the -lX11 right after -lXext -- It's probably
just my configuration (bastardized Mandrake 7.2) -- I don't think it's
anything that needs/can be fixed universally, but it might lend some
insight for other people who seem to have ahd the same problem (who have
been peppering e-devel for a while looking at the archives)

Regards,
	Greyson

On 12 Apr 2002 03:56:30 -0400 Greyson Fischer <greyson@...>
babbled:

> 
> > On 12 Apr 2002 02:40:57 -0400 Raster babbled back:
> 
> > and what would this configure script that you modified be fore? as the
> > ones i'm looking at explicitly add -lX11 to the link line to detect 
> > xext.
> 
> I'm just reporting what I saw, and what I had to do to get it to compile
> -- on some packages, the generic autogen.sh worked just fine, created
> all library dependancies just right... but for ecore and one other in
> that tree (forgetting which since I just pounced on it, fixed it and
> forgot it) I had to add the -lX11 right after -lXext -- It's probably
> just my configuration (bastardized Mandrake 7.2) -- I don't think it's
> anything that needs/can be fixed universally, but it might lend some
> insight for other people who seem to have ahd the same problem (who have
> been peppering e-devel for a while looking at the archives)

the ecore configure.in (for 2.13) works just fine and adds -lX11 (as its part of
the $x_libs added)

-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
The Rasterman (Carsten Haitzler)    raster@...
                                    raster@...
Mobile Phone: +61 (0)413 451 899    Home Phone: 02 9386 9439

Ben Ford wrote:
> pirata wrote:
>
> > I can't get e17 iconbar working as shown in the website screenshot,
> > why?? snif...
> > I ran build_iconbar.sh & copied resulting dbs to
> > (prefix)/enlightenment/share/enlightenment/data/config/behavoir/default
> > & also .e/behavoir
>
>
> Behavior is spelled wrong.  Could that be your problem?

We could go on about the correct spelling of "behaviour" for ages, but it
wouldn't solve anything. ;-)

Matthew

-- 
An ant doesn't have a lot of processing power available to it. I'm not trying
to be speciesist - I wouldn't want to detract you from such a wonderful
creature, but, well, there isn't a lot there, is there?
                                        -- Computer Science Lecturer

On Thu, 2003-05-15 at 11:25, Matthew Wakeling wrote:

> We could go on about the correct spelling of "behaviour" for ages, but it
> wouldn't solve anything. ;-)

No, but it'd be darn good fun!

Behaviour, behaviour, behaviour!  Bloody illiterate yanks!

Ta,

o o                                       mailto:Moredhel@...
/v\ark R. Bowyer  http://www.bowyer.screaming.net   Mark.Bowyer@...
`-'  ---------------------------------------  /"\
...fingerprint =3D 7924 9E9E 7B91 225E B065     \ / ASCII Ribbon Campaign=20
1024D/19BC72F6   39D0 551D ABE6 1514 0DC1      X  Against HTML Mail
--------------------------------------------  / \=20

> On Thu, 2003-05-15 at 11:25, Matthew Wakeling wrote:
>
>> We could go on about the correct spelling of "behaviour" for ages, but
>> it
>> wouldn't solve anything. ;-)
>
> No, but it'd be darn good fun!
>
> Behaviour, behaviour, behaviour!  Bloody illiterate yanks!

Ironically we (UK/Commonwealth) used to spell like the Americans do now
(lack of 'u's in 'ou' comibinations and 'z's in place of 's's) until
~100-150 years ago... then for some reason the English language changed in
England (and this got propogated throughout the Commonwealth yadda yadda).
 I dunno why.  (I picked it up from a Radio 5 morning discussion the other
day - the lady who said it was an Historian so it should be correct.) 
Probably because it didn't sound right.  The Yanks just carry on an
ancient English spelling tradition.

Anyway, this pathetic History lesson is over. :)

- Charlie

On Thu, 2003-05-15 at 15:46, Charles Goodwin wrote:

> Ironically we (UK/Commonwealth) used to spell like the Americans do now
> (lack of 'u's in 'ou' comibinations and 'z's in place of 's's) until
> ~100-150 years ago... then for some reason the English language changed i=
n
> England (and this got propogated throughout the Commonwealth yadda yadda)=
.
>  I dunno why.  (I picked it up from a Radio 5 morning discussion the othe=
r
> day - the lady who said it was an Historian so it should be correct.)=20
> Probably because it didn't sound right.  The Yanks just carry on an
> ancient English spelling tradition.
>=20
> Anyway, this pathetic History lesson is over. :)

I've heard tell that the american accent is probably more like the
English accent of 4-500 years ago, and it's us that changed that, too...

Oh well,

Ta,

o o                                       mailto:Moredhel@...
/v\ark R. Bowyer  http://www.bowyer.screaming.net   Mark.Bowyer@...
`-'  ---------------------------------------  /"\
...fingerprint =3D 7924 9E9E 7B91 225E B065     \ / ASCII Ribbon Campaign=20
1024D/19BC72F6   39D0 551D ABE6 1514 0DC1      X  Against HTML Mail
--------------------------------------------  / \=20

On Thu, 2003-05-15 at 17:53, Mark R. Bowyer wrote:
> On Thu, 2003-05-15 at 15:46, Charles Goodwin wrote:
> 
> > Ironically we (UK/Commonwealth) used to spell like the Americans do now
> > (lack of 'u's in 'ou' comibinations and 'z's in place of 's's) until
> > ~100-150 years ago... then for some reason the English language changed in
> > England (and this got propogated throughout the Commonwealth yadda yadda).
> >  I dunno why.  (I picked it up from a Radio 5 morning discussion the other
> > day - the lady who said it was an Historian so it should be correct.) 
> > Probably because it didn't sound right.  The Yanks just carry on an
> > ancient English spelling tradition.
> > 
> > Anyway, this pathetic History lesson is over. :)
> 
> I've heard tell that the american accent is probably more like the
> English accent of 4-500 years ago, and it's us that changed that, too...
> 
> Oh well,
> 
> Ta,

So? why not simply call it Verhalten?

reg.
 moritz

> > Ironically we (UK/Commonwealth) used to spell like the Americans do now
> > (lack of 'u's in 'ou' comibinations and 'z's in place of 's's) until
> > ~100-150 years ago... then for some reason the English language changed in
> > England (and this got propogated throughout the Commonwealth yadda yadda).
> >  I dunno why.  (I picked it up from a Radio 5 morning discussion the other
> > day - the lady who said it was an Historian so it should be correct.) 
> > Probably because it didn't sound right.  The Yanks just carry on an
> > ancient English spelling tradition.
> > 
> > Anyway, this pathetic History lesson is over. :)
> 
> I've heard tell that the american accent is probably more like the
> English accent of 4-500 years ago, and it's us that changed that, too...

which american accent would that be?  new england?  and if so, *which* new 
england accent?

i've known a few people from europe who referred to 'that american
accent', but given the differences within the us, i don't see there being
a single american accent..

-- 
trey

enlightenment-users@...
Cc: 
Bcc: 
Subject: Re: [E-devel] e16.6 is out
Reply-To: 
In-Reply-To: <20031106112553.70fa2081.raster@...>

On Thu 06 Nov 2003, Carsten Haitzler wrote:
> On Thu, 06 Nov 2003 01:03:44 +0100 Kim Woelders <kim@...> babbled:
> 
> > Changes since e16.6-pre8:
> > 
> > Don't overwrite file.menu and user_apps.menu when regenerating menus.
> > Fixed click-to-focus bug introduced in pre8.
> > Fixed problem with applications that de-iconify their windows introduced 
> > in pre5.
> > 
> > Thanks to all for contributions, bug reports, testing, suggestions, and 
> > support!
> > Have fun :-)
> 
> ok cool. excellent! SUGOII! lets do announcement soon then on e.org and try to
> ignore the /.ing e.org will get :)
> 

Congratulations to everyone who made this release a success :)

I think Kim deserves special compliements for the work he has done on this
release :)
-- 

Ibukun Olumuyiwa
http://xcomputerman.com

"Wisdom is the principal thing; therefore get wisdom: and with all thy
getting get understanding." - Proverbs 4:7

* Ibukun Olumuyiwa (ibukun@...) wrote:
>=20
> Congratulations to everyone who made this release a success :)
>=20
> I think Kim deserves special compliements for the work he has done on this
> release :)

Thanks a lot for this release. I've started using e16 again as of this
morning 8)

Alan Schmitt

--=20
The hacker: someone who figured things out and made something cool happen.

Hi, well, I'm using the latest cvs e16 version (Apr 22 2004) and i want to
note that when compilling since sometime ago, I've to pull the folder
e/intl/ source from cvs dated 4/2/2003 because for some reason if i do a
clean cvs update (this means doing a rm * deleting everything but
excluding the CVS directory), the 'intl' folder is pulled empty and when
running the autogen.sh script it tells that "int/Makefile.in: file not
found" and it stop ...

when pulling intl version dated 4/2/2003 it works ok. (doing cvs uptade
-PAdD 4/2/2004)

this happen me since I had tryed to do a cvs update after cleanning the
folder, it used not to happen before.

e16/e/intl/.cvsignore file should be checked, it may be where the problem is

-- 
Ing. Carlos Alberto Morales Ramirez
Instituto Tecnologico de Mexicali
Mexicali, B.C. Mexico

Carlos Alberto Morales Ramirez wrote:
> Hi, well, I'm using the latest cvs e16 version (Apr 22 2004) and i want to
> note that when compilling since sometime ago, I've to pull the folder
> e/intl/ source from cvs dated 4/2/2003 because for some reason if i do a
> clean cvs update (this means doing a rm * deleting everything but
> excluding the CVS directory), the 'intl' folder is pulled empty and when
> running the autogen.sh script it tells that "int/Makefile.in: file not
> found" and it stop ...
> 
> when pulling intl version dated 4/2/2003 it works ok. (doing cvs uptade
> -PAdD 4/2/2004)
> 
> this happen me since I had tryed to do a cvs update after cleanning the
> folder, it used not to happen before.
> 
> e16/e/intl/.cvsignore file should be checked, it may be where the problem is
> 
This is a problem with certain combinations of auto* and gettext.
intl/ is supposed to be populated by gettextize or autopoint called by 
setup-gettext.sh in autogen.sh.

What are your auto*/gettext versions?

/Kim

I=92ve been following the project lately. It looks like the almost only d=
ocs
at the moment are the doxygen-generated ones. Are the EFL docs reaching a
=93stable=94 status? Are there more/newer docs ? I might help with some
Spanish translation but I need to get some docs that are not gonna change
more. I=92m not a member of any list or anything but please send me
suggestions to rtx@....

By the way I=92m Spanish but I live in London.

Rotxa

On Mon, Aug 02, 2004 at 10:26:42PM +0200, rtx@... wrote:
> I=3D92ve been following the project lately. It looks like the almost only=
 d=3D
> ocs
> at the moment are the doxygen-generated ones. Are the EFL docs reaching a
> =3D93stable=3D94 status? Are there more/newer docs ? I might help with so=
me
> Spanish translation but I need to get some docs that are not gonna change
> more. I=3D92m not a member of any list or anything but please send me
> suggestions to rtx@....
>=20
> By the way I=3D92m Spanish but I live in London.
>=20
> Rotxa

There is a "cookbook" document that provides a larger set of examples
and explanations. They are in cvs in e17/docs.

--=20
------------------------------------------------------------------------
| Nathan Ingersoll          \\  Computer Systems & Network Coordinator |
| ningerso@...   \\  http://www.ruralcenter.org            |
| http://ningerso.atmos.org/  \\  Rural Health Resource Center         |
------------------------------------------------------------------------

Hi there, 

I recently installed e17 from cvs, and have a couple of problems I wanted to 
report! I checked the TODO list, and found my first one: 

* sometimes windows that get shut down/closed get unparented but the whole
 border stays around - something is keeping extra references maybe? it is
 hidden, until you flip desktops then it appears again - but with no client
 around. currently they have a dangling reference - need to find out WHO
 added that ref and didnt remove it (i haven't seen this for ages now) 

I'm only writing because of that last bit in brackets ;) What happens is 
that when I close windows like terminals or firefox by clicking in the X in 
the top right hand corner of the window, it seems to close, but remains in 
the Window list dialogue in the menu, and in the ALT TAB list. If I switch 
desktops I see the window frame, with the top bar flashing red. I can then 
minimise it but NOT close it. 

ok, second issue is simply that when i start emblem, it crashes. I've tried 
nuking ~/.e and rebuilding enlightenment from cvs but it still happens. 
Essentially, when i open it, I see no images (even if I add some background 
files to ~/.e/e/backgrounds/) and if I drag the window it distorts. I can't 
click on anything. I can however close it without problems. 

Hope this helps!! Feel free to ask me for any further clarifications. 

Matt

Carlos Daniel Ruvalcaba Valenzuela writes: 

> As for your first questions it has been discussed on IRC a bunch of
> times, we think is a bug on the program not on E apartently, it
> happens mostly with Mozilla Firefox. 
> 
> But i can be wrong ;)

Thanks for your response Carlos. Just to say: I get it with firefox, all the 
terminals I've tried (xterm, aterm, urxvt) and bluefish. I haven't tried a 
lot of programs with E17 though. 

(original msg below) 

thanks, Matt 

> On 6/22/05, matthew.east@... <matthew.east@...> wrote:
>> Hi there, 
>> 
>> I recently installed e17 from cvs, and have a couple of problems I wanted to
>> report! I checked the TODO list, and found my first one: 
>> 
>> * sometimes windows that get shut down/closed get unparented but the whole
>>  border stays around - something is keeping extra references maybe? it is
>>  hidden, until you flip desktops then it appears again - but with no client
>>  around. currently they have a dangling reference - need to find out WHO
>>  added that ref and didnt remove it (i haven't seen this for ages now) 
>> 
>> I'm only writing because of that last bit in brackets ;) What happens is
>> that when I close windows like terminals or firefox by clicking in the X in
>> the top right hand corner of the window, it seems to close, but remains in
>> the Window list dialogue in the menu, and in the ALT TAB list. If I switch
>> desktops I see the window frame, with the top bar flashing red. I can then
>> minimise it but NOT close it. 
>> 
>> ok, second issue is simply that when i start emblem, it crashes. I've tried
>> nuking ~/.e and rebuilding enlightenment from cvs but it still happens.
>> Essentially, when i open it, I see no images (even if I add some background
>> files to ~/.e/e/backgrounds/) and if I drag the window it distorts. I can't
>> click on anything. I can however close it without problems. 
>> 
>> Hope this helps!! Feel free to ask me for any further clarifications. 
>> 
>> Matt 
>> 
>> 
>> -------------------------------------------------------
>> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>> from IBM. Find simple to follow Roadmaps, straightforward articles,
>> informative Webcasts and more! Get everything you need to get up to
>> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>> _______________________________________________
>> enlightenment-devel mailing list
>> enlightenment-devel@...
>> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel 
>>
 


 --
Make Poverty History:
http://www.makepovertyhistory.org

Project: Eterm: CVS
https://sourceforge.net/cvs/?group_id=212

On sourceforge.net


Under the section for Anonymous CVS Access it says web-based CVS
repository viewer.  I know it says it right after "..to see which
modules are available.." but your eye gets drawn to the highlighted
phrase and that link goes to the cvs repository for the www site:
http://cvs.sourceforge.net/viewcvs.py/eterm/


RiverRat on #Edevelop,
-- 
Tres

Please ignore the parent email, I was collecting information for an
email and accidently had the control down when I hit return.  Sorry.

Basically, go to http://sourceforge.net (login or not), search for
Eterm, click on the Eterm project, click on the CVS link at the top of
the page, and click on either the web based CVS viewer in Anonymous CVS
Access (link below) or the Browse CVS Repository on the right and you go
to a CVS viewer for the WWW site and not the Eterm project source (link
below).

The only way that I found the Eterm code was by going through the
Enlightenment project.
http://cvs.sourceforge.net/viewcvs.py/enlightenment/eterm/Eterm/src/

Shouldn't one be able to get to Eterm's CVS source tree on
SourceForge.net through the Eterm project page?  If I've overlooked
something then please tell me but I think this is "wrong behavior".
(TM)  :-)

Regards,

On Wed, 2005-07-20 at 03:56 -0600, Tres Melton wrote:

>    Project: Eterm: CVS
> https://sourceforge.net/cvs/?group_id=212
> 
> On sourceforge.net
> 
> 
> Under the section for Anonymous CVS Access it says web-based CVS
> repository viewer.  I know it says it right after "..to see which
> modules are available.." but your eye gets drawn to the highlighted
> phrase and that link goes to the cvs repository for the www site:
> http://cvs.sourceforge.net/viewcvs.py/eterm/

RiverRat on #Edevelop,
-- 
Tres

On Wednesday, 20 July 2005, at 04:23:27 (-0600),
Tres Melton wrote:

> Please ignore the parent email, I was collecting information for an
> email and accidently had the control down when I hit return.  Sorry.
> 
> Basically, go to http://sourceforge.net (login or not), search for
> Eterm, click on the Eterm project, click on the CVS link at the top of
> the page, and click on either the web based CVS viewer in Anonymous CVS
> Access (link below) or the Browse CVS Repository on the right and you go
> to a CVS viewer for the WWW site and not the Eterm project source (link
> below).
> 
> The only way that I found the Eterm code was by going through the
> Enlightenment project.
> http://cvs.sourceforge.net/viewcvs.py/enlightenment/eterm/Eterm/src/
> 
> Shouldn't one be able to get to Eterm's CVS source tree on
> SourceForge.net through the Eterm project page?  If I've overlooked
> something then please tell me but I think this is "wrong behavior".
> (TM)  :-)

I don't think there's a way to fix that, other than moving Eterm's CVS
tree out of E's tree.  And I don't really want to do that.

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej@...>
n + 1, Inc., http://www.nplus1.net/       Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
 "[Heather Graham] is the new I-would-run-over-my-best-friend-in-a-
  hummer-to-get-next-to-her girl."                    -- Claude Nobler

On 7/21/05, Michael Jennings <e-devel@...> wrote:
> On Wednesday, 20 July 2005, at 04:23:27 (-0600),
> Tres Melton wrote:

> > The only way that I found the Eterm code was by going through the
> > Enlightenment project.
> > http://cvs.sourceforge.net/viewcvs.py/enlightenment/eterm/Eterm/src/
> >
> > Shouldn't one be able to get to Eterm's CVS source tree on
> > SourceForge.net through the Eterm project page?  If I've overlooked
> > something then please tell me but I think this is "wrong behavior".
> > (TM)  :-)
>=20
> I don't think there's a way to fix that, other than moving Eterm's CVS
> tree out of E's tree.  And I don't really want to do that.
>=20
> Michael
>=20
> --

I think that he's saying that the link to Eterm's cvs repository (as
in the code repository) is pointing to the wrong place.  It's pointing
to the cvs repository for the content of the eterm.sourceforge.net
website pages (html pages, imgs, etc).  Which is the exact same thing
that I get when I do exactly the same thing that Tres did.  What the
problem is is that the link needs to be pointing to the Eterm
directory in E's tree, in
http://cvs.sourceforge.net/viewcvs.py/enlightenment/eterm/ rather than
http://cvs.sourceforge.net/viewcvs.py/eterm/

Hope this clears things up, and that this can get fixed.
Thanks,
--=20
Eric Thompson
thompson.eric@...

On Thursday, 21 July 2005, at 19:34:58 (-0600),
Eric Thompson wrote:

> I think that he's saying that the link to Eterm's cvs repository (as
> in the code repository) is pointing to the wrong place.  It's pointing
> to the cvs repository for the content of the eterm.sourceforge.net
> website pages (html pages, imgs, etc).  Which is the exact same thing
> that I get when I do exactly the same thing that Tres did.  What the
> problem is is that the link needs to be pointing to the Eterm
> directory in E's tree, in
> http://cvs.sourceforge.net/viewcvs.py/enlightenment/eterm/ rather than
> http://cvs.sourceforge.net/viewcvs.py/eterm/

Yes, I understand that.  But that page is automatically generated by
SourceForge.  I can't change that link to point to E's CVS tree any
more than I could point it to any other SF project tree.

Michael

-- 
Michael Jennings (a.k.a. KainX)  http://www.kainx.org/  <mej@...>
n + 1, Inc., http://www.nplus1.net/       Author, Eterm (www.eterm.org)
-----------------------------------------------------------------------
 "When I hear about people making vast fortunes without doing any
  productive work or contributing anything to society, my reaction is,
  'How do I get in on that?'"                            -- Dave Barry

Heres a little patch to add a 'Favorites' button to EFM_nav. The icon
is taken from the default theme for favorite.
Big thanks to ptomaine for making the home path easier to find :)
The code could do with a review since it was just a copy n paste hack
to be honest.
Thanks,
Toma.

(Lets try this again with an upload.)
http://members.iinet.net.au/~haste/e17/efm_nav_fav.tar.gz

In cvs, slightly modified. Thanks :)

Toma wrote:
> Heres a little patch to add a 'Favorites' button to EFM_nav. The icon
> is taken from the default theme for favorite.
> Big thanks to ptomaine for making the home path easier to find :)
> The code could do with a review since it was just a copy n paste hack
> to be honest.
> Thanks,
> Toma.
> 
> (Lets try this again with an upload.)
> http://members.iinet.net.au/~haste/e17/efm_nav_fav.tar.gz
>

Hello there. 

This is a small patch for elm_animator.

Please review and apply this to upstream. 

The main modification are as follows.                   

1. Since the concept of curve in/out was wrong, those functions are
rearranged. It was just my mistake. You can find the operation order of
elm_animator_curve_in_out is reversed in origin code. 
2. Added Dog-tag field for safe using. 

Thank you. 
Hermet

Dear Elementary developers.

It's a bugfix patch and adding new functionality for wrapmode changing at
elm_label.

1. bugfix strbuf_key_value_replace which is internal function
2. add wrapmode change api (wordwrap or charwrap)


Thank you.


-------------------------------------------
Hyoyoung CHANG
Engineer

SAMSUNG ELECTRONICS, Co., Ltd.
E-mail: hyoyoung.chang@...
-------------------------------------------

Hi,

I can't find libglu1-xorg-dev package in my Ubuntu 11.04 machine.
It's described in http://trac.enlightenment.org/e/wiki/Ubuntu

Any reason?

Thanks.
Daniel Juyung Seo (SeoZ)

Oops.
(no subject).
My bad :)

Daniel Juyung Seo (SeoZ)

On Thu, May 5, 2011 at 11:29 AM, Daniel Juyung Seo <seojuyung2@...> wrote:
> Hi,
>
> I can't find libglu1-xorg-dev package in my Ubuntu 11.04 machine.
> It's described in http://trac.enlightenment.org/e/wiki/Ubuntu
>
> Any reason?
>
> Thanks.
> Daniel Juyung Seo (SeoZ)
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today.  Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>

maybe the name is a bit different

2011/5/5 Daniel Juyung Seo <seojuyung2@...>

> Oops.
> (no subject).
> My bad :)
>
> Daniel Juyung Seo (SeoZ)
>
> On Thu, May 5, 2011 at 11:29 AM, Daniel Juyung Seo <seojuyung2@...>
> wrote:
> > Hi,
> >
> > I can't find libglu1-xorg-dev package in my Ubuntu 11.04 machine.
> > It's described in http://trac.enlightenment.org/e/wiki/Ubuntu
> >
> > Any reason?
> >
> > Thanks.
> > Daniel Juyung Seo (SeoZ)
> >
> ------------------------------------------------------------------------------
> > WhatsUp Gold - Download Free Network Management Software
> > The most intuitive, comprehensive, and cost-effective network
> > management toolset available today.  Delivers lowest initial
> > acquisition cost and overall TCO of any competing solution.
> > http://p.sf.net/sfu/whatsupgold-sd
> > _______________________________________________
> > enlightenment-devel mailing list
> > enlightenment-devel@...
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
>
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today.  Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>



-- 
Regards.

2011/5/5 Daniel Juyung Seo <seojuyung2@...>

> Hi,
>
> I can't find libglu1-xorg-dev package in my Ubuntu 11.04 machine.
> It's described in http://trac.enlightenment.org/e/wiki/Ubuntu
>
> Any reason?
>
> Thanks.
> Daniel Juyung Seo (SeoZ)
>
> ------------------------------------------------------------------------------
> WhatsUp Gold - Download Free Network Management Software
> The most intuitive, comprehensive, and cost-effective network
> management toolset available today.  Delivers lowest initial
> acquisition cost and overall TCO of any competing solution.
> http://p.sf.net/sfu/whatsupgold-sd
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>

maybe this one : libglu1-mesa-dev

-- 
Nicolas Aguirre
Mail: aguirre.nicolas@...
Web: http://enna.geexbox.org
Blog: http://dev.enlightenment.fr/~captainigloo/

Hello,

This patch is for reading socks version5 proxy from global variables.
This is almost same as previous socks version4.
discomfitor can help to review this patch.

Thanks.

-- 
BRs,
Kim.

On Sat, 3 Mar 2012 13:19:24 +0900
Bluezery <ohpowel@...> wrote:

> Hello,
> 
> This patch is for reading socks version5 proxy from global variables.
> This is almost same as previous socks version4.
> discomfitor can help to review this patch.
> 
> Thanks.
> 
hmm I could be reading this wrong, but it looks to me that this does not allow
for socks4a (proxy DNS lookups) inheritance from global proxies? other than
that it looks good

2012/3/3 Michael Blumenkrantz <michael.blumenkrantz@...>:
> On Sat, 3 Mar 2012 13:19:24 +0900
> Bluezery <ohpowel@...> wrote:
>
>> Hello,
>>
>> This patch is for reading socks version5 proxy from global variables.
>> This is almost same as previous socks version4.
>> discomfitor can help to review this patch.
>>
>> Thanks.
>>
> hmm I could be reading this wrong, but it looks to me that this does not allow
> for socks4a (proxy DNS lookups) inheritance from global proxies? other than
> that it looks good

I add checking socks4a protocol.
I cannot find exactly what is socks5h protocol.
But I think that socks5h (CURLPROXY_SOCKS5_HOSTNAME) may be enhanced
sock5 for resolving such as socks4a.
So socks5h checking is also added.


Anyway, I am sorry for no title and duplicated mail. :(

-- 
BRs,
Kim.

On Sat, 3 Mar 2012 23:02:58 +0900
Bluezery <ohpowel@...> wrote:

> 2012/3/3 Michael Blumenkrantz <michael.blumenkrantz@...>:
> > On Sat, 3 Mar 2012 13:19:24 +0900
> > Bluezery <ohpowel@...> wrote:
> >
> >> Hello,
> >>
> >> This patch is for reading socks version5 proxy from global variables.
> >> This is almost same as previous socks version4.
> >> discomfitor can help to review this patch.
> >>
> >> Thanks.
> >>
> > hmm I could be reading this wrong, but it looks to me that this does not
> > allow for socks4a (proxy DNS lookups) inheritance from global proxies?
> > other than that it looks good
> 
> I add checking socks4a protocol.
> I cannot find exactly what is socks5h protocol.
> But I think that socks5h (CURLPROXY_SOCKS5_HOSTNAME) may be enhanced
> sock5 for resolving such as socks4a.
> So socks5h checking is also added.
> 
> 
> Anyway, I am sorry for no title and duplicated mail. :(
> 
Good patch, committed.

You are correct, "socks5h" is just socks5 with proxy DNS. It is not an actual
protocol, just the name that the author of cURL gave to socks5 with hostname
lookup because there is no name since it is just part of base socks5.

anyone here who knows how to start development using efl in vala? I have 
access to vapi files, i just don't know how to use it yet...

I will also appreciate it if anyone can instruct me on using vapi 
files.... thank you :)

Hello,

beware, the switch to Git will be happening soon! We will migrate efl,
elementary and enlightenment one-by-one and send mails with specific
details when each will happen.

For the time when we are using Git here is a really small list of what
you need to change:

First setup Git as it will need to know your name and email (global here
means per-user)
$ git config --global user.name "Jane Doe"
$ git config --global user.email "janedoe@..."

Useful commands:
To get the repository, run
$ git clone ssh://git@...>>
-> (svn checkout)
The names will be announced as we switch - the first ones will most
likely be core/efl.git, core/elementary.git and core/enlightenment.git

To update to the newest version
$ git pull --rebase
-> (svn update)

To commit all local changes
$ git commit -a
$ git push
-> (svn ci)
OR (better) if you just want to commit specific files
$ git add <files>
$ git commit
$ git push
-> (svn ci <files>)

Here's more Git for SVN users:
http://git-scm.com/course/svn.html


If you want to know more I recommend reading (part of) the Git book at
http://git-scm.com/book
I even recommend reading it if you don't want to know more.
A sneak peek of the awesomeness that awaits you at the other side of
that link:

# Enable color in diffs, etc. (should be default by now)
$ git config --global color.ui true

# Change your editor if you don't like what $EDITOR points to
$ git config --global core.editor vim

# Configure shortcuts for commands
$ git config --global alias.ci commit



These were the very basics of how to work with Git on a technical level.
In the following paragraphs I want to introduce some common work flows
that I think are useful to adopt. If you don't understand it all -
that's okay. It's not a MUST. But please feel free to ask if anything is
unclear.

Structure of the repositories
-----------------------------

Official:
These branches will be fast-forward only (you cannot rewrite
history/commits that have been published to the server). This is what
people expect from official branches and the same behaviour as with SVN.
Once commits are made you cannot "uncommit" something - only revert.

* "master" is what trunk used to be. All official development happens
  there.
* For a stabilization branch we will have "<packagename>-<version>"
  branching off of master. This is analog to the way SVN branches were
  used in the past. An example would be "elementary-1.7"
* Git tags will mark the exact commit that was used for a release. As
  such these commits will usually reside within the release branches or
  be the starting point for one. Tags will follow the naming scheme
  v<version>, so for example "v1.7.5".

Topic branches:
* In each repository every developer with commit access will be able to
  push/update branches in their own namespace (devs/<name>/*). These
  branches will allow non-fastforward updates and no one should expect
  these to be stable.
* This is a testing ground for developers where new features can be
  developed, debugged and shared with fellow developers. Ideally any new
  feature would live in its own branch until it matures and is merged
  into master.

Local branches:
* Go nuts. Branches are cheap and merging/rebasing them is easy as well.
  It's a good way to try out some small things while keeping other
  development separate.

Commits best practices:
I will probably be laughed at (at best) or thrown out of the project for
bringing this up, but here goes.

Because of the way git integrates with email it is encouraged to write a
commit message with a one-line summary, a blank line and then a body
describing the commit in greater detail. Most of you will ask "More than
one line? Why would I need more than one line to write 'Fix, fix,
spankies!'". You have a point, but I would actually want to push for
commit messages that are a little longer than that.

I know some will refuse to adopt that, but I would still like to see
everyone else setting a good example. If you want a good example of how
to write and structure your commits and messages I recommend taking a
look at QT.

I would be really happy (almost ecstatic with joy) if we could have more
commit messages that include the problem and what was done.

Example:
"""
Fix memory leak in function xyz

If the allocation of foo fails the error path doesn't clean up correctly
which leads to variable bla being leaked. Clean up correctly and exit.
"""

Similarly, the individual commits shouldn't be too large. I don't want
you to commit every line change separately, but git allows you to commit
a bunch of stuff locally before pushing it upstream. What was one large
commit in SVN can be broken up into several smaller ones in Git. This
makes commits much easier to review (as does a proper commit message,
hint, hint). If you do have a larger feature that requires tens of
commits please don't just dump them into upstream Git at once, but
develop them publicly in a topic branch (see topic branches) and merge
them when they are ready.

That's it for now, specific news will follow shortly.


Regards,
The SVN->Git migration team

As a humble e tester many thanks for the info. Tarball ->cvs ->svn -> git.
still enjoying the ride and the result!

Cheers

M


On 11 February 2013 17:07, Daniel Willmann <d.willmann@...> wrote:

> Hello,
>
> beware, the switch to Git will be happening soon! We will migrate efl,
> elementary and enlightenment one-by-one and send mails with specific
> details when each will happen.
>
> For the time when we are using Git here is a really small list of what
> you need to change:
>
> First setup Git as it will need to know your name and email (global here
> means per-user)
> $ git config --global user.name "Jane Doe"
> $ git config --global user.email "janedoe@..."
>
> Useful commands:
> To get the repository, run
> $ git clone ssh://git@...>>
> -> (svn checkout)
> The names will be announced as we switch - the first ones will most
> likely be core/efl.git, core/elementary.git and core/enlightenment.git
>
> To update to the newest version
> $ git pull --rebase
> -> (svn update)
>
> To commit all local changes
> $ git commit -a
> $ git push
> -> (svn ci)
> OR (better) if you just want to commit specific files
> $ git add <files>
> $ git commit
> $ git push
> -> (svn ci <files>)
>
> Here's more Git for SVN users:
> http://git-scm.com/course/svn.html
>
>
> If you want to know more I recommend reading (part of) the Git book at
> http://git-scm.com/book
> I even recommend reading it if you don't want to know more.
> A sneak peek of the awesomeness that awaits you at the other side of
> that link:
>
> # Enable color in diffs, etc. (should be default by now)
> $ git config --global color.ui true
>
> # Change your editor if you don't like what $EDITOR points to
> $ git config --global core.editor vim
>
> # Configure shortcuts for commands
> $ git config --global alias.ci commit
>
>
>
> These were the very basics of how to work with Git on a technical level.
> In the following paragraphs I want to introduce some common work flows
> that I think are useful to adopt. If you don't understand it all -
> that's okay. It's not a MUST. But please feel free to ask if anything is
> unclear.
>
> Structure of the repositories
> -----------------------------
>
> Official:
> These branches will be fast-forward only (you cannot rewrite
> history/commits that have been published to the server). This is what
> people expect from official branches and the same behaviour as with SVN.
> Once commits are made you cannot "uncommit" something - only revert.
>
> * "master" is what trunk used to be. All official development happens
>   there.
> * For a stabilization branch we will have "<packagename>-<version>"
>   branching off of master. This is analog to the way SVN branches were
>   used in the past. An example would be "elementary-1.7"
> * Git tags will mark the exact commit that was used for a release. As
>   such these commits will usually reside within the release branches or
>   be the starting point for one. Tags will follow the naming scheme
>   v<version>, so for example "v1.7.5".
>
> Topic branches:
> * In each repository every developer with commit access will be able to
>   push/update branches in their own namespace (devs/<name>/*). These
>   branches will allow non-fastforward updates and no one should expect
>   these to be stable.
> * This is a testing ground for developers where new features can be
>   developed, debugged and shared with fellow developers. Ideally any new
>   feature would live in its own branch until it matures and is merged
>   into master.
>
> Local branches:
> * Go nuts. Branches are cheap and merging/rebasing them is easy as well.
>   It's a good way to try out some small things while keeping other
>   development separate.
>
> Commits best practices:
> I will probably be laughed at (at best) or thrown out of the project for
> bringing this up, but here goes.
>
> Because of the way git integrates with email it is encouraged to write a
> commit message with a one-line summary, a blank line and then a body
> describing the commit in greater detail. Most of you will ask "More than
> one line? Why would I need more than one line to write 'Fix, fix,
> spankies!'". You have a point, but I would actually want to push for
> commit messages that are a little longer than that.
>
> I know some will refuse to adopt that, but I would still like to see
> everyone else setting a good example. If you want a good example of how
> to write and structure your commits and messages I recommend taking a
> look at QT.
>
> I would be really happy (almost ecstatic with joy) if we could have more
> commit messages that include the problem and what was done.
>
> Example:
> """
> Fix memory leak in function xyz
>
> If the allocation of foo fails the error path doesn't clean up correctly
> which leads to variable bla being leaked. Clean up correctly and exit.
> """
>
> Similarly, the individual commits shouldn't be too large. I don't want
> you to commit every line change separately, but git allows you to commit
> a bunch of stuff locally before pushing it upstream. What was one large
> commit in SVN can be broken up into several smaller ones in Git. This
> makes commits much easier to review (as does a proper commit message,
> hint, hint). If you do have a larger feature that requires tens of
> commits please don't just dump them into upstream Git at once, but
> develop them publicly in a topic branch (see topic branches) and merge
> them when they are ready.
>
> That's it for now, specific news will follow shortly.
>
>
> Regards,
> The SVN->Git migration team
>
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>



-- 
Mark Dickie

Tel (+34) 654 583 648
Google Voice (+1) 253 470-6603
Email blaeberries@...
Skype blaeberries

On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann <d.willmann@...> wrote:
> Hello,
>
> beware, the switch to Git will be happening soon! We will migrate efl,
> elementary and enlightenment one-by-one and send mails with specific
> details when each will happen.
>
> For the time when we are using Git here is a really small list of what
> you need to change:
>
> First setup Git as it will need to know your name and email (global here
> means per-user)
> $ git config --global user.name "Jane Doe"
> $ git config --global user.email "janedoe@..."
>
> Useful commands:
> To get the repository, run
> $ git clone ssh://git@...>>
> -> (svn checkout)
> The names will be announced as we switch - the first ones will most
> likely be core/efl.git, core/elementary.git and core/enlightenment.git
>
> To update to the newest version
> $ git pull --rebase
> -> (svn update)
>
> To commit all local changes
> $ git commit -a
> $ git push
> -> (svn ci)
> OR (better) if you just want to commit specific files
> $ git add <files>
> $ git commit
> $ git push
> -> (svn ci <files>)
>
> Here's more Git for SVN users:
> http://git-scm.com/course/svn.html
>
>
> If you want to know more I recommend reading (part of) the Git book at
> http://git-scm.com/book
> I even recommend reading it if you don't want to know more.
> A sneak peek of the awesomeness that awaits you at the other side of
> that link:
>
> # Enable color in diffs, etc. (should be default by now)
> $ git config --global color.ui true
>
> # Change your editor if you don't like what $EDITOR points to
> $ git config --global core.editor vim
>
> # Configure shortcuts for commands
> $ git config --global alias.ci commit
>
>
>
> These were the very basics of how to work with Git on a technical level.
> In the following paragraphs I want to introduce some common work flows
> that I think are useful to adopt. If you don't understand it all -
> that's okay. It's not a MUST. But please feel free to ask if anything is
> unclear.
>
> Structure of the repositories
> -----------------------------
>
> Official:
> These branches will be fast-forward only (you cannot rewrite
> history/commits that have been published to the server). This is what
> people expect from official branches and the same behaviour as with SVN.
> Once commits are made you cannot "uncommit" something - only revert.
>
> * "master" is what trunk used to be. All official development happens
>   there.
> * For a stabilization branch we will have "<packagename>-<version>"
>   branching off of master. This is analog to the way SVN branches were
>   used in the past. An example would be "elementary-1.7"
> * Git tags will mark the exact commit that was used for a release. As
>   such these commits will usually reside within the release branches or
>   be the starting point for one. Tags will follow the naming scheme
>   v<version>, so for example "v1.7.5".
>
> Topic branches:
> * In each repository every developer with commit access will be able to
>   push/update branches in their own namespace (devs/<name>/*). These
>   branches will allow non-fastforward updates and no one should expect
>   these to be stable.
> * This is a testing ground for developers where new features can be
>   developed, debugged and shared with fellow developers. Ideally any new
>   feature would live in its own branch until it matures and is merged
>   into master.

Hey Daniel,

It's a nice proposal, but what about master branch permissions ?
Every developer would be allowed to push stuff on there (with a flow
similar to svn) ? Or we'll try to establish some kind of policy about
it (maintainers, review, etc) ?

>
> Local branches:
> * Go nuts. Branches are cheap and merging/rebasing them is easy as well.
>   It's a good way to try out some small things while keeping other
>   development separate.
>
> Commits best practices:
> I will probably be laughed at (at best) or thrown out of the project for
> bringing this up, but here goes.
>
> Because of the way git integrates with email it is encouraged to write a
> commit message with a one-line summary, a blank line and then a body
> describing the commit in greater detail. Most of you will ask "More than
> one line? Why would I need more than one line to write 'Fix, fix,
> spankies!'". You have a point, but I would actually want to push for
> commit messages that are a little longer than that.
>
> I know some will refuse to adopt that, but I would still like to see
> everyone else setting a good example. If you want a good example of how
> to write and structure your commits and messages I recommend taking a
> look at QT.
>
> I would be really happy (almost ecstatic with joy) if we could have more
> commit messages that include the problem and what was done.
>
> Example:
> """
> Fix memory leak in function xyz
>
> If the allocation of foo fails the error path doesn't clean up correctly
> which leads to variable bla being leaked. Clean up correctly and exit.
> """
>
> Similarly, the individual commits shouldn't be too large. I don't want
> you to commit every line change separately, but git allows you to commit
> a bunch of stuff locally before pushing it upstream. What was one large
> commit in SVN can be broken up into several smaller ones in Git. This
> makes commits much easier to review (as does a proper commit message,
> hint, hint). If you do have a larger feature that requires tens of
> commits please don't just dump them into upstream Git at once, but
> develop them publicly in a topic branch (see topic branches) and merge
> them when they are ready.
>
> That's it for now, specific news will follow shortly.
>
>
> Regards,
> The SVN->Git migration team
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



-- 
Bruno Dilly
Lead Developer
ProFUSION embedded systems
http://profusion.mobi

On Wed, Feb 13, 2013 at 9:36 AM, Bruno Dilly <bdilly@...> wrote:
> On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann <d.willmann@...> wrote:
>> Hello,
>>
>> beware, the switch to Git will be happening soon! We will migrate efl,
>> elementary and enlightenment one-by-one and send mails with specific
>> details when each will happen.
>>
>> For the time when we are using Git here is a really small list of what
>> you need to change:
>>
>> First setup Git as it will need to know your name and email (global here
>> means per-user)
>> $ git config --global user.name "Jane Doe"
>> $ git config --global user.email "janedoe@..."
>>
>> Useful commands:
>> To get the repository, run
>> $ git clone ssh://git@...>>
>> -> (svn checkout)
>> The names will be announced as we switch - the first ones will most
>> likely be core/efl.git, core/elementary.git and core/enlightenment.git
>>
>> To update to the newest version
>> $ git pull --rebase
>> -> (svn update)
>>
>> To commit all local changes
>> $ git commit -a
>> $ git push
>> -> (svn ci)
>> OR (better) if you just want to commit specific files
>> $ git add <files>
>> $ git commit
>> $ git push
>> -> (svn ci <files>)
>>
>> Here's more Git for SVN users:
>> http://git-scm.com/course/svn.html
>>
>>
>> If you want to know more I recommend reading (part of) the Git book at
>> http://git-scm.com/book
>> I even recommend reading it if you don't want to know more.
>> A sneak peek of the awesomeness that awaits you at the other side of
>> that link:
>>
>> # Enable color in diffs, etc. (should be default by now)
>> $ git config --global color.ui true
>>
>> # Change your editor if you don't like what $EDITOR points to
>> $ git config --global core.editor vim
>>
>> # Configure shortcuts for commands
>> $ git config --global alias.ci commit
>>
>>
>>
>> These were the very basics of how to work with Git on a technical level.
>> In the following paragraphs I want to introduce some common work flows
>> that I think are useful to adopt. If you don't understand it all -
>> that's okay. It's not a MUST. But please feel free to ask if anything is
>> unclear.
>>
>> Structure of the repositories
>> -----------------------------
>>
>> Official:
>> These branches will be fast-forward only (you cannot rewrite
>> history/commits that have been published to the server). This is what
>> people expect from official branches and the same behaviour as with SVN.
>> Once commits are made you cannot "uncommit" something - only revert.
>>
>> * "master" is what trunk used to be. All official development happens
>>   there.
>> * For a stabilization branch we will have "<packagename>-<version>"
>>   branching off of master. This is analog to the way SVN branches were
>>   used in the past. An example would be "elementary-1.7"
>> * Git tags will mark the exact commit that was used for a release. As
>>   such these commits will usually reside within the release branches or
>>   be the starting point for one. Tags will follow the naming scheme
>>   v<version>, so for example "v1.7.5".
>>
>> Topic branches:
>> * In each repository every developer with commit access will be able to
>>   push/update branches in their own namespace (devs/<name>/*). These
>>   branches will allow non-fastforward updates and no one should expect
>>   these to be stable.
>> * This is a testing ground for developers where new features can be
>>   developed, debugged and shared with fellow developers. Ideally any new
>>   feature would live in its own branch until it matures and is merged
>>   into master.
>
> It's a nice proposal, but what about master branch permissions ?
> Every developer would be allowed to push stuff on there (with a flow
> similar to svn) ? Or we'll try to establish some kind of policy about
> it (maintainers, review, etc) ?

We did have some discussion and sharing idea about that during fosdem.
The consensus is that we were not ready as a group of developers to
move to that kind of organisation. Instead something that maybe would
fit us more is a release cycle and development process based on time.
  1 week of feature addition
  2 week of bug fixing
This cycle would be repeated 3 times, then followed by :
  a release candidate
  2 additional weeks of stabilization (maybe another RC)
  a beta
  1 additional week of polishing
  release (if everything is good of course)

Of course we don't start a feature addition cycle if current master
branch is unstable. The hope is to be on a more rapid development
cycle, but still stable and avoiding glacial era like we have before
each release. Finally it should give us a good release every 3 months.
It should not change our workflow to much and still be an improvement
over our current model.

Any though or improvement about it ? Or a better proposal ?
-- 
Cedric BAIL

On Wed, Feb 13, 2013 at 12:18 AM, Cedric BAIL <cedric.bail@...> wrote:
> Of course we don't start a feature addition cycle if current master
> branch is unstable. The hope is to be on a more rapid development
> cycle, but still stable and avoiding glacial era like we have before
> each release. Finally it should give us a good release every 3 months.
> It should not change our workflow to much and still be an improvement
> over our current model.
>
> Any though or improvement about it ? Or a better proposal ?

The question was whether we'll all have write permission to the master branch
and push stuff there as we do with SVN or if we'll keep our own repositories
and have someone(s) integrate them into upstream.

> --
> Cedric BAIL
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

On Wed, 13 Feb 2013 01:00:26 -0200
Iván Briano <sachieru@...> wrote:

> On Wed, Feb 13, 2013 at 12:18 AM, Cedric BAIL <cedric.bail@...> wrote:
> > Of course we don't start a feature addition cycle if current master
> > branch is unstable. The hope is to be on a more rapid development
> > cycle, but still stable and avoiding glacial era like we have before
> > each release. Finally it should give us a good release every 3 months.
> > It should not change our workflow to much and still be an improvement
> > over our current model.
> >
> > Any though or improvement about it ? Or a better proposal ?
> 
> The question was whether we'll all have write permission to the master branch
> and push stuff there as we do with SVN or if we'll keep our own repositories
> and have someone(s) integrate them into upstream.
> 
> > --
> > Cedric BAIL
> >

Having reviewer(s) who are the only people with commit access to certain repos may work for some side projects that we have, but, despite it being a good idea in theory, there's no real way for us to do it for larger components. We just don't have the manpower for it, and the reviewers, who must then also be our most knowledgeable developers, will immediately be buried with code to review and be unable to do any work of their own.

Just ask raster about his backlog if you doubt this.

On Wed, Feb 13, 2013 at 12:00 PM, Iván Briano <sachieru@...> wrote:
> On Wed, Feb 13, 2013 at 12:18 AM, Cedric BAIL <cedric.bail@...> wrote:
>> Of course we don't start a feature addition cycle if current master
>> branch is unstable. The hope is to be on a more rapid development
>> cycle, but still stable and avoiding glacial era like we have before
>> each release. Finally it should give us a good release every 3 months.
>> It should not change our workflow to much and still be an improvement
>> over our current model.
>>
>> Any though or improvement about it ? Or a better proposal ?
>
> The question was whether we'll all have write permission to the master branch
> and push stuff there as we do with SVN or if we'll keep our own repositories
> and have someone(s) integrate them into upstream.

My answer is maybe not clear enough, but nobody will be a gate keeper
in that proposal. We will rely on developer good will.
-- 
Cedric BAIL

On Wed, 13 Feb 2013 12:08:44 +0900 Cedric BAIL <cedric.bail@...> said:

> On Wed, Feb 13, 2013 at 12:00 PM, Iván Briano <sachieru@...> wrote:
> > On Wed, Feb 13, 2013 at 12:18 AM, Cedric BAIL <cedric.bail@...> wrote:
> >> Of course we don't start a feature addition cycle if current master
> >> branch is unstable. The hope is to be on a more rapid development
> >> cycle, but still stable and avoiding glacial era like we have before
> >> each release. Finally it should give us a good release every 3 months.
> >> It should not change our workflow to much and still be an improvement
> >> over our current model.
> >>
> >> Any though or improvement about it ? Or a better proposal ?
> >
> > The question was whether we'll all have write permission to the master
> > branch and push stuff there as we do with SVN or if we'll keep our own
> > repositories and have someone(s) integrate them into upstream.
> 
> My answer is maybe not clear enough, but nobody will be a gate keeper
> in that proposal. We will rely on developer good will.

yes - no gatekeepers. you either have push access (equivalent to svn commit
access), play nice and behave (or be kicked out of having access), or you do
not (and then you submit patches).

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@...

On Wed, 13 Feb 2013 12:35:10 +0900 Carsten Haitzler (The Rasterman)
<raster@...> wrote:

> On Wed, 13 Feb 2013 12:08:44 +0900 Cedric BAIL <cedric.bail@...>
> said:
> 
> > On Wed, Feb 13, 2013 at 12:00 PM, Iván Briano <sachieru@...>
> > wrote:
> > > On Wed, Feb 13, 2013 at 12:18 AM, Cedric BAIL
> > > <cedric.bail@...> wrote:
> > >> Of course we don't start a feature addition cycle if current
> > >> master branch is unstable. The hope is to be on a more rapid
> > >> development cycle, but still stable and avoiding glacial era
> > >> like we have before each release. Finally it should give us a
> > >> good release every 3 months. It should not change our workflow
> > >> to much and still be an improvement over our current model.
> > >>
> > >> Any though or improvement about it ? Or a better proposal ?
> > >
> > > The question was whether we'll all have write permission to the
> > > master branch and push stuff there as we do with SVN or if we'll
> > > keep our own repositories and have someone(s) integrate them into
> > > upstream.
> > 
> > My answer is maybe not clear enough, but nobody will be a gate
> > keeper in that proposal. We will rely on developer good will.
> 
> yes - no gatekeepers. you either have push access (equivalent to svn
> commit access), play nice and behave (or be kicked out of having
> access), or you do not (and then you submit patches).

Business as usual, and it's worked OK for us so far.  Should keep
working for us.  Don't think we have ever kicked out anyone from SVN
access?  Not counting those that kicked themselves out.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.

On Wed, 13 Feb 2013 13:53:35 +1000 David Seikel <onefang@...> said:

> On Wed, 13 Feb 2013 12:35:10 +0900 Carsten Haitzler (The Rasterman)
> <raster@...> wrote:
> 
> > On Wed, 13 Feb 2013 12:08:44 +0900 Cedric BAIL <cedric.bail@...>
> > said:
> > 
> > > On Wed, Feb 13, 2013 at 12:00 PM, Iván Briano <sachieru@...>
> > > wrote:
> > > > On Wed, Feb 13, 2013 at 12:18 AM, Cedric BAIL
> > > > <cedric.bail@...> wrote:
> > > >> Of course we don't start a feature addition cycle if current
> > > >> master branch is unstable. The hope is to be on a more rapid
> > > >> development cycle, but still stable and avoiding glacial era
> > > >> like we have before each release. Finally it should give us a
> > > >> good release every 3 months. It should not change our workflow
> > > >> to much and still be an improvement over our current model.
> > > >>
> > > >> Any though or improvement about it ? Or a better proposal ?
> > > >
> > > > The question was whether we'll all have write permission to the
> > > > master branch and push stuff there as we do with SVN or if we'll
> > > > keep our own repositories and have someone(s) integrate them into
> > > > upstream.
> > > 
> > > My answer is maybe not clear enough, but nobody will be a gate
> > > keeper in that proposal. We will rely on developer good will.
> > 
> > yes - no gatekeepers. you either have push access (equivalent to svn
> > commit access), play nice and behave (or be kicked out of having
> > access), or you do not (and then you submit patches).
> 
> Business as usual, and it's worked OK for us so far.  Should keep
> working for us.  Don't think we have ever kicked out anyone from SVN
> access?  Not counting those that kicked themselves out.

correct. if it ain't broke, don't fix it. :)

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@...

On 13/02/13 00:36, Bruno Dilly wrote:
> On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann <d.willmann@...>
> wrote:
>>
>> Topic branches:
>> * In each repository every developer with commit access will be able to
>>   push/update branches in their own namespace (devs/<name>/*). These
>>   branches will allow non-fastforward updates and no one should expect
>>   these to be stable.
>> * This is a testing ground for developers where new features can be
>>   developed, debugged and shared with fellow developers. Ideally any new
>>   feature would live in its own branch until it matures and is merged
>>   into master.
> 
> Hey Daniel,
> 
> It's a nice proposal, but what about master branch permissions ?
> Every developer would be allowed to push stuff on there (with a flow
> similar to svn) ? Or we'll try to establish some kind of policy about
> it (maintainers, review, etc) ?

As others have already pointed out there seems to be consensus that we
don't have enough manpower to work with an integrator workflow (whether
or not that's true I don't know).

What I want to achieve with the topic branches is that whoever wants to
can maintain an integrator-like workflow. You develop your feature in a
topic branch, then post a request for review/review and test yourself
and if everything looks good you can merge into master.

Speaking of merging...is there any preference on merge vs. rebase?

Lots of small merges can really pollute your history and I don't really
like them. For larger topic branches I think merging makes sense.


Regards,
Daniel

On Wed, 13 Feb 2013 10:42:17 +0000 Daniel Willmann <d.willmann@...>
said:

> On 13/02/13 00:36, Bruno Dilly wrote:
> > On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann <d.willmann@...>
> > wrote:
> >>
> >> Topic branches:
> >> * In each repository every developer with commit access will be able to
> >>   push/update branches in their own namespace (devs/<name>/*). These
> >>   branches will allow non-fastforward updates and no one should expect
> >>   these to be stable.
> >> * This is a testing ground for developers where new features can be
> >>   developed, debugged and shared with fellow developers. Ideally any new
> >>   feature would live in its own branch until it matures and is merged
> >>   into master.
> > 
> > Hey Daniel,
> > 
> > It's a nice proposal, but what about master branch permissions ?
> > Every developer would be allowed to push stuff on there (with a flow
> > similar to svn) ? Or we'll try to establish some kind of policy about
> > it (maintainers, review, etc) ?
> 
> As others have already pointed out there seems to be consensus that we
> don't have enough manpower to work with an integrator workflow (whether
> or not that's true I don't know).

the day the pending patches on our mailing lists are all handled before i get
around to them is the day i might consider we do... but i have maybe 30-50+
pending patches in my backlog that havent (seemingly) been dealt with. :)

> What I want to achieve with the topic branches is that whoever wants to
> can maintain an integrator-like workflow. You develop your feature in a
> topic branch, then post a request for review/review and test yourself
> and if everything looks good you can merge into master.
> 
> Speaking of merging...is there any preference on merge vs. rebase?
> 
> Lots of small merges can really pollute your history and I don't really
> like them. For larger topic branches I think merging makes sense.
> 
> 
> Regards,
> Daniel
> 
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013 
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@...

On 13/02/13 10:42, Daniel Willmann wrote:
> On 13/02/13 00:36, Bruno Dilly wrote:
>> On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann <d.willmann@...>
>> wrote:
>>>
>>> Topic branches:
>>> * In each repository every developer with commit access will be able to
>>>    push/update branches in their own namespace (devs/<name>/*). These
>>>    branches will allow non-fastforward updates and no one should expect
>>>    these to be stable.
>>> * This is a testing ground for developers where new features can be
>>>    developed, debugged and shared with fellow developers. Ideally any new
>>>    feature would live in its own branch until it matures and is merged
>>>    into master.
>>
>> Hey Daniel,
>>
>> It's a nice proposal, but what about master branch permissions ?
>> Every developer would be allowed to push stuff on there (with a flow
>> similar to svn) ? Or we'll try to establish some kind of policy about
>> it (maintainers, review, etc) ?
>
> As others have already pointed out there seems to be consensus that we
> don't have enough manpower to work with an integrator workflow (whether
> or not that's true I don't know).
>
> What I want to achieve with the topic branches is that whoever wants to
> can maintain an integrator-like workflow. You develop your feature in a
> topic branch, then post a request for review/review and test yourself
> and if everything looks good you can merge into master.
>
> Speaking of merging...is there any preference on merge vs. rebase?


Rebase is easier to work with. I think we should rebase whenever 
possible. When not possible, we should try to rebase anyway. Linear 
history is cooler.

--
Tom.

On Wed, 13 Feb 2013 16:48:52 +0000 Tom Hacohen
<tom.hacohen@...> wrote:

> On 13/02/13 10:42, Daniel Willmann wrote:
> > On 13/02/13 00:36, Bruno Dilly wrote:
> >> On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann
> >> <d.willmann@...> wrote:
> >>>
> >>> Topic branches:
> >>> * In each repository every developer with commit access will be
> >>> able to push/update branches in their own namespace
> >>> (devs/<name>/*). These branches will allow non-fastforward
> >>> updates and no one should expect these to be stable.
> >>> * This is a testing ground for developers where new features can
> >>> be developed, debugged and shared with fellow developers. Ideally
> >>> any new feature would live in its own branch until it matures and
> >>> is merged into master.
> >>
> >> Hey Daniel,
> >>
> >> It's a nice proposal, but what about master branch permissions ?
> >> Every developer would be allowed to push stuff on there (with a
> >> flow similar to svn) ? Or we'll try to establish some kind of
> >> policy about it (maintainers, review, etc) ?
> >
> > As others have already pointed out there seems to be consensus that
> > we don't have enough manpower to work with an integrator workflow
> > (whether or not that's true I don't know).
> >
> > What I want to achieve with the topic branches is that whoever
> > wants to can maintain an integrator-like workflow. You develop your
> > feature in a topic branch, then post a request for review/review
> > and test yourself and if everything looks good you can merge into
> > master.
> >
> > Speaking of merging...is there any preference on merge vs. rebase?
> 
> 
> Rebase is easier to work with. I think we should rebase whenever 
> possible. When not possible, we should try to rebase anyway. Linear 
> history is cooler.

The history is not linear though, coz the topic branch was developed in
parallel with the master branch, so that would be a lie to turn it
into a linear history.  Sometimes it's important to know the proper
spaghetti history of branches, especially when lots of people are
contributing their own mess of branchings and merges in their own
style, or lack of style.

So yes, it's easier to rebase, until something inevitably goes wrong
and you need to sort out when and where it went wrong.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.

On Wed, Feb 13, 2013 at 12:18 AM, Cedric BAIL <cedric.bail@...> wrote:
> On Wed, Feb 13, 2013 at 9:36 AM, Bruno Dilly <bdilly@...> wrote:
>> On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann <d.willmann@...> wrote:
>>> Hello,
>>>
>>> beware, the switch to Git will be happening soon! We will migrate efl,
>>> elementary and enlightenment one-by-one and send mails with specific
>>> details when each will happen.
>>>
>>> For the time when we are using Git here is a really small list of what
>>> you need to change:
>>>
>>> First setup Git as it will need to know your name and email (global here
>>> means per-user)
>>> $ git config --global user.name "Jane Doe"
>>> $ git config --global user.email "janedoe@..."
>>>
>>> Useful commands:
>>> To get the repository, run
>>> $ git clone ssh://git@...>>
>>> -> (svn checkout)
>>> The names will be announced as we switch - the first ones will most
>>> likely be core/efl.git, core/elementary.git and core/enlightenment.git
>>>
>>> To update to the newest version
>>> $ git pull --rebase
>>> -> (svn update)
>>>
>>> To commit all local changes
>>> $ git commit -a
>>> $ git push
>>> -> (svn ci)
>>> OR (better) if you just want to commit specific files
>>> $ git add <files>
>>> $ git commit
>>> $ git push
>>> -> (svn ci <files>)
>>>
>>> Here's more Git for SVN users:
>>> http://git-scm.com/course/svn.html
>>>
>>>
>>> If you want to know more I recommend reading (part of) the Git book at
>>> http://git-scm.com/book
>>> I even recommend reading it if you don't want to know more.
>>> A sneak peek of the awesomeness that awaits you at the other side of
>>> that link:
>>>
>>> # Enable color in diffs, etc. (should be default by now)
>>> $ git config --global color.ui true
>>>
>>> # Change your editor if you don't like what $EDITOR points to
>>> $ git config --global core.editor vim
>>>
>>> # Configure shortcuts for commands
>>> $ git config --global alias.ci commit
>>>
>>>
>>>
>>> These were the very basics of how to work with Git on a technical level.
>>> In the following paragraphs I want to introduce some common work flows
>>> that I think are useful to adopt. If you don't understand it all -
>>> that's okay. It's not a MUST. But please feel free to ask if anything is
>>> unclear.
>>>
>>> Structure of the repositories
>>> -----------------------------
>>>
>>> Official:
>>> These branches will be fast-forward only (you cannot rewrite
>>> history/commits that have been published to the server). This is what
>>> people expect from official branches and the same behaviour as with SVN.
>>> Once commits are made you cannot "uncommit" something - only revert.
>>>
>>> * "master" is what trunk used to be. All official development happens
>>>   there.
>>> * For a stabilization branch we will have "<packagename>-<version>"
>>>   branching off of master. This is analog to the way SVN branches were
>>>   used in the past. An example would be "elementary-1.7"
>>> * Git tags will mark the exact commit that was used for a release. As
>>>   such these commits will usually reside within the release branches or
>>>   be the starting point for one. Tags will follow the naming scheme
>>>   v<version>, so for example "v1.7.5".
>>>
>>> Topic branches:
>>> * In each repository every developer with commit access will be able to
>>>   push/update branches in their own namespace (devs/<name>/*). These
>>>   branches will allow non-fastforward updates and no one should expect
>>>   these to be stable.
>>> * This is a testing ground for developers where new features can be
>>>   developed, debugged and shared with fellow developers. Ideally any new
>>>   feature would live in its own branch until it matures and is merged
>>>   into master.
>>
>> It's a nice proposal, but what about master branch permissions ?
>> Every developer would be allowed to push stuff on there (with a flow
>> similar to svn) ? Or we'll try to establish some kind of policy about
>> it (maintainers, review, etc) ?
>
> We did have some discussion and sharing idea about that during fosdem.
> The consensus is that we were not ready as a group of developers to
> move to that kind of organisation. Instead something that maybe would
> fit us more is a release cycle and development process based on time.
>   1 week of feature addition
>   2 week of bug fixing
> This cycle would be repeated 3 times, then followed by :
>   a release candidate
>   2 additional weeks of stabilization (maybe another RC)
>   a beta
>   1 additional week of polishing
>   release (if everything is good of course)
>
> Of course we don't start a feature addition cycle if current master
> branch is unstable. The hope is to be on a more rapid development
> cycle, but still stable and avoiding glacial era like we have before
> each release. Finally it should give us a good release every 3 months.
> It should not change our workflow to much and still be an improvement
> over our current model.
>
> Any though or improvement about it ? Or a better proposal ?

It sounds good. Let's try it =)

> --
> Cedric BAIL
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



-- 
Bruno Dilly
Lead Developer
ProFUSION embedded systems
http://profusion.mobi

On 14/02/13 02:24, David Seikel wrote:
> On Wed, 13 Feb 2013 16:48:52 +0000 Tom Hacohen
> <tom.hacohen@...> wrote:
>
>> On 13/02/13 10:42, Daniel Willmann wrote:
>>> On 13/02/13 00:36, Bruno Dilly wrote:
>>>> On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann
>>>> <d.willmann@...> wrote:
>>>>>
>>>>> Topic branches:
>>>>> * In each repository every developer with commit access will be
>>>>> able to push/update branches in their own namespace
>>>>> (devs/<name>/*). These branches will allow non-fastforward
>>>>> updates and no one should expect these to be stable.
>>>>> * This is a testing ground for developers where new features can
>>>>> be developed, debugged and shared with fellow developers. Ideally
>>>>> any new feature would live in its own branch until it matures and
>>>>> is merged into master.
>>>>
>>>> Hey Daniel,
>>>>
>>>> It's a nice proposal, but what about master branch permissions ?
>>>> Every developer would be allowed to push stuff on there (with a
>>>> flow similar to svn) ? Or we'll try to establish some kind of
>>>> policy about it (maintainers, review, etc) ?
>>>
>>> As others have already pointed out there seems to be consensus that
>>> we don't have enough manpower to work with an integrator workflow
>>> (whether or not that's true I don't know).
>>>
>>> What I want to achieve with the topic branches is that whoever
>>> wants to can maintain an integrator-like workflow. You develop your
>>> feature in a topic branch, then post a request for review/review
>>> and test yourself and if everything looks good you can merge into
>>> master.
>>>
>>> Speaking of merging...is there any preference on merge vs. rebase?
>>
>>
>> Rebase is easier to work with. I think we should rebase whenever
>> possible. When not possible, we should try to rebase anyway. Linear
>> history is cooler.
>
> The history is not linear though, coz the topic branch was developed in
> parallel with the master branch, so that would be a lie to turn it
> into a linear history.  Sometimes it's important to know the proper
> spaghetti history of branches, especially when lots of people are
> contributing their own mess of branchings and merges in their own
> style, or lack of style.
>
> So yes, it's easier to rebase, until something inevitably goes wrong
> and you need to sort out when and where it went wrong.

The development's history is not linear, but we can make the master 
branch's history linear, that's the whole point I'm making. Especially 
for long time SVN users, but not only.

--
Tom.

On Wed, Feb 13, 2013 at 8:42 AM, Daniel Willmann <d.willmann@...> wrote:
> On 13/02/13 00:36, Bruno Dilly wrote:
>> On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann <d.willmann@...>
>> wrote:
>>>
>>> Topic branches:
>>> * In each repository every developer with commit access will be able to
>>>   push/update branches in their own namespace (devs/<name>/*). These
>>>   branches will allow non-fastforward updates and no one should expect
>>>   these to be stable.
>>> * This is a testing ground for developers where new features can be
>>>   developed, debugged and shared with fellow developers. Ideally any new
>>>   feature would live in its own branch until it matures and is merged
>>>   into master.
>>
>> Hey Daniel,
>>
>> It's a nice proposal, but what about master branch permissions ?
>> Every developer would be allowed to push stuff on there (with a flow
>> similar to svn) ? Or we'll try to establish some kind of policy about
>> it (maintainers, review, etc) ?
>
> As others have already pointed out there seems to be consensus that we
> don't have enough manpower to work with an integrator workflow (whether
> or not that's true I don't know).

ok, I got it.

>
> What I want to achieve with the topic branches is that whoever wants to
> can maintain an integrator-like workflow. You develop your feature in a
> topic branch, then post a request for review/review and test yourself
> and if everything looks good you can merge into master.
>
> Speaking of merging...is there any preference on merge vs. rebase?
>
> Lots of small merges can really pollute your history and I don't really
> like them. For larger topic branches I think merging makes sense.

I agree with Tom here.
I'm always trying to keep a linear history, focusing on rebases
instead of merges.
We've used this approach on Profusion projects for years and it worked
fine so far.

Maybe it will give you a little bit more work, you'll have to fix
conflicts in the commits it happens instead of only once in a final
merge commit, but it will be nicer to review or look
for issues later, imo.

Using the merge approach, in a project with so many commiters could
lead us to a very confuse history.

>
>
> Regards,
> Daniel
>
> ------------------------------------------------------------------------------
> Free Next-Gen Firewall Hardware Offer
> Buy your Sophos next-gen firewall before the end March 2013
> and get the hardware for free! Learn more.
> http://p.sf.net/sfu/sophos-d2d-feb
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel



-- 
Bruno Dilly
Lead Developer
ProFUSION embedded systems
http://profusion.mobi

On Thu, 14 Feb 2013 08:53:22 -0200 Bruno Dilly <bdilly@...>
wrote:

> On Wed, Feb 13, 2013 at 8:42 AM, Daniel Willmann
> <d.willmann@...> wrote:
> > On 13/02/13 00:36, Bruno Dilly wrote:
> >> On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann
> >> <d.willmann@...> wrote:
> >>>
> >>> Topic branches:
> >>> * In each repository every developer with commit access will be
> >>> able to push/update branches in their own namespace
> >>> (devs/<name>/*). These branches will allow non-fastforward
> >>> updates and no one should expect these to be stable.
> >>> * This is a testing ground for developers where new features can
> >>> be developed, debugged and shared with fellow developers. Ideally
> >>> any new feature would live in its own branch until it matures and
> >>> is merged into master.
> >>
> >> Hey Daniel,
> >>
> >> It's a nice proposal, but what about master branch permissions ?
> >> Every developer would be allowed to push stuff on there (with a
> >> flow similar to svn) ? Or we'll try to establish some kind of
> >> policy about it (maintainers, review, etc) ?
> >
> > As others have already pointed out there seems to be consensus that
> > we don't have enough manpower to work with an integrator workflow
> > (whether or not that's true I don't know).
> 
> ok, I got it.
> 
> >
> > What I want to achieve with the topic branches is that whoever
> > wants to can maintain an integrator-like workflow. You develop your
> > feature in a topic branch, then post a request for review/review
> > and test yourself and if everything looks good you can merge into
> > master.
> >
> > Speaking of merging...is there any preference on merge vs. rebase?
> >
> > Lots of small merges can really pollute your history and I don't
> > really like them. For larger topic branches I think merging makes
> > sense.
> 
> I agree with Tom here.
> I'm always trying to keep a linear history, focusing on rebases
> instead of merges.
> We've used this approach on Profusion projects for years and it worked
> fine so far.
> 
> Maybe it will give you a little bit more work, you'll have to fix
> conflicts in the commits it happens instead of only once in a final
> merge commit, but it will be nicer to review or look
> for issues later, imo.
> 
> Using the merge approach, in a project with so many commiters could
> lead us to a very confuse history.

If the history is confused, then that's what it should show.  I really
don't like the idea of rewriting history just to make it easier for
some people.  Sometimes you just need to track down what actually
happened, not the convenient lie we tell ourselves is what happened.

Those who don't know history are destined to repeat it.  B-)

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.

On Thu, Feb 14, 2013 at 9:12 AM, David Seikel <onefang@...> wrote:
> On Thu, 14 Feb 2013 08:53:22 -0200 Bruno Dilly <bdilly@...>
> wrote:
>
>> On Wed, Feb 13, 2013 at 8:42 AM, Daniel Willmann
>> <d.willmann@...> wrote:
>> > On 13/02/13 00:36, Bruno Dilly wrote:
>> >> On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann
>> >> <d.willmann@...> wrote:
>> >>>
>> >>> Topic branches:
>> >>> * In each repository every developer with commit access will be
>> >>> able to push/update branches in their own namespace
>> >>> (devs/<name>/*). These branches will allow non-fastforward
>> >>> updates and no one should expect these to be stable.
>> >>> * This is a testing ground for developers where new features can
>> >>> be developed, debugged and shared with fellow developers. Ideally
>> >>> any new feature would live in its own branch until it matures and
>> >>> is merged into master.
>> >>
>> >> Hey Daniel,
>> >>
>> >> It's a nice proposal, but what about master branch permissions ?
>> >> Every developer would be allowed to push stuff on there (with a
>> >> flow similar to svn) ? Or we'll try to establish some kind of
>> >> policy about it (maintainers, review, etc) ?
>> >
>> > As others have already pointed out there seems to be consensus that
>> > we don't have enough manpower to work with an integrator workflow
>> > (whether or not that's true I don't know).
>>
>> ok, I got it.
>>
>> >
>> > What I want to achieve with the topic branches is that whoever
>> > wants to can maintain an integrator-like workflow. You develop your
>> > feature in a topic branch, then post a request for review/review
>> > and test yourself and if everything looks good you can merge into
>> > master.
>> >
>> > Speaking of merging...is there any preference on merge vs. rebase?
>> >
>> > Lots of small merges can really pollute your history and I don't
>> > really like them. For larger topic branches I think merging makes
>> > sense.
>>
>> I agree with Tom here.
>> I'm always trying to keep a linear history, focusing on rebases
>> instead of merges.
>> We've used this approach on Profusion projects for years and it worked
>> fine so far.
>>
>> Maybe it will give you a little bit more work, you'll have to fix
>> conflicts in the commits it happens instead of only once in a final
>> merge commit, but it will be nicer to review or look
>> for issues later, imo.
>>
>> Using the merge approach, in a project with so many commiters could
>> lead us to a very confuse history.
>
> If the history is confused, then that's what it should show.  I really
> don't like the idea of rewriting history just to make it easier for

ahn??  nobody is talking about rewriting the history of the public repository

> some people.  Sometimes you just need to track down what actually
> happened, not the convenient lie we tell ourselves is what happened.
>
> Those who don't know history are destined to repeat it.  B-)

/me confused and so seems you are.


Lucas De Marchi

On Thu, 14 Feb 2013 12:04:49 -0200 Lucas De Marchi
<lucas.demarchi@...> wrote:

> On Thu, Feb 14, 2013 at 9:12 AM, David Seikel <onefang@...>
> wrote:
> > On Thu, 14 Feb 2013 08:53:22 -0200 Bruno Dilly
> > <bdilly@...> wrote:
> >
> >> On Wed, Feb 13, 2013 at 8:42 AM, Daniel Willmann
> >> <d.willmann@...> wrote:
> >> > On 13/02/13 00:36, Bruno Dilly wrote:
> >> >> On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann
> >> >> <d.willmann@...> wrote:
> >> >>>
> >> >>> Topic branches:
> >> >>> * In each repository every developer with commit access will be
> >> >>> able to push/update branches in their own namespace
> >> >>> (devs/<name>/*). These branches will allow non-fastforward
> >> >>> updates and no one should expect these to be stable.
> >> >>> * This is a testing ground for developers where new features
> >> >>> can be developed, debugged and shared with fellow developers.
> >> >>> Ideally any new feature would live in its own branch until it
> >> >>> matures and is merged into master.
> >> >>
> >> >> Hey Daniel,
> >> >>
> >> >> It's a nice proposal, but what about master branch permissions ?
> >> >> Every developer would be allowed to push stuff on there (with a
> >> >> flow similar to svn) ? Or we'll try to establish some kind of
> >> >> policy about it (maintainers, review, etc) ?
> >> >
> >> > As others have already pointed out there seems to be consensus
> >> > that we don't have enough manpower to work with an integrator
> >> > workflow (whether or not that's true I don't know).
> >>
> >> ok, I got it.
> >>
> >> >
> >> > What I want to achieve with the topic branches is that whoever
> >> > wants to can maintain an integrator-like workflow. You develop
> >> > your feature in a topic branch, then post a request for
> >> > review/review and test yourself and if everything looks good you
> >> > can merge into master.
> >> >
> >> > Speaking of merging...is there any preference on merge vs.
> >> > rebase?
> >> >
> >> > Lots of small merges can really pollute your history and I don't
> >> > really like them. For larger topic branches I think merging makes
> >> > sense.
> >>
> >> I agree with Tom here.
> >> I'm always trying to keep a linear history, focusing on rebases
> >> instead of merges.
> >> We've used this approach on Profusion projects for years and it
> >> worked fine so far.
> >>
> >> Maybe it will give you a little bit more work, you'll have to fix
> >> conflicts in the commits it happens instead of only once in a final
> >> merge commit, but it will be nicer to review or look
> >> for issues later, imo.
> >>
> >> Using the merge approach, in a project with so many commiters could
> >> lead us to a very confuse history.
> >
> > If the history is confused, then that's what it should show.  I
> > really don't like the idea of rewriting history just to make it
> > easier for
> 
> ahn??  nobody is talking about rewriting the history of the public
> repository
> 
> > some people.  Sometimes you just need to track down what actually
> > happened, not the convenient lie we tell ourselves is what happened.
> >
> > Those who don't know history are destined to repeat it.  B-)
> 
> /me confused and so seems you are.

You are talking about changing a non linear history to a linear one.
That removes that portion of the information in the history that
concerns what branched / merged from what and when.  In other words the
essence of the non linearness is being removed.  I have dealt with big
git projects with lots of contributors and complex merges.  Sometimes
that info has been useful.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.

On Thu, Feb 14, 2013 at 08:53:22AM -0200, Bruno Dilly wrote:
> On Wed, Feb 13, 2013 at 8:42 AM, Daniel Willmann <d.willmann@...> wrote:
> > On 13/02/13 00:36, Bruno Dilly wrote:
> >> On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann <d.willmann@...>
> >> wrote:
> >>>
> >>> Topic branches:
> >>> * In each repository every developer with commit access will be able to
> >>>   push/update branches in their own namespace (devs/<name>/*). These
> >>>   branches will allow non-fastforward updates and no one should expect
> >>>   these to be stable.
> >>> * This is a testing ground for developers where new features can be
> >>>   developed, debugged and shared with fellow developers. Ideally any new
> >>>   feature would live in its own branch until it matures and is merged
> >>>   into master.
> >>
> >> Hey Daniel,
> >>
> >> It's a nice proposal, but what about master branch permissions ?
> >> Every developer would be allowed to push stuff on there (with a flow
> >> similar to svn) ? Or we'll try to establish some kind of policy about
> >> it (maintainers, review, etc) ?
> >
> > As others have already pointed out there seems to be consensus that we
> > don't have enough manpower to work with an integrator workflow (whether
> > or not that's true I don't know).
> 
> ok, I got it.
> 
> >
> > What I want to achieve with the topic branches is that whoever wants to
> > can maintain an integrator-like workflow. You develop your feature in a
> > topic branch, then post a request for review/review and test yourself
> > and if everything looks good you can merge into master.
> >
> > Speaking of merging...is there any preference on merge vs. rebase?
> >
> > Lots of small merges can really pollute your history and I don't really
> > like them. For larger topic branches I think merging makes sense.
> 
> I agree with Tom here.
> I'm always trying to keep a linear history, focusing on rebases
> instead of merges.
> We've used this approach on Profusion projects for years and it worked
> fine so far.
> 
> Maybe it will give you a little bit more work, you'll have to fix
> conflicts in the commits it happens instead of only once in a final
> merge commit, but it will be nicer to review or look
> for issues later, imo.

It's usually less work for me, because it's easier for me to reapply
patches I had in my own branch and check if they still do what they did
before rebase correctly, then to resolve one big merge conflict where
you can get 5 different people touching the same code as what you had in
branch and you have to be sure that your resolution does not only keep
your change correct, but also does not break those 5 different changes.

> Using the merge approach, in a project with so many commiters could
> lead us to a very confuse history.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@...

Hi David,

On Thu, Feb 14, 2013 at 9:12 AM, David Seikel <onefang@...> wrote:
> On Thu, 14 Feb 2013 08:53:22 -0200 Bruno Dilly <bdilly@...>
> wrote:
>
>> On Wed, Feb 13, 2013 at 8:42 AM, Daniel Willmann
>> <d.willmann@...> wrote:
>> > On 13/02/13 00:36, Bruno Dilly wrote:
>> >> On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann
>> >> <d.willmann@...> wrote:
>> >>>
>> >>> Topic branches:
>> >>> * In each repository every developer with commit access will be
>> >>> able to push/update branches in their own namespace
>> >>> (devs/<name>/*). These branches will allow non-fastforward
>> >>> updates and no one should expect these to be stable.
>> >>> * This is a testing ground for developers where new features can
>> >>> be developed, debugged and shared with fellow developers. Ideally
>> >>> any new feature would live in its own branch until it matures and
>> >>> is merged into master.
>> >>
>> >> Hey Daniel,
>> >>
>> >> It's a nice proposal, but what about master branch permissions ?
>> >> Every developer would be allowed to push stuff on there (with a
>> >> flow similar to svn) ? Or we'll try to establish some kind of
>> >> policy about it (maintainers, review, etc) ?
>> >
>> > As others have already pointed out there seems to be consensus that
>> > we don't have enough manpower to work with an integrator workflow
>> > (whether or not that's true I don't know).
>>
>> ok, I got it.
>>
>> >
>> > What I want to achieve with the topic branches is that whoever
>> > wants to can maintain an integrator-like workflow. You develop your
>> > feature in a topic branch, then post a request for review/review
>> > and test yourself and if everything looks good you can merge into
>> > master.
>> >
>> > Speaking of merging...is there any preference on merge vs. rebase?
>> >
>> > Lots of small merges can really pollute your history and I don't
>> > really like them. For larger topic branches I think merging makes
>> > sense.
>>
>> I agree with Tom here.
>> I'm always trying to keep a linear history, focusing on rebases
>> instead of merges.
>> We've used this approach on Profusion projects for years and it worked
>> fine so far.
>>
>> Maybe it will give you a little bit more work, you'll have to fix
>> conflicts in the commits it happens instead of only once in a final
>> merge commit, but it will be nicer to review or look
>> for issues later, imo.
>>
>> Using the merge approach, in a project with so many commiters could
>> lead us to a very confuse history.
>
> If the history is confused, then that's what it should show.  I really
> don't like the idea of rewriting history just to make it easier for
> some people.  Sometimes you just need to track down what actually
> happened, not the convenient lie we tell ourselves is what happened.

I don't think those that a rebased branch history is a lie. Each
commit will still have the original commit date (if the author did not
change it). You can use that to know when the feature started to be
developed.


OK, you lose a way to track the parent commit for that feature branch,
but on the other hand you earn something important here: the knowledge
that the commits from that feature branch will apply correctly on top
of the current state of the tree, without a magic merge commit fixing
stuff later since some things on the tree are not exactly as they seem
to be in the diff from this commit. The changes that appear in the
diff from a given commit are exactly what that commit is doing.

I know that this is not a poll, but I particularly prefer rebased
branches/commits too.

-- 
Rafael Antognolli
http://antognolli.org/

On Fri, Feb 15, 2013 at 11:56 AM, Rafael Antognolli
<antognolli@...> wrote:
> Hi David,
>
> On Thu, Feb 14, 2013 at 9:12 AM, David Seikel <onefang@...> wrote:
>> On Thu, 14 Feb 2013 08:53:22 -0200 Bruno Dilly <bdilly@...>
>> wrote:
>>
>>> On Wed, Feb 13, 2013 at 8:42 AM, Daniel Willmann
>>> <d.willmann@...> wrote:
>>> > On 13/02/13 00:36, Bruno Dilly wrote:
>>> >> On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann
>>> >> <d.willmann@...> wrote:
>>> >>>
>>> >>> Topic branches:
>>> >>> * In each repository every developer with commit access will be
>>> >>> able to push/update branches in their own namespace
>>> >>> (devs/<name>/*). These branches will allow non-fastforward
>>> >>> updates and no one should expect these to be stable.
>>> >>> * This is a testing ground for developers where new features can
>>> >>> be developed, debugged and shared with fellow developers. Ideally
>>> >>> any new feature would live in its own branch until it matures and
>>> >>> is merged into master.
>>> >>
>>> >> Hey Daniel,
>>> >>
>>> >> It's a nice proposal, but what about master branch permissions ?
>>> >> Every developer would be allowed to push stuff on there (with a
>>> >> flow similar to svn) ? Or we'll try to establish some kind of
>>> >> policy about it (maintainers, review, etc) ?
>>> >
>>> > As others have already pointed out there seems to be consensus that
>>> > we don't have enough manpower to work with an integrator workflow
>>> > (whether or not that's true I don't know).
>>>
>>> ok, I got it.
>>>
>>> >
>>> > What I want to achieve with the topic branches is that whoever
>>> > wants to can maintain an integrator-like workflow. You develop your
>>> > feature in a topic branch, then post a request for review/review
>>> > and test yourself and if everything looks good you can merge into
>>> > master.
>>> >
>>> > Speaking of merging...is there any preference on merge vs. rebase?
>>> >
>>> > Lots of small merges can really pollute your history and I don't
>>> > really like them. For larger topic branches I think merging makes
>>> > sense.
>>>
>>> I agree with Tom here.
>>> I'm always trying to keep a linear history, focusing on rebases
>>> instead of merges.
>>> We've used this approach on Profusion projects for years and it worked
>>> fine so far.
>>>
>>> Maybe it will give you a little bit more work, you'll have to fix
>>> conflicts in the commits it happens instead of only once in a final
>>> merge commit, but it will be nicer to review or look
>>> for issues later, imo.
>>>
>>> Using the merge approach, in a project with so many commiters could
>>> lead us to a very confuse history.
>>
>> If the history is confused, then that's what it should show.  I really
>> don't like the idea of rewriting history just to make it easier for
>> some people.  Sometimes you just need to track down what actually
>> happened, not the convenient lie we tell ourselves is what happened.
>
> I don't think those that a rebased branch history is a lie. Each
> commit will still have the original commit date (if the author did not
> change it). You can use that to know when the feature started to be
> developed.
>
>
> OK, you lose a way to track the parent commit for that feature branch,
> but on the other hand you earn something important here: the knowledge
> that the commits from that feature branch will apply correctly on top
> of the current state of the tree, without a magic merge commit fixing
> stuff later since some things on the tree are not exactly as they seem
> to be in the diff from this commit. The changes that appear in the
> diff from a given commit are exactly what that commit is doing.
>
> I know that this is not a poll, but I particularly prefer rebased
> branches/commits too.

me too.

Merges only make sense when there are maintainers of particular pieces
of the repository. The best example of this is the Linux Kernel. You
merge what the submaintainers send to you. They can't rebase on top of
you because otherwise they would break the history for whoever is
basing their development on their tree.

On the other side, take projects like BlueZ, ConnMan, WebKit.  There
aren't merges... and there's no lie as you are implying. People are
used to rebase before sending the features they developed.

Also we don't need to be black or white here. Sometimes it's easier to
use merges and still don't pollute the repository. I myself sometimes
use merges in the projects I maintain, though most of the times
rebases are better.


Lucas De Marchi

Hi,

On Fri, Feb 15, 2013 at 3:16 PM, Lucas De Marchi
<lucas.demarchi@...> wrote:
>
> On Fri, Feb 15, 2013 at 11:56 AM, Rafael Antognolli
> <antognolli@...> wrote:
> > I know that this is not a poll, but I particularly prefer rebased
> > branches/commits too.
>
> me too.
>
> Merges only make sense when there are maintainers of particular pieces
> of the repository. The best example of this is the Linux Kernel. You
> merge what the submaintainers send to you. They can't rebase on top of
> you because otherwise they would break the history for whoever is
> basing their development on their tree.
>
> On the other side, take projects like BlueZ, ConnMan, WebKit.  There
> aren't merges... and there's no lie as you are implying. People are
> used to rebase before sending the features they developed.
>
> Also we don't need to be black or white here. Sometimes it's easier to
> use merges and still don't pollute the repository. I myself sometimes
> use merges in the projects I maintain, though most of the times
> rebases are better.

+1

-- Ulisses Furquim

On Fri, 15 Feb 2013 11:56:06 -0200 Rafael Antognolli
<antognolli@...> wrote:

> Hi David,
> 
> On Thu, Feb 14, 2013 at 9:12 AM, David Seikel <onefang@...>
> wrote:
> > On Thu, 14 Feb 2013 08:53:22 -0200 Bruno Dilly
> > <bdilly@...> wrote:
> >
> >> On Wed, Feb 13, 2013 at 8:42 AM, Daniel Willmann
> >> <d.willmann@...> wrote:
> >> > On 13/02/13 00:36, Bruno Dilly wrote:
> >> >> On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann
> >> >> <d.willmann@...> wrote:
> >> >>>
> >> >>> Topic branches:
> >> >>> * In each repository every developer with commit access will be
> >> >>> able to push/update branches in their own namespace
> >> >>> (devs/<name>/*). These branches will allow non-fastforward
> >> >>> updates and no one should expect these to be stable.
> >> >>> * This is a testing ground for developers where new features
> >> >>> can be developed, debugged and shared with fellow developers.
> >> >>> Ideally any new feature would live in its own branch until it
> >> >>> matures and is merged into master.
> >> >>
> >> >> Hey Daniel,
> >> >>
> >> >> It's a nice proposal, but what about master branch permissions ?
> >> >> Every developer would be allowed to push stuff on there (with a
> >> >> flow similar to svn) ? Or we'll try to establish some kind of
> >> >> policy about it (maintainers, review, etc) ?
> >> >
> >> > As others have already pointed out there seems to be consensus
> >> > that we don't have enough manpower to work with an integrator
> >> > workflow (whether or not that's true I don't know).
> >>
> >> ok, I got it.
> >>
> >> >
> >> > What I want to achieve with the topic branches is that whoever
> >> > wants to can maintain an integrator-like workflow. You develop
> >> > your feature in a topic branch, then post a request for
> >> > review/review and test yourself and if everything looks good you
> >> > can merge into master.
> >> >
> >> > Speaking of merging...is there any preference on merge vs.
> >> > rebase?
> >> >
> >> > Lots of small merges can really pollute your history and I don't
> >> > really like them. For larger topic branches I think merging makes
> >> > sense.
> >>
> >> I agree with Tom here.
> >> I'm always trying to keep a linear history, focusing on rebases
> >> instead of merges.
> >> We've used this approach on Profusion projects for years and it
> >> worked fine so far.
> >>
> >> Maybe it will give you a little bit more work, you'll have to fix
> >> conflicts in the commits it happens instead of only once in a final
> >> merge commit, but it will be nicer to review or look
> >> for issues later, imo.
> >>
> >> Using the merge approach, in a project with so many commiters could
> >> lead us to a very confuse history.
> >
> > If the history is confused, then that's what it should show.  I
> > really don't like the idea of rewriting history just to make it
> > easier for some people.  Sometimes you just need to track down what
> > actually happened, not the convenient lie we tell ourselves is what
> > happened.
> 
> I don't think those that a rebased branch history is a lie. Each
> commit will still have the original commit date (if the author did not
> change it). You can use that to know when the feature started to be
> developed.

It is a lie, it's changing the history to say it was all done one after
the other, when in fact a major feature of distributed development was
used to branch then merge.  It was not done in a linear fashion, thus
making it be linear after the fact is not representing the truth.  Sure
SOME parts of the commit history are still the truth, but not all.

> OK, you lose a way to track the parent commit for that feature branch,
> but on the other hand you earn something important here: the knowledge
> that the commits from that feature branch will apply correctly on top
> of the current state of the tree, without a magic merge commit fixing
> stuff later since some things on the tree are not exactly as they seem
> to be in the diff from this commit. The changes that appear in the
> diff from a given commit are exactly what that commit is doing.

That's what I'm saying, loosing information to make things more
convenient.  I'd prefer to err on the side of not loosing information.
But then again, I'm a hoarder.  B-)

> I know that this is not a poll, but I particularly prefer rebased
> branches/commits too.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.

On 02/16/13 15:58, David Seikel wrote:
> On Fri, 15 Feb 2013 11:56:06 -0200 Rafael Antognolli
> <antognolli@...> wrote:
> 
> > Hi David,
> > 
> > On Thu, Feb 14, 2013 at 9:12 AM, David Seikel <onefang@...>
> > wrote:
> > > On Thu, 14 Feb 2013 08:53:22 -0200 Bruno Dilly
> > > <bdilly@...> wrote:
> > >
> > >> On Wed, Feb 13, 2013 at 8:42 AM, Daniel Willmann
> > >> <d.willmann@...> wrote:
> > >> > On 13/02/13 00:36, Bruno Dilly wrote:
> > >> >> On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann
> > >> >> <d.willmann@...> wrote:
> > >> >>>
> > >> >>> Topic branches:
> > >> >>> * In each repository every developer with commit access will be
> > >> >>> able to push/update branches in their own namespace
> > >> >>> (devs/<name>/*). These branches will allow non-fastforward
> > >> >>> updates and no one should expect these to be stable.
> > >> >>> * This is a testing ground for developers where new features
> > >> >>> can be developed, debugged and shared with fellow developers.
> > >> >>> Ideally any new feature would live in its own branch until it
> > >> >>> matures and is merged into master.
> > >> >>
> > >> >> Hey Daniel,
> > >> >>
> > >> >> It's a nice proposal, but what about master branch permissions ?
> > >> >> Every developer would be allowed to push stuff on there (with a
> > >> >> flow similar to svn) ? Or we'll try to establish some kind of
> > >> >> policy about it (maintainers, review, etc) ?
> > >> >
> > >> > As others have already pointed out there seems to be consensus
> > >> > that we don't have enough manpower to work with an integrator
> > >> > workflow (whether or not that's true I don't know).
> > >>
> > >> ok, I got it.
> > >>
> > >> >
> > >> > What I want to achieve with the topic branches is that whoever
> > >> > wants to can maintain an integrator-like workflow. You develop
> > >> > your feature in a topic branch, then post a request for
> > >> > review/review and test yourself and if everything looks good you
> > >> > can merge into master.
> > >> >
> > >> > Speaking of merging...is there any preference on merge vs.
> > >> > rebase?
> > >> >
> > >> > Lots of small merges can really pollute your history and I don't
> > >> > really like them. For larger topic branches I think merging makes
> > >> > sense.
> > >>
> > >> I agree with Tom here.
> > >> I'm always trying to keep a linear history, focusing on rebases
> > >> instead of merges.
> > >> We've used this approach on Profusion projects for years and it
> > >> worked fine so far.
> > >>
> > >> Maybe it will give you a little bit more work, you'll have to fix
> > >> conflicts in the commits it happens instead of only once in a final
> > >> merge commit, but it will be nicer to review or look
> > >> for issues later, imo.
> > >>
> > >> Using the merge approach, in a project with so many commiters could
> > >> lead us to a very confuse history.
> > >
> > > If the history is confused, then that's what it should show.  I
> > > really don't like the idea of rewriting history just to make it
> > > easier for some people.  Sometimes you just need to track down what
> > > actually happened, not the convenient lie we tell ourselves is what
> > > happened.
> > 
> > I don't think those that a rebased branch history is a lie. Each
> > commit will still have the original commit date (if the author did not
> > change it). You can use that to know when the feature started to be
> > developed.
> 
> It is a lie, it's changing the history to say it was all done one after
> the other, when in fact a major feature of distributed development was
> used to branch then merge.  It was not done in a linear fashion, thus
> making it be linear after the fact is not representing the truth.  Sure
> SOME parts of the commit history are still the truth, but not all.
> 
> > OK, you lose a way to track the parent commit for that feature branch,
> > but on the other hand you earn something important here: the knowledge
> > that the commits from that feature branch will apply correctly on top
> > of the current state of the tree, without a magic merge commit fixing
> > stuff later since some things on the tree are not exactly as they seem
> > to be in the diff from this commit. The changes that appear in the
> > diff from a given commit are exactly what that commit is doing.
> 
> That's what I'm saying, loosing information to make things more
> convenient.  I'd prefer to err on the side of not loosing information.
> But then again, I'm a hoarder.  B-)
> 
> > I know that this is not a poll, but I particularly prefer rebased
> > branches/commits too.

LWN has a neat article about the git rebase thing:
http://lwn.net/Articles/328436/ 

"Thou Shalt Not Rebase Trees With History Visible To Others"

-- 
Jérôme Pinot
http://ngc891.blogdns.net/

On Sat, 16 Feb 2013 15:42:46 +0900 Jérôme Pinot <ngc891@...>
wrote:

> On 02/16/13 15:58, David Seikel wrote:
> > On Fri, 15 Feb 2013 11:56:06 -0200 Rafael Antognolli
> > <antognolli@...> wrote:
> > 
> > > Hi David,
> > > 
> > > On Thu, Feb 14, 2013 at 9:12 AM, David Seikel <onefang@...>
> > > wrote:
> > > > On Thu, 14 Feb 2013 08:53:22 -0200 Bruno Dilly
> > > > <bdilly@...> wrote:
> > > >
> > > >> On Wed, Feb 13, 2013 at 8:42 AM, Daniel Willmann
> > > >> <d.willmann@...> wrote:
> > > >> > On 13/02/13 00:36, Bruno Dilly wrote:
> > > >> >> On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann
> > > >> >> <d.willmann@...> wrote:
> > > >> >>>
> > > >> >>> Topic branches:
> > > >> >>> * In each repository every developer with commit access
> > > >> >>> will be able to push/update branches in their own namespace
> > > >> >>> (devs/<name>/*). These branches will allow non-fastforward
> > > >> >>> updates and no one should expect these to be stable.
> > > >> >>> * This is a testing ground for developers where new
> > > >> >>> features can be developed, debugged and shared with fellow
> > > >> >>> developers. Ideally any new feature would live in its own
> > > >> >>> branch until it matures and is merged into master.
> > > >> >>
> > > >> >> Hey Daniel,
> > > >> >>
> > > >> >> It's a nice proposal, but what about master branch
> > > >> >> permissions ? Every developer would be allowed to push
> > > >> >> stuff on there (with a flow similar to svn) ? Or we'll try
> > > >> >> to establish some kind of policy about it (maintainers,
> > > >> >> review, etc) ?
> > > >> >
> > > >> > As others have already pointed out there seems to be
> > > >> > consensus that we don't have enough manpower to work with an
> > > >> > integrator workflow (whether or not that's true I don't
> > > >> > know).
> > > >>
> > > >> ok, I got it.
> > > >>
> > > >> >
> > > >> > What I want to achieve with the topic branches is that
> > > >> > whoever wants to can maintain an integrator-like workflow.
> > > >> > You develop your feature in a topic branch, then post a
> > > >> > request for review/review and test yourself and if
> > > >> > everything looks good you can merge into master.
> > > >> >
> > > >> > Speaking of merging...is there any preference on merge vs.
> > > >> > rebase?
> > > >> >
> > > >> > Lots of small merges can really pollute your history and I
> > > >> > don't really like them. For larger topic branches I think
> > > >> > merging makes sense.
> > > >>
> > > >> I agree with Tom here.
> > > >> I'm always trying to keep a linear history, focusing on rebases
> > > >> instead of merges.
> > > >> We've used this approach on Profusion projects for years and it
> > > >> worked fine so far.
> > > >>
> > > >> Maybe it will give you a little bit more work, you'll have to
> > > >> fix conflicts in the commits it happens instead of only once
> > > >> in a final merge commit, but it will be nicer to review or look
> > > >> for issues later, imo.
> > > >>
> > > >> Using the merge approach, in a project with so many commiters
> > > >> could lead us to a very confuse history.
> > > >
> > > > If the history is confused, then that's what it should show.  I
> > > > really don't like the idea of rewriting history just to make it
> > > > easier for some people.  Sometimes you just need to track down
> > > > what actually happened, not the convenient lie we tell
> > > > ourselves is what happened.
> > > 
> > > I don't think those that a rebased branch history is a lie. Each
> > > commit will still have the original commit date (if the author
> > > did not change it). You can use that to know when the feature
> > > started to be developed.
> > 
> > It is a lie, it's changing the history to say it was all done one
> > after the other, when in fact a major feature of distributed
> > development was used to branch then merge.  It was not done in a
> > linear fashion, thus making it be linear after the fact is not
> > representing the truth.  Sure SOME parts of the commit history are
> > still the truth, but not all.
> > 
> > > OK, you lose a way to track the parent commit for that feature
> > > branch, but on the other hand you earn something important here:
> > > the knowledge that the commits from that feature branch will
> > > apply correctly on top of the current state of the tree, without
> > > a magic merge commit fixing stuff later since some things on the
> > > tree are not exactly as they seem to be in the diff from this
> > > commit. The changes that appear in the diff from a given commit
> > > are exactly what that commit is doing.
> > 
> > That's what I'm saying, loosing information to make things more
> > convenient.  I'd prefer to err on the side of not loosing
> > information. But then again, I'm a hoarder.  B-)
> > 
> > > I know that this is not a poll, but I particularly prefer rebased
> > > branches/commits too.
> 
> LWN has a neat article about the git rebase thing:
> http://lwn.net/Articles/328436/ 
> 
> "Thou Shalt Not Rebase Trees With History Visible To Others"

I was easily able to come up with many "rebase is evil" things with a
web search engine, and it turned up a few "rebase is not evil" things as
well.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.

By the way, Daniel,

Could it possible to make git mail title messages to be more meaningful?

i.e) [core/efl] xxxmaster updated. f27ff2fbf31a01c2f8d98e773bed6cc4298749bd
 -> [core/efl/evas] xxxmaster updated. f27ff2fbf31a01c2f8d98e773bed6cc4298749bd

If the title shows any detailed core lib name that was changed, it would be better to know what is changed in abstractly. 
 
-Regards, Hermet-

-----Original Message-----
From: "David Seikel"<onefang@...> 
To: <enlightenment-devel@...>; 
Cc: 
Sent: 2013-02-16 (토) 16:19:58
Subject: Re: [E-devel] SVN->Git Migration (was: (no subject))

On Sat, 16 Feb 2013 15:42:46 +0900 Jérôme Pinot <ngc891>@gmail.com>
wrote:

> On 02/16/13 15:58, David Seikel wrote:
> > On Fri, 15 Feb 2013 11:56:06 -0200 Rafael Antognolli
> > <antognolli>@gmail.com> wrote:
> > 
> > > Hi David,
> > > 
> > > On Thu, Feb 14, 2013 at 9:12 AM, David Seikel <onefang>@gmail.com>
> > > wrote:
> > > > On Thu, 14 Feb 2013 08:53:22 -0200 Bruno Dilly
> > > > <bdilly>@profusion.mobi> wrote:
> > > >
> > > >> On Wed, Feb 13, 2013 at 8:42 AM, Daniel Willmann
> > > >> <d.willmann>@samsung.com> wrote:
> > > >> > On 13/02/13 00:36, Bruno Dilly wrote:
> > > >> >> On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann
> > > >> >> <d.willmann>@samsung.com> wrote:
> > > >> >>>
> > > >> >>> Topic branches:
> > > >> >>> * In each repository every developer with commit access
> > > >> >>> will be able to push/update branches in their own namespace
> > > >> >>> (devs/<name>/*). These branches will allow non-fastforward
> > > >> >>> updates and no one should expect these to be stable.
> > > >> >>> * This is a testing ground for developers where new
> > > >> >>> features can be developed, debugged and shared with fellow
> > > >> >>> developers. Ideally any new feature would live in its own
> > > >> >>> branch until it matures and is merged into master.
> > > >> >>
> > > >> >> Hey Daniel,
> > > >> >>
> > > >> >> It's a nice proposal, but what about master branch
> > > >> >> permissions ? Every developer would be allowed to push
> > > >> >> stuff on there (with a flow similar to svn) ? Or we'll try
> > > >> >> to establish some kind of policy about it (maintainers,
> > > >> >> review, etc) ?
> > > >> >
> > > >> > As others have already pointed out there seems to be
> > > >> > consensus that we don't have enough manpower to work with an
> > > >> > integrator workflow (whether or not that's true I don't
> > > >> > know).
> > > >>
> > > >> ok, I got it.
> > > >>
> > > >> >
> > > >> > What I want to achieve with the topic branches is that
> > > >> > whoever wants to can maintain an integrator-like workflow.
> > > >> > You develop your feature in a topic branch, then post a
> > > >> > request for review/review and test yourself and if
> > > >> > everything looks good you can merge into master.
> > > >> >
> > > >> > Speaking of merging...is there any preference on merge vs.
> > > >> > rebase?
> > > >> >
> > > >> > Lots of small merges can really pollute your history and I
> > > >> > don't really like them. For larger topic branches I think
> > > >> > merging makes sense.
> > > >>
> > > >> I agree with Tom here.
> > > >> I'm always trying to keep a linear history, focusing on rebases
> > > >> instead of merges.
> > > >> We've used this approach on Profusion projects for years and it
> > > >> worked fine so far.
> > > >>
> > > >> Maybe it will give you a little bit more work, you'll have to
> > > >> fix conflicts in the commits it happens instead of only once
> > > >> in a final merge commit, but it will be nicer to review or look
> > > >> for issues later, imo.
> > > >>
> > > >> Using the merge approach, in a project with so many commiters
> > > >> could lead us to a very confuse history.
> > > >
> > > > If the history is confused, then that's what it should show.  I
> > > > really don't like the idea of rewriting history just to make it
> > > > easier for some people.  Sometimes you just need to track down
> > > > what actually happened, not the convenient lie we tell
> > > > ourselves is what happened.
> > > 
> > > I don't think those that a rebased branch history is a lie. Each
> > > commit will still have the original commit date (if the author
> > > did not change it). You can use that to know when the feature
> > > started to be developed.
> > 
> > It is a lie, it's changing the history to say it was all done one
> > after the other, when in fact a major feature of distributed
> > development was used to branch then merge.  It was not done in a
> > linear fashion, thus making it be linear after the fact is not
> > representing the truth.  Sure SOME parts of the commit history are
> > still the truth, but not all.
> > 
> > > OK, you lose a way to track the parent commit for that feature
> > > branch, but on the other hand you earn something important here:
> > > the knowledge that the commits from that feature branch will
> > > apply correctly on top of the current state of the tree, without
> > > a magic merge commit fixing stuff later since some things on the
> > > tree are not exactly as they seem to be in the diff from this
> > > commit. The changes that appear in the diff from a given commit
> > > are exactly what that commit is doing.
> > 
> > That's what I'm saying, loosing information to make things more
> > convenient.  I'd prefer to err on the side of not loosing
> > information. But then again, I'm a hoarder.  B-)
> > 
> > > I know that this is not a poll, but I particularly prefer rebased
> > > branches/commits too.
> 
> LWN has a neat article about the git rebase thing:
> http://lwn.net/Articles/328436/ 
> 
> "Thou Shalt Not Rebase Trees With History Visible To Others"

I was easily able to come up with many "rebase is evil" things with a
web search engine, and it turned up a few "rebase is not evil" things as
well.

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.

------------------------------------------------------------------------------
The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
is your hub for all things parallel software development, from weekly thought 
leadership blogs to news, videos, case studies, tutorials, tech docs, 
whitepapers, evaluation guides, and opinion stories. Check out the most 
recent posts - join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@...
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

And it'll be great if the title includes the first line of commit message.
That should be way more useful.
Thanks.

Daniel Juyung Seo (SeoZ)

On Mon, Feb 18, 2013 at 10:14 AM, ChunEon Park <hermet@...> wrote:

> By the way, Daniel,
>
> Could it possible to make git mail title messages to be more meaningful?
>
> i.e) [core/efl] xxxmaster updated. f27ff2fbf31a01c2f8d98e773bed6cc4298749bd
>  -> [core/efl/evas] xxxmaster updated.
> f27ff2fbf31a01c2f8d98e773bed6cc4298749bd
>
> If the title shows any detailed core lib name that was changed, it would
> be better to know what is changed in abstractly.
>
> -Regards, Hermet-
>
> -----Original Message-----
> From: "David Seikel"<onefang@...>
> To: <enlightenment-devel@...>;
> Cc:
> Sent: 2013-02-16 (토) 16:19:58
> Subject: Re: [E-devel] SVN->Git Migration (was: (no subject))
>
> On Sat, 16 Feb 2013 15:42:46 +0900 Jérôme Pinot <ngc891>@gmail.com>
> wrote:
>
> > On 02/16/13 15:58, David Seikel wrote:
> > > On Fri, 15 Feb 2013 11:56:06 -0200 Rafael Antognolli
> > > <antognolli>@gmail.com> wrote:
> > >
> > > > Hi David,
> > > >
> > > > On Thu, Feb 14, 2013 at 9:12 AM, David Seikel <onefang>@gmail.com>
> > > > wrote:
> > > > > On Thu, 14 Feb 2013 08:53:22 -0200 Bruno Dilly
> > > > > <bdilly>@profusion.mobi> wrote:
> > > > >
> > > > >> On Wed, Feb 13, 2013 at 8:42 AM, Daniel Willmann
> > > > >> <d.willmann>@samsung.com> wrote:
> > > > >> > On 13/02/13 00:36, Bruno Dilly wrote:
> > > > >> >> On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann
> > > > >> >> <d.willmann>@samsung.com> wrote:
> > > > >> >>>
> > > > >> >>> Topic branches:
> > > > >> >>> * In each repository every developer with commit access
> > > > >> >>> will be able to push/update branches in their own namespace
> > > > >> >>> (devs/<name>/*). These branches will allow non-fastforward
> > > > >> >>> updates and no one should expect these to be stable.
> > > > >> >>> * This is a testing ground for developers where new
> > > > >> >>> features can be developed, debugged and shared with fellow
> > > > >> >>> developers. Ideally any new feature would live in its own
> > > > >> >>> branch until it matures and is merged into master.
> > > > >> >>
> > > > >> >> Hey Daniel,
> > > > >> >>
> > > > >> >> It's a nice proposal, but what about master branch
> > > > >> >> permissions ? Every developer would be allowed to push
> > > > >> >> stuff on there (with a flow similar to svn) ? Or we'll try
> > > > >> >> to establish some kind of policy about it (maintainers,
> > > > >> >> review, etc) ?
> > > > >> >
> > > > >> > As others have already pointed out there seems to be
> > > > >> > consensus that we don't have enough manpower to work with an
> > > > >> > integrator workflow (whether or not that's true I don't
> > > > >> > know).
> > > > >>
> > > > >> ok, I got it.
> > > > >>
> > > > >> >
> > > > >> > What I want to achieve with the topic branches is that
> > > > >> > whoever wants to can maintain an integrator-like workflow.
> > > > >> > You develop your feature in a topic branch, then post a
> > > > >> > request for review/review and test yourself and if
> > > > >> > everything looks good you can merge into master.
> > > > >> >
> > > > >> > Speaking of merging...is there any preference on merge vs.
> > > > >> > rebase?
> > > > >> >
> > > > >> > Lots of small merges can really pollute your history and I
> > > > >> > don't really like them. For larger topic branches I think
> > > > >> > merging makes sense.
> > > > >>
> > > > >> I agree with Tom here.
> > > > >> I'm always trying to keep a linear history, focusing on rebases
> > > > >> instead of merges.
> > > > >> We've used this approach on Profusion projects for years and it
> > > > >> worked fine so far.
> > > > >>
> > > > >> Maybe it will give you a little bit more work, you'll have to
> > > > >> fix conflicts in the commits it happens instead of only once
> > > > >> in a final merge commit, but it will be nicer to review or look
> > > > >> for issues later, imo.
> > > > >>
> > > > >> Using the merge approach, in a project with so many commiters
> > > > >> could lead us to a very confuse history.
> > > > >
> > > > > If the history is confused, then that's what it should show.  I
> > > > > really don't like the idea of rewriting history just to make it
> > > > > easier for some people.  Sometimes you just need to track down
> > > > > what actually happened, not the convenient lie we tell
> > > > > ourselves is what happened.
> > > >
> > > > I don't think those that a rebased branch history is a lie. Each
> > > > commit will still have the original commit date (if the author
> > > > did not change it). You can use that to know when the feature
> > > > started to be developed.
> > >
> > > It is a lie, it's changing the history to say it was all done one
> > > after the other, when in fact a major feature of distributed
> > > development was used to branch then merge.  It was not done in a
> > > linear fashion, thus making it be linear after the fact is not
> > > representing the truth.  Sure SOME parts of the commit history are
> > > still the truth, but not all.
> > >
> > > > OK, you lose a way to track the parent commit for that feature
> > > > branch, but on the other hand you earn something important here:
> > > > the knowledge that the commits from that feature branch will
> > > > apply correctly on top of the current state of the tree, without
> > > > a magic merge commit fixing stuff later since some things on the
> > > > tree are not exactly as they seem to be in the diff from this
> > > > commit. The changes that appear in the diff from a given commit
> > > > are exactly what that commit is doing.
> > >
> > > That's what I'm saying, loosing information to make things more
> > > convenient.  I'd prefer to err on the side of not loosing
> > > information. But then again, I'm a hoarder.  B-)
> > >
> > > > I know that this is not a poll, but I particularly prefer rebased
> > > > branches/commits too.
> >
> > LWN has a neat article about the git rebase thing:
> > http://lwn.net/Articles/328436/
> >
> > "Thou Shalt Not Rebase Trees With History Visible To Others"
>
> I was easily able to come up with many "rebase is evil" things with a
> web search engine, and it turned up a few "rebase is not evil" things as
> well.
>
> --
> A big old stinking pile of genius that no one wants
> coz there are too many silver coated monkeys in the world.
>
>
> ------------------------------------------------------------------------------
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
> is your hub for all things parallel software development, from weekly
> thought
> leadership blogs to news, videos, case studies, tutorials, tech docs,
> whitepapers, evaluation guides, and opinion stories. Check out the most
> recent posts - join the conversation now.
> http://goparallel.sourceforge.net/
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>
>
> ------------------------------------------------------------------------------
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
> is your hub for all things parallel software development, from weekly
> thought
> leadership blogs to news, videos, case studies, tutorials, tech docs,
> whitepapers, evaluation guides, and opinion stories. Check out the most
> recent posts - join the conversation now.
> http://goparallel.sourceforge.net/
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>

On Mon, Feb 18, 2013 at 1:02 PM, Daniel Juyung Seo <seojuyung2@...> wrote:
> And it'll be great if the title includes the first line of commit message.
> That should be way more useful.

Indeed.
-- 
Cedric BAIL

+1 I strongly agree.
Commit id title is inconvenient.
2013. 2. 18. 오후 1:04에 "Daniel Juyung Seo" <seojuyung2@...>님이 작성:

> And it'll be great if the title includes the first line of commit message.
> That should be way more useful.
> Thanks.
>
> Daniel Juyung Seo (SeoZ)
>
> On Mon, Feb 18, 2013 at 10:14 AM, ChunEon Park <hermet@...> wrote:
>
> > By the way, Daniel,
> >
> > Could it possible to make git mail title messages to be more meaningful?
> >
> > i.e) [core/efl] xxxmaster updated.
> f27ff2fbf31a01c2f8d98e773bed6cc4298749bd
> >  -> [core/efl/evas] xxxmaster updated.
> > f27ff2fbf31a01c2f8d98e773bed6cc4298749bd
> >
> > If the title shows any detailed core lib name that was changed, it would
> > be better to know what is changed in abstractly.
> >
> > -Regards, Hermet-
> >
> > -----Original Message-----
> > From: "David Seikel"<onefang@...>
> > To: <enlightenment-devel@...>;
> > Cc:
> > Sent: 2013-02-16 (토) 16:19:58
> > Subject: Re: [E-devel] SVN->Git Migration (was: (no subject))
> >
> > On Sat, 16 Feb 2013 15:42:46 +0900 Jérôme Pinot <ngc891>@gmail.com>
> > wrote:
> >
> > > On 02/16/13 15:58, David Seikel wrote:
> > > > On Fri, 15 Feb 2013 11:56:06 -0200 Rafael Antognolli
> > > > <antognolli>@gmail.com> wrote:
> > > >
> > > > > Hi David,
> > > > >
> > > > > On Thu, Feb 14, 2013 at 9:12 AM, David Seikel <onefang>@gmail.com>
> > > > > wrote:
> > > > > > On Thu, 14 Feb 2013 08:53:22 -0200 Bruno Dilly
> > > > > > <bdilly>@profusion.mobi> wrote:
> > > > > >
> > > > > >> On Wed, Feb 13, 2013 at 8:42 AM, Daniel Willmann
> > > > > >> <d.willmann>@samsung.com> wrote:
> > > > > >> > On 13/02/13 00:36, Bruno Dilly wrote:
> > > > > >> >> On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann
> > > > > >> >> <d.willmann>@samsung.com> wrote:
> > > > > >> >>>
> > > > > >> >>> Topic branches:
> > > > > >> >>> * In each repository every developer with commit access
> > > > > >> >>> will be able to push/update branches in their own namespace
> > > > > >> >>> (devs/<name>/*). These branches will allow non-fastforward
> > > > > >> >>> updates and no one should expect these to be stable.
> > > > > >> >>> * This is a testing ground for developers where new
> > > > > >> >>> features can be developed, debugged and shared with fellow
> > > > > >> >>> developers. Ideally any new feature would live in its own
> > > > > >> >>> branch until it matures and is merged into master.
> > > > > >> >>
> > > > > >> >> Hey Daniel,
> > > > > >> >>
> > > > > >> >> It's a nice proposal, but what about master branch
> > > > > >> >> permissions ? Every developer would be allowed to push
> > > > > >> >> stuff on there (with a flow similar to svn) ? Or we'll try
> > > > > >> >> to establish some kind of policy about it (maintainers,
> > > > > >> >> review, etc) ?
> > > > > >> >
> > > > > >> > As others have already pointed out there seems to be
> > > > > >> > consensus that we don't have enough manpower to work with an
> > > > > >> > integrator workflow (whether or not that's true I don't
> > > > > >> > know).
> > > > > >>
> > > > > >> ok, I got it.
> > > > > >>
> > > > > >> >
> > > > > >> > What I want to achieve with the topic branches is that
> > > > > >> > whoever wants to can maintain an integrator-like workflow.
> > > > > >> > You develop your feature in a topic branch, then post a
> > > > > >> > request for review/review and test yourself and if
> > > > > >> > everything looks good you can merge into master.
> > > > > >> >
> > > > > >> > Speaking of merging...is there any preference on merge vs.
> > > > > >> > rebase?
> > > > > >> >
> > > > > >> > Lots of small merges can really pollute your history and I
> > > > > >> > don't really like them. For larger topic branches I think
> > > > > >> > merging makes sense.
> > > > > >>
> > > > > >> I agree with Tom here.
> > > > > >> I'm always trying to keep a linear history, focusing on rebases
> > > > > >> instead of merges.
> > > > > >> We've used this approach on Profusion projects for years and it
> > > > > >> worked fine so far.
> > > > > >>
> > > > > >> Maybe it will give you a little bit more work, you'll have to
> > > > > >> fix conflicts in the commits it happens instead of only once
> > > > > >> in a final merge commit, but it will be nicer to review or look
> > > > > >> for issues later, imo.
> > > > > >>
> > > > > >> Using the merge approach, in a project with so many commiters
> > > > > >> could lead us to a very confuse history.
> > > > > >
> > > > > > If the history is confused, then that's what it should show.  I
> > > > > > really don't like the idea of rewriting history just to make it
> > > > > > easier for some people.  Sometimes you just need to track down
> > > > > > what actually happened, not the convenient lie we tell
> > > > > > ourselves is what happened.
> > > > >
> > > > > I don't think those that a rebased branch history is a lie. Each
> > > > > commit will still have the original commit date (if the author
> > > > > did not change it). You can use that to know when the feature
> > > > > started to be developed.
> > > >
> > > > It is a lie, it's changing the history to say it was all done one
> > > > after the other, when in fact a major feature of distributed
> > > > development was used to branch then merge.  It was not done in a
> > > > linear fashion, thus making it be linear after the fact is not
> > > > representing the truth.  Sure SOME parts of the commit history are
> > > > still the truth, but not all.
> > > >
> > > > > OK, you lose a way to track the parent commit for that feature
> > > > > branch, but on the other hand you earn something important here:
> > > > > the knowledge that the commits from that feature branch will
> > > > > apply correctly on top of the current state of the tree, without
> > > > > a magic merge commit fixing stuff later since some things on the
> > > > > tree are not exactly as they seem to be in the diff from this
> > > > > commit. The changes that appear in the diff from a given commit
> > > > > are exactly what that commit is doing.
> > > >
> > > > That's what I'm saying, loosing information to make things more
> > > > convenient.  I'd prefer to err on the side of not loosing
> > > > information. But then again, I'm a hoarder.  B-)
> > > >
> > > > > I know that this is not a poll, but I particularly prefer rebased
> > > > > branches/commits too.
> > >
> > > LWN has a neat article about the git rebase thing:
> > > http://lwn.net/Articles/328436/
> > >
> > > "Thou Shalt Not Rebase Trees With History Visible To Others"
> >
> > I was easily able to come up with many "rebase is evil" things with a
> > web search engine, and it turned up a few "rebase is not evil" things as
> > well.
> >
> > --
> > A big old stinking pile of genius that no one wants
> > coz there are too many silver coated monkeys in the world.
> >
> >
> >
> ------------------------------------------------------------------------------
> > The Go Parallel Website, sponsored by Intel - in partnership with
> Geeknet,
> > is your hub for all things parallel software development, from weekly
> > thought
> > leadership blogs to news, videos, case studies, tutorials, tech docs,
> > whitepapers, evaluation guides, and opinion stories. Check out the most
> > recent posts - join the conversation now.
> > http://goparallel.sourceforge.net/
> > _______________________________________________
> > enlightenment-devel mailing list
> > enlightenment-devel@...
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
> >
> >
> ------------------------------------------------------------------------------
> > The Go Parallel Website, sponsored by Intel - in partnership with
> Geeknet,
> > is your hub for all things parallel software development, from weekly
> > thought
> > leadership blogs to news, videos, case studies, tutorials, tech docs,
> > whitepapers, evaluation guides, and opinion stories. Check out the most
> > recent posts - join the conversation now.
> > http://goparallel.sourceforge.net/
> > _______________________________________________
> > enlightenment-devel mailing list
> > enlightenment-devel@...
> > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> >
>
> ------------------------------------------------------------------------------
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
> is your hub for all things parallel software development, from weekly
> thought
> leadership blogs to news, videos, case studies, tutorials, tech docs,
> whitepapers, evaluation guides, and opinion stories. Check out the most
> recent posts - join the conversation now.
> http://goparallel.sourceforge.net/
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>

On 18/02/13 04:02, Daniel Juyung Seo wrote:
> And it'll be great if the title includes the first line of commit message.
> That should be way more useful.
> Thanks.

Correct me if I'm wrong, but I'm starting to think you guys would like 
to see the whole diff in the title.

--
Tom.

ignore him, just make it as close to the previous svn mail subjects as
possible.

On Mon, Feb 18, 2013 at 9:21 AM, Tom Hacohen <tom.hacohen@...:

> On 18/02/13 04:02, Daniel Juyung Seo wrote:
> > And it'll be great if the title includes the first line of commit
> message.
> > That should be way more useful.
> > Thanks.
>
> Correct me if I'm wrong, but I'm starting to think you guys would like
> to see the whole diff in the title.
>
> --
> Tom.
>
>
> ------------------------------------------------------------------------------
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
> is your hub for all things parallel software development, from weekly
> thought
> leadership blogs to news, videos, case studies, tutorials, tech docs,
> whitepapers, evaluation guides, and opinion stories. Check out the most
> recent posts - join the conversation now.
> http://goparallel.sourceforge.net/
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>

On 18/02/13 09:26, Michael Blumenkrantz wrote:
> ignore him, just make it as close to the previous svn mail subjects as
> possible.

I never ignore SeoZ, but I'll disregard his suggestion here. I was 
planning on just making it the same as SVN was.

--
Tom.

On 18/02/2013 10:21, Tom Hacohen wrote:
> On 18/02/13 04:02, Daniel Juyung Seo wrote:
>> And it'll be great if the title includes the first line of commit message.
>> That should be way more useful.
>> Thanks.
> Correct me if I'm wrong, but I'm starting to think you guys would like
> to see the whole diff in the title.
>
>
Great idea! please also add my local weather please.

Hello.

On 18/02/13 09:21, Tom Hacohen wrote:
> On 18/02/13 04:02, Daniel Juyung Seo wrote:
>> And it'll be great if the title includes the first line of commit
> message.
>> That should be way more useful.
>> Thanks.
>
> Correct me if I'm wrong, but I'm starting to think you guys would like
> to see the whole diff in the title.

Come on. Take a step back and look at the commit email subject line as 
we have it right now:

[EGIT] [core/efl] branch master updated. 
04e660c5c76fa9168be08de1f979a1684c464154

[EGIT] Might be needed for people that can or want not filter on message 
headers.

[core/efl] Gives the repo. Useful.

branch master updated: I argued before that commit mails should only be 
send for the master branch. Everything else is only interesting for a 
small group of people and they will pull and look at the specific 
branches on their own.

git hash: Not useful in the title I would argue. Gives you zero 
informations about what was changed. Needed in the body for sure, but 
not in the subject.

I would propose:

[EGIT] [core/efl] First line of commit message.

The body does then have the full commit message, the hash as well as a 
shortlog before the complete diff comes in.

And yes that means one commit should result in one mail.

regards
Stefan Schmidt

On 18/02/13 09:36, Stefan Schmidt wrote:
> Hello.
>
> On 18/02/13 09:21, Tom Hacohen wrote:
>> On 18/02/13 04:02, Daniel Juyung Seo wrote:
>>> And it'll be great if the title includes the first line of commit
>> message.
>>> That should be way more useful.
>>> Thanks.
>>
>> Correct me if I'm wrong, but I'm starting to think you guys would like
>> to see the whole diff in the title.
>
> Come on. Take a step back and look at the commit email subject line as
> we have it right now:
>
> [EGIT] [core/efl] branch master updated.
> 04e660c5c76fa9168be08de1f979a1684c464154
>
> [EGIT] Might be needed for people that can or want not filter on message
> headers.
>
> [core/efl] Gives the repo. Useful.
>
> branch master updated: I argued before that commit mails should only be
> send for the master branch. Everything else is only interesting for a
> small group of people and they will pull and look at the specific
> branches on their own.
>
> git hash: Not useful in the title I would argue. Gives you zero
> informations about what was changed. Needed in the body for sure, but
> not in the subject.
>
> I would propose:
>
> [EGIT] [core/efl] First line of commit message.
>
> The body does then have the full commit message, the hash as well as a
> shortlog before the complete diff comes in.
>
> And yes that means one commit should result in one mail.

Yes, most of that will be there anyway, I was just joking... You are 
seating by my side, if it wasn't for the huge noise-cancelling 
headphones you have on your head, you've heard me and Daniel talking 
about it 10 minutes ago.

--
Tom.

maybe he's writing a mail about it so that I can read it from my quarantine

On Mon, Feb 18, 2013 at 9:45 AM, Tom Hacohen <tom.hacohen@...:

> On 18/02/13 09:36, Stefan Schmidt wrote:
> > Hello.
> >
> > On 18/02/13 09:21, Tom Hacohen wrote:
> >> On 18/02/13 04:02, Daniel Juyung Seo wrote:
> >>> And it'll be great if the title includes the first line of commit
> >> message.
> >>> That should be way more useful.
> >>> Thanks.
> >>
> >> Correct me if I'm wrong, but I'm starting to think you guys would like
> >> to see the whole diff in the title.
> >
> > Come on. Take a step back and look at the commit email subject line as
> > we have it right now:
> >
> > [EGIT] [core/efl] branch master updated.
> > 04e660c5c76fa9168be08de1f979a1684c464154
> >
> > [EGIT] Might be needed for people that can or want not filter on message
> > headers.
> >
> > [core/efl] Gives the repo. Useful.
> >
> > branch master updated: I argued before that commit mails should only be
> > send for the master branch. Everything else is only interesting for a
> > small group of people and they will pull and look at the specific
> > branches on their own.
> >
> > git hash: Not useful in the title I would argue. Gives you zero
> > informations about what was changed. Needed in the body for sure, but
> > not in the subject.
> >
> > I would propose:
> >
> > [EGIT] [core/efl] First line of commit message.
> >
> > The body does then have the full commit message, the hash as well as a
> > shortlog before the complete diff comes in.
> >
> > And yes that means one commit should result in one mail.
>
> Yes, most of that will be there anyway, I was just joking... You are
> seating by my side, if it wasn't for the huge noise-cancelling
> headphones you have on your head, you've heard me and Daniel talking
> about it 10 minutes ago.
>
> --
> Tom.
>
>
>
> ------------------------------------------------------------------------------
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
> is your hub for all things parallel software development, from weekly
> thought
> leadership blogs to news, videos, case studies, tutorials, tech docs,
> whitepapers, evaluation guides, and opinion stories. Check out the most
> recent posts - join the conversation now.
> http://goparallel.sourceforge.net/
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>

On Mon, 18 Feb 2013 09:45:54 +0000 Tom Hacohen
<tom.hacohen@...> wrote:

> I was just joking... You are seating by my side, if it wasn't for the
> huge noise-cancelling headphones you have on your head, you've heard
> me and Daniel talking about it 10 minutes ago.

lol

-- 
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.

On 18/02/13 01:14, ChunEon Park wrote:
> Could it possible to make git mail title messages to be more meaningful?
> 
> i.e) [core/efl] xxxmaster updated. f27ff2fbf31a01c2f8d98e773bed6cc4298749bd
>  -> [core/efl/evas] xxxmaster updated. 
> f27ff2fbf31a01c2f8d98e773bed6cc4298749bd

I think after some discussion we all agree that the commit mails and
titles need to change.

I believe we have a sort of consensus now that we need to:
* send one mail per commit
* change the subject of the mail to include author and first line of
  commit message
  so: [EGIT] [core/efl] eina: fix siginfo detection (Cedric BAIL)
* If we send mails for more than just master we should include the
  branch in the commit message

Are we in favour of sending mails for all branches or just for master?
Anything else I missed?

> If the title shows any detailed core lib name that was changed, it would be 
> better to know what is changed in abstractly.

I don't think that we can easily do that. We know the repository, but
figuring out the component that changed is harder. What I am in favour
of is prefixing the first line of the commit message with the part
you're actually working on. (See example above)


Regards,
Daniel

On Mon, Feb 18, 2013 at 6:58 AM, Daniel Willmann <d.willmann@...> wrote:
> On 18/02/13 01:14, ChunEon Park wrote:
>> Could it possible to make git mail title messages to be more meaningful?
>>
>> i.e) [core/efl] xxxmaster updated. f27ff2fbf31a01c2f8d98e773bed6cc4298749bd
>>  -> [core/efl/evas] xxxmaster updated.
>> f27ff2fbf31a01c2f8d98e773bed6cc4298749bd
>
> I think after some discussion we all agree that the commit mails and
> titles need to change.
>
> I believe we have a sort of consensus now that we need to:
> * send one mail per commit
> * change the subject of the mail to include author and first line of
>   commit message
>   so: [EGIT] [core/efl] eina: fix siginfo detection (Cedric BAIL)
> * If we send mails for more than just master we should include the
>   branch in the commit message
>
> Are we in favour of sending mails for all branches or just for master?
> Anything else I missed?
>

Once we have backporting branches in git too it might be useful to have mails
for those, but I'm not sure other cases matter here.

>> If the title shows any detailed core lib name that was changed, it would be
>> better to know what is changed in abstractly.
>
> I don't think that we can easily do that. We know the repository, but
> figuring out the component that changed is harder. What I am in favour
> of is prefixing the first line of the commit message with the part
> you're actually working on. (See example above)
>
>
> Regards,
> Daniel
>
> ------------------------------------------------------------------------------
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
> is your hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials, tech docs,
> whitepapers, evaluation guides, and opinion stories. Check out the most
> recent posts - join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

On 18/02/13 10:07, Ivan Briano wrote:
> On Mon, Feb 18, 2013 at 6:58 AM, Daniel Willmann <d.willmann@...>
> wrote:
>> Are we in favour of sending mails for all branches or just for master?
>> Anything else I missed?

> Once we have backporting branches in git too it might be useful to have
> mails
> for those, but I'm not sure other cases matter here.

True. So send mails for all branches but those under devs/*


Regards,
Daniel

On Mon, 18 Feb 2013 09:58:55 +0000 Daniel Willmann <d.willmann@...>
said:

> On 18/02/13 01:14, ChunEon Park wrote:
> > Could it possible to make git mail title messages to be more meaningful?
> > 
> > i.e) [core/efl] xxxmaster updated. f27ff2fbf31a01c2f8d98e773bed6cc4298749bd
> >  -> [core/efl/evas] xxxmaster updated. 
> > f27ff2fbf31a01c2f8d98e773bed6cc4298749bd
> 
> I think after some discussion we all agree that the commit mails and
> titles need to change.
> 
> I believe we have a sort of consensus now that we need to:
> * send one mail per commit
> * change the subject of the mail to include author and first line of
>   commit message
>   so: [EGIT] [core/efl] eina: fix siginfo detection (Cedric BAIL)
> * If we send mails for more than just master we should include the
>   branch in the commit message

can we have subject have the dirs affected like [src/lib/eina src/lib/eet] etc.
- a list of them? 

> Are we in favour of sending mails for all branches or just for master?
> Anything else I missed?
> 
> > If the title shows any detailed core lib name that was changed, it would be 
> > better to know what is changed in abstractly.
> 
> I don't think that we can easily do that. We know the repository, but
> figuring out the component that changed is harder. What I am in favour
> of is prefixing the first line of the commit message with the part
> you're actually working on. (See example above)
> 
> 
> Regards,
> Daniel
> 
> ------------------------------------------------------------------------------
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
> is your hub for all things parallel software development, from weekly thought 
> leadership blogs to news, videos, case studies, tutorials, tech docs, 
> whitepapers, evaluation guides, and opinion stories. Check out the most 
> recent posts - join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@...

On 18/02/13 10:07, Iván Briano wrote:
> On Mon, Feb 18, 2013 at 6:58 AM, Daniel Willmann <d.willmann@...> wrote:
>> On 18/02/13 01:14, ChunEon Park wrote:
>>> Could it possible to make git mail title messages to be more meaningful?
>>>
>>> i.e) [core/efl] xxxmaster updated. f27ff2fbf31a01c2f8d98e773bed6cc4298749bd
>>>   -> [core/efl/evas] xxxmaster updated.
>>> f27ff2fbf31a01c2f8d98e773bed6cc4298749bd
>>
>> I think after some discussion we all agree that the commit mails and
>> titles need to change.
>>
>> I believe we have a sort of consensus now that we need to:
>> * send one mail per commit
>> * change the subject of the mail to include author and first line of
>>    commit message
>>    so: [EGIT] [core/efl] eina: fix siginfo detection (Cedric BAIL)
>> * If we send mails for more than just master we should include the
>>    branch in the commit message
>>
>> Are we in favour of sending mails for all branches or just for master?
>> Anything else I missed?
>>
>
> Once we have backporting branches in git too it might be useful to have mails
> for those, but I'm not sure other cases matter here.
>

To elaborate more on what Daniel has mentioned:
The plan is actually to send updates on all branches except for dev 
branches, so all branches will get update mails except for devs/*.

--
Tom.

On 16/02/13 06:42, Jérôme Pinot wrote:
>> On Fri, 15 Feb 2013 11:56:06 -0200 Rafael Antognolli
>> <antognolli@...> wrote:
>>> I know that this is not a poll, but I particularly prefer rebased
>>> branches/commits too.
> 
> LWN has a neat article about the git rebase thing:
> http://lwn.net/Articles/328436/
> 
> "Thou Shalt Not Rebase Trees With History Visible To Others"

I agree with this which is why master and other branches are
fast-forward only. Local branches are not "visible to others" in any
case, that's pretty clear.

What's not so clear is the developer branches in devs/user/

The link you mentioned states:
"""
[I]f you're still in the "git rebase" phase, you don't push it out. If
it's not ready, you send patches around, or use private git trees (just
as a "patch series replacement") that you don't tell the public at large
about.
"""

I think we should handle them as private and people should not depend on
them (the alternative is to have developers use private repositories
which is a bit more complicated).


Regards,
Daniel

On Sat, Feb 16, 2013 at 4:42 AM, Jérôme Pinot <ngc891@...> wrote:
> On 02/16/13 15:58, David Seikel wrote:
>> On Fri, 15 Feb 2013 11:56:06 -0200 Rafael Antognolli
>> <antognolli@...> wrote:
>>
>> > Hi David,
>> >
>> > On Thu, Feb 14, 2013 at 9:12 AM, David Seikel <onefang@...>
>> > wrote:
>> > > On Thu, 14 Feb 2013 08:53:22 -0200 Bruno Dilly
>> > > <bdilly@...> wrote:
>> > >
>> > >> On Wed, Feb 13, 2013 at 8:42 AM, Daniel Willmann
>> > >> <d.willmann@...> wrote:
>> > >> > On 13/02/13 00:36, Bruno Dilly wrote:
>> > >> >> On Mon, Feb 11, 2013 at 2:07 PM, Daniel Willmann
>> > >> >> <d.willmann@...> wrote:
>> > >> >>>
>> > >> >>> Topic branches:
>> > >> >>> * In each repository every developer with commit access will be
>> > >> >>> able to push/update branches in their own namespace
>> > >> >>> (devs/<name>/*). These branches will allow non-fastforward
>> > >> >>> updates and no one should expect these to be stable.
>> > >> >>> * This is a testing ground for developers where new features
>> > >> >>> can be developed, debugged and shared with fellow developers.
>> > >> >>> Ideally any new feature would live in its own branch until it
>> > >> >>> matures and is merged into master.
>> > >> >>
>> > >> >> Hey Daniel,
>> > >> >>
>> > >> >> It's a nice proposal, but what about master branch permissions ?
>> > >> >> Every developer would be allowed to push stuff on there (with a
>> > >> >> flow similar to svn) ? Or we'll try to establish some kind of
>> > >> >> policy about it (maintainers, review, etc) ?
>> > >> >
>> > >> > As others have already pointed out there seems to be consensus
>> > >> > that we don't have enough manpower to work with an integrator
>> > >> > workflow (whether or not that's true I don't know).
>> > >>
>> > >> ok, I got it.
>> > >>
>> > >> >
>> > >> > What I want to achieve with the topic branches is that whoever
>> > >> > wants to can maintain an integrator-like workflow. You develop
>> > >> > your feature in a topic branch, then post a request for
>> > >> > review/review and test yourself and if everything looks good you
>> > >> > can merge into master.
>> > >> >
>> > >> > Speaking of merging...is there any preference on merge vs.
>> > >> > rebase?
>> > >> >
>> > >> > Lots of small merges can really pollute your history and I don't
>> > >> > really like them. For larger topic branches I think merging makes
>> > >> > sense.
>> > >>
>> > >> I agree with Tom here.
>> > >> I'm always trying to keep a linear history, focusing on rebases
>> > >> instead of merges.
>> > >> We've used this approach on Profusion projects for years and it
>> > >> worked fine so far.
>> > >>
>> > >> Maybe it will give you a little bit more work, you'll have to fix
>> > >> conflicts in the commits it happens instead of only once in a final
>> > >> merge commit, but it will be nicer to review or look
>> > >> for issues later, imo.
>> > >>
>> > >> Using the merge approach, in a project with so many commiters could
>> > >> lead us to a very confuse history.
>> > >
>> > > If the history is confused, then that's what it should show.  I
>> > > really don't like the idea of rewriting history just to make it
>> > > easier for some people.  Sometimes you just need to track down what
>> > > actually happened, not the convenient lie we tell ourselves is what
>> > > happened.
>> >
>> > I don't think those that a rebased branch history is a lie. Each
>> > commit will still have the original commit date (if the author did not
>> > change it). You can use that to know when the feature started to be
>> > developed.
>>
>> It is a lie, it's changing the history to say it was all done one after
>> the other, when in fact a major feature of distributed development was
>> used to branch then merge.  It was not done in a linear fashion, thus
>> making it be linear after the fact is not representing the truth.  Sure
>> SOME parts of the commit history are still the truth, but not all.
>>
>> > OK, you lose a way to track the parent commit for that feature branch,
>> > but on the other hand you earn something important here: the knowledge
>> > that the commits from that feature branch will apply correctly on top
>> > of the current state of the tree, without a magic merge commit fixing
>> > stuff later since some things on the tree are not exactly as they seem
>> > to be in the diff from this commit. The changes that appear in the
>> > diff from a given commit are exactly what that commit is doing.
>>
>> That's what I'm saying, loosing information to make things more
>> convenient.  I'd prefer to err on the side of not loosing information.
>> But then again, I'm a hoarder.  B-)
>>
>> > I know that this is not a poll, but I particularly prefer rebased
>> > branches/commits too.
>
> LWN has a neat article about the git rebase thing:
> http://lwn.net/Articles/328436/
>
> "Thou Shalt Not Rebase Trees With History Visible To Others"

Hey Jérôme,

Just to make things clear, nobody is suggesting to rebase master
branch (or any public branch).
Only devs/* will accept non-fastforward updates. But nobody else
should be based on these.

>
> --
> Jérôme Pinot
> http://ngc891.blogdns.net/
>
> ------------------------------------------------------------------------------
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet,
> is your hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials, tech docs,
> whitepapers, evaluation guides, and opinion stories. Check out the most
> recent posts - join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
>



-- 
Bruno Dilly
Lead Developer
ProFUSION embedded systems
http://profusion.mobi

On Mon, Feb 18, 2013 at 09:36:50AM +0000, Stefan Schmidt wrote:
> Hello.
> 
> On 18/02/13 09:21, Tom Hacohen wrote:
> > On 18/02/13 04:02, Daniel Juyung Seo wrote:
> >> And it'll be great if the title includes the first line of commit
> > message.
> >> That should be way more useful.
> >> Thanks.
> >
> > Correct me if I'm wrong, but I'm starting to think you guys would like
> > to see the whole diff in the title.
> 
> Come on. Take a step back and look at the commit email subject line as 
> we have it right now:
> 
> [EGIT] [core/efl] branch master updated. 
> 04e660c5c76fa9168be08de1f979a1684c464154
> 
> [EGIT] Might be needed for people that can or want not filter on message 
> headers.
> 
> [core/efl] Gives the repo. Useful.
> 
> branch master updated: I argued before that commit mails should only be 
> send for the master branch. Everything else is only interesting for a 
> small group of people and they will pull and look at the specific 
> branches on their own.
> 
> git hash: Not useful in the title I would argue. Gives you zero 
> informations about what was changed. Needed in the body for sure, but 
> not in the subject.

OE has IMHO good setup for git commits, and it should be easy to get
their git hook. Messages look like this:

From: git@...                                                                                                                                                    
Subject: [oe-commits] Martin Jansa : ca-certificates: upgrade to 20130119                                                                                                         
                                                                                                                                                                                  
Module: meta-openembedded.git                                                                                                                                                     
Branch: master                                                                                                                                                                    
Commit: af0a0dde191acb5725073e30a8a0b42d819233c6                                                                                                                                  
URL:    http://git.openembedded.org/?p=meta-openembedded.git&a=commit;h=af0a0dde191acb5725073e30a8a0b42d819233c6                                                                  
                                                                                                                                                                                  
Author: Martin Jansa <martin.jansa@...>                                                                                                                                     
Date:   Mon Feb 11 20:23:51 2013 +0000                                                                                                                                            
                                                                                                                                                                                  
ca-certificates: upgrade to 20130119                                                                                                                                              
                                                                                                                                                                                  
* old archive is no longer on upstream URL                                                                                                                                        
                                                                                                                                                                                  
Signed-off-by: Martin Jansa <Martin.Jansa@...>                                                                                                                              

---

whole patch here

---

With this format it's easy to filter emails to different mail foder for different
branches or modules.

Cheers,

> 
> I would propose:
> 
> [EGIT] [core/efl] First line of commit message.
> 
> The body does then have the full commit message, the hash as well as a 
> shortlog before the complete diff comes in.
> 
> And yes that means one commit should result in one mail.
> 
> regards
> Stefan Schmidt
> 
> ------------------------------------------------------------------------------
> The Go Parallel Website, sponsored by Intel - in partnership with Geeknet, 
> is your hub for all things parallel software development, from weekly thought 
> leadership blogs to news, videos, case studies, tutorials, tech docs, 
> whitepapers, evaluation guides, and opinion stories. Check out the most 
> recent posts - join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@...
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@...

On 18/02/13 18:41, Martin Jansa wrote:
> On Mon, Feb 18, 2013 at 09:36:50AM +0000, Stefan Schmidt wrote:
>> Hello.
>>
>> On 18/02/13 09:21, Tom Hacohen wrote:
>>> On 18/02/13 04:02, Daniel Juyung Seo wrote:
>>>> And it'll be great if the title includes the first line of commit
>>> message.
>>>> That should be way more useful.
>>>> Thanks.
>>>
>>> Correct me if I'm wrong, but I'm starting to think you guys would like
>>> to see the whole diff in the title.
>>
>> Come on. Take a step back and look at the commit email subject line as
>> we have it right now:
>>
>> [EGIT] [core/efl] branch master updated.
>> 04e660c5c76fa9168be08de1f979a1684c464154
>>
>> [EGIT] Might be needed for people that can or want not filter on message
>> headers.
>>
>> [core/efl] Gives the repo. Useful.
>>
>> branch master updated: I argued before that commit mails should only be
>> send for the master branch. Everything else is only interesting for a
>> small group of people and they will pull and look at the specific
>> branches on their own.
>>
>> git hash: Not useful in the title I would argue. Gives you zero
>> informations about what was changed. Needed in the body for sure, but
>> not in the subject.
>
> OE has IMHO good setup for git commits, and it should be easy to get
> their git hook. Messages look like this:
>
> From: git@...
> Subject: [oe-commits] Martin Jansa : ca-certificates: upgrade to 20130119
>
> Module: meta-openembedded.git
> Branch: master
> Commit: af0a0dde191acb5725073e30a8a0b42d819233c6
> URL:    http://git.openembedded.org/?p=meta-openembedded.git&a=commit;h=af0a0dde191acb5725073e30a8a0b42d819233c6
>
> Author: Martin Jansa <martin.jansa@...>
> Date:   Mon Feb 11 20:23:51 2013 +0000
>
> ca-certificates: upgrade to 20130119
>
> * old archive is no longer on upstream URL
>
> Signed-off-by: Martin Jansa <Martin.Jansa@...>
>
> ---
>
> whole patch here
>
> ---
>
> With this format it's easy to filter emails to different mail foder for different
> branches or modules.
>
> Cheers,
>

We've improved it now, I think it's better. Anyhow could we have their hook?

One additional note: our mails (and I bet their as well) have a lot of 
extra header fields to help users filter the mails. You guys might want 
to take a look.

Cheers,
Tom.