First, thank you Gabriel, Damien, and others who've been working hard on
improving package quality with each new release of OCaml.
I have the chance to be most of the time a passive user of OCaml, i.e.
we develop a commercial application, and we typically upgrade OCaml only
when it becomes necessary. Also it's normally not a problem for us to
wait for 6 months to a year to upgrade. We have really no complaints
there. I feel however that it's a missed opportunity to contribute back
to the community. We generally don't mind bugs in features that we start
using, but we're really afraid of regression. So it would be good for us
to confidently upgrade OCaml as soon as we know it's unlikely to break
our application, but not delay the upgrade out of fear.
I'm also involved in maintaining a small number of public tools because
I started them. Bugs due to incompatibilities with newer versions of
OCaml have been reported and sometimes fixed by others, and while this
is great, I'd rather (1) not have these bugs in the first place and (2)
fix the bugs before they start affecting users. I must say I really lack
the motivation for such maintenance, compared to developing a new
feature that I need.
What could be useful is a few user-visible stats on what's installable
and what's usable in opam, for a given OCaml version. It's the same idea
as labeling an OCaml/opam distribution as beta, but finer-grained. Each
package known to have version-specific problems would be labeled as
such. A package could be in one of a few states such as: OK, Usable but
has some version-specific bugs, Uninstallable. For the opam user
wondering whether they should upgrade OCaml, it would be useful to get
the percentage of packages in each state for a given OCaml version, as
well as the list of packages in each state and links to the relevant bug
reports. Hopefully this would help users be more adventurous and make
informed decisions on whether to upgrade.
On 06/29/2016 09:40 AM, Gabriel Scherer wrote:
Dear platform,
TL;DR: I propose that we change the OCaml release process to remain in
"beta" stage while there remain OPAM packages that are broken by the new
releases and their version bounds have not been updated.
I'm a bit frustrated with the time it takes for the OCaml ecosystem to
catch up with the 4.03 release -- which has been released two months ago
now, on April 25.
A large chunk of my personal hacking time following the release was
spent on updating Batteries, with a 4.03-compatible release happening on
May 12, so two weeks after the release -- a time I would still consider
too long for our downstream users waiting to try the 4.03 goodness but
held back by a Batteries dependency. I recently helped make atdgen
compatible with 4.03 (it's a dependency of IOCaml for example), and just
today found out that Coq releases (or its CoqIDE part) did not work on
4.03 (with no upper-bound in opam, it would just miscompile).
I find it frustrating because that means that there is a large time
window where we advertise (externally, to beginners, etc.) that the best
OCaml versions ever is 4.03.0, while running opam from this switch to
install any major software whatsoever feels like playing a rigged
russian roulette. I feel bad whenever I'm informed that my software (or
anyone else's, in fact) does not work by end-users that would rather
have spent their day doing something else than trying broken software.
Do you agree that this is a problem? What could we do to fix that?
When I started writing this email I intended to send it to Damien
Doligez, as the release manager of the compiler distribution, with the
following suggestion: maybe we could have a *much longer* beta-testing
period for OCaml versions that would be used not (only) for finding bugs
in the new version, but also to let important pieces of the ecosystem
update to the new version. Say, at least a month. We could have a fixed
set of software that we monitor, or in fact all of what's in OPAM, and
delay the release until they get updated/fixed or their OPAM version
bounds get fixed. (Aha, a Platform indeed!)
Does that sound like a reasonable idea to you? Should we monitor all
OPAM, or only a subset?
This suggestion is rooted in the idea that when we announce the release
to our end-users, stuff should just work -- or refuse to install itself.
Maybe this is an old idea of the SVN times and we're now in the era of
continuously-released, always-broken stuff?
Finally, there has been all this work on the "OPAM weather services",
continuous build of opam packages etc., plus the work that Damien is
doing around release time. It doesn't seem to have worked very well for
4.03. Who is monitoring this stuff? Do we need to fix them to make them
work better, or to fix our process to use them better? To be honest, I'm
never looking at these services -- I just don't think of using them. Can
I get an email whenever they detect that my stuff is broken? Say I'm a
new package manager, are there guidelines somewhere on what the best
practices are and what I should do?
_______________________________________________
Platform mailing list
[email protected]
http://lists.ocaml.org/listinfo/platform
_______________________________________________
Platform mailing list
[email protected]
http://lists.ocaml.org/listinfo/platform
