From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: org-export raises stringp nil error Date: Sat, 09 Mar 2013 11:01:33 +0200 Message-ID: <83haklx7yq.fsf@gnu.org> References: <87ip539io1.fsf@nautilus.nautilus> <87zjye96ph.fsf@bzg.ath.cx> <87vc928kcm.fsf@bzg.ath.cx> <83sj46z468.fsf@gnu.org> <87txomz1j7.fsf@yandex.ru> <83li9yyyul.fsf@gnu.org> <87li9xu9y5.fsf@Rainer.invalid> <83zjydy8ny.fsf@gnu.org> <87vc91slfj.fsf@Rainer.invalid> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1362819723 848 80.91.229.3 (9 Mar 2013 09:02:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 9 Mar 2013 09:02:03 +0000 (UTC) Cc: emacs-devel@gnu.org To: Achim Gratz Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 09 10:02:27 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UEFfe-0000J9-At for ged-emacs-devel@m.gmane.org; Sat, 09 Mar 2013 10:02:26 +0100 Original-Received: from localhost ([::1]:56769 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UEFfH-0005qf-NC for ged-emacs-devel@m.gmane.org; Sat, 09 Mar 2013 04:02:03 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:32798) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UEFf9-0005qW-Io for emacs-devel@gnu.org; Sat, 09 Mar 2013 04:02:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UEFf4-00041v-IX for emacs-devel@gnu.org; Sat, 09 Mar 2013 04:01:55 -0500 Original-Received: from mtaout23.012.net.il ([80.179.55.175]:58155) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UEFf4-00041f-2u for emacs-devel@gnu.org; Sat, 09 Mar 2013 04:01:50 -0500 Original-Received: from conversion-daemon.a-mtaout23.012.net.il by a-mtaout23.012.net.il (HyperSendmail v2007.08) id <0MJD00L00YANJG00@a-mtaout23.012.net.il> for emacs-devel@gnu.org; Sat, 09 Mar 2013 11:01:46 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout23.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0MJD00LK2YEYJN00@a-mtaout23.012.net.il>; Sat, 09 Mar 2013 11:01:46 +0200 (IST) In-reply-to: <87vc91slfj.fsf@Rainer.invalid> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.175 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:157650 Archived-At: > From: Achim Gratz > Date: Fri, 08 Mar 2013 21:09:36 +0100 >=20 > Eli Zaretskii writes: > >> In any case, doing the built-in packages this way (or something = similar) > >> takes a lot of unecessary churn and merges out of the release pr= ocess > >> and I would think that would be a clear advantage to everyone in= volved. > > > > I see that we have come a full circle, what with all this new blo= od > > pouring into Emacs development, and we are finally ready to repea= t the > > failed experiment with dividing Emacs into "core" and "all the re= st". >=20 > Please enlighten me as to what this experiment was and when it happ= ened > so I can read up on it. This is a sincere request, I have no desir= e to > repeat a past mistake. I meant XEmacs. I'll ask Stephen to describe that and suggest any conclusions from that experience, including those which contradict my personal conclusions. > Note that I haven't said anything about what is core and what is no= t, > that issue is orthogonal to how Emacs' structures its software > repositories. Off the cuff I'd say we'd end up with roughly the sa= me > set of "core" packages than today, then grow from there. I don't understand what that means. There's no "core" packages today= , the entire Emacs repository is handled as one monolith piece of software. The fact that some parts of it are copies of upstream repositories maintained by others elsewhere is not relevant to the issues I have with separating them from Emacs. > What I am talking about is reducing the interdependencies between > projects on wildly different release schedules for the purpose of m= aking > the integration easier. That requires effort on both sides, but I = posit > that there is a net gain =E2=80=94 if there is agreement on how to = do this and > an easily followed set of rules that describes the procedures. Your optimism in this matter is enviable, but my gray hair doesn't le= t me share it. I don't believe in any net gain here. I don't know why is that so, perhaps because complexity tends to disrupt any hope of reaching an "agreement on how to do this" and having "an easily followed set of rules that describes the procedures". Heck, we couldn't even agree on the VCS to use, remember? > > Good luck (you will need it)! >=20 > This is engineering, not gaming (although I wouldn't mind a bit of = luck > once in a while). If you don't believe in luck in software engineering, just stick around for a while.