Re: [gentoo-dev] SHA256 and indention in metadata.xml

2011-06-28 Thread Peter Volkov
В Вск, 26/06/2011 в 17:20 +0200, Maciej Mrozowski пишет:
 I never understood the reason after keeping deps not sorted alphabetically 
 where order doesn't matter - it's like someone purposely made ebuild harder 
 to 
 read - it's counter productive.

Like with perl modules with well written configure.ac I like them to be
sorted in the order there. This way makes easier for me to see if there
is anything redundant in deps or not.

--
Peter.




Re: [gentoo-dev] SHA256 and indention in metadata.xml

2011-06-28 Thread Peter Volkov
В Сбт, 25/06/2011 в 13:24 -0400, Mike Frysinger пишет:
 On Sat, Jun 25, 2011 at 10:23, Nirbheek Chauhan wrote:
  On Sat, Jun 25, 2011 at 6:16 PM, justin wrote:
  Another question, do we have a rule, how the metadata.xml has to be
  indented? Tabs or n spaces?
 
  There's no rule, but we should follow the same rule as ebuilds —
  indentation should be with a tab that's displayed as 4 spaces in
  editors (no expansion of tabs to spaces).
 
 meh ... let devs do whatever they want

Why? This looks like perfect case to use standard indentation.
Personally I'd like indentation to be fixed (and I don't really care
how).

--
Peter.





Re: [gentoo-dev] SHA256 and indention in metadata.xml

2011-06-28 Thread Mike Frysinger
On Tuesday, June 28, 2011 08:02:03 Peter Volkov wrote:
 В Сбт, 25/06/2011 в 13:24 -0400, Mike Frysinger пишет:
  On Sat, Jun 25, 2011 at 10:23, Nirbheek Chauhan wrote:
   On Sat, Jun 25, 2011 at 6:16 PM, justin wrote:
   Another question, do we have a rule, how the metadata.xml has to be
   indented? Tabs or n spaces?
   
   There's no rule, but we should follow the same rule as ebuilds —
   indentation should be with a tab that's displayed as 4 spaces in
   editors (no expansion of tabs to spaces).
  
  meh ... let devs do whatever they want
 
 Why? This looks like perfect case to use standard indentation.
 Personally I'd like indentation to be fixed (and I don't really care
 how).

these files are so small/minor, and now we tread into xml territory which has 
much less standardized indenting and line wrapping rules.  it isnt simply a 
matter of how much space do i put before an open tag.  i really dont see it 
being a problem that needs solving.
-mike


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] SHA256 and indention in metadata.xml

2011-06-27 Thread Mike Frysinger
On Sunday, June 26, 2011 12:51:53 Nirbheek Chauhan wrote:
 On Sun, Jun 26, 2011 at 9:45 PM, Mike Frysinger wrote:
  On Sat, Jun 25, 2011 at 13:51, Nirbheek Chauhan wrote:
  On Sat, Jun 25, 2011 at 10:54 PM, Mike Frysinger wrote:
  On Sat, Jun 25, 2011 at 10:23, Nirbheek Chauhan wrote:
  On Sat, Jun 25, 2011 at 6:16 PM, justin wrote:
  Another question, do we have a rule, how the metadata.xml has to be
  indented? Tabs or n spaces?
  
  There's no rule, but we should follow the same rule as ebuilds —
  indentation should be with a tab that's displayed as 4 spaces in
  editors (no expansion of tabs to spaces).
  
  meh ... let devs do whatever they want
  
  Didn't I just say there's no rule?
  
  and if you keep reading, you'll see that you also said devs should XXX
 
 should != must.

and all i said was devs should do whatever they want

 I understand that you're touchy about rules after the whole ChangeLog
 mess, but must we debate the nuances of the English language and
 contribute to the massive amount of pre-existing bikeshed noise on
 this mailing list?

i'm really not.  i dont why you read more into it than is actually there.  if 
anything, your responses seem a bit more touchy.
-mike


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] SHA256 and indention in metadata.xml

2011-06-26 Thread Maciej Mrozowski
On Saturday 25 of June 2011 22:32:43 Jorge Manuel B. S. Vicetto wrote:
 On 25-06-2011 14:23, Nirbheek Chauhan wrote:
  On Sat, Jun 25, 2011 at 6:16 PM, justin j...@gentoo.org wrote:
  Another question, do we have a rule, how the metadata.xml has to be
  indented? Tabs or n spaces?
  
  There's no rule, but we should follow the same rule as ebuilds —
  indentation should be with a tab that's displayed as 4 spaces in
  editors (no expansion of tabs to spaces).
 
 Talking from my own experience when doing retirement stuff, there seems
 to be two large currents on metadata.xml in the tree, using tabs and 2
 spaces for indentation.




 I personally prefer tabs, but I also like using EAPI=version,
 sorting everything alphabetically and even use the following depend blocks:

 *DEPEND=
   !X-2.0
   !Y
   A
   B
   ...
   Z
   a? ( X )
   b? ( Y )
   c? (
   J
   K
   )
 

^^ is actually the main point of my ebuild formatting nazi agenda (usually 
followed by oh why did you break formatting in my shiny ebuild!11, revert! 
chants by various developers in case I happened to touch packages of theirs).

I never understood the reason after keeping deps not sorted alphabetically 
where order doesn't matter - it's like someone purposely made ebuild harder to 
read - it's counter productive.

-- 
regards
MM


signature.asc
Description: This is a digitally signed message part.


Re: [gentoo-dev] SHA256 and indention in metadata.xml

2011-06-26 Thread Nirbheek Chauhan
On Sun, Jun 26, 2011 at 8:50 PM, Maciej Mrozowski reave...@gmail.com wrote:
 On Saturday 25 of June 2011 22:32:43 Jorge Manuel B. S. Vicetto wrote:
 *DEPEND=
       !X-2.0
       !Y
       A
       B
       ...
       Z
       a? ( X )
       b? ( Y )
       c? (
               J
               K
       )
 

 ^^ is actually the main point of my ebuild formatting nazi agenda (usually
 followed by oh why did you break formatting in my shiny ebuild!11, revert!
 chants by various developers in case I happened to touch packages of theirs).

 I never understood the reason after keeping deps not sorted alphabetically
 where order doesn't matter - it's like someone purposely made ebuild harder to
 read - it's counter productive.


Well, the GNOME team likes to order it by type and library
heirarchy. So, libraries in one paragraph, then applications. Plain-C
libraries first, followed by glib, and then glib-using libraries, and
then gtk+, and gtk+-using libraries, then Python modules, etc. We also
separate out lines with and without versions/blocks/use-conditionals
in them to make them easier to read.


-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team



Re: [gentoo-dev] SHA256 and indention in metadata.xml

2011-06-26 Thread Mike Frysinger
On Sat, Jun 25, 2011 at 13:51, Nirbheek Chauhan wrote:
 On Sat, Jun 25, 2011 at 10:54 PM, Mike Frysinger wrote:
 On Sat, Jun 25, 2011 at 10:23, Nirbheek Chauhan wrote:
 On Sat, Jun 25, 2011 at 6:16 PM, justin wrote:
 Another question, do we have a rule, how the metadata.xml has to be
 indented? Tabs or n spaces?

 There's no rule, but we should follow the same rule as ebuilds —
 indentation should be with a tab that's displayed as 4 spaces in
 editors (no expansion of tabs to spaces).

 meh ... let devs do whatever they want

 Didn't I just say there's no rule?

and if you keep reading, you'll see that you also said devs should XXX
-mike



Re: [gentoo-dev] SHA256 and indention in metadata.xml

2011-06-26 Thread Nirbheek Chauhan
On Sun, Jun 26, 2011 at 9:45 PM, Mike Frysinger vap...@gentoo.org wrote:
 On Sat, Jun 25, 2011 at 13:51, Nirbheek Chauhan wrote:
 On Sat, Jun 25, 2011 at 10:54 PM, Mike Frysinger wrote:
 On Sat, Jun 25, 2011 at 10:23, Nirbheek Chauhan wrote:
 On Sat, Jun 25, 2011 at 6:16 PM, justin wrote:
 Another question, do we have a rule, how the metadata.xml has to be
 indented? Tabs or n spaces?

 There's no rule, but we should follow the same rule as ebuilds —
 indentation should be with a tab that's displayed as 4 spaces in
 editors (no expansion of tabs to spaces).

 meh ... let devs do whatever they want

 Didn't I just say there's no rule?

 and if you keep reading, you'll see that you also said devs should XXX


should != must.

I understand that you're touchy about rules after the whole ChangeLog
mess, but must we debate the nuances of the English language and
contribute to the massive amount of pre-existing bikeshed noise on
this mailing list?

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team



Re: [gentoo-dev] SHA256 and indention in metadata.xml

2011-06-26 Thread Dale

Nirbheek Chauhan wrote:

On Sun, Jun 26, 2011 at 9:45 PM, Mike Frysingervap...@gentoo.org  wrote:
   

On Sat, Jun 25, 2011 at 13:51, Nirbheek Chauhan wrote:
 

On Sat, Jun 25, 2011 at 10:54 PM, Mike Frysinger wrote:
   

On Sat, Jun 25, 2011 at 10:23, Nirbheek Chauhan wrote:
 

On Sat, Jun 25, 2011 at 6:16 PM, justin wrote:
   

Another question, do we have a rule, how the metadata.xml has to be
indented? Tabs or n spaces?
 

There's no rule, but we should follow the same rule as ebuilds —
indentation should be with a tab that's displayed as 4 spaces in
editors (no expansion of tabs to spaces).
   

meh ... let devs do whatever they want
 

Didn't I just say there's no rule?
   

and if you keep reading, you'll see that you also said devs should XXX

 

should != must.

I understand that you're touchy about rules after the whole ChangeLog
mess, but must we debate the nuances of the English language and
contribute to the massive amount of pre-existing bikeshed noise on
this mailing list?

   


I always understood shall means must.  Should means on most occasions.

Dale

:-)  :-)



Re: [gentoo-dev] SHA256 and indention in metadata.xml

2011-06-26 Thread Kent Fredric
On 27 June 2011 03:20, Maciej Mrozowski reave...@gmail.com wrote:
 I personally prefer tabs, but I also like using EAPI=version,
 sorting everything alphabetically and even use the following depend blocks:

 *DEPEND=
       !X-2.0
       !Y
       A
       B
       ...
       Z
       a? ( X )
       b? ( Y )
       c? (
               J
               K
       )
 

 ^^ is actually the main point of my ebuild formatting nazi agenda (usually
 followed by oh why did you break formatting in my shiny ebuild!11, revert!
 chants by various developers in case I happened to touch packages of theirs).

 I never understood the reason after keeping deps not sorted alphabetically
 where order doesn't matter - it's like someone purposely made ebuild harder to
 read - it's counter productive.


In the case where upstream also have a rather well structured
dependency list that is prone to change ( ie: perl modules ) I've
found it beneficial to keep the dependencies in the same order as they
use upstream.

Makes it much easier to check later and makes it much easier to notice
when they add a dependency

-- 
Kent

perl -e  print substr( \edrgmaM  SPA NOcomil.ic\\@tfrken\, \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );

http://kent-fredric.fox.geek.nz



Re: [gentoo-dev] SHA256 and indention in metadata.xml

2011-06-25 Thread Nirbheek Chauhan
On Sat, Jun 25, 2011 at 6:16 PM, justin j...@gentoo.org wrote:
 Another question, do we have a rule, how the metadata.xml has to be
 indented? Tabs or n spaces?


There's no rule, but we should follow the same rule as ebuilds —
indentation should be with a tab that's displayed as 4 spaces in
editors (no expansion of tabs to spaces).

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team



Re: [gentoo-dev] SHA256 and indention in metadata.xml

2011-06-25 Thread Mike Frysinger
On Sat, Jun 25, 2011 at 10:23, Nirbheek Chauhan wrote:
 On Sat, Jun 25, 2011 at 6:16 PM, justin wrote:
 Another question, do we have a rule, how the metadata.xml has to be
 indented? Tabs or n spaces?

 There's no rule, but we should follow the same rule as ebuilds —
 indentation should be with a tab that's displayed as 4 spaces in
 editors (no expansion of tabs to spaces).

meh ... let devs do whatever they want
-mike



Re: [gentoo-dev] SHA256 and indention in metadata.xml

2011-06-25 Thread Nirbheek Chauhan
On Sat, Jun 25, 2011 at 10:54 PM, Mike Frysinger vap...@gentoo.org wrote:
 On Sat, Jun 25, 2011 at 10:23, Nirbheek Chauhan wrote:
 On Sat, Jun 25, 2011 at 6:16 PM, justin wrote:
 Another question, do we have a rule, how the metadata.xml has to be
 indented? Tabs or n spaces?

 There's no rule, but we should follow the same rule as ebuilds —
 indentation should be with a tab that's displayed as 4 spaces in
 editors (no expansion of tabs to spaces).

 meh ... let devs do whatever they want


Didn't I just say there's no rule?

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team



Re: [gentoo-dev] SHA256 and indention in metadata.xml

2011-06-25 Thread Jorge Manuel B. S. Vicetto
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 25-06-2011 14:23, Nirbheek Chauhan wrote:
 On Sat, Jun 25, 2011 at 6:16 PM, justin j...@gentoo.org wrote:
 Another question, do we have a rule, how the metadata.xml has to be
 indented? Tabs or n spaces?

 
 There's no rule, but we should follow the same rule as ebuilds —
 indentation should be with a tab that's displayed as 4 spaces in
 editors (no expansion of tabs to spaces).

Talking from my own experience when doing retirement stuff, there seems
to be two large currents on metadata.xml in the tree, using tabs and 2
spaces for indentation.
I personally prefer tabs, but I also like using EAPI=version,
sorting everything alphabetically and even use the following depend blocks:

*DEPEND=
!X-2.0
!Y
A
B
...
Z
a? ( X )
b? ( Y )
c? (
J
K
)


As expected, I'm sure many of the others disagree / dislike at least
part of my preferences.

- -- 
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJOBkXrAAoJEC8ZTXQF1qEPjUgQANBsE0uhZPR0Yqlmh6G4bCpo
F+IvN0PbMcU35tjy87jQ47Y4dCg9mCQftPe1uPt4rtmc1Sww/ztqPdlsXJdi4nRQ
pnVPnJdds39hYzmc5rOjVtsyZOKLH92J7ytVom9AiuO7DqxJvs/A6q/sj46E0KBI
MSUHvSNMH+aq6xGVyQ2lTRAUXUT83bkl3BOrxdPLApgZvteF+fDKHUIviLoQA+wO
VV31Jsav+IIa3KNmxmiF6IoWZFeCLyVlwMJDHp0r23Q28n6qDOoKbWjpwQBwGPXQ
5a/nLKHRTVStzy94gqqCSlNyZso4KjrC5JAeadHiAPisRGloJUWB12UYN/Tm/4CA
KfA4Myvk3Aclr6BGnUQ+DeX+r0hKElHwR60XqkebTt04dcDS1GylV1IpJjpHt8dZ
j2Btz6HdZKzDTRabCyaaOk2UaXAYtN4KjkaWepKHauR73XEtLxs8YY1gc+0T3i4Q
pbjQJfGCP166b/1hS9Evr5/oAcxlDlSRHL0773BowrX/CGpKTDv5bv+9Gm3skiOV
Zd89MomsoV++QUTcXe1i7m6XAYyHkhf9doJl62t5LlflQYE+UIb69HnhdpdHQdfw
km55lo24X4lvxV+nDz26v+fi9mHqlJ4TNxZaQ+6PnvrI4K862biRz+VlsSWcE5ay
1nb/tuwZ0VlfQvUh5TES
=wuC1
-END PGP SIGNATURE-