Re: Switching to git?
I do object. Personally, I believe that git is inferior to other modern version control systems, thus I don't want to move. If we do, I prefer to go with something better. Which features are you missing? http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Which management software do you prefer at the moment? Regards, Markus ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Switching to git?
Yoshinori K. Okuji [EMAIL PROTECTED] writes: On Saturday 15 December 2007 11:54, Robert Millan wrote: So it seems nobody objected. What do we need to proceed? I do object. Personally, I believe that git is inferior to other modern version control systems, thus I don't want to move. If we do, I prefer to go with something better. Please cite the ones you think are superior so we all can discuss it. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Switching to git?
Inferior? I see the disadvantage, that now it works only on unix. This view is incomplete. http://en.wikipedia.org/wiki/Git_%28software%29#Portability There might be some inconvenience so far. TortoiseSVN is nice because it works as a shell extension for the Windows Explorer. Trac can provide a web interface to several source control systems. Regards, Markus ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: moving ata initialisation to a command
Robert Millan [EMAIL PROTECTED] writes: [...] While you are there why not add optional IO-base argument so one could use more than one controller lurking in other IO-bases (second/third PCI ?). Of course there needs to be some kind of auto detect for easier usage for normal users. I don't like that. Sounds like a workaround for not having proper PCI support.. :-/ Right, I plan to add PCI support soon. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: moving ata initialisation to a command
On Mon, 2007-12-17 at 17:01 +0100, Marco Gerards wrote: A better solution, IMO, would be changing grub-mkrescue so it doesn't load all modules. Maybe grub-mkrescue should create a filesystem? Even FAT should be fine. This way, it will be possible to load problematic modules from the filesystem. The only problem would be dependency on filesystem making tools. Fortunately, mtools is quite common. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Grub on x86_64 crash?
On Mon, 2007-12-17 at 05:56 +, Steven Yi wrote: by http://cross-lfs.org/view/svn/x86_64-64/boot/building-a-bootloader.html : On x86 and x86_64 (multilib) architectures, the preferred bootloader is GRUB. Unfortunately, GRUB doesn't work on x86_64 Pure64 - the stage2 files can be correctly built as 32-bit, but the grub shell is a 64-bit program, and tries to execute some of the stage2 routines - this results in a segmentation fault. Therefore, in the final system we use Lilo as the bootloader. How is it going on now? GRUB 2 it should be presumed working unless there is specific evidence of the problem, including the version number and the details of the crash. It's not worth my time to verify unspecific bugreports, but if you care about that, perhaps you should do the checking. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: moving ata initialisation to a command
Pavel Roskin [EMAIL PROTECTED] writes: On Mon, 2007-12-17 at 17:01 +0100, Marco Gerards wrote: A better solution, IMO, would be changing grub-mkrescue so it doesn't load all modules. Maybe grub-mkrescue should create a filesystem? Even FAT should be fine. This way, it will be possible to load problematic modules from the filesystem. The only problem would be dependency on filesystem making tools. Fortunately, mtools is quite common. This sounds like a good plan. For the CDROM image, mkisofs can be used. -- Marco ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Switching to git?
Markus Elfring wrote: I do object. Personally, I believe that git is inferior to other modern version control systems, thus I don't want to move. If we do, I prefer to go with something better. Which features are you missing? http://en.wikipedia.org/wiki/Comparison_of_revision_control_software Which management software do you prefer at the moment? Regards, Markus ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel There are so many version control systems under active development, so it is hard to choose the best one. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Switching to git?
Otavio Salvador wrote: Yoshinori K. Okuji [EMAIL PROTECTED] writes: On Saturday 15 December 2007 11:54, Robert Millan wrote: So it seems nobody objected. What do we need to proceed? I do object. Personally, I believe that git is inferior to other modern version control systems, thus I don't want to move. If we do, I prefer to go with something better. Please cite the ones you think are superior so we all can discuss it. Sun did choose Mercurial ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Switching to git?
Quoting willem [EMAIL PROTECTED]: Otavio Salvador wrote: Yoshinori K. Okuji [EMAIL PROTECTED] writes: On Saturday 15 December 2007 11:54, Robert Millan wrote: So it seems nobody objected. What do we need to proceed? I do object. Personally, I believe that git is inferior to other modern version control systems, thus I don't want to move. If we do, I prefer to go with something better. Please cite the ones you think are superior so we all can discuss it. Sun did choose Mercurial We are limited by what Savannah provides, unless some other place is found to host the project, which would complicate things. If there are any specific problems with git pertinent to GRUB or preferences of the GRUB developers, I'm ready to convey them to the git developers and take the blame (if any). We don't have to look for the best tool, just for the best tool for this particular project and those working on it. -- Regards, Pavel Roskin ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Switching to git?
Pavel Roskin [EMAIL PROTECTED] writes: If there are any specific problems with git pertinent to GRUB or preferences of the GRUB developers, I'm ready to convey them to the git developers and take the blame (if any). Personally I'm very happy with GIT and I'm using it in daily basis for most of project I'm active on. The easy merging and the wonderful workflow it allow is really nice. Besides that, it's really active and rapidly improving. We don't have to look for the best tool, just for the best tool for this particular project and those working on it. For me, it fits very well. I think it's worth to cite about http://packages.debian.org/sid/mr that allows to abstract the SCM and use a single command set for daily uses. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft sells you Windows ... Linux gives you the whole house. ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
Re: Switching to git?
On Tuesday 18 December 2007 02:20, Pavel Roskin wrote: If there are any specific problems with git pertinent to GRUB or preferences of the GRUB developers, I'm ready to convey them to the git developers and take the blame (if any). We don't have to look for the best tool, just for the best tool for this particular project and those working on it. I bet that you under-estimate the pain of migrating to another SCM. I have experienced such migrations twice, and they were always a pain, something that nobody wants to repeat. Some reasons: - The repository will be temporarily down (negligible in a long term). - All developers are forced to install new software and learn it (always a pain). - All local (pending) changes in working copies become very hard to merge (extremely painful). - It is hard to re-select yet another SCM later, because old software is usually better supported for migrations, i.e. it's not cheap to migrate back and forth (very painful). Since Robert was in a hurry so much, I had to stop it immediately with very terse words. I am sorry about that, but please do not make a haste. I have discussed (and objected to) possibilities to move to another SCM in the IRC, the mailing list, etc., but it seems that people forget my words at every time. It's sad to me, as I must repeat the same thing again and again. First of all, this is not a hurry at all. CVS is far from nice, but it has worked well for GRUB for the past 10 years, and we haven't had any critical problem with it. This is because GRUB is a very simple project from the viewpoint of source code management. You might be excited with technical innovations, but please don't forget that it costs to change things. Note that I don't mean that we should't change, but that we must be a bit more conservative with regard to SCM. Since we are not developing SCM itself, we should consider carefully pros and cons, before making an action. Ok, now about the git. As Tomáš pointed out, the lack of portability is regression from CVS. If you think, for example, grub4dos is important, why can you choose git? Besides the portability, I don't like the merging algorithm. If my knowledge is not completely outdated yet, git still uses 3-way merging, right? I don't describe the math here, as it is (a little) documented in the revctrl wiki: http://revctrl.org/CategoryMergeAlgorithm As long as git uses this naive algorithm, I am not willing to use it. CVS's merging algorithm is also very simple and stupid, but it is not a big problem, because CVS is centralized. When getting distributed, things get far more complicated and critical, since there are so many corner cases where one cannot see in a centralized SCM. These are the requirements for a new SCM in the context of GRUB from my point of view: - Free Software (definitely!) - Good merging algorithm (if distributed) - Good web interface (as good as viewvc) - Commit notification by email at the server side - Good portability (as good as CVS) - Ability to track changes efficiently, i.e. annotation (probably supported by most SCMs) - Usable interface (not like arch) - Good user document (like svnbook) - No conflict in a (main) repository (not like monotone) Other features are not so important, since GRUB is small. Here are some examples: - Subversion (+ svk) is good enough, if we only sometimes want to work offline. - Bazaar looks good, if we believe that their claim is all correct. Okuji ___ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
