Project

General

Profile

Task #1943

make sure releases are submitted early for Debian Experimental

Added by Szilárd Páll over 3 years ago. Updated 11 months ago.

Status:
Accepted
Priority:
Low
Category:
testing
Target version:
Difficulty:
uncategorized
Close

Description

Debian has very impressive hardware arch coverage in their package auto-building setup:
https://buildd.debian.org/status/package.php?p=gromacs&suite=unstable

We should make sure to submit releases early, i.e. starting from PR/beta to get the benefit of having them tested on the wide range of platforms.

How/what needs to be done:
  • ping a dev/maintainer to do the packaging which give a chance to get early feedback on what the distro may need for a smoother packaging
  • have the maintainer upload the package to Debian Experimental
  • benefit
TODOs:
  • make sure Debian enables make check in buildd
  • consider pulling in the regressiotests;

History

#1 Updated by Szilárd Páll over 3 years ago

  • Category set to testing
  • Assignee set to Szilárd Páll
  • Target version set to 2016

#2 Updated by Erik Lindahl over 3 years ago

  • Priority changed from Normal to Low
  • Target version changed from 2016 to future

While this is a good idea in principle, all these ideas will require somebody to spend time and effort on it, and prioritize that over other things. Unfortunately those resources don't magically appear just because we add it to redmine, so since none of us is prioritizing this higher than the other stuff we're doing it definitely won't happen for the 2016 release.

#3 Updated by Szilárd Páll over 3 years ago

As #1986, #1987, #1988 exemplifies well, this is a good idea in practice too not just in principle. The issue is practically WIP without anyone having been forced to prioritize it or do extra work. In fact, the debian maintainer filed well documented bug reports.

Hence, diverting the change from the current release is unnecessary; I set the target quite intentionally and intended to follow up on it.

I am trying to use redmine as a project management tool to track tasks in a cetralized manner, but if that not wanted, I can use a separate tool, I'm just not certain what's the benefit of that.

So in summary:
  • test builds with make check have been executed (see here)
  • most relevant failing tests with 5.1.3: all PPC in double, x32 tests segv,
  • failing tests with 2016-beta2: see #1987 (in particular ARM), PPC/Power (see #1988 -- a big endian issue?);

#4 Updated by Szilárd Páll over 2 years ago

I think we can close this, but I'd like to highlight examples of concrete benefits brought by working with the community:
- we had no Power8 access last summer/fall and feedback from these builds highlighted issues early;
- the help of the Debian maintainer allowed us to get the buggy 2016.2 quickly upgraded to 2016.3 before Ubuntu 17.04 was released; all it took was a brief mail and within 24 hours the brand new release was packaged and tested;
- we had no regular testing on exotic arch to harden portability, but the Debian infrastructure has had most of our betas and every single release built and tested.

The value of just the above outweighs the small cost of a couple of emails exchanged. With a full year to reflect and concrete examples of clear impact, it's fair to say that shelving this issue changing the target to the dummy "future" was unnecessary.

#5 Updated by Szilárd Páll over 2 years ago

  • Status changed from New to Resolved
  • Target version changed from future to 2018

#6 Updated by Mark Abraham over 2 years ago

Szilárd Páll wrote:

I think we can close this, but I'd like to highlight examples of concrete benefits brought by working with the community:
- we had no Power8 access last summer/fall and feedback from these builds highlighted issues early;
- the help of the Debian maintainer allowed us to get the buggy 2016.2 quickly upgraded to 2016.3 before Ubuntu 17.04 was released; all it took was a brief mail and within 24 hours the brand new release was packaged and tested;
- we had no regular testing on exotic arch to harden portability, but the Debian infrastructure has had most of our betas and every single release built and tested.

Indeed, these were valuable outcomes, but e.g. we also spent expensive resources discussing #1939.

A recurring task for each e.g. major release to ping DebiChem and equivalent Fedora people to please test the beta would be valuable.

The value of just the above outweighs the small cost of a couple of emails exchanged. With a full year to reflect and concrete examples of clear impact, it's fair to say that shelving this issue changing the target to the dummy "future" was unnecessary.

Agreed re: future, and the use of Redmine as a more general project management tool. Erik should have noted that you'd stated the benefits and assigned it to yourself, and suggested that we postpone to 2017.

Note that teammates are more appreciative of new ideas when a target date is further away. Each new thing proposed or done takes time away from doing the set of things already agreed, which creates pressure on the team, the quality or the release date.

#7 Updated by Mark Abraham almost 2 years ago

I've enquired on the debichem-dev list to see if there's anything they want help on to get this started for 2018-beta2

#8 Updated by Mark Abraham almost 2 years ago

Mark Abraham wrote:

I've enquired on the debichem-dev list to see if there's anything they want help on to get this started for 2018-beta2

Things will happen, hopefully this week.

#10 Updated by Mark Abraham almost 2 years ago

  • Target version changed from 2018 to 2019

Testing from both Fedora and DebiChem has been useful for finding portability issues.

#11 Updated by Mark Abraham over 1 year ago

  • Status changed from Resolved to Accepted

#12 Updated by Mark Abraham 12 months ago

Szilard has asked DebiChem, and I have seen some automated emails from them

#13 Updated by Szilárd Páll 12 months ago

Mark Abraham wrote:

Szilard has asked DebiChem, and I have seen some automated emails from them

Yes, I've been in touch with the maintainer; beta2 had issues, but beta3 is fine (other than expected failures): https://buildd.debian.org/status/package.php?p=gromacs&suite=experimental

#14 Updated by Paul Bauer 11 months ago

I think we should keep this for future versions, but I would bump it to 2020 then

#15 Updated by Paul Bauer 11 months ago

  • Target version changed from 2019 to 2020

Also available in: Atom PDF