Hi all,
I installed an instance of Indefero (www.indefero.net), a *forge or googlecode alike, with most of our projects at http://www.coresystems.de/~patrick/indefero/. It's a purely experimental setup, but I'd like some feedback on what's good and what isn't, for our use.
The reasons for this experiment are: - lack of acceptance of our trac install - imho better usability than trac - a more formalized notion of "projects", with issue tracker, code browser, download area, documentation, developers. - out of the box support for svn and git, with hg around the corner and support for multiple SCMs in the design.
If you miss a project in the list, tell me, we can (probably) add it. Libpayload unfortunately doesn't have its own repository, which seems to be a requirement for svn-based projects - hence "probably". The developer of the software seems to be quite responsive to requests and bug reports, so it might be possible to overcome such problems.
I'm open to any result (use it, don't use it, wait until scenario $x is better supported, ...), but if it is decided that we want to use this tool, we could put it at a subdomain (code.coreboot.org or whatever), either with the data migrated or a fresh start (depends on how much test "junk" ends up in the database).
Regards, Patrick Georgi
it's nice. I was unable to upload a file for the problem, however (I did get a login, you can see my issue on buildrom)
ron
On Wed, 25 Feb 2009 06:30:12 -0800, ron minnich rminnich@gmail.com wrote:
it's nice. I was unable to upload a file for the problem, however (I did get a login, you can see my issue on buildrom)
Thanks, it's fixed now (permission problem)
Patrick
Patrick Georgi wrote:
The reasons for this experiment are:
- lack of acceptance of our trac install
I think the problem is less with Trac and more with anything off mailing list, but I'm not sure. I am usually the last to advocate anything on the web, but I do like Trac.
- imho better usability than trac
Maybe, but it seems that indefero lacks many of the nice things in Trac at least for tickets/issues. Noone likes thousand field forms but I think indefero is too simplistic. :\
- a more formalized notion of "projects", with issue tracker, code browser, download area, documentation, developers.
No doubt this is better than Trac. That's an area where Trac really sucks; it only handles one project. But they are working on it, although it wasn't done when I last looked half a year ago or so.
- out of the box support for svn and git, with hg around the corner and support for multiple SCMs in the design.
A big plus. Trac is getting it too, eventually.
There are some pages in Trac land on both of the above topics. Some things can be tested already, but they haven't yet gone into a release.
http://trac.edgewall.org/wiki/VcRefactoring http://trac.edgewall.org/wiki/TracMultipleProjects http://trac.edgewall.org/wiki/MultipleRepositorySupport
//Peter
If you miss a project in the list, tell me, we can (probably) add it. Libpayload unfortunately doesn't have its own repository, which seems to be a requirement for svn-based projects - hence "probably". The developer of the software seems to be quite responsive to requests and bug reports, so it might be possible to overcome such problems.
I would vote to have flashrom show up on the list of projects.
Myles
On Wed, 25 Feb 2009 08:44:54 -0700, "Myles Watson" mylesgw@gmail.com wrote:
I would vote to have flashrom show up on the list of projects.
The problem with this, just as with libpayload, is that they're part of the coreboot-v2 repository. Indefero wants a 1:1 mapping between project and repository (and I'd also prefer it, for clarity).
I think the many-projects-in-a-single-repo thing is somewhat "historical". Recently, projects simply got their own repository, but we used to stuff everything into the main repo.
I see three possible solutions: - Split out the projects into separate repositories (and probably use svn:externals for help with transition) - Extend indefero so it can use partial svn repositories for projects (ideally, an upstream feature) - Don't use indefero (or other tools that don't support this layout).
Regards, Patrick
On Wed, Feb 25, 2009 at 05:13:46PM +0100, Patrick Georgi wrote:
On Wed, 25 Feb 2009 08:44:54 -0700, "Myles Watson" mylesgw@gmail.com wrote:
I would vote to have flashrom show up on the list of projects.
The problem with this, just as with libpayload, is that they're part of the coreboot-v2 repository. Indefero wants a 1:1 mapping between project and repository (and I'd also prefer it, for clarity).
I think the many-projects-in-a-single-repo thing is somewhat "historical". Recently, projects simply got their own repository, but we used to stuff everything into the main repo.
I see three possible solutions:
- Split out the projects into separate repositories (and probably use
svn:externals for help with transition)
I think this would be a good idea anyway, regardless of whether we use indefero.
Thanks, Ward.
On Wed, 25 Feb 2009 11:20:43 -0500, Ward Vandewege ward@gnu.org wrote:
I think this would be a good idea anyway, regardless of whether we use indefero.
I separated out libpayload, flashrom and coreboot-v1. What else should be separate? Every payload in its own repository (that would be bayou and coreinfo)? Which of the other utilities should be separated?
I'll keep the repos up-to-date until we officially make the switch.
Regards, Patrick
Patrick Georgi wrote:
On Wed, 25 Feb 2009 11:20:43 -0500, Ward Vandewege ward@gnu.org wrote:
I think this would be a good idea anyway, regardless of whether we use indefero.
I separated out libpayload, flashrom and coreboot-v1. What else should be separate? Every payload in its own repository (that would be bayou and coreinfo)?
I'm not sure where the tint patch should live - but there really needs to be a home for patches to existing payloads such as the tint patch, or the long lost gPXE patches. Maybe we can toss them into libpayload/contribs or something.
Jordan
Jordan Crouse wrote:
I'm not sure where the tint patch should live - but there really needs to be a home for patches to existing payloads such as the tint patch, or the long lost gPXE patches. Maybe we can toss them into libpayload/contribs or something.
That's a great place.
The alternative is in buildrom, but I would prefer in libpayload.
//Peter
On 25.02.2009 17:20, Ward Vandewege wrote:
On Wed, Feb 25, 2009 at 05:13:46PM +0100, Patrick Georgi wrote:
I think the many-projects-in-a-single-repo thing is somewhat "historical". Recently, projects simply got their own repository, but we used to stuff everything into the main repo.
I see three possible solutions:
- Split out the projects into separate repositories (and probably use
svn:externals for help with transition)
I think this would be a good idea anyway, regardless of whether we use indefero.
There is one big problem affecting almost all of our contributors from big companies: svn:externals. Even if you access the main repository via https, svn:externals specifies the protocol as native svn, so users behind corporate firewalls not allowing native svn are stuck once they try to check out our trees. Although svn:externals can handle the same protocols as a normal svn tree, the protocol used for svn:externals is a repository property.
That problem was fixed in subversion 1.5, see http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html (search for "frustrations"). However, the new svn:externals format is incompatible with subversion 1.4, so we'd erect a big roadblock for everyone stuck with svn 1.4 or earlier.
Even if we ignore all that, preserving history will be difficult.
Regards, Carl-Daniel
On Fri, 27 Feb 2009 16:08:54 +0100, Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@gmx.net wrote:
That problem was fixed in subversion 1.5, see http://svnbook.red-bean.com/en/1.5/svn.advanced.externals.html (search for "frustrations"). However, the new svn:externals format is incompatible with subversion 1.4, so we'd erect a big roadblock for everyone stuck with svn 1.4 or earlier.
Stefan and I talked about moving to using https access for svn only, precisely for that reason. I think we have an "agreeable" cert, even by MITM-attack firewalls.
Even if we ignore all that, preserving history will be difficult.
I already did it. New repositories, containing only the history of the various projects. I removed the renames and moves (eg. LinuxBIOSv2/util/flash_and_burn to ../util/flashrom to util/flashrom), the code resides at /trunk from the beginning instead, and the revisions are renumbered.
Other than that, they're identical to what we have now.
I did that for coreboot-v1, flashrom and libpayload. Bayou and coreinfo would be the remaining candidates as far as I can see.
Regards, Patrick Georgi
Patrick Georgi wrote:
Stefan and I talked about moving to using https access for svn only, precisely for that reason.
Sounds good to me. But maybe some will appreciate if the svn protocal can still be used?
I removed the renames and moves (eg. LinuxBIOSv2/util/flash_and_burn to ../util/flashrom to util/flashrom), the code resides at /trunk from the beginning instead, and the revisions are renumbered.
Awesome. I suggest to simply announce a date a little in advance, say in two weeks, when the same process is done for the public repos.
//Peter
Hi All:
I am not a grub2 for coreboot expert, thus I am seeking advice for those who have done this before...
If I want grub2 to boot a HDD from primary master (on a regular x86 platform, specifically AMD's Cheetah) which options should I choose ?
I've been trying different options, and I wonder if I am on the right direction. See my last attempt:
--> $PWD/installed/bin/grub-mkimage -o core.img normal fat iso9660 pc ata lar configfile multiboot boot --prefix='(ata0)/boot/grub'
--> cp core.img ../coreboot-v2-957/targets/amd/serengeti_cheetah/serengeti_cheetah/paylo ad.elf
Can anyone help ?
Best Regards,
Vincent
On Fri, 27 Feb 2009 17:05:03 +0100, Peter Stuge peter@stuge.se wrote:
Sounds good to me. But maybe some will appreciate if the svn protocal can still be used?
Hmm.. what would that be for - really obnoxious firewalls that filter https, but leave "random" ports alone?
Awesome. I suggest to simply announce a date a little in advance, say in two weeks, when the same process is done for the public repos.
I could push the repos live "right now", but I see no reason to make them active on svn:// and move them in 2 weeks or whenever (and require another synchronization by users)
Regards, Patrick Georgi
Patrick Georgi wrote:
Sounds good to me. But maybe some will appreciate if the svn protocal can still be used?
Hmm.. what would that be for - really obnoxious firewalls that filter https, but leave "random" ports alone?
It would be for users that have a working setup and are unable to communicate with their network administrators in the timeframe that we choose for making the switch to https.
Awesome. I suggest to simply announce a date a little in advance, say in two weeks, when the same process is done for the public repos.
I could push the repos live "right now", but I see no reason to make them active on svn:// and move them in 2 weeks or whenever (and require another synchronization by users)
I think "right now" is too short time for people to make neccessary changes, and catch up with the fact that we are making the change.
If https+repomove do not happen at the same time I think https should come first. But the other way around is not so nice.
//Peter
On Wed, 25 Feb 2009 14:52:29 +0100, Patrick Georgi patrick.georgi@coresystems.de wrote:
Hi all,
I installed an instance of Indefero (www.indefero.net), a *forge or googlecode alike, with most of our projects at http://www.coresystems.de/~patrick/indefero/. It's a purely experimental setup, but I'd like some feedback on what's good and what isn't, for our use.
The reasons for this experiment are:
- lack of acceptance of our trac install
- imho better usability than trac
- a more formalized notion of "projects", with issue tracker, code browser, download area, documentation, developers.
- out of the box support for svn and git, with hg around the corner and support for multiple SCMs in the design.
If you miss a project in the list, tell me, we can (probably) add it. Libpayload unfortunately doesn't have its own repository, which seems to be a requirement for svn-based projects - hence "probably". The developer of the software seems to be quite responsive to requests and bug reports, so it might be possible to overcome such problems.
I'm open to any result (use it, don't use it, wait until scenario $x is better supported, ...), but if it is decided that we want to use this tool, we could put it at a subdomain (code.coreboot.org or whatever), either with the data migrated or a fresh start (depends on how much test "junk" ends up in the database).
It looks good, but you can't browse and see the source code (on the web page) like trac. I like that feature.
On Wed, 25 Feb 2009 11:22:24 -0500, Joseph Smith joe@settoplinux.org wrote:
It looks good, but you can't browse and see the source code (on the web page) like trac. I like that feature.
http://www.coresystems.de/~patrick/indefero/index.php/p/coreboot-v2/source/t... http://www.coresystems.de/~patrick/indefero/index.php/p/coreboot-v2/source/t... http://www.coresystems.de/~patrick/indefero/index.php/p/coreboot-v2/source/t...
These seem to work. However, some of the file types (.inc, .lds) don't. I'll take a look at that. Anything else that is missing?
Regards, Patrick
On Wed, 25 Feb 2009 17:36:58 +0100, Patrick Georgi patrick.georgi@coresystems.de wrote:
On Wed, 25 Feb 2009 11:22:24 -0500, Joseph Smith joe@settoplinux.org wrote:
It looks good, but you can't browse and see the source code (on the web page) like trac. I like that feature.
http://www.coresystems.de/~patrick/indefero/index.php/p/coreboot-v2/source/t...
http://www.coresystems.de/~patrick/indefero/index.php/p/coreboot-v2/source/t...
http://www.coresystems.de/~patrick/indefero/index.php/p/coreboot-v2/source/t...
These seem to work. However, some of the file types (.inc, .lds) don't. I'll take a look at that. Anything else that is missing?
Ah, I see :-) I was trying to open a Config.lb and a Options.lb those aren't working. Besides that it looks great.
Patrick Georgi patrick.georgi@coresystems.de wrote:
The reasons for this experiment are: - imho better usability than trac
An alternative to Trac is Redmine (www.redmine.org).
Phil
Am Mittwoch, den 25.02.2009, 21:49 -0800 schrieb Phil Garcia:
Patrick Georgi patrick.georgi@coresystems.de wrote:
The reasons for this experiment are:
- imho better usability than trac
An alternative to Trac is Redmine (www.redmine.org).
I also read about Redmine. But I could not find a comparison on the Web¹ and I do not have experience with them myself.
Do you have more information?
Thanks,
Paul
¹ Searching for “indefero redmine comparison” and [1] does not list InDefero.
[1] http://en.wikipedia.org/wiki/Comparison_of_issue_tracking_systems
On Thu, 26 Feb 2009 08:36:16 +0100, Paul Menzel paulepanter@users.sourceforge.net wrote:
and I do not have experience with them myself.
Redmine has three disadvantages (which are probably related): 1. It's ruby-on-rails. We don't use that framework on our servers yet, so there might be quite some work involved to make it fit our configuration 2. It seems to have performance issues (eg. http://www.mail-archive.com/sharpos-developers@lists.sourceforge.net/msg0143...) 3. rails doesn't seem stable (can't say much about its execution qualities, but its APIs seem to be rather fluid). I'd like to avoid a maintenance mess.
That's why I didn't look any closer at implementing it, when there are more obvious choices. Of course, if there's some important feature that indefero lacks (and can't provide), I'd try.
Regards, Patrick Georgi
Patrick Georgi wrote:
Of course, if there's some important feature that indefero lacks (and can't provide), I'd try.
I say again, let's keep Trac. But look at upgrading.
Unless of course people really dislike it and would actually make more use of something else?
//Peter
-
Carl-Daniel Hailfinger -
Jordan Crouse -
Joseph Smith -
Lim, Vincent -
Myles Watson -
Patrick Georgi -
Patrick Georgi -
Paul Menzel -
Peter Stuge -
Phil Garcia -
ron minnich -
Ward Vandewege