Re: RFS: codelite
> 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
> >> 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, 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
Yes, that would be a more fault tolerant approach. However, I do not intend to
take part of teams around any kind of IDE's, at least not for the time being.
> >> 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.
Right on. Since one of them is more mature and with larger user base, it seems
more reasonable to me to invest my reviewing time with it. Furthermore,
CodeBlocks has already been looked at by several parties.
> 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.
I'm afraid we would need the same amount of sponsor's time too to cover both
teams who already spent their own time preparing the packages. If we fail to
meet the former, the latter would be a needless waste of `their own' time...
remember the packages are large and complex, hence the waste would be
> >> 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.
> >>>  ITP: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304570
> >>> (lots of interested users, but nothing yet)
> >>>  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.
> >>  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?
Actually, I don't have a good receipt for finding more reviewers other than
poking -mentors list from time to time. See, that is the tricky part: since
I'm much more familiar and prepared to deal with codeblocks package, I would
need a significant amount of time to get around with codelite (it is not just
to take a look at debian/ directory;-), hence I would think trice what would
be the best course to take before even touch the keyboard ;-) This means that
I'd be very happy if another sponsor takes time to review and hopefully upload
codelite, while I'll take care of codeblocks when packagers enter the scene,
once again. Nonetheless, I promise to take a look at codelite too at some
point, but can't promise to upload.
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>