* Bleeding edge in elpa
@ 2015-03-07 14:36 Nikolai Weibull
2015-03-07 14:47 ` Xavier Maillard
` (5 more replies)
0 siblings, 6 replies; 39+ messages in thread
From: Nikolai Weibull @ 2015-03-07 14:36 UTC (permalink / raw)
To: emacs-orgmode
Hi!
Would it be of interest to anyone else if the bleeding edge version
was available via elpa?
^ permalink raw reply [flat|nested] 39+ messages in thread* Re: Bleeding edge in elpa 2015-03-07 14:36 Bleeding edge in elpa Nikolai Weibull @ 2015-03-07 14:47 ` Xavier Maillard 2015-03-07 16:09 ` Nikolai Weibull 2015-03-07 15:40 ` Grant Rettke ` (4 subsequent siblings) 5 siblings, 1 reply; 39+ messages in thread From: Xavier Maillard @ 2015-03-07 14:47 UTC (permalink / raw) To: Nikolai Weibull; +Cc: emacs-orgmode Hi, Nikolai Weibull <now@disu.se> writes: > Would it be of interest to anyone else if the bleeding edge version > was available via elpa? Isn't it already available via M-x package interface ? I'd rather use git (I really do not like the package stuff). Regards -- Xavier. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-07 14:47 ` Xavier Maillard @ 2015-03-07 16:09 ` Nikolai Weibull 2015-03-08 5:48 ` Xavier Maillard 2015-03-09 9:08 ` Sebastien Vauban 0 siblings, 2 replies; 39+ messages in thread From: Nikolai Weibull @ 2015-03-07 16:09 UTC (permalink / raw) To: Xavier Maillard; +Cc: emacs-orgmode On Sat, Mar 7, 2015 at 3:47 PM, Xavier Maillard <xavier@maillard.im> wrote: > Nikolai Weibull <now@disu.se> writes: >> Would it be of interest to anyone else if the bleeding edge version >> was available via elpa? > Isn't it already available via M-x package interface ? No, only the version based on the maint branch is available via elpa. > I'd rather use > git (I really do not like the package stuff). As Grant pointed out, it’s a lot more convenient working inside Emacs for switching between versions and such. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-07 16:09 ` Nikolai Weibull @ 2015-03-08 5:48 ` Xavier Maillard 2015-03-09 9:08 ` Sebastien Vauban 1 sibling, 0 replies; 39+ messages in thread From: Xavier Maillard @ 2015-03-08 5:48 UTC (permalink / raw) To: Nikolai Weibull; +Cc: emacs-orgmode [-- Attachment #1: Type: text/plain, Size: 686 bytes --] Nikolai Weibull <now@disu.se> writes: > On Sat, Mar 7, 2015 at 3:47 PM, Xavier Maillard <xavier@maillard.im> wrote: > >> Nikolai Weibull <now@disu.se> writes: > >>> Would it be of interest to anyone else if the bleeding edge version >>> was available via elpa? > >> Isn't it already available via M-x package interface ? > > No, only the version based on the maint branch is available via elpa. Ah yes, I see. >> I'd rather use >> git (I really do not like the package stuff). > > As Grant pointed out, it’s a lot more convenient working inside Emacs > for switching between versions and such. I understand but that's not my use case too so... -- Xavier. [-- Attachment #2: Type: application/pgp-signature, Size: 1494 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-07 16:09 ` Nikolai Weibull 2015-03-08 5:48 ` Xavier Maillard @ 2015-03-09 9:08 ` Sebastien Vauban 2015-03-09 16:24 ` T.F. Torrey 1 sibling, 1 reply; 39+ messages in thread From: Sebastien Vauban @ 2015-03-09 9:08 UTC (permalink / raw) To: emacs-orgmode-mXXj517/zsQ Nikolai Weibull wrote: > On Sat, Mar 7, 2015 at 3:47 PM, Xavier Maillard <xavier-U5RQyKqGfor/u5h4R/Qkbg@public.gmane.org> wrote: >> Nikolai Weibull <now-yvQGvizXgks@public.gmane.org> writes: > >>> Would it be of interest to anyone else if the bleeding edge version >>> was available via elpa? > >> Isn't it already available via M-x package interface ? > > No, only the version based on the maint branch is available via elpa. > >> I'd rather use git (I really do not like the package stuff). > > As Grant pointed out, it’s a lot more convenient working inside Emacs > for switching between versions and such. How do you switch between versions in ELPA? IIUC, you only get the latest version, and if that one is not right, you're kind of stuck: you can't reinstall the previous version via the interface. Or maybe I have to learn something new? Best regards, Seb -- Sebastien Vauban ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-09 9:08 ` Sebastien Vauban @ 2015-03-09 16:24 ` T.F. Torrey 0 siblings, 0 replies; 39+ messages in thread From: T.F. Torrey @ 2015-03-09 16:24 UTC (permalink / raw) To: Sebastien Vauban; +Cc: emacs-orgmode Hello, Sebastien Vauban <sva-news@mygooglest.com> writes: >> As Grant pointed out, it’s a lot more convenient working inside Emacs >> for switching between versions and such. > > How do you switch between versions in ELPA? IIUC, you only get the > latest version, and if that one is not right, you're kind of stuck: you > can't reinstall the previous version via the interface. Or maybe I have > to learn something new? Only one version per package name is allowed, so with everything in one archive it won't currently work. However, with smaller archives each holding one version, it becomes possible. For instance, to get the latest package of the main version of Org, enable the Orgmode.org/elpa archive. To go back to the slightly older, perhaps more stable version in the GNU archive, remove the Orgmode.org/elpa archive from your archive configuration, uninstall Org, then reinstall it, and you will get the version from the GNU archive, which will now be the latest one the packages system can find. It's kind of a hack, sure, but until the package system is upgraded to handle dependence on multiple versions of the same package, it works. It would probably be inconvenient to do this for every package, but I don't mind doing it for major packages like Org. HTH, Terry -- T.F. Torrey ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-07 14:36 Bleeding edge in elpa Nikolai Weibull 2015-03-07 14:47 ` Xavier Maillard @ 2015-03-07 15:40 ` Grant Rettke 2015-03-07 21:44 ` T.F. Torrey ` (3 subsequent siblings) 5 siblings, 0 replies; 39+ messages in thread From: Grant Rettke @ 2015-03-07 15:40 UTC (permalink / raw) To: Nikolai Weibull; +Cc: emacs-orgmode@gnu.org Yes because it would allow us to very easily switch between a stable and unstable installation using the built-in package infrastructure. On Sat, Mar 7, 2015 at 8:36 AM, Nikolai Weibull <now@disu.se> wrote: > Hi! > > Would it be of interest to anyone else if the bleeding edge version > was available via elpa? > -- Grant Rettke gcr@wisdomandwonder.com | http://www.wisdomandwonder.com/ “Wisdom begins in wonder.” --Socrates ((λ (x) (x x)) (λ (x) (x x))) “Life has become immeasurably better since I have been forced to stop taking it seriously.” --Thompson ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-07 14:36 Bleeding edge in elpa Nikolai Weibull 2015-03-07 14:47 ` Xavier Maillard 2015-03-07 15:40 ` Grant Rettke @ 2015-03-07 21:44 ` T.F. Torrey 2015-03-08 1:32 ` Nicolas Girard ` (2 subsequent siblings) 5 siblings, 0 replies; 39+ messages in thread From: T.F. Torrey @ 2015-03-07 21:44 UTC (permalink / raw) To: Nikolai Weibull; +Cc: emacs-orgmode Nikolai Weibull <now@disu.se> writes: > Would it be of interest to anyone else if the bleeding edge version > was available via elpa? I would also very much appreciate it. Terry -- T.F. Torrey ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-07 14:36 Bleeding edge in elpa Nikolai Weibull ` (2 preceding siblings ...) 2015-03-07 21:44 ` T.F. Torrey @ 2015-03-08 1:32 ` Nicolas Girard 2015-03-08 14:17 ` Aaron Ecay 2015-03-10 10:51 ` Steinar Bang 5 siblings, 0 replies; 39+ messages in thread From: Nicolas Girard @ 2015-03-08 1:32 UTC (permalink / raw) To: Nikolai Weibull; +Cc: emacs-orgmode 2015-03-07 15:36 GMT+01:00 Nikolai Weibull <now@disu.se>: > > Would it be of interest to anyone else if the bleeding edge version > was available via elpa? > I'd greatly appreciate it too ! Cheers, Nicolas ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-07 14:36 Bleeding edge in elpa Nikolai Weibull ` (3 preceding siblings ...) 2015-03-08 1:32 ` Nicolas Girard @ 2015-03-08 14:17 ` Aaron Ecay 2015-03-08 17:24 ` Nikolai Weibull ` (2 more replies) 2015-03-10 10:51 ` Steinar Bang 5 siblings, 3 replies; 39+ messages in thread From: Aaron Ecay @ 2015-03-08 14:17 UTC (permalink / raw) To: Nikolai Weibull, emacs-orgmode Hi Nikolai, IMO this is a bad idea. The bleeding edge version is expected to be somewhat unstable, and exposing it via ELPA will lead to foot-shooting incidents. On the other hand, it would be nice to have more regular releases from master to maint. AFAIK the last one was a year and a half ago (Org 8.2). However, this has traditionally required a lot of effort from Bastien and others, so it’s not a simple case of “wishing will make it so”. -- Aaron Ecay ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-08 14:17 ` Aaron Ecay @ 2015-03-08 17:24 ` Nikolai Weibull 2015-03-08 17:59 ` Achim Gratz 2015-03-08 18:09 ` T.F. Torrey 2015-08-05 0:00 ` Bastien Guerry 2 siblings, 1 reply; 39+ messages in thread From: Nikolai Weibull @ 2015-03-08 17:24 UTC (permalink / raw) To: Nikolai Weibull, emacs-orgmode On Sun, Mar 8, 2015 at 3:17 PM, Aaron Ecay <aaronecay@gmail.com> wrote: > IMO this is a bad idea. The bleeding edge version is expected to be > somewhat unstable, and exposing it via ELPA will lead to foot-shooting > incidents. Is trying to manage it via git+make oneself less likely to cause incidents? From the FAQ: The master branch of the git repository always contains the bleeding edge development code. This is important for Org's fast development, because code on master gets checked out by many people daily and we quickly receive bug reports if something is wrong. On rare occasions, this code may not function perfectly for a limited time while we are trying to fix things. It is therefore recommended to keep a known-good version of org-mode installed outside the source tree and always run the full test suite before using a new version from master. > On the other hand, it would be nice to have more regular releases from > master to maint. AFAIK the last one was a year and a half ago (Org > 8.2). However, this has traditionally required a lot of effort from > Bastien and others, so it’s not a simple case of “wishing will make it > so”. The more time that passes between releases, the harder it is to release a new version. And as this is the case here, having easy access to the latest “version” would lessen the effect of this. It would also allow more people to find bugs. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-08 17:24 ` Nikolai Weibull @ 2015-03-08 17:59 ` Achim Gratz 2015-03-08 18:34 ` Nikolai Weibull 2015-03-09 7:53 ` T.F. Torrey 0 siblings, 2 replies; 39+ messages in thread From: Achim Gratz @ 2015-03-08 17:59 UTC (permalink / raw) To: emacs-orgmode Nikolai Weibull writes: > Is trying to manage it via git+make oneself less likely to cause > incidents? There's a bunch of people who seem to manage it just fine. > From the FAQ: > > The master branch of the git repository always contains the bleeding > edge development code. This is important for Org's fast development, > because code on master gets checked out by many people daily and we > quickly receive bug reports if something is wrong. On rare occasions, > this code may not function perfectly for a limited time while we are > trying to fix things. It is therefore recommended to keep a known-good > version of org-mode installed outside the source tree and always run > the full test suite before using a new version from master. Yes, if the absolutely latest master doesn't work, people can just check out whatever version was working for them last and continue without waiting for the next snapshot from ELPA /which may or may not work). > The more time that passes between releases, the harder it is to > release a new version. > > And as this is the case here, having easy access to the latest > “version” would lessen the effect of this. It would also allow more > people to find bugs. It doesn't get any easier than it already is. Having both a stable and an unstable version of Org avilable via ELPA is a non-starter for the simple reason that the package manager can't deal with the versioning problems this would introduce. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf rackAttack V1.04R1: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-08 17:59 ` Achim Gratz @ 2015-03-08 18:34 ` Nikolai Weibull 2015-03-08 18:59 ` Rasmus 2015-03-09 7:53 ` T.F. Torrey 1 sibling, 1 reply; 39+ messages in thread From: Nikolai Weibull @ 2015-03-08 18:34 UTC (permalink / raw) To: Achim Gratz; +Cc: emacs-orgmode On Sun, Mar 8, 2015 at 6:59 PM, Achim Gratz <Stromeko@nexgo.de> wrote: > Nikolai Weibull writes: >> Is trying to manage it via git+make oneself less likely to cause >> incidents? > There's a bunch of people who seem to manage it just fine. Did I say otherwise? Does this preclude making an alternative available, one that at least some would consider simpler to access? >> From the FAQ: >> >> The master branch of the git repository always contains the bleeding >> edge development code. This is important for Org's fast development, >> because code on master gets checked out by many people daily and we >> quickly receive bug reports if something is wrong. On rare occasions, >> this code may not function perfectly for a limited time while we are >> trying to fix things. It is therefore recommended to keep a known-good >> version of org-mode installed outside the source tree and always run >> the full test suite before using a new version from master. > Yes, if the absolutely latest master doesn't work, people can just check > out whatever version was working for them last and continue without > waiting for the next snapshot from ELPA /which may or may not work). See below. >> The more time that passes between releases, the harder it is to >> release a new version. >> >> And as this is the case here, having easy access to the latest >> “version” would lessen the effect of this. It would also allow more >> people to find bugs. > It doesn't get any easier than it already is. (How can this statement possibly be true?) > Having both a stable and > an unstable version of Org avilable via ELPA is a non-starter for the > simple reason that the package manager can't deal with the versioning > problems this would introduce. This could, I assume, and was sort of implied in my original e-mail, be solved by providing an “org” package as it is today (based off of maint) and an “org-edge” package that’d be based off of master. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-08 18:34 ` Nikolai Weibull @ 2015-03-08 18:59 ` Rasmus 2015-03-09 6:48 ` T.F. Torrey 0 siblings, 1 reply; 39+ messages in thread From: Rasmus @ 2015-03-08 18:59 UTC (permalink / raw) To: emacs-orgmode Nikolai Weibull <now@disu.se> writes: >> Having both a stable and >> an unstable version of Org avilable via ELPA is a non-starter for the >> simple reason that the package manager can't deal with the versioning >> problems this would introduce. > > This could, I assume, and was sort of implied in my original e-mail, > be solved by providing an “org” package as it is today (based off of > maint) and an “org-edge” package that’d be based off of master. As I think somebody said, the correct "fix" to this problem is more frequent released. I'm sure Bastien would appreciate help with this. Do you want to volunteer? —Rasmus -- One thing that is clear: it's all down hill from here ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-08 18:59 ` Rasmus @ 2015-03-09 6:48 ` T.F. Torrey 2015-03-10 1:57 ` Aaron Ecay 0 siblings, 1 reply; 39+ messages in thread From: T.F. Torrey @ 2015-03-09 6:48 UTC (permalink / raw) To: Rasmus; +Cc: emacs-orgmode Hello, Rasmus <rasmus@gmx.us> writes: > As I think somebody said, the correct "fix" to this problem is more > frequent released. I'm sure Bastien would appreciate help with this. > Do you want to volunteer? If the goal is to have the latest and greatest version of Org available via ELPA (for all the reasons some people use ELPA instead of git), there are two obvious options: 1. Org could have a stable release every month or so. 2. The Org server could be configured to automatically package the master version of Org every day, as the maint version is now. Option 1 is widely regarded as the best choice. However, it requires a lot of actual, repeated human effort. As Debian repeatedly demonstrates, this is very hard to do, even once. If option 1 could be done, it would already be done. Option 2 would be a one-time (mostly) human effort, and the daily work would be automated. So, if the goal is to have the latest and greates version of Org available via ELPA (and it should be), option 2 is the only one that is possible in the real world, so that's the one we should set up. All the best, Terry -- T.F. Torrey ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-09 6:48 ` T.F. Torrey @ 2015-03-10 1:57 ` Aaron Ecay 2015-03-10 21:30 ` T.F. Torrey 0 siblings, 1 reply; 39+ messages in thread From: Aaron Ecay @ 2015-03-10 1:57 UTC (permalink / raw) To: T.F. Torrey; +Cc: emacs-orgmode Hi Terry, 2015ko martxoak 9an, "T.F. Torrey"-ek idatzi zuen: > > Hello, > > Rasmus <rasmus@gmx.us> writes: > >> As I think somebody said, the correct "fix" to this problem is more >> frequent released. I'm sure Bastien would appreciate help with this. >> Do you want to volunteer? > > If the goal is to have the latest and greatest version of Org available via > ELPA (for all the reasons some people use ELPA instead of git), there > are two obvious options: > > 1. Org could have a stable release every month or so. > > 2. The Org server could be configured to automatically package the > master version of Org every day, as the maint version is now. > > Option 1 is widely regarded as the best choice. However, it requires a > lot of actual, repeated human effort. As Debian repeatedly > demonstrates, this is very hard to do, even once. If option 1 could be > done, it would already be done. > > Option 2 would be a one-time (mostly) human effort, and the daily work > would be automated. But what would not be automated is the actual human effort that goes into making a release: writing NEWS and documentation for new features, testing for regressions, generating the emacs Changelog files, merging changes from emacs trunk back into to org code base, merging org code into emacs trunk, ... Someone still has to do all those things eventually. Or not, and the quality of org as a software product suffers. -- Aaron Ecay ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-10 1:57 ` Aaron Ecay @ 2015-03-10 21:30 ` T.F. Torrey 2015-03-11 2:51 ` Aaron Ecay 0 siblings, 1 reply; 39+ messages in thread From: T.F. Torrey @ 2015-03-10 21:30 UTC (permalink / raw) To: Aaron Ecay; +Cc: emacs-orgmode Hello Aaron, Aaron Ecay <aaronecay@gmail.com> writes: >> If the goal is to have the latest and greatest version of Org available via >> ELPA (for all the reasons some people use ELPA instead of git), there >> are two obvious options: >> >> 1. Org could have a stable release every month or so. >> >> 2. The Org server could be configured to automatically package the >> master version of Org every day, as the maint version is now. >> >> Option 1 is widely regarded as the best choice. However, it requires a >> lot of actual, repeated human effort. As Debian repeatedly >> demonstrates, this is very hard to do, even once. If option 1 could be >> done, it would already be done. >> >> Option 2 would be a one-time (mostly) human effort, and the daily work >> would be automated. > > But what would not be automated is the actual human effort that goes into > making a release: writing NEWS and documentation for new features, testing > for regressions, generating the emacs Changelog files, merging changes > from emacs trunk back into to org code base, merging org code into emacs > trunk, ... Someone still has to do all those things eventually. Or not, > and the quality of org as a software product suffers. Refusing to make the git master version available through ELPA doesn't help any of those things get done. It simply denies the latest Org to those unable or afraid of using git. Of the things in your list, I think only the NEWS and Changelog are absent from the master branch in git. Lots of us happily use Org master from git without them every day. Do they really need to be done at all? If Emacs 25 is taking Org out of core, does the code still have to be merged into the trunk? If the manpower does not exist to support both a maint and a master branch, maybe they should be merged. Could that be done? Still just trying to make it easier to spread the gospel of Org, Terry -- T.F. Torrey ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-10 21:30 ` T.F. Torrey @ 2015-03-11 2:51 ` Aaron Ecay 2015-03-11 19:18 ` T.F. Torrey 0 siblings, 1 reply; 39+ messages in thread From: Aaron Ecay @ 2015-03-11 2:51 UTC (permalink / raw) To: T.F. Torrey; +Cc: emacs-orgmode Hi Terry, 2015ko martxoak 10an, "T.F. Torrey"-ek idatzi zuen: > Of the things in your list, I think only the NEWS and Changelog are > absent from the master branch in git. Lots of us happily use Org master > from git without them every day. Do they really need to be done at > all? Many people are very happy not using org at all. Perhaps we should just all quit and find other hobbies. OTOH, release milestones are important to the health of a software project and so yes, really need to be done. > > If Emacs 25 is taking Org out of core, does the code still have to be > merged into the trunk? This is not on the table. Rather, the (tentative) proposal from the emacs side is for some packages to be developed in the GNU ELPA repository, and be extracted from there and bundled with emacs release tarballs (in addition to being released in ELPA). Org is sometimes cited as an example of a package that would benefit from this strategy, but there has been no discussion of this from the org side, and AFAIK no decision has been made whether we’d take advantage of this facility if/when it’s available. > > If the manpower does not exist to support both a maint and a master > branch, maybe they should be merged. Could that be done? > > Still just trying to make it easier to spread the gospel of Org, Exposing new users to the vagaries of the master branch may rather lead to atheism. -- Aaron Ecay ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-11 2:51 ` Aaron Ecay @ 2015-03-11 19:18 ` T.F. Torrey 2015-03-11 19:59 ` Nick Dokos 0 siblings, 1 reply; 39+ messages in thread From: T.F. Torrey @ 2015-03-11 19:18 UTC (permalink / raw) To: Aaron Ecay; +Cc: emacs-orgmode Hello Aaron, Aaron Ecay <aaronecay@gmail.com> writes: > Hi Terry, > > 2015ko martxoak 10an, "T.F. Torrey"-ek idatzi zuen: > >> Of the things in your list, I think only the NEWS and Changelog are >> absent from the master branch in git. Lots of us happily use Org master >> from git without them every day. Do they really need to be done at >> all? > > Many people are very happy not using org at all. Perhaps we should just > all quit and find other hobbies. OTOH, release milestones are important > to the health of a software project and so yes, really need to be done. You seem to be arguing with a point I wasn't making. Release milestones are fine, but the current plan for doing them is too much work for the people involved. Couldn't a simpler way work? >> If Emacs 25 is taking Org out of core, does the code still have to be >> merged into the trunk? > > This is not on the table. Rather, the (tentative) proposal from the > emacs side is for some packages to be developed in the GNU ELPA > repository, and be extracted from there and bundled with emacs release > tarballs (in addition to being released in ELPA). > > Org is sometimes cited as an example of a package that would benefit from > this strategy, but there has been no discussion of this from the org > side, and AFAIK no decision has been made whether we’d take advantage of > this facility if/when it’s available. Interesting. > Exposing new users to the vagaries of the master branch may rather lead > to atheism. This sounds like the foot-shooting argument again. Could one not just as easily harm one's foot with the master version from git? Or is the assumption that only git users are smart enough to wield the power? Maybe Org is so powerful that it should not be released via by ELPA at all, for the sake of everyone's appendages. All the best, Terry -- T.F. Torrey ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-11 19:18 ` T.F. Torrey @ 2015-03-11 19:59 ` Nick Dokos 0 siblings, 0 replies; 39+ messages in thread From: Nick Dokos @ 2015-03-11 19:59 UTC (permalink / raw) To: emacs-orgmode tftorrey@tftorrey.com (T.F. Torrey) writes: > Aaron Ecay <aaronecay@gmail.com> writes: > ... >> Exposing new users to the vagaries of the master branch may rather lead >> to atheism. > > This sounds like the foot-shooting argument again. Could one not just > as easily harm one's foot with the master version from git? Or is the > assumption that only git users are smart enough to wield the power? > Maybe Org is so powerful that it should not be released via by ELPA at > all, for the sake of everyone's appendages. > I took Aaaron's comment to mean that most users would be happier *not* using the master branch (however obtained), relying instead on the maint branch. Nick ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-08 17:59 ` Achim Gratz 2015-03-08 18:34 ` Nikolai Weibull @ 2015-03-09 7:53 ` T.F. Torrey 2015-03-09 18:24 ` Achim Gratz 1 sibling, 1 reply; 39+ messages in thread From: T.F. Torrey @ 2015-03-09 7:53 UTC (permalink / raw) To: Achim Gratz; +Cc: emacs-orgmode Hello, Achim Gratz <Stromeko@nexgo.de> writes: > It doesn't get any easier than it already is. Having both a stable and > an unstable version of Org avilable via ELPA is a non-starter for the > simple reason that the package manager can't deal with the versioning > problems this would introduce. I think this is not only not a "non-starter", I think it is very easy with the existing package manager. The package manager can only handle one version of a package *per archive*, so instead use one archive per version. The current daily builds are here: http://orgmode.org/elpa/ To allow choosing between stable (maint) and unstable (master), put the package archives here instead: Stable: http://orgmode.org/elpa-stable/ Unstable: http://orgmode.org/elpa-unstable/ Then, just add-to-list 'package-archives whichever flavor you want. (And actually, to do away with the current conflict between the org and org-plus-contrib packages, each of those should be in a separate archive as well.) If the next version of Emacs breaks Org out of core into the GNU ELPA package archive, things can be even easier: Keep the stable version in the GNU package archive, and keep the unstable version in the archive on the orgmode.org server. (And personally, I think the "contrib" parts should either be merged into the core or split into separate packages, but that's another can of worms.) All the best, Terry -- T.F. Torrey ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-09 7:53 ` T.F. Torrey @ 2015-03-09 18:24 ` Achim Gratz 2015-03-09 19:21 ` T.F. Torrey 0 siblings, 1 reply; 39+ messages in thread From: Achim Gratz @ 2015-03-09 18:24 UTC (permalink / raw) To: emacs-orgmode T.F. Torrey writes: > The package manager can only handle one version of a package *per > archive*, so instead use one archive per version. The version of package manager that people most likely use today always choses the latest version from _any_ archive available when you update. You can't tell it to consider some archive more authoritative than another or that it should stick with whatever source archive the package was originally installed from. > The current daily builds are here: […] That sort of contorsionist gymnastics defeats the whole point of having a package manager in the first place. If every package would have to do that we'd all end up juggling dozens of archives in our config files. > If the next version of Emacs breaks Org out of core into the GNU ELPA > package archive, things can be even easier: Keep the stable version in > the GNU package archive, and keep the unstable version in the archive on > the orgmode.org server. I wouldn't hold my breath. At the moment that mechanism by which to do that is certainly not in place and there's no agreement on what it should look like. > (And personally, I think the "contrib" parts should either be merged > into the core or split into separate packages, but that's another can of > worms.) if you want to move things into core, clean those files up, create tests and get the copyrights assignmed to the FSF by their authors and propose their inclusion. If you want separate packages, I'm quite certain that this needs further modifications at least to some of the files. The current mode of operation is that they should be compiled together with the rest of Org and no checks are made if they work if installed sepaerately. Some of them likely do, others probably not. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf microQ V2.22R2: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-09 18:24 ` Achim Gratz @ 2015-03-09 19:21 ` T.F. Torrey 2015-03-10 11:01 ` Alexis 0 siblings, 1 reply; 39+ messages in thread From: T.F. Torrey @ 2015-03-09 19:21 UTC (permalink / raw) To: Achim Gratz; +Cc: emacs-orgmode Achim Gratz <Stromeko@nexgo.de> writes: > The version of package manager that people most likely use today always > choses the latest version from _any_ archive available when you update. > You can't tell it to consider some archive more authoritative than > another or that it should stick with whatever source archive the package > was originally installed from. Of course. My explanation was worded poorly, because instead of sleeping I was wasting my time supporting someone else's request to be able to get the latest version of Org via ELPA. >> The current daily builds are here: > […] > > That sort of contorsionist gymnastics defeats the whole point of having > a package manager in the first place. If every package would have to do > that we'd all end up juggling dozens of archives in our config files. The guidance for using Org via ELPA is already to "add the Orgmode.org/elpa archive" (paraphrased). Changing that to "add Orgmode.org/elpa-stable for the stable version or Orgmode.org/elpa-unstable for the bleeding edge version" is suddenly contortionist gymnastics? Really? Compared to using git? >> If the next version of Emacs breaks Org out of core into the GNU ELPA >> package archive, things can be even easier: Keep the stable version in >> the GNU package archive, and keep the unstable version in the archive on >> the orgmode.org server. > > I wouldn't hold my breath. At the moment that mechanism by which to do > that is certainly not in place and there's no agreement on what it > should look like. Agreement or not, something will be done. Already the mechanisms are in place that put the maint version in both locations. The biggest obstacle I to this that I see is that developers tend to hate the package manager and love git. >> (And personally, I think the "contrib" parts should either be merged >> into the core or split into separate packages, but that's another can of >> worms.) > > if you want to move things into core, clean those files up, create tests > and get the copyrights assignmed to the FSF by their authors and propose > their inclusion. > > If you want separate packages, I'm quite certain that this needs further > modifications at least to some of the files. The current mode of > operation is that they should be compiled together with the rest of Org > and no checks are made if they work if installed sepaerately. Some of > them likely do, others probably not. Yes, either choice would be an effort. However, there is currently the problem that some packages depend on org, and others on org-plus-contrib, which cause both to be installed (without some controtionist gymnastics). IMHO, the Org package at Orgmode.org/elpa should either always include contrib, as the git repository does, or split the contrib part into an org-contrib package that depends on org. All the best, Terry -- T.F. Torrey ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-09 19:21 ` T.F. Torrey @ 2015-03-10 11:01 ` Alexis 2015-03-10 15:21 ` Grant Rettke 0 siblings, 1 reply; 39+ messages in thread From: Alexis @ 2015-03-10 11:01 UTC (permalink / raw) To: emacs-orgmode On 2015-03-10T06:21:10+1100, T.F. Torrey <tftorrey@tftorrey.com> said: TFT> The biggest obstacle I to this that I see is that developers tend TFT> to hate the package manager and love git. This developer appreciates both, and thus particularly appreciates MELPA as well. :-) Alexis. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-10 11:01 ` Alexis @ 2015-03-10 15:21 ` Grant Rettke 0 siblings, 0 replies; 39+ messages in thread From: Grant Rettke @ 2015-03-10 15:21 UTC (permalink / raw) To: Alexis; +Cc: emacs-orgmode@gnu.org `package-pinned-packages' seems to allow for user choice here. It is still easy to muck up one's installation, but that is between the user and package.el, not any particular package, I believe. On Tue, Mar 10, 2015 at 6:01 AM, Alexis <flexibeast@gmail.com> wrote: > > On 2015-03-10T06:21:10+1100, T.F. Torrey <tftorrey@tftorrey.com> said: > > TFT> The biggest obstacle I to this that I see is that developers tend TFT> > to hate the package manager and love git. > > This developer appreciates both, and thus particularly appreciates MELPA as > well. :-) > > > Alexis. > -- Grant Rettke gcr@wisdomandwonder.com | http://www.wisdomandwonder.com/ “Wisdom begins in wonder.” --Socrates ((λ (x) (x x)) (λ (x) (x x))) “Life has become immeasurably better since I have been forced to stop taking it seriously.” --Thompson ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-08 14:17 ` Aaron Ecay 2015-03-08 17:24 ` Nikolai Weibull @ 2015-03-08 18:09 ` T.F. Torrey 2015-03-08 19:57 ` Rasmus 2015-08-05 0:00 ` Bastien Guerry 2 siblings, 1 reply; 39+ messages in thread From: T.F. Torrey @ 2015-03-08 18:09 UTC (permalink / raw) To: Aaron Ecay; +Cc: now, emacs-orgmode A major benefit of an ELPA version of the "bleeding edge" version of Org is that it enables those of us who run Emacs and Org on machines where we can not install git (or just do not want to) to have the latest version of Org nonetheless. In a real-world situation, I want to collaborate on Org files with my wife and parents, and I want to use the current best version of Org (which has significant improvements to #+INCLUDE that I use), but I do not want to try to install git on their Windows machines, and I do not want to scare them off by introducing the world of Git in addition to Emacs. And it's not limited to #+INCLUDE. I've been using Org for many years, and no matter how good a release of Org has been, the version in maint has followed right behind with new killer features. Having that version in Elpa makes it easier for me to share the awesome. Aaron Ecay <aaronecay@gmail.com> writes: > IMO this is a bad idea. The bleeding edge version is expected to be > somewhat unstable, and exposing it via ELPA will lead to foot-shooting > incidents. I understand this concern in principle, but it is difficult for me to imagine how it would be validated in actual usage. Serious Org users are already forced to install and run git to use the master version, and whatever the dangers, the practice is almost completely without problems. A "bleeding edge" ELPA would merely make that simpler. I regularly use both the git master version of Org and the ELPA version of Org, and I do extensive elisp coding that interacts with both, and I do not remember a problem that could be described as "foot-shooting". Any significant problems in a bleeding edge version would be resolved the same way they are in the master version of git, only with the solution packaged, delivered, and installed by the next day, except automatically. It is easy to imagine someone else unofficially packaging the bleeding edge version and making it available via ELPA, and hard to imagine that resulting in significant problems. Melpa is loaded with bleeding edge versions, but the problems I hear or see from it are very rare. Also, as noted before, if someone is unhappy with the "bleeding edge" version, switching back would be easy. > On the other hand, it would be nice to have more regular releases from > master to maint. AFAIK the last one was a year and a half ago (Org > 8.2). However, this has traditionally required a lot of effort from > Bastien and others, so it’s not a simple case of “wishing will make it > so”. Very true, and no doubt there are benefits to having a "stable" version available. However, not providing the "bleeding edge" version on ELPA is not without cost. The mailing list is littered with responses from Nicolas saying "that problem has been fixed in the master version ...." One last thought: I think it would be better to name the versions "stable" and "unstable", to match the meanings established by Debian. All the best, Terry -- T.F. Torrey ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-08 18:09 ` T.F. Torrey @ 2015-03-08 19:57 ` Rasmus 2015-03-08 20:20 ` Achim Gratz 2015-03-09 7:31 ` T.F. Torrey 0 siblings, 2 replies; 39+ messages in thread From: Rasmus @ 2015-03-08 19:57 UTC (permalink / raw) To: emacs-orgmode Hi, tftorrey@tftorrey.com (T.F. Torrey) writes: > I want to collaborate on Org files with my wife and parents, ^^^^^^^ Do you? It sounds cool! > In a real-world situation, I want to collaborate on Org files with my > wife and parents, and I want to use the current best version of Org > (which has significant improvements to #+INCLUDE that I use), but I do > not want to try to install git on their Windows machines, I agree. I have the same problem when I build documents (via CI) on a remote Debian server where I don't want to mess around with anything more than what comes with Emacs by default. > Serious Org users are already forced to install and run git to use the > master version, and whatever the dangers, the practice is almost > completely without problems. A "bleeding edge" ELPA would merely make > that simpler. I understand that in Emacs 25 Org, Company, Gnus, CEDET and maybe a couple of other packages will move to GNU ELPA and thus separate release channels (these packages will still be bundled with Emacs). This means we can push out new versions easily, making more frequent releases more attractive. Again, if you want to help out with preparing releases just let the list and Bastien now. —Rasmus -- I feel emotional landscapes they puzzle me ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-08 19:57 ` Rasmus @ 2015-03-08 20:20 ` Achim Gratz 2015-03-08 20:27 ` Rasmus 2015-03-09 8:13 ` T.F. Torrey 2015-03-09 7:31 ` T.F. Torrey 1 sibling, 2 replies; 39+ messages in thread From: Achim Gratz @ 2015-03-08 20:20 UTC (permalink / raw) To: emacs-orgmode Rasmus writes: > I agree. I have the same problem when I build documents (via CI) on a > remote Debian server where I don't want to mess around with anything more > than what comes with Emacs by default. You can use a tarball and the support for manual builds, described in: http://orgmode.org/worg/dev/org-build-system.html#sec-7 > I understand that in Emacs 25 Org, Company, Gnus, CEDET and maybe a couple > of other packages will move to GNU ELPA and thus separate release channels > (these packages will still be bundled with Emacs). This means we can push > out new versions easily, making more frequent releases more > attractive. None of this is going to lift one core limitation of package manager: "there can be only one". It doesn't support packages that subsume other packages, so "org-whatever" is totally different from "org" and would be installed together when referenced by dependencies even though it makes no sense. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-08 20:20 ` Achim Gratz @ 2015-03-08 20:27 ` Rasmus 2015-03-08 20:36 ` Achim Gratz 2015-03-09 8:13 ` T.F. Torrey 1 sibling, 1 reply; 39+ messages in thread From: Rasmus @ 2015-03-08 20:27 UTC (permalink / raw) To: emacs-orgmode Achim Gratz <Stromeko@nexgo.de> writes: > Rasmus writes: >> I agree. I have the same problem when I build documents (via CI) on a >> remote Debian server where I don't want to mess around with anything more >> than what comes with Emacs by default. > > You can use a tarball and the support for manual builds, described in: > http://orgmode.org/worg/dev/org-build-system.html#sec-7 I have no desire to use anything more than what comes with emacs-24-nox on this system. >> I understand that in Emacs 25 Org, Company, Gnus, CEDET and maybe a couple >> of other packages will move to GNU ELPA and thus separate release channels >> (these packages will still be bundled with Emacs). This means we can push >> out new versions easily, making more frequent releases more >> attractive. > > None of this is going to lift one core limitation of package manager: > "there can be only one". It doesn't support packages that subsume other > packages, so "org-whatever" is totally different from "org" and would be > installed together when referenced by dependencies even though it makes > no sense. I'm arguing against "org-whatever" and for less time between Org version N and (1+ N). —Rasmus -- . . . The proofs are technical in nature and provides no real understanding ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-08 20:27 ` Rasmus @ 2015-03-08 20:36 ` Achim Gratz 0 siblings, 0 replies; 39+ messages in thread From: Achim Gratz @ 2015-03-08 20:36 UTC (permalink / raw) To: emacs-orgmode Rasmus writes: >> You can use a tarball and the support for manual builds, described in: >> http://orgmode.org/worg/dev/org-build-system.html#sec-7 > > I have no desire to use anything more than what comes with emacs-24-nox on > this system. You can download any git commit directly from orgmode.org as a tarball (or use the daily snapshot), via Emacs. The rest of the installation doesn't need any outside tools either. To get the tip of master, try for instance: http://orgmode.org/cgit.cgi/org-mode.git/snapshot/org-mode-master.tar.gz Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-08 20:20 ` Achim Gratz 2015-03-08 20:27 ` Rasmus @ 2015-03-09 8:13 ` T.F. Torrey 1 sibling, 0 replies; 39+ messages in thread From: T.F. Torrey @ 2015-03-09 8:13 UTC (permalink / raw) To: Achim Gratz; +Cc: emacs-orgmode Hello again, Achim Gratz <Stromeko@nexgo.de> writes: > Rasmus writes: >> I agree. I have the same problem when I build documents (via CI) on a >> remote Debian server where I don't want to mess around with anything more >> than what comes with Emacs by default. > > You can use a tarball and the support for manual builds, described in: > http://orgmode.org/worg/dev/org-build-system.html#sec-7 I think there is even an existing way to automate the whole process, isn't there? Org is awesome. But still, we were looking for an ELPA solution, not just a different workaround. >> I understand that in Emacs 25 Org, Company, Gnus, CEDET and maybe a couple >> of other packages will move to GNU ELPA and thus separate release channels >> (these packages will still be bundled with Emacs). This means we can push >> out new versions easily, making more frequent releases more >> attractive. > > None of this is going to lift one core limitation of package manager: > "there can be only one". It doesn't support packages that subsume other > packages, so "org-whatever" is totally different from "org" and would be > installed together when referenced by dependencies even though it makes > no sense. I wrote in my other e-mail that the limit is one per archive, but I don't think that's technically true. I think you can actually have as many as you want, even from the same archive, but only the one with the newest date (actually, greatest file name) will be installed. So, to make all the packages that depend on Org use the unstable version rather than the stable version, add-to-list 'package-archives the unstable archive rather than the stable archive. And if you want to keep have both the GNU archive and the Orgmode.org archive in your package-archives, and you want to have the unstable version from Orgmode.org installed instead of the stable version from the GNU archive, no problem: The one in the GNU archive has an older date because the unstable one on the Orgmode.org server gets updates every day, and thus the package manager will select that one to install. IIUC, Terry -- T.F. Torrey ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-08 19:57 ` Rasmus 2015-03-08 20:20 ` Achim Gratz @ 2015-03-09 7:31 ` T.F. Torrey 2015-03-10 2:01 ` Richard Y. Kim 1 sibling, 1 reply; 39+ messages in thread From: T.F. Torrey @ 2015-03-09 7:31 UTC (permalink / raw) To: Rasmus; +Cc: emacs-orgmode Hello again, Rasmus <rasmus@gmx.us> writes: >> I want to collaborate on Org files with my wife and parents, > ^^^^^^^ > > Do you? It sounds cool! It's complicated. I've convinced my parents to begin writing memoir-type books, and my wife works in non-profit, where good books are always good solutions. I push them toward using plain text files for the benefits we all know, and because I can turn the files into epub books, Kindle books, and PDF print books using my custom Org export code. I would love to introduce them to the awesomeness of Org. I think they could work in Emacs, and I'm sure they could handle updating things via ELPA, but I'm also pretty sure that the sight of git would send them screaming all the way back to Microsoft Word. At the same time, I don't want to use or write my custom code for an old version of Org, and the files produced by the maint and master versions of Org are slightly incompatible. So. The current process is for them to use Markdown formatting in their plain-text files. At least these can be converted with a quick script (and Calibre's ebook-convert) to epub, Kindle, and pdf versions. These are okay, but not great. For "final" versions, I will need to convert the Markdown down Org using Pandoc, then do the pretty exports using my Manuscript package. This is not a solution. This is a labor-intensive, error-prone hack. I would so much prefer to get them into Emacs and Org. And I could, if the master version was availble through ELPA. >> In a real-world situation, I want to collaborate on Org files with my >> wife and parents, and I want to use the current best version of Org >> (which has significant improvements to #+INCLUDE that I use), but I do >> not want to try to install git on their Windows machines, > > I agree. I have the same problem when I build documents (via CI) on a > remote Debian server where I don't want to mess around with anything more > than what comes with Emacs by default. This is another great use-case for an ELPA version of the git master. >> Serious Org users are already forced to install and run git to use the >> master version, and whatever the dangers, the practice is almost >> completely without problems. A "bleeding edge" ELPA would merely make >> that simpler. > > I understand that in Emacs 25 Org, Company, Gnus, CEDET and maybe a couple > of other packages will move to GNU ELPA and thus separate release channels > (these packages will still be bundled with Emacs). This means we can push > out new versions easily, making more frequent releases more attractive. > Again, if you want to help out with preparing releases just let the list > and Bastien now. I'm looking forward to this new arrangement (though it will be interesting when, AFAIK, Gnus still doesn't have a workflow through ELPA). However, I don't see how this will make it easier to push out new stable releases. That still has the inherent problem that making something called a "stable" version takes a lot of human effort. I wonder how much effort it would take to copy onto my own machine the scripts on the server that package the git maint version into an ELPA version, and modify them to package master instead. Probably not much. I could host that on my own server, or maybe upload it to Melpa. I think I will look into that. All the best, Terry -- T.F. Torrey ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-09 7:31 ` T.F. Torrey @ 2015-03-10 2:01 ` Richard Y. Kim 2015-03-10 6:29 ` Achim Gratz 2015-03-10 20:20 ` T.F. Torrey 0 siblings, 2 replies; 39+ messages in thread From: Richard Y. Kim @ 2015-03-10 2:01 UTC (permalink / raw) To: T.F. Torrey; +Cc: emacs-orgmode tftorrey@tftorrey.com (T.F. Torrey) writes: > I wonder how much effort it would take to copy onto my own machine the > scripts on the server that package the git maint version into an ELPA > version, and modify them to package master instead. Probably not much. The shell script below is what I use to create my own org-plus-contrib ELPA package. Rather than relying on elpa.gnu.org, melpa.org, orgmode.org/elpa, etc., I've been creating my own packages over the past year or so. This way I know exactly which packages are installed in not only my emacs, but my colleagues who use my packages. So far this has worked out great for me. #!/bin/sh # This script builds org-plus-contrib-YYYYMMDD.tar ELPA package from the git # clone of org-mode. if [ ! -f mk/server.mk ]; then echo "Current directory must be org-mode root directory" exit 1 fi # Where to install the tarballs SERVROOT=$HOME/public_html/elpa/orgmode # server.mk has the elpaplus makefile target echo " include mk/server.mk" >> Makefile make SERVROOT=$SERVROOT elpaplus elpaplus-up # Undo the change made above git checkout Makefile rm -f archive-contents # $SERVROOT/org-plus-contrib-YYYYMMDD.tar # should now be created with today as value of YYYYMMDD. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-10 2:01 ` Richard Y. Kim @ 2015-03-10 6:29 ` Achim Gratz 2015-03-10 21:21 ` T.F. Torrey 2015-03-10 20:20 ` T.F. Torrey 1 sibling, 1 reply; 39+ messages in thread From: Achim Gratz @ 2015-03-10 6:29 UTC (permalink / raw) To: emacs-orgmode Richard Y. Kim writes: > # server.mk has the elpaplus makefile target > echo " include mk/server.mk" >> Makefile […] > # Undo the change made above > git checkout Makefile You know, local.mk was introduced specifically so you wouldn't have to do anything like that. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-10 6:29 ` Achim Gratz @ 2015-03-10 21:21 ` T.F. Torrey 0 siblings, 0 replies; 39+ messages in thread From: T.F. Torrey @ 2015-03-10 21:21 UTC (permalink / raw) To: Achim Gratz; +Cc: emacs-orgmode Achim Gratz <Stromeko@nexgo.de> writes: > Richard Y. Kim writes: >> # server.mk has the elpaplus makefile target >> echo " include mk/server.mk" >> Makefile > […] >> # Undo the change made above >> git checkout Makefile > > You know, local.mk was introduced specifically so you wouldn't have to > do anything like that. I did know that. I remember the massive overhaul of the makefile system (which, IIRC, you masterminded). Unfortunately, I am not a makefile guru, so merely knowing that is not enough. I wish I had fewer dirty hacks in my life, but I'd rather get something done with a dirty hack than not get it done at all. All the best, Terry -- T.F. Torrey ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-10 2:01 ` Richard Y. Kim 2015-03-10 6:29 ` Achim Gratz @ 2015-03-10 20:20 ` T.F. Torrey 1 sibling, 0 replies; 39+ messages in thread From: T.F. Torrey @ 2015-03-10 20:20 UTC (permalink / raw) To: emacs18; +Cc: emacs-orgmode emacs18@gmail.com (Richard Y. Kim) writes: > tftorrey@tftorrey.com (T.F. Torrey) writes: > >> I wonder how much effort it would take to copy onto my own machine the >> scripts on the server that package the git maint version into an ELPA >> version, and modify them to package master instead. Probably not much. > > The shell script below is what I use to create my own org-plus-contrib > ELPA package. > > Rather than relying on elpa.gnu.org, melpa.org, orgmode.org/elpa, etc., > I've been creating my own packages over the past year or so. This way I > know exactly which packages are installed in not only my emacs, but my > colleagues who use my packages. So far this has worked out great for > me. Looks excellent. Thank you! All the best, Terry -- T.F. Torrey ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-08 14:17 ` Aaron Ecay 2015-03-08 17:24 ` Nikolai Weibull 2015-03-08 18:09 ` T.F. Torrey @ 2015-08-05 0:00 ` Bastien Guerry 2 siblings, 0 replies; 39+ messages in thread From: Bastien Guerry @ 2015-08-05 0:00 UTC (permalink / raw) To: Aaron Ecay; +Cc: Nikolai Weibull, emacs-orgmode I believe GNU ELPA should contain the stable release. Of course, this means we need to have a stable release cycle, and we should put efforts into that, obviously. -- Bastien ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-07 14:36 Bleeding edge in elpa Nikolai Weibull ` (4 preceding siblings ...) 2015-03-08 14:17 ` Aaron Ecay @ 2015-03-10 10:51 ` Steinar Bang 2015-03-10 17:11 ` Achim Gratz 5 siblings, 1 reply; 39+ messages in thread From: Steinar Bang @ 2015-03-10 10:51 UTC (permalink / raw) To: emacs-orgmode >>>>> Nikolai Weibull <now@disu.se>: > Would it be of interest to anyone else if the bleeding edge version > was available via elpa? Isn't this what's MELPA is for? http://www.emacswiki.org/emacs/MELPA Ie. GNU ELPA for the official releases and MELPA for git master HEAD. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: Bleeding edge in elpa 2015-03-10 10:51 ` Steinar Bang @ 2015-03-10 17:11 ` Achim Gratz 0 siblings, 0 replies; 39+ messages in thread From: Achim Gratz @ 2015-03-10 17:11 UTC (permalink / raw) To: emacs-orgmode Steinar Bang writes: > Isn't this what's MELPA is for? > http://www.emacswiki.org/emacs/MELPA MELPA is unable to provide a correctly installable package for Org since they just pull down the tree and don't do the necessary build steps. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves ^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, other threads:[~2015-08-05 0:26 UTC | newest] Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-03-07 14:36 Bleeding edge in elpa Nikolai Weibull 2015-03-07 14:47 ` Xavier Maillard 2015-03-07 16:09 ` Nikolai Weibull 2015-03-08 5:48 ` Xavier Maillard 2015-03-09 9:08 ` Sebastien Vauban 2015-03-09 16:24 ` T.F. Torrey 2015-03-07 15:40 ` Grant Rettke 2015-03-07 21:44 ` T.F. Torrey 2015-03-08 1:32 ` Nicolas Girard 2015-03-08 14:17 ` Aaron Ecay 2015-03-08 17:24 ` Nikolai Weibull 2015-03-08 17:59 ` Achim Gratz 2015-03-08 18:34 ` Nikolai Weibull 2015-03-08 18:59 ` Rasmus 2015-03-09 6:48 ` T.F. Torrey 2015-03-10 1:57 ` Aaron Ecay 2015-03-10 21:30 ` T.F. Torrey 2015-03-11 2:51 ` Aaron Ecay 2015-03-11 19:18 ` T.F. Torrey 2015-03-11 19:59 ` Nick Dokos 2015-03-09 7:53 ` T.F. Torrey 2015-03-09 18:24 ` Achim Gratz 2015-03-09 19:21 ` T.F. Torrey 2015-03-10 11:01 ` Alexis 2015-03-10 15:21 ` Grant Rettke 2015-03-08 18:09 ` T.F. Torrey 2015-03-08 19:57 ` Rasmus 2015-03-08 20:20 ` Achim Gratz 2015-03-08 20:27 ` Rasmus 2015-03-08 20:36 ` Achim Gratz 2015-03-09 8:13 ` T.F. Torrey 2015-03-09 7:31 ` T.F. Torrey 2015-03-10 2:01 ` Richard Y. Kim 2015-03-10 6:29 ` Achim Gratz 2015-03-10 21:21 ` T.F. Torrey 2015-03-10 20:20 ` T.F. Torrey 2015-08-05 0:00 ` Bastien Guerry 2015-03-10 10:51 ` Steinar Bang 2015-03-10 17:11 ` Achim Gratz
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).