On Mon, 2019-02-11 at 17:01 -0600, Ken Gaillot wrote:
> On Mon, 2019-02-11 at 22:48 +0100, Jan Pokorný wrote:
> > On 20/01/19 12:44 +0100, Jan Pokorný wrote:
> > > On 18/01/19 20:32 +0100, Jan Pokorný wrote:
> > > > It was discovered that this release of glib project changed
> > > > sligthly
> > >
On Mon, 2019-02-11 at 22:48 +0100, Jan Pokorný wrote:
> On 20/01/19 12:44 +0100, Jan Pokorný wrote:
> > On 18/01/19 20:32 +0100, Jan Pokorný wrote:
> > > It was discovered that this release of glib project changed
> > > sligthly
> > > some parameters of how distribution of values within hash
On 20/01/19 12:44 +0100, Jan Pokorný wrote:
> On 18/01/19 20:32 +0100, Jan Pokorný wrote:
>> It was discovered that this release of glib project changed sligthly
>> some parameters of how distribution of values within hash tables
>> structures work, undermining pacemaker's hard (alas unfeasible)
On 21/01/19 09:17 +0100, Ulrich Windl wrote:
> IMHO it's like in Perl: When relying the hash keys to be returned
> in any particular (or even stable) order, the idea is just broken!
> Either keep the keys in an extra array for ordering, or sort them
> in some way...
Exactly, IT silos lacking
On 18/01/19 20:32 +0100, Jan Pokorný wrote:
> It was discovered that this release of glib project changed sligthly
> some parameters of how distribution of values within hash tables
> structures work, undermining pacemaker's hard (alas unfeasible) attempt
> to turn this data type into fully
It was discovered that this release of glib project changed sligthly
some parameters of how distribution of values within hash tables
structures work, undermining pacemaker's hard (alas unfeasible) attempt
to turn this data type into fully predictable entity.
Current impact is unknown beside
