Write Access to buildroot?
What happened to this?
Can't even generate a branch right now...
BR
Ulf Samuelsson
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Ulf" == Ulf Samuelsson <[email protected]> writes:
Ulf> What happened to this?
Ulf> Can't even generate a branch right now...
That's on purpose. See:
http://lists.busybox.net/pipermail/buildroot/2009-March/026875.html
and
Signature · 1 line
Bye, Peter Korsgaard
Peter Korsgaard skrev:
Quoted 6 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
"Ulf" == Ulf Samuelsson <[email protected]> writes:
Ulf> What happened to this?
Ulf> Can't even generate a branch right now...
Quoted 9 lines
That's on purpose. See:
http://lists.busybox.net/pipermail/buildroot/2009-March/026875.html
and
OK,
Have not been active for a while and have about 3000 unread emails. Seems to me that there a multiple people with write access from the git commit mails, How come?
Personally, I think it would make sense to have
a development git with personal branches with write access.
This would complement any personal git's and would allow easier testing with other people's patches.
The main tree, used for the release
could then pull changes from both the development tree and the personal tree's.
Is there a list of maintainers?
The target/device/Atmel tree will need to be updated due to the SAM9G10/G45/M10/M11. The target/linux tree is also in need of maintenance.
BR
Ulf Samuelsson
Quoted 11 lines · Ulf Samuelsson
Quoted 7 lines
http://lists.busybox.net/pipermail/buildroot/2009-March/026875.html
and
OK,
Have not been active for a while and have about 3000 unread emails. Seems to me that there a multiple people with write access from the git commit mails, How come?
That's just the git post-commit hook that takes the original author as sender address of the email. That always happens when Peter picks a patch and commits it to his tree.
Quoted 5 lines
Personally, I think it would make sense to have
a development git with personal branches with write access.This would complement any personal git's and would allow easier testing with other people's patches.
The thing about git and other distributed SCMs is: everbody has write access. To his local copy. You can than push your tree to an publically accesible external tree and share your personal patches with others. Or do the same thing by sending a thread of patches, if you don't want to share your patches among others before they're ready for the master branch.
Quoted 3 lines
The main tree, used for the release
could then pull changes from both the development tree and the personal tree's.
This is basicaly exactly the same thing than having your own repository, with the difference that the admins of ublibc.org won't have to fiddle with user permissions.
Quoted 3 lines
Is there a list of maintainers?
The target/device/Atmel tree will need to be updated due to the SAM9G10/G45/M10/M11. The target/linux tree is also in need of maintenance.
That's exactly why you want to have distributed repositories. You simply don't have to care about all that. Once you tested the patches in your tree for long enough, simply send in a pull request, and they will end up in the master branch.
There a multiple free git hosting services out there, for example github.com.
Hope that helps :)
Daniel
Le Fri, 24 Jul 2009 10:56:03 +0200,
Daniel Mack <[email protected]> a ?crit :
Quoted 2 lines
There a multiple free git hosting services out there, for example github.com.
As explained in
http://lists.busybox.net/pipermail/buildroot/2009-March/026875.html,
Buildroot developers also have a public git repository on the uclibc server. For example, my own git tree is visible at
http://git.buildroot.net/~tpetazzoni/git/buildroot/.
Sincerly,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com
Quoted 22 lines · Ulf Samuelsson
Quoted 11 lines
Quoted 7 lines
http://lists.busybox.net/pipermail/buildroot/2009-March/026875.html
and
OK,
Have not been active for a while and have about 3000 unread emails. Seems to me that there a multiple people with write access from the git commit mails, How come?That's just the git post-commit hook that takes the original author as sender address of the email. That always happens when Peter picks a patch and commits it to his tree.
Quoted 3 lines
Personally, I think it would make sense to have
a development git with personal branches with write access.
Quoted 6 lines
Quoted 2 lines
This would complement any personal git's and would allow easier testing with other people's patches.
The thing about git and other distributed SCMs is: everbody has write access. To his local copy. You can than push your tree to an publically accesible external tree and share your personal patches with others.
That is the problem, buildroot does not provide a "publically accesible external tree"
for developers.
Why rely on github.com mentioned below which people won't find on their own?
If the development tree is within buildroot, then people are more likely to test it
or contribute.
Quoted 11 lines
Or do the same thing by sending a thread of patches, if you don't want to share your patches among others before they're ready for the master branch.
Quoted 3 lines
The main tree, used for the release
could then pull changes from both the development tree and the personal tree's.This is basicaly exactly the same thing than having your own repository, with the difference that the admins of ublibc.org won't have to fiddle with user permissions.
The difference is that the development tree is shared.
Quoted 6 lines
Quoted 5 lines
Is there a list of maintainers?
The target/device/Atmel tree will need to be updated due to the SAM9G10/G45/M10/M11.
The target/linux tree is also in need of maintenance.
Quoted 7 lines
That's exactly why you want to have distributed repositories. You simply don't have to care about all that. Once you tested the patches in your tree for long enough, simply send in a pull request, and they will end up in the master branch.
There a multiple free git hosting services out there, for example github.com.
Thanks for the link.
Quoted 5 lines
Hope that helps :)
Daniel
Best Regards
Ulf Samuelsson ulf at atmel.com
Atmel Nordic AB
Mail: Box 2033, 174 02 Sundbyberg, Sweden Visit: Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29
GSM +46 (706) 22 44 57
Le Fri, 24 Jul 2009 11:19:36 +0200,
"Ulf Samuelsson" <[email protected]> a ?crit :
Quoted 3 lines
That is the problem, buildroot does not provide a "publically accesible external tree"
for developers.
As explained on
http://lists.busybox.net/pipermail/buildroot/2009-March/026875.html,
there are publically accessible external trees provided by Buildroot for developers.
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com
A message that is not in the archive (sent off-list or not yet received): [email protected]
[ Keeping the list in Cc: since these things should probably be
discussed publicly. ]
Le Fri, 24 Jul 2009 13:37:01 +0200,
Ulf Samuelsson <[email protected]> a ?crit :
Quoted 5 lines
With read access only, allowing you to make your own tree from the main tree.
If you want to share your stuff, before committing to the main tree, you have to do it outside the buildroot world.
Am I missing something?
Yes you're missing something.
Look at http://git.buildroot.net/
You have a link to the official Buildroot Git tree, browsable at
http://git.buildroot.net/buildroot/. This Git tree is read-only, except for Peter.
But at the bottom of the page, you have ? User repositories ?. These are read/write for their owner. For example, mine is
http://git.buildroot.net/~tpetazzoni/git/buildroot/. In my own repository, I have a master branch which is just a clone of the main Buildroot repository. And all the other branches (presently directfb-bump, ext-toolchain-target-path, external-toolchain, kconfig-update and xorg) contain my *own* work, ready for submission to Peter. And some of this work has actually already been integrated in mainline (branches directfb-bump, ext-toolchain-target-path and external-toolchain).
The link
http://lists.busybox.net/pipermail/buildroot/2009-March/026875.html
that I've already posted explains how to use these user repositories, that *are read/write.
Does that clarify the situation ?
Sincerly,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com
Thomas Petazzoni skrev:
Quoted 33 lines
[ Keeping the list in Cc: since these things should probably be
discussed publicly. ]Le Fri, 24 Jul 2009 13:37:01 +0200,
Ulf Samuelsson <[email protected]> a ?crit :Quoted 6 lines
With read access only, allowing you to make your own tree from the main tree.
If you want to share your stuff, before committing to the main tree, you have to do it outside the buildroot world.
Am I missing something?Yes you're missing something.
Look at http://git.buildroot.net/
You have a link to the official Buildroot Git tree, browsable at
http://git.buildroot.net/buildroot/. This Git tree is read-only, except for Peter.But at the bottom of the page, you have ? User repositories ?. These are read/write for their owner. For example, mine is
http://git.buildroot.net/~tpetazzoni/git/buildroot/. In my own repository, I have a master branch which is just a clone of the main Buildroot repository. And all the other branches (presently directfb-bump, ext-toolchain-target-path, external-toolchain, kconfig-update and xorg) contain my *own* work, ready for submission to Peter. And some of this work has actually already been integrated in mainline (branches directfb-bump, ext-toolchain-target-path and external-toolchain).
Quoted 8 lines
The link
http://lists.busybox.net/pipermail/buildroot/2009-March/026875.html
that I've already posted explains how to use these user repositories, that *are read/write.Does that clarify the situation ?
And what I am missing, is a way to have several people commit to the same tree.
I.E: A development tree.
Quoted 4 lines
Sincerly,
Thomas
BR
Ulf Samuelsson
Le Fri, 24 Jul 2009 17:16:30 +0200,
Ulf Samuelsson <[email protected]> a ?crit :
Quoted 3 lines
And what I am missing, is a way to have several people commit to the same tree.
I.E: A development tree.
This is not how development works with Git. Everyone works in its own working tree, and asks the project maintainer to pull the working tree when things are ready. Things gets integrated in the project maintainer tree, which everyone can update from to get the changes from the other developers.
In Buildroot, there's no ? development tree ? in the current development model. The same tree (the official way) is sometimes a development tree (before -rc1 is released), sometimes a stabilization tree (between the release of -rc1 and the release of the stable version).
Sincerly,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com
Thomas Petazzoni skrev:
Quoted 9 lines
Le Fri, 24 Jul 2009 17:16:30 +0200,
Ulf Samuelsson <[email protected]> a ?crit :Quoted 4 lines
And what I am missing, is a way to have several people commit to the same tree.
I.E: A development tree.
Quoted 6 lines
This is not how development works with Git. Everyone works in its own working tree, and asks the project maintainer to pull the working tree when things are ready. Things gets integrated in the project maintainer tree, which everyone can update from to get the changes from the other developers.
In the openembedded project all the developers have write access to the development tree and can create their own branches within the tree.
This makes it a lot easier to test other peoples patches.
If you look at the statistics for the user repositories, you see that there are 5 people with user repositories, including mine, and last updates were from
correa: 3 months ago, wberrier: 2 months ago, tpetazzoni: 9 days ago ulf: 33 hours ago jacmet: -
This does not indicate a high level of popularity to me. Maybe people are keeping trees in other locations, but that means that they are hidden from most users.
In reality, the way Buildroot works today seems to be that people are sending patches to the mailing-list.
It is fairly easy to set up common git trees, by creating a "common" user with a git subdirectory and then have a symbolic link in each user directory to this git directory with group write permissions.
Quoted 7 lines
In Buildroot, there's no ? development tree ? in the current development model. The same tree (the official way) is sometimes a development tree (before -rc1 is released), sometimes a stabilization tree (between the release of -rc1 and the release of the stable version).
The suggestion does not change this.
Quoted 4 lines
Sincerly,
Thomas
BR
Ulf Samuelsson
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Ulf" == Ulf Samuelsson <[email protected]> writes:
Hi,
Ulf> In the openembedded project all the developers have Ulf> write access to the development tree and can create Ulf> their own branches within the tree.
Ulf> This makes it a lot easier to test other peoples patches.
I don't agree, typing git add remove <foo> is trivial. That's the glory of the distributed nature of git.
Ulf> If you look at the statistics for the user repositories, Ulf> you see that there are 5 people with user repositories, Ulf> including mine, and last updates were from
Ulf> correa: 3 months ago,
Ulf> wberrier: 2 months ago,
Ulf> tpetazzoni: 9 days ago
Ulf> ulf: 33 hours ago
Ulf> jacmet: -
which corresponds pretty nicely with the list of active developers:
git shortlog -s -n 2009.05..
73 Peter Korsgaard
31 Thomas Petazzoni
9 Maxim Grigoriev
8 Will Newton
7 Sven Neumann
5 Gustavo Zacarias
4 Nigel Kukard
2 Bernhard Reutner-Fischer
2 Daniel Mack
2 Ulf Samuelsson
1 Alex Dobrynin
1 Evan Zelkowitz
1 H Hartley Sweeten
1 Lionel Landwerlin
1 Markus Heidelberg
1 Pwalters
1 laurent laffontBernhard has his repo on repo.or.cz for historical reasons.
Ulf> This does not indicate a high level of popularity to me. Ulf> Maybe people are keeping trees in other locations, but Ulf> that means that they are hidden from most users.
No, it indicates that buildroot is a small project with limited amount of active developers (and luckily a lot of outside contributers).
Ulf> In reality, the way Buildroot works today seems to be that Ulf> people are sending patches to the mailing-list.
And that's exactly what they should do. We *WANT* to see the patches on the mailing list so they can get reviewed.
We also don't want to require outsiders to learn git in order to contribute patches.
Signature · 1 line
Bye, Peter Korsgaard
Peter Korsgaard skrev:
Quoted 51 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
"Ulf" == Ulf Samuelsson <[email protected]> writes:
Hi,
Ulf> In the openembedded project all the developers have Ulf> write access to the development tree and can create Ulf> their own branches within the tree.
Ulf> This makes it a lot easier to test other peoples patches.
I don't agree, typing git add remove <foo> is trivial. That's the glory of the distributed nature of git.
Ulf> If you look at the statistics for the user repositories, Ulf> you see that there are 5 people with user repositories, Ulf> including mine, and last updates were from
Ulf> correa: 3 months ago,
Ulf> wberrier: 2 months ago,
Ulf> tpetazzoni: 9 days ago
Ulf> ulf: 33 hours ago
Ulf> jacmet: -which corresponds pretty nicely with the list of active developers:
git shortlog -s -n 2009.05..
73 Peter Korsgaard 31 Thomas Petazzoni 9 Maxim Grigoriev 8 Will Newton 7 Sven Neumann 5 Gustavo Zacarias 4 Nigel Kukard 2 Bernhard Reutner-Fischer 2 Daniel Mack 2 Ulf Samuelsson 1 Alex Dobrynin 1 Evan Zelkowitz 1 H Hartley Sweeten 1 Lionel Landwerlin 1 Markus Heidelberg 1 Pwalters 1 laurent laffontBernhard has his repo on repo.or.cz for historical reasons.
Ulf> This does not indicate a high level of popularity to me. Ulf> Maybe people are keeping trees in other locations, but Ulf> that means that they are hidden from most users.
Quoted 9 lines
No, it indicates that buildroot is a small project with limited amount of active developers (and luckily a lot of outside contributers).
Ulf> In reality, the way Buildroot works today seems to be that Ulf> people are sending patches to the mailing-list.
And that's exactly what they should do. We *WANT* to see the patches on the mailing list so they can get reviewed.
I do not see a contracdiction here.
You can have multiple persons work on one thing, and once it is ready, the patches can be automatically generated and sent to the mailing list.
What is the drawback of letting people work together by allowing them to share a git.
People can share a git anyway, by using another git server, but that makes it less visible to Buildroot users, so I would like to avoid that.
Quoted 3 lines
We also don't want to require outsiders to learn git in order to contribute patches.
It it very different to require people to learn git, from blocking people that wants to use git, to work together.
BR
Ulf Samuelsson
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Ulf" == Ulf Samuelsson <[email protected]> writes:
Hi,
Quoted 3 lines
Quoted 3 lines
We also don't want to require outsiders to learn git in order to contribute patches.
Ulf> It it very different to require people to learn git, from Ulf> blocking people that wants to use git, to work together.
Blocking? Noone is blocking anyone from anything. That particular work flow is not used for the official tree, but you can do what you want to with your own trees.
Don't confuse working together with commit access. The Linux kernel gets contributions from ~1000 people for each release, and yet Linus is the only one having commit access to the official tree.
Signature · 1 line
Bye, Peter Korsgaard
Peter Korsgaard skrev:
Quoted 7 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Ulf" == Ulf Samuelsson <[email protected]> writes:
Hi,
Quoted 3 lines
Quoted 3 lines
We also don't want to require outsiders to learn git in order to contribute patches.
Quoted 7 lines
Ulf> It it very different to require people to learn git, from Ulf> blocking people that wants to use git, to work together.
Blocking? Noone is blocking anyone from anything. That particular work flow is not used for the official tree, but you can do what you want to with your own trees.
I have requested a capability where multiple people have write capability to a tree which can then be pulled to the official tree.
It is possible to do this on another git server,
but that means that it is less visible to other Buildroot users.
It is simple to implement.
Create the "common" user, and let developers have write access to "~common/git", possibly using a symbolic link.
Quoted 4 lines
Don't confuse working together with commit access. The Linux kernel gets contributions from ~1000 people for each release, and yet Linus is the only one having commit access to the official tree.
That comments is irrelevant because I am not asking for commit access to the official tree.
BR
Ulf Samuelsson
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Ulf" == Ulf Samuelsson <[email protected]> writes:
Hi,
Ulf> I have requested a capability where multiple people have Ulf> write capability to a tree which can then be pulled Ulf> to the official tree.
Ulf> It is possible to do this on another git server,
Ulf> but that means that it is less visible to other Buildroot users.
Ulf> It is simple to implement.
Ulf> Create the "common" user, and let developers have Ulf> write access to "~common/git", possibly using a symbolic link.
Then do so. You have shell access to the buildroot.net machine, so you can make ~ulf/git/common world writable.
Signature · 1 line
Bye, Peter Korsgaard
For what it's worth, we have a shared git tree on linux-xtensa.org for Xtensa arch development of buildroot (we've had it there for many months before the buildroot project itself switched over to git).
We had to be careful with file ownership/protection (and maybe umask) to make sure it works smoothly, but once setup, it works quite well. Everybody has their own userid, no shared user or anything. We always use the git+ssh://... method to access the tree if we want to be able to write to it, else anyone can access it read-only using the usual git://... method -- if you're curious, see:
http://wiki.linux-xtensa.org/index.php/Repository_Access
One also has to be careful to only push things to this tree. No playing directly with the tree (such as rebase or otherwise pointing HEAD backwards in time and possibly committing new changes from there) which plays havoc with others' clones of the tree. As long as it's only accessed remotely, this is pretty easy.
In case you notice it out of sync... we've only merged this tree with the official buildroot tree once in a long while -- were waiting for the Xtensa arch port to get submitted (which it just has, yeah! :-) and to setup things to make it easier to catch merges that break things.
-Marc
Quoted 43 lines · Ulf Samuelsson
Peter Korsgaard skrev:
Quoted 11 lines
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Ulf" == Ulf Samuelsson <[email protected]> writes:
Hi,
Quoted 3 lines
Quoted 3 lines
We also don't want to require outsiders to learn git in order to contribute patches.
Ulf> It it very different to require people to learn git, from Ulf> blocking people that wants to use git, to work together.
Blocking? Noone is blocking anyone from anything. That
particular work
Quoted 3 lines
flow is not used for the official tree, but you can do what you want to with your own trees.
I have requested a capability where multiple people have write capability to a tree which can then be pulled to the official tree.
It is possible to do this on another git server,
but that means that it is less visible to other Buildroot users.It is simple to implement.
Create the "common" user, and let developers have write access to "~common/git", possibly using a symbolic link.Quoted 4 lines
Don't confuse working together with commit access. The Linux kernel gets contributions from ~1000 people for each release, and yet Linus is the only one having commit access to the official tree.
That comments is irrelevant because I am not asking for commit access to the official tree.
BR
Ulf Samuelsson
_______________________________________________
buildroot mailing list
buildroot at busybox.net
http://lists.busybox.net/mailman/listinfo/buildroot
Quoted 9 lines
For what it's worth, we have a shared git tree on linux-xtensa.org for Xtensa arch development of buildroot (we've had it there for many months before the buildroot project itself switched over to git).
We had to be careful with file ownership/protection (and maybe umask) to make sure it works smoothly, but once setup, it works quite well. Everybody has their own userid, no shared user or anything.
Thanks, it is the model used by Openembedded as well.
I do not specifically need a shared user,
I just want the http://git.uclibc.org/ to report
~common/<myproject>
instead of
~/ulf/git/common/<myproject>.
since the former better illustrates how I'd like to work.
It seems easier to just create a new user though.
Quoted 12 lines
We always use the git+ssh://... method to access the tree if we want to be able to write to it, else anyone can access it read-only using the usual
git://... method -- if you're curious, see:http://wiki.linux-xtensa.org/index.php/Repository_Access
One also has to be careful to only push things to this tree. No playing directly with the tree (such as rebase or otherwise pointing HEAD backwards in time and possibly committing new changes from there) which plays havoc with others' clones of the tree. As long as it's only accessed remotely, this is pretty easy.
Quoted 6 lines
In case you notice it out of sync... we've only merged this tree with the official buildroot tree once in a long while -- were waiting for the Xtensa arch port to get submitted (which it just has, yeah! :-) and to setup things to make it easier to catch merges that break things.
-Marc
Best Regards
Ulf Samuelsson ulf at atmel.com
Atmel Nordic AB
Mail: Box 2033, 174 02 Sundbyberg, Sweden Visit: Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29
GSM +46 (706) 22 44 57
Le Mon, 27 Jul 2009 08:40:13 +0200,
"Ulf Samuelsson" <[email protected]> a ?crit :
Quoted 9 lines
I just want the http://git.uclibc.org/ to report
~common/<myproject>
instead of
~/ulf/git/common/<myproject>.
since the former better illustrates how I'd like to work.
I really don't see the difference between the two approaches, and what are the advantages of the approach you're proposing. In terms of visibility, it is *exactly* the same thing.
Honestly, what I understand from this discussion is that you're saying ?I want this to be *this* way and no other way ?, but you're not giving any strong and convicing arguments of why the current way is bad and should be changed.
The way we do it in Buildroot is similar to dozens or hundreds of projects out there. It may be different to dozens or hundreds other projects. Participating to a community means that making concessions is necessary to progress and work together.
Sincerly,
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com
Quoted 9 lines
For what it's worth, we have a shared git tree on linux-xtensa.org for Xtensa arch development of buildroot (we've had it there for many months before the buildroot project itself switched over to git).
We had to be careful with file ownership/protection (and maybe umask) to make sure it works smoothly, but once setup, it works quite well. Everybody has their own userid, no shared user or anything.
Thanks, it is the model used by Openembedded as well.
I do not specifically need a shared user,
I just want the http://git.uclibc.org/ to report
~common/<myproject>
instead of
~/ulf/git/common/<myproject>.
since the former better illustrates how I'd like to work.
It seems easier to just create a new user though.
Quoted 12 lines
We always use the git+ssh://... method to access the tree if we want to be able to write to it, else anyone can access it read-only using the usual
git://... method -- if you're curious, see:http://wiki.linux-xtensa.org/index.php/Repository_Access
One also has to be careful to only push things to this tree. No playing directly with the tree (such as rebase or otherwise pointing HEAD backwards in time and possibly committing new changes from there) which plays havoc with others' clones of the tree. As long as it's only accessed remotely, this is pretty easy.
Quoted 6 lines
In case you notice it out of sync... we've only merged this tree with the official buildroot tree once in a long while -- were waiting for the Xtensa arch port to get submitted (which it just has, yeah! :-) and to setup things to make it easier to catch merges that break things.
-Marc
Best Regards
Ulf Samuelsson ulf at atmel.com
Atmel Nordic AB
Mail: Box 2033, 174 02 Sundbyberg, Sweden Visit: Kavalleriv?gen 24, 174 58 Sundbyberg, Sweden
Phone +46 (8) 441 54 22 Fax +46 (8) 441 54 29
GSM +46 (706) 22 44 57
Le Sun, 26 Jul 2009 22:21:00 +0200,
Ulf Samuelsson <[email protected]> a ?crit :
Quoted 2 lines
It is possible to do this on another git server,
but that means that it is less visible to other Buildroot users.
Since visibility seems to be your main complaint against the developer Git trees, what kind of better visibility would you like than the one already available at http://git.buildroot.net/ ?
All developer trees are directly visible, on the mainpage of the Git page. Isn't that enough ?
Thomas
Signature · 4 lines
Thomas Petazzoni, Free Electrons Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Ulf" == Ulf Samuelsson <[email protected]> writes:
Hi,
Ulf> Personally, I think it would make sense to have Ulf> a development git with personal branches with write access.
You have the possibility to put your own development tree on the server as explained by Thomas.
Ulf> This would complement any personal git's and would allow Ulf> easier testing with other people's patches.
Ulf> The main tree, used for the release
Ulf> could then pull changes from both the development tree Ulf> and the personal tree's.
Ulf> Is there a list of maintainers?
Not an explicit list, no.
Ulf> The target/device/Atmel tree will need to be updated due to the Ulf> SAM9G10/G45/M10/M11.
You are probably in the best position to do this - Last I looked the G45 wasn't publicly announced and no documentation available.
Patches are welcome.
Ulf> The target/linux tree is also in need of maintenance.
What exactly do you mean? 2.6.31-rcX options?
Signature · 1 line
Bye, Peter Korsgaard
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Ulf" == Ulf Samuelsson <[email protected]> writes:
Hi,
Ulf> The target/device/Atmel tree will need to be updated due to the Ulf> SAM9G10/G45/M10/M11.
Quoted 3 lines
Quoted 3 lines
You are probably in the best position to do this - Last I looked the G45 wasn't publicly announced and no documentation available.
Ulf> I dont have a datasheet either, only design specs, but I do have Ulf> a board and there are internal patches available.
External as well. Nicolas Ferre posted 9G45 patches to linux-arm-kernel back in June.
Signature · 1 line
Bye, Peter Korsgaard