[Buildroot] svn commit: trunk/buildroot/package: editors editors/vi

[Buildroot] svn commit: trunk/buildroot/package: editors editors/vi

[Arnar Mar Sig]

> From: Hamish Moffatt <hamish@cloud.net.au>
> Date: March 6, 2008 11:54:55 PM GMT+00:00
> To: buildroot at uclibc.org
> Subject: Re: [Buildroot] svn commit: trunk/buildroot/package:  
> editors	editors/vim
>>
>> Added:
>>  trunk/buildroot/package/editors/
>
> Why add hierarchy into the package directory?
>
It's getting a little crowded in the package/ directory so i added  
this subdirectory

> From: Peter Korsgaard <jacmet@uclibc.org>
> Date: March 6, 2008 9:33:26 PM GMT+00:00
> To: buildroot at uclibc.org
> Subject: Re: [Buildroot] svn commit: trunk/buildroot/package:  
> editors editors/vim
>
> There's already a texteditors submenu under packages. Please merge vim
> with that (and probably move nano+uemacs under editors/).

Didin't see any editors submenu when i added the package, i was going  
to move the other editor packages under editors/ and move the  
Config.in includes from packages/Config.in, or are you people against  
this move?


Arnar Mar Sig

[Buildroot] svn commit: trunk/buildroot/package:editors editors/vi

[Ulf Samuelsson]

>>> Added:
>>>  trunk/buildroot/package/editors/
>>
>> Why add hierarchy into the package directory?
>>
> It's getting a little crowded in the package/ directory so i added  
> this subdirectory
> 

Guess what, searching "package/*/*.mk" will not find anything related to editors.


Best Regards
Ulf Samuelsson

[Buildroot] svn commit: trunk/buildroot/package:editors editors/vi

[Arnar Mar Sig]

On Mar 7, 2008, at 7:47 AM, Ulf Samuelsson wrote:

>>>> Added:
>>>> trunk/buildroot/package/editors/
>>>
>>> Why add hierarchy into the package directory?
>>>
>> It's getting a little crowded in the package/ directory so i added
>> this subdirectory
>>
>
> Guess what, searching "package/*/*.mk" will not find anything  
> related to editors.
>
This patch moves the other editors nano, uemacs and ed into packages/ 
editors and also moves the includes from package/Config.in into  
package/editors/Config.in. Makes the package/ dir a bit more organized.

http://mx1.opex.is/move-editor-patch.txt

Arnar Mar Sig

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: move-editor-patch.txt
Url: http://busybox.net/lists/buildroot/attachments/20080307/c0cee3bc/attachment-0001.txt 
-------------- next part --------------

[Buildroot] svn commit: trunk/buildroot/package:editors editors/vi

[Peter Korsgaard]

>>>>> "Arnar" == Arnar Mar Sig <antab@valka.is> writes:

Hi,

 Arnar> This patch moves the other editors nano, uemacs and ed into packages/
 Arnar> editors and also moves the includes from package/Config.in into
 Arnar> package/editors/Config.in. Makes the package/ dir a bit more
 Arnar> organized.

Committed, thanks.

-- 
Bye, Peter Korsgaard

[Buildroot] svn commit: trunk/buildroot/package:editors editors/vi

[Hamish Moffatt]

On Fri, Mar 07, 2008 at 08:57:08AM +0000, Arnar Mar Sig wrote:
> On Mar 7, 2008, at 7:47 AM, Ulf Samuelsson wrote:
>> Guess what, searching "package/*/*.mk" will not find anything related 
>> to editors.
>>
> This patch moves the other editors nano, uemacs and ed into packages/ 
> editors and also moves the includes from package/Config.in into  
> package/editors/Config.in. Makes the package/ dir a bit more organized.
>
> http://mx1.opex.is/move-editor-patch.txt

Like Ulf says, it's convenient to be able to grep package/*/*.mk and now
that's broken. I think dividing of the package/ directory needs discussion 
first.

It's not really a crowded directory by modern standards. Our file
systems can cope with much larger directories than that.

Hamish
-- 
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

[Buildroot] svn commit: trunk/buildroot/package:editors editors/vi

[Arnar Mar Sig]

On Mar 7, 2008, at 11:53 PM, Hamish Moffatt wrote:
> On Fri, Mar 07, 2008 at 08:57:08AM +0000, Arnar Mar Sig wrote:
>> On Mar 7, 2008, at 7:47 AM, Ulf Samuelsson wrote:
>>> Guess what, searching "package/*/*.mk" will not find anything  
>>> related
>>> to editors.
>>>
>> This patch moves the other editors nano, uemacs and ed into packages/
>> editors and also moves the includes from package/Config.in into
>> package/editors/Config.in. Makes the package/ dir a bit more  
>> organized.
>>
>> http://mx1.opex.is/move-editor-patch.txt
>
> Like Ulf says, it's convenient to be able to grep package/*/*.mk and  
> now
> that's broken.
grep -r --include=*.mk "editors" package/*

> I think dividing of the package/ directory needs discussion
> first.
>
> It's not really a crowded directory by modern standards. Our file
> systems can cope with much larger directories than that.
Most filesystems can cope with it. But thats not the reason for the  
move.

IMO the config menu and dir structure should try to match. Its a lot  
faster to type: "ls package/editors" then running "make menuconfig"  
and going thru the menus to see if a editor package exists, or you see  
a package in package/ but when you try look for it you cant find it  
because its hidden in some submenu or worse, hidden because some of  
its 'depends' are not selected.

Arnar Mar Sig

[Buildroot] svn commit: trunk/buildroot/package:editors editors/vi

[Peter Korsgaard]

>>>>> "Hamish" == Hamish Moffatt <hamish@cloud.net.au> writes:

Hi,

 Hamish> Like Ulf says, it's convenient to be able to grep
 Hamish> package/*/*.mk and now that's broken. I think dividing of the
 Hamish> package/ directory needs discussion first.

grep -r is your friend.

I must say I kinda like the splitup of the package dir. The flat tree
goes back to when we didn't have many packages and no submenus under
packages. More consistency between menuconfig and the directory
structure is good thing.

 Hamish> It's not really a crowded directory by modern standards. Our file
 Hamish> systems can cope with much larger directories than that.

The limiting factor is us humans, not the file systems.

-- 
Bye, Peter Korsgaard

[Buildroot] svn commit: trunk/buildroot/package:editors editors/vi

[Ulf Samuelsson]

----- Original Message ----- 
From: "Peter Korsgaard" <jacmet@uclibc.org>
To: <buildroot@uclibc.org>
Cc: "Ulf Samuelsson" <ulf.samuelsson@atmel.com>
Sent: Sunday, March 09, 2008 10:47 PM
Subject: Re: [Buildroot] svn commit: trunk/buildroot/package:editors editors/vi


>>>>>> "Hamish" == Hamish Moffatt <hamish@cloud.net.au> writes:
> 
> Hi,
> 
> Hamish> Like Ulf says, it's convenient to be able to grep
> Hamish> package/*/*.mk and now that's broken. I think dividing of the
> Hamish> package/ directory needs discussion first.
> 
> grep -r is your friend.
> 
> I must say I kinda like the splitup of the package dir. The flat tree
> goes back to when we didn't have many packages and no submenus under
> packages. More consistency between menuconfig and the directory
> structure is good thing.
> 
> Hamish> It's not really a crowded directory by modern standards. Our file
> Hamish> systems can cope with much larger directories than that.
> 
> The limiting factor is us humans, not the file systems.
> 

It is not OK, to introduce this without discussing it on the list though.
Luckily, we have a method to resolve a controversy and that is to let Eric decide.
I think we should give him maybe a week, and only if no reply the patches should be reverted.
(With possible resubmit, if Eric comes back later with ACK)

An alternative way of handling the problem is to have TWO trees.

The package tree remains as it is, and then we have a second tree
which contains the configuration files (make & config files) 
and and subdirectories showing the structure of the configuration.
This tree could also contain html documentation of each link.
The second tree would not contain any 




> -- 
> Bye, Peter Korsgaard
>



Best Regards
Ulf Samuelsson

[Buildroot] svn commit: trunk/buildroot/package:editors editors/vi

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
 
 Ulf> It is not OK, to introduce this without discussing it on the
 Ulf> list though.  Luckily, we have a method to resolve a controversy
 Ulf> and that is to let Eric decide.  I think we should give him
 Ulf> maybe a week, and only if no reply the patches should be
 Ulf> reverted.  (With possible resubmit, if Eric comes back later
 Ulf> with ACK)

Ulf, you have added plenty of controversal stuff without discussing
it on the list. I really don't see a simple cleanup like this being a
big issue.

And no - with all respect, considering Eric's lack of involvement the
last few years - I don't see that as being a solution. Most likely he
isn't reading this thread at all.

Do you have any TECHNICAL objections to the patch? If not, I would
suggest we keep it.

 Ulf> An alternative way of handling the problem is to have TWO trees.

That seems to me to complicate matters rather than solving any
problems.

-- 
Bye, Peter Korsgaard

[Buildroot] svn commit: trunk/buildroot/package:editors editors/vi

[sjhill at realitydiluted.com]

I'll review the patch when I return home this evening and try and help
out with resolving this.

-Steve

[Buildroot] svn commit: trunk/buildroot/package:editors editors/vi

[Ulf Samuelsson]

>>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
> 
> Ulf> It is not OK, to introduce this without discussing it on the
> Ulf> list though.  Luckily, we have a method to resolve a controversy
> Ulf> and that is to let Eric decide.  I think we should give him
> Ulf> maybe a week, and only if no reply the patches should be
> Ulf> reverted.  (With possible resubmit, if Eric comes back later
> Ulf> with ACK)
> 
> Ulf, you have added plenty of controversal stuff without discussing
> it on the list. 

I started off by giving a description to Eric what I wanted to do in the beginning
and this was acked by him. There has been protest against several things
which he acked.


> I really don't see a simple cleanup like this being a big issue.
> 

> And no - with all respect, considering Eric's lack of involvement the
> last few years - I don't see that as being a solution. Most likely he
> isn't reading this thread at all.
> 

Then we do not have any way to resolve differences.
How do you plan to resolve this - by suggesting your way is the only way?

> Do you have any TECHNICAL objections to the patch? If not, I would
> suggest we keep it.
> 

Yes, it is harder to process the information in each directory using scripts.
That is enough for me.

> Ulf> An alternative way of handling the problem is to have TWO trees.
> 
> That seems to me to complicate matters rather than solving any
> problems.

This will provide both the current structure and the structure people want to move to.
If you think it is over complex, I am happy if the current patches are reverted.

> 
> -- 
> Bye, Peter Korsgaard
>

Best Regards
Ulf Samuelsson 

[Buildroot] svn commit: trunk/buildroot/package:editors editors/vi

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

Hi,

 >> Ulf, you have added plenty of controversal stuff without discussing
 >> it on the list. 

 Ulf> I started off by giving a description to Eric what I wanted to
 Ulf> do in the beginning and this was acked by him. There has been
 Ulf> protest against several things which he acked.

And that's basically why we lost Bernard.

 >> I really don't see a simple cleanup like this being a big issue.
 >> 

 >> And no - with all respect, considering Eric's lack of involvement the
 >> last few years - I don't see that as being a solution. Most likely he
 >> isn't reading this thread at all.
 >> 

 Ulf> Then we do not have any way to resolve differences.
 Ulf> How do you plan to resolve this - by suggesting your way is the only way?

Simply by looking at the technical pro/cons. If the patch doesn't
cause any regressions, someone is ready to support it and it helps
cleaning stuff up it can go in for me. You have certainly added stuff
I don't need / use, but so what - As long as it doesn't interfere too
much with how I'm using BR it's fine by me.

John certainly seems to be serious about his work.

I think that's basically the only way to do it with a project without
a benevolent dictator.

 >> Do you have any TECHNICAL objections to the patch? If not, I would
 >> suggest we keep it.
 >> 

 Ulf> Yes, it is harder to process the information in each directory
 Ulf> using scripts.  That is enough for me.

Come on, just add -r to your grep. You already need to search
package/, toolchain/ and target/ anyway. That doesn't sound like a
real issue.

 Ulf> An alternative way of handling the problem is to have TWO trees.
 >> 
 >> That seems to me to complicate matters rather than solving any
 >> problems.

 Ulf> This will provide both the current structure and the structure
 Ulf> people want to move to.  If you think it is over complex, I am
 Ulf> happy if the current patches are reverted.

Bernard several times asked you to fork and do the atmel stuff in a
seperate branch. I still don't think that's a good idea considering
the limited amount of BR development ressources we have.

Let's stop coloring the bike shed and move on to bigger stuff.

-- 
Bye, Peter Korsgaard

[Buildroot] svn commit: trunk/buildroot/package:editors editors/vi

[Peter Korsgaard]

>>>>> "Peter" == Peter Korsgaard <jacmet@uclibc.org> writes:

Huh, where did that buildroot at atmel.com come from?
>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
 Peter> Hi,

 >>> John certainly seems to be serious about his work.

 Ulf> Yes, I agree with this, which is why I recommended he should
 Ulf> have write access.

 Peter> Ok.

 >>> Come on, just add -r to your grep. You already need to search
 >>> package/, toolchain/ and target/ anyway. That doesn't sound like a
 >>> real issue.

 Ulf> I am talking about sed and awk which will be more difficult.

 Peter> Then just do a find ..|xargs on those or use **/*.mk (if you use a
 Peter> proper shell).

 >>> Bernard several times asked you to fork and do the atmel stuff in a
 >>> seperate branch. I still don't think that's a good idea considering
 >>> the limited amount of BR development ressources we have.

 Ulf> He complained about things breaking, but this is bound to
 Ulf> happen.  He seemed to complain a lot on me, when patches in
 Ulf> reality came from others.  I know *his* patches caused me about
 Ulf> 3-4 weeks of extra work.

 Peter> Well, it's very hard to be absolutely sure you don't break anything
 Peter> when you change something in a system like BR simply because of the
 Peter> number of config combinations you would need to test.

 Peter> That ofcause doesn't mean we shouldn't be careful, just that random
 Peter> breakage is to be expected.

 Peter> I've been playing a bit around with buildbot (http://buildbot.net) -
 Peter> And that looks quite nice.

 Peter> -- 
 Peter> Bye, Peter Korsgaard

-- 
Bye, Peter Korsgaard

[Buildroot] svn commit: trunk/buildroot/package:editors editors/vi

[Ulf Samuelsson]

> >>> Come on, just add -r to your grep. You already need to search
> >>> package/, toolchain/ and target/ anyway. That doesn't sound like a
> >>> real issue.
> 
> Ulf> I am talking about sed and awk which will be more difficult.
> 
> Peter> Then just do a find ..|xargs on those or use **/*.mk (if you use a
> Peter> proper shell).
> 

Yes, I can try to become an expert in shell programming, but
that is not on my top 100 list of things to do.

> >>> Bernard several times asked you to fork and do the atmel stuff in a
> >>> seperate branch. I still don't think that's a good idea considering
> >>> the limited amount of BR development ressources we have.
> 
> Ulf> He complained about things breaking, but this is bound to
> Ulf> happen.  He seemed to complain a lot on me, when patches in
> Ulf> reality came from others.  I know *his* patches caused me about
> Ulf> 3-4 weeks of extra work.
> 
> Peter> Well, it's very hard to be absolutely sure you don't break anything
> Peter> when you change something in a system like BR simply because of the
> Peter> number of config combinations you would need to test.
> 

Yes, however sometimes others can see that a patch has potential problems
in certain areas, and if pointed out I think that the submitter should do some extra testing.

> Peter> That ofcause doesn't mean we shouldn't be careful, just that random
> Peter> breakage is to be expected.
> 
> Peter> I've been playing a bit around with buildbot (http://buildbot.net) -
> Peter> And that looks quite nice.


> 
> Peter> -- 
> Peter> Bye, Peter Korsgaard
> 


Best Regards
Ulf Samuelsson

[Buildroot] svn commit: trunk/buildroot/package:editors editors/vi

[Peter Korsgaard]

>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:

Hi,

 Peter> Then just do a find ..|xargs on those or use **/*.mk (if you use a
 Peter> proper shell).
 >> 

 Ulf> Yes, I can try to become an expert in shell programming, but
 Ulf> that is not on my top 100 list of things to do.

A pity. BR is basically just a bunch of shell (and) make scripts ;)

-- 
Bye, Peter Korsgaard

[Buildroot] svn commit: trunk/buildroot/package:editors editors/vi

[Arnar Mar Sig]

Hi.

And just to point out. This subdir structure is already used for the  
x11r7 packages, so why not keep the package/ structure constant and do  
this for the other package groups?

Arnar Mar Sig.

On Mar 10, 2008, at 10:53 PM, Peter Korsgaard wrote:

>>>>>> "Ulf" == Ulf Samuelsson <ulf.samuelsson@atmel.com> writes:
>
> Hi,
>
> Peter> Then just do a find ..|xargs on those or use **/*.mk (if you  
> use a
> Peter> proper shell).
>>>
>
> Ulf> Yes, I can try to become an expert in shell programming, but
> Ulf> that is not on my top 100 list of things to do.
>
> A pity. BR is basically just a bunch of shell (and) make scripts ;)
>
> -- 
> Bye, Peter Korsgaard
> _______________________________________________
> buildroot mailing list
> buildroot at uclibc.org
> http://busybox.net/mailman/listinfo/buildroot