2009/5/15 Chitlesh GOORAH <chitlesh.goorah@xxxxxxxxx>: > Hello there, > > I want to hear your thoughts about removing verilog-mode from the > emacs packages : emacs-el and emacs-common > > Files affected are > /usr/share/emacs/22.3/lisp/progmodes/verilog-mode.el.gz > /usr/share/emacs/22.3/lisp/progmodes/verilog-mode.elc > > I will instead package verilog-mode separately for fedora for the > following reasons: [snip] I have concerns about this. There are many emacs lisp packages which are both bundled with Emacs and also developed in their own "further upstream" sandbox. Other examples include org-mode, reftex, gnus etc. If we start going down the path of ripping these out of the emacs distribution and replacing them with their more rapidly evolving upstreams we don't benefit from the integration and bug fixing work done in the emacs trunk. This amounts to more work for the Fedora emacs package maintainers when it comes to bugs etc. On the other hand I do see the appeal of newer packages (personally I end up having a local copy of org-mode which is loaded in preference to the emacs bundled one, for example). The origin of this is the emacs development model really, and the lack of a well integrated add-on module mechanism (although Tom Tromey's work on this is great). Personally, I'd rather see us develop a packaging strategy whereby we don't rip out verilog-mode from the core emacs packages, but we can also have an add-on package which contains the latest and greatest verilog-mode which, if installed, is loaded in preference to the one from the core emacs packages. The first response when a bug is reported against verilog-mode would then be " do a yum remove emacs-verilog-mode and see if the bug is still there". I haven't looked too closely at what would be required as far as what is required in terms of load-path munging, but it should be possible I think. Jonathan. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list