[AUCTeX] Preparing new AUCTeX version and comments about more frequent releases

[Mosè Giordano]

Dear all,

the latest stable release of AUCTeX doesn't include the fix for the
parsing of TeX Live 2017 logs (see
https://lists.gnu.org/archive/html/auctex/2017-04/msg00007.html), so
now that TeX Live 2017 has been release it's a good idea to release
AUCTeX 11.91. Is there any other quick change that you would like to
see into this version?

In addition, Norbert Preining expressed[1] the wish to see more
synchronization between ELPA releases and stable releases, because
GNU/Linux distributions rely on the latter, which however often lag
behind ELPA versions. As I explained to him on TeX.se, it's a general
trend in the Emacs ecosystem to favor ELPA to install and update
packages. In addition, AUCTeX used to have a very awkward method of
installation on Windows that was even more awkward for upgrades, on
this system ELPA very easily solves our problems.

I'd like to cooperate as much as possible with downstream
distributors, but I'm not sure about what's the best way to do it:

* start tagging and releasing bug-fix versions also in the main
repository (not only in ELPA)?
* continue to not tagging bug-fix versions but do more frequent stable releases?
* other options?

Bye,
Mosè


Notes
[1] https://tex.stackexchange.com/questions/368408/auctex-says-latex-problems-after-1-page/368424?noredirect=1#comment945029_368424

[Tamas Papp]

Post by Mosè Giordano
I'd like to cooperate as much as possible with downstream
* start tagging and releasing bug-fix versions also in the main
repository (not only in ELPA)?
* continue to not tagging bug-fix versions but do more frequent stable releases?
* other options?

Given that ELPA is very easy to set up and use, I would prefer the
choice that minimizes developer effort, so you and other developers have
time for important stuff and nifty new features.

I am puzzled why distributions consider it necessary to package a subset
of ELPA (unless there is a compelling reason to do so, eg because of
binary dependencies, but that is rare). It is wasted effort for all
participants.

best,

Tamas

[Ken Brown]

Post by Tamas Papp

Post by Mosè Giordano
I'd like to cooperate as much as possible with downstream
* start tagging and releasing bug-fix versions also in the main
repository (not only in ELPA)?
* continue to not tagging bug-fix versions but do more frequent stable releases?
* other options?

Given that ELPA is very easy to set up and use, I would prefer the
choice that minimizes developer effort, so you and other developers have
time for important stuff and nifty new features.
I am puzzled why distributions consider it necessary to package a subset
of ELPA (unless there is a compelling reason to do so, eg because of
binary dependencies, but that is rare). It is wasted effort for all
participants.

Distributions have been packaging AUCTeX since long before AUCTeX was
part of ELPA. To suddenly stop packaging it now would lead to
unnecessary confusion for users. I think it's fine if ELPA releases
happen more often than stable releases, but there should be stable
releases whenever there is a major change or bug fix, as is the case now.

Ken

[Norbert Preining]

Hi Mosè

Post by Mosè Giordano
AUCTeX 11.91. Is there any other quick change that you would like to
see into this version?

Not from my side.

Post by Mosè Giordano
In addition, Norbert Preining expressed[1] the wish to see more
synchronization between ELPA releases and stable releases, because

Not necessarily! I leave this to the maintainer to decide what they want
to release with tarballs etc.

The only thing I ask for is please do not switch to ELPA releases only,
but do proper releases at times.

Post by Mosè Giordano
I'd like to cooperate as much as possible with downstream
* start tagging and releasing bug-fix versions also in the main
repository (not only in ELPA)?

That would be nice indeed. Also for the history. Having a tag
elpa_11.90.2
or similar in the git repo would allow those who want to to build from
elpa releases, too.

Post by Mosè Giordano
* other options?

Another option would be of course to only do ELPA and stop doing
normal releases. That would of course create quite some work for
distributors because they would have to switch to ELPA packaging,
but recently at least in Debian packages made from ELPA are increasing,
and AFAIR tools for elpa packaging are available.

Again, all this is from a my POV! I am *not* the Debian developer
of AucTeX, but the one of TeX Live, but have worked with the
Debian developer at times. So finally it is the decision of the
auctex maintainer what to do with auctex in Debian, not mine ;-)

All the best

Norbert

--
PREINING Norbert http://www.preining.info
Accelia Inc. + JAIST + TeX Live + Debian Developer
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

[Mosè Giordano]

Hi Norbert,

first of all, thanks for raising the issue of the important bugfix
missing in a stable release. Lately the development of AUCTeX slowed
down and rolling a new release went outside my radar.

Post by Norbert Preining
Hi Mosè

Post by Mosè Giordano
In addition, Norbert Preining expressed[1] the wish to see more
synchronization between ELPA releases and stable releases, because

Not necessarily! I leave this to the maintainer to decide what they want
to release with tarballs etc.
The only thing I ask for is please do not switch to ELPA releases only,
but do proper releases at times.

Post by Mosè Giordano
I'd like to cooperate as much as possible with downstream
* start tagging and releasing bug-fix versions also in the main
repository (not only in ELPA)?

That would be nice indeed. Also for the history. Having a tag
elpa_11.90.2
or similar in the git repo would allow those who want to to build from
elpa releases, too.

Ok, that's an option we can definitely consider and it's probably the
solution with less grief.

Post by Norbert Preining

Post by Mosè Giordano
* other options?

Another option would be of course to only do ELPA and stop doing
normal releases.

Well, this would be by far the best solution for us. Tagging a commit
is very easy, preparing a tarball requires more work because from
version to version there is something to adjust, especially in the
Windows tarball, which is no more distributed, luckily.

Post by Norbert Preining
That would of course create quite some work for
distributors because they would have to switch to ELPA packaging,
but recently at least in Debian packages made from ELPA are increasing,
and AFAIR tools for elpa packaging are available.

Hopefully, this would be a one-time work.

Post by Norbert Preining
Again, all this is from a my POV! I am *not* the Debian developer
of AucTeX, but the one of TeX Live, but have worked with the
Debian developer at times. So finally it is the decision of the
auctex maintainer what to do with auctex in Debian, not mine ;-)

We have the Debian maintainer reading us :-) Davide, do you think
you'd be able in the future to prepare the Debian package from a git
tag or an ELPA package?

Anyway, I don't want to take a decision right now, this won't affect
release of AUCTeX 11.91 which I'll do in the next few days, after
Keita applies his patch.

Bye,
Mosè

[Davide G. M. Salvetti]

MG == Mosè Giordano [2017-7-21]

[...]

MG> We have the Debian maintainer reading us :-) Davide, do you think
MG> you'd be able in the future to prepare the Debian package from a git
MG> tag or an ELPA package?

Hi everybody,

in the long run I could use both, but ATM the most straightforward way
for me would be to package from a git tag, especially if I could use
git archive to get a orig.tar.gz.

Apart from packaging, I think that AUCTeX users would benefit from
having clearly marked stable releases. What about using some branching
git workflow like using the master branch to track stable releases and a
next branch to develop new features until they are deemed stable enough
to be included in master?

P.S. I'll be very busy for a week or so starting from tomorrow,
therefore I might not be able to comment on this thread until then.

[Mosè Giordano]

Hi Davide,

Post by Davide G. M. Salvetti

MG == Mosè Giordano [2017-7-21]

[...]
MG> We have the Debian maintainer reading us :-) Davide, do you think
MG> you'd be able in the future to prepare the Debian package from a git
MG> tag or an ELPA package?
Hi everybody,
in the long run I could use both, but ATM the most straightforward way
for me would be to package from a git tag, especially if I could use
git archive to get a orig.tar.gz.
Apart from packaging, I think that AUCTeX users would benefit from
having clearly marked stable releases. What about using some branching
git workflow like using the master branch to track stable releases and a
next branch to develop new features until they are deemed stable enough
to be included in master?

I'm not sure this workflow would work for a program with few people
using the git version. I guess this is the case for AUCTeX, but I
don't numbers to back up this assumption.

Ok, we'll return on this topic later.

Bye,
Mosè

[Norbert Preining]

Hi both of you,

Post by Mosè Giordano

Post by Davide G. M. Salvetti
in the long run I could use both, but ATM the most straightforward way
for me would be to package from a git tag, especially if I could use
git archive to get a orig.tar.gz.

In this case, both the current stable release tags, as well as the
hopefully to be done elpa release tags can be used. I agree that
this would be good.

Post by Mosè Giordano

Post by Davide G. M. Salvetti
Apart from packaging, I think that AUCTeX users would benefit from
having clearly marked stable releases. What about using some branching

Well, I think this is what is happening by now, with release balls and
tags in git. It is more about the additional releases to elpa and how
they are reflected into stable releases, or whatever stable releases
will be.

Post by Mosè Giordano

Post by Davide G. M. Salvetti
git workflow like using the master branch to track stable releases and a
next branch to develop new features until they are deemed stable enough
to be included in master?

I'm not sure this workflow would work for a program with few people

Here I agree with Mose, I am doing most TeX packaging practically alone,
and I prefer one master that has all the development, and branches
for stable and oldstable.

Combining what you two said, it seems that the easiest way forward for
you (upstream) and not too disturbing for downstream to stop doing
whatever "tarball releases" you are doing, and we consider the
elpa releases as "the releases" which are properly tagged in git, and
people can build from there, or get the tarballs from the elpa
repository.

WDYT?

Norbert

--
PREINING Norbert http://www.preining.info
Accelia Inc. + JAIST + TeX Live + Debian Developer
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

[Davide G. M. Salvetti]

Post by Davide G. M. Salvetti

NP == Norbert Preining [2017-7-22]

NP> Combining what you two said, it seems that the easiest way forward for
NP> you (upstream) and not too disturbing for downstream to stop doing
NP> whatever "tarball releases" you are doing, and we consider the
NP> elpa releases as "the releases" which are properly tagged in git, and
NP> people can build from there, or get the tarballs from the elpa
NP> repository.

I've released Debian auctex 11.91-1 based on the AUCTeX release_11_91
Savannah tag. As far as Debian packaging is concerned tarball releases
are no more necessary. @Mosè: I'd suggest you to sign future release
tags with the same key you are using to sign the tarballs.

NP> In this case, both the current stable release tags, as well as the
NP> hopefully to be done elpa release tags can be used. I agree that
NP> this would be good.

Post by Davide G. M. Salvetti
Apart from packaging, I think that AUCTeX users would benefit from
having clearly marked stable releases.

NP> Well, I think this is what is happening by now, with release balls and
NP> tags in git. It is more about the additional releases to elpa and how
NP> they are reflected into stable releases, or whatever stable releases
NP> will be.

Yes, I agree. ATM I do not understand if elpa releases should be
considered stable releases. I tend to think of them as bleeding edge
releases, maybe suitable for Debian experimental, but unsuitable for the
unstable->testing->stable cycle. WDYT?

[Ikumi Keita]

Hi all,

Post by Mosè Giordano
Dear all,
the latest stable release of AUCTeX doesn't include the fix for the
parsing of TeX Live 2017 logs (see
https://lists.gnu.org/archive/html/auctex/2017-04/msg00007.html), so
now that TeX Live 2017 has been release it's a good idea to release
AUCTeX 11.91. Is there any other quick change that you would like to
see into this version?

Attached is a patch to make AUCTeX conform to elisp coding conventions,
quoted below from emacs lisp reference. (This issue is not in hurry at
all, so I don't mind whether it gets into 11.91 release or not.)

* When you mention a default value in a minibuffer prompt, put it and
the word `default' inside parentheses. It should look like this:

Enter the answer (default 42):

* Many commands that take a long time to execute display a message
that says something like `Operating...' when they start, and change
it to `Operating...done' when they finish. Please keep the style
of these messages uniform: _no_ space around the ellipsis, and _no_
period after `done'. *Note Progress::, for an easy way to generate
such messages.

[Mosè Giordano]

Hi Keita,

Post by Ikumi Keita
Hi all,

Post by Mosè Giordano
Dear all,
the latest stable release of AUCTeX doesn't include the fix for the
parsing of TeX Live 2017 logs (see
https://lists.gnu.org/archive/html/auctex/2017-04/msg00007.html), so
now that TeX Live 2017 has been release it's a good idea to release
AUCTeX 11.91. Is there any other quick change that you would like to
see into this version?

Attached is a patch to make AUCTeX conform to elisp coding conventions,
quoted below from emacs lisp reference. (This issue is not in hurry at
all, so I don't mind whether it gets into 11.91 release or not.)
* When you mention a default value in a minibuffer prompt, put it and
* Many commands that take a long time to execute display a message
that says something like `Operating...' when they start, and change
it to `Operating...done' when they finish. Please keep the style
of these messages uniform: _no_ space around the ellipsis, and _no_
period after `done'. *Note Progress::, for an easy way to generate
such messages.

Looks good, and they're also only stylistic changes, so should be safe
to include them right now. Go ahead and install the patch ;-)

Thanks,
Mosè

[Ikumi Keita]

Post by Mosè Giordano
Hi Keita,
Looks good, and they're also only stylistic changes, so should be safe
to include them right now. Go ahead and install the patch ;-)

Done. This is my first time to use `prog2' in a meaningful way :-)

Bye,
Ikumi Keita