32 bits releases: in or out

[Otto van der Schaaf <os...@we-amp.com>]

Hi all,

I'm working on producing artifacts for a first incubator release candidate,
and I am reminded by the process that producing 32 bits artifacts takes a
lot
of time and effort compared to the 64 bits ones (about 90:10 this time).

The release process for 32 bits keeps breaking on all kinds of things.
Getting to the 64 bits artifacts has consistently been a much nicer
experience.

We are not testing 32 bits in CI.  And I suspect that demand for 32 bits
releases
is pretty small. (and if someone really wants it: building from source on
an actual 32 bits
system is a fairly smooth process).

So I wonder: should we stop releasing for 32-bits systems?
Any thoughts?

Otto

Re: 32 bits releases: in or out

[Joshua Marantz <jm...@google.com.INVALID>]

+1 -- let's stop releasing binaries for 32-bit systems and see if any
issues arise.


On Sun, Dec 2, 2018 at 2:46 PM Otto van der Schaaf <os...@we-amp.com>
wrote:

> Hi all,
>
> I'm working on producing artifacts for a first incubator release candidate,
> and I am reminded by the process that producing 32 bits artifacts takes a
> lot
> of time and effort compared to the 64 bits ones (about 90:10 this time).
>
> The release process for 32 bits keeps breaking on all kinds of things.
> Getting to the 64 bits artifacts has consistently been a much nicer
> experience.
>
> We are not testing 32 bits in CI.  And I suspect that demand for 32 bits
> releases
> is pretty small. (and if someone really wants it: building from source on
> an actual 32 bits
> system is a fairly smooth process).
>
> So I wonder: should we stop releasing for 32-bits systems?
> Any thoughts?
>
> Otto
>

Re: 32 bits releases: in or out

[Otto van der Schaaf <os...@we-amp.com>]

Well, next to a source tarball, .rpm and .deb packages are products of the
currently documented
release process; I stashed my work on a potential first RC here which has
the 64 bits versions:
https://www.modpagespeed.com/release_archive/1.14.36.1-incubator-RC0/

I'll continue following the release process later this week, after doing
some further manual sanity
checks on the source tarball.

Otto


On Mon, Dec 3, 2018 at 3:17 AM Nick Kew <ni...@apache.org> wrote:

>
> > On 2 Dec 2018, at 19:45, Otto van der Schaaf <os...@we-amp.com> wrote:
> >
> > Hi all,
> >
> > I'm working on producing artifacts for a first incubator release
> candidate,
> > and I am reminded by the process that producing 32 bits artifacts takes a
> > lot
> > of time and effort compared to the 64 bits ones (about 90:10 this time).
>
> Is there something 64-bit-specific about the code?
>
> >  (and if someone really wants it: building from source on
> > an actual 32 bits
> > system is a fairly smooth process).
>
> Then I'd guess not.
>
> > So I wonder: should we stop releasing for 32-bits systems?
> > Any thoughts?
>
> If you're talking binaries, Apache doesn't release binaries of anything.
> A project may offer binaries, but those would be unofficial.
> Our downstream packagers - e.g. Linux distros or commercial vendors -
> typically build binaries for their users.
>
> If what you're asking is whether it should be marked as
> untested/unsupported
> on 32-bit, I have no view one way or the other, provided any non-support
> is clearly documented.
>
> --
> Nick Kew
>

Re: 32 bits releases: in or out

[Nick Kew <ni...@apache.org>]

> On 2 Dec 2018, at 19:45, Otto van der Schaaf <os...@we-amp.com> wrote:
> 
> Hi all,
> 
> I'm working on producing artifacts for a first incubator release candidate,
> and I am reminded by the process that producing 32 bits artifacts takes a
> lot
> of time and effort compared to the 64 bits ones (about 90:10 this time).

Is there something 64-bit-specific about the code?

>  (and if someone really wants it: building from source on
> an actual 32 bits
> system is a fairly smooth process).

Then I'd guess not.

> So I wonder: should we stop releasing for 32-bits systems?
> Any thoughts?

If you're talking binaries, Apache doesn't release binaries of anything.
A project may offer binaries, but those would be unofficial.
Our downstream packagers - e.g. Linux distros or commercial vendors -
typically build binaries for their users.

If what you're asking is whether it should be marked as untested/unsupported
on 32-bit, I have no view one way or the other, provided any non-support
is clearly documented.

-- 
Nick Kew