Hi George, On Monday 17,August,2009 02:42 AM, George Danchev wrote: > [...] >> I actually use a series of IDEs/editors hopping from one to another >> depending on my mood or purpose: emacs, geany, codelite. > > That is something I don't really understand, if not done for fun of course ;-) > Overwhelmed developers usually do not change their tools lightly. Let's put it > that way: how is codelite better than geany wrt your goals (I don't really buy > the `mood' argument;-), we are looking for significant differences here? Simply put, CodeLite's more of a project-based IDE, whereas Geany tends more towards a text editor. For individual files, or if I'm lazy to set up a CodeLite project, I use Geany. If I'm in a terminal, I use emacs or vim. >> I'm not >> actually familiar with Code::Blocks, but I do feel that it would be nice > > Roughly Code::Blocks resembles MSVC face and look, and in my humble opinion > intentionally targets that user base. Nothing wrong with that of course. > >> to have all of them in Debian (and Ubuntu) to provide more choice to the >> end-user. There are bound to be those not satisfied with Code::Blocks >> and love CodeLite[1], and vice versa. > > I'm afraid that if we go that way, we could flood the Debian archive even more > with lots of large and hard to maintain packages which tend to be neglected in > not so distant future. Perhaps a team should be started up to maintain different IDEs' packages then? I'm sure that would help avoid a situation where the packages are neglected. > >> Picking one would probably create >> unnecessary hostility between the two IDEs' communities. > > ... or instead of provoking hostility this could help competition between > these alternatives. I really do like competition and multiple alternatives to > choose from, however these packages are large and complex and would probably > consume a lot of maintainers time while fighting the bug log, therefore I see > nothing wrong to apply Occam razor when selecting amongst such expensive > alternatives, maintenance-wise. I understand your point about the maintainers' time, but I don't really agree with your whole idea of this helping competition. Choosing only one to enter the archives would necessarily mean omitting the other. Rather, if we can find one person who's interested in CodeLite, and another interested in Code::Blocks, why not allow them to maintain their own packages independently (or collaboratively maintain both) rather than alienating one in favour of the other? It's their own time and effort they're investing after all. > >> By the way, I am the Ubuntu maintainer for CodeLite. I got it into >> Ubuntu via Revu during my early days of packaging (it was my first from >> scratch) before someone (Iain Lane iirc) convinced me that it's better >> to get packages into Debian and let them be synced into Ubuntu. >> >>> [1] ITP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304570 >>> (lots of interested users, but nothing yet) >>> [2] Jen Lody's unofficial packages, I saw some of my colleagues to use >>> happily: http://apt.jenslody.de/ >>> >>> P.S. and yes, I'm not a fan Eclipse CDT nor I have any feeling with MSVC >>> though I use it daily. >> >> [1] http://krnjevic.com/wp/?p=96 > > That is a very good summary, indeed, but for the time being I saw much more > users of codeblocks. This is not that I'm against codelite, it is just that > I'm looking hard for a good way to invest the effort, maintenance-wise. Code::Blocks would be the more mature project of the lot, considering CodeLite started off from a Code::Blocks plugin. Naturally there would be more Code::Blocks users compared to CodeLite users. > >> P.S. If/When you do review the rest of the package, please note that the >> get-orig-source rule is currently failing miserably due to the whole >> sf.net uscan breakage. You'll have to download the tarball first, rename >> it to codelite_<VERSION>.orig.tar.gz and then use this: >> >> debian/rules get-orig-source VERSION=<VERSION> USCAN=echo >> (Overriding USCAN=echo is to disable all invocations of uscan) >> >> Also, if you upload this package, please use the tarball I've uploaded >> into mentors.debian.net, as that's the same one that's used in Ubuntu's >> CodeLite package. If you regenerate the dfsg tarball and use that >> instead, there will be tarball mismatch issues. > > Sure, that is fine. Let's see when I can find some time to look at it more > closely. Meanwhile, engaging more reviewers would be very nice, in fact. Does that mean I should keep firing off RFS emails at intervals to look for reviewers? -- Kind regards, Chow Loong Jin
Attachment:
signature.asc
Description: OpenPGP digital signature