Release schedule & tasks for 1.0

Release schedule & tasks for 1.0

[Rich Felker]

Hi everyone,

In the interest of coordinating release publicity with news cycles,
I'd like to aim to make the 1.0 release one week from today: March 17.
This is not a hard deadline (we can change it if any problems come up)
but I think it's a reasonable goal. The main things I need to do are
still some docs work (yes...), web/git hosting infrastructure, and
publicity materials/organizing.

If anyone has outstanding bugs that can be fixed quickly and
non-invasively (low risk from making changes) please [re-]report them
in this thread.

Please also let me know if you can help with publicity in any way:
news sites you frequent and can submit a story to, if you're on
twitter and can retweet the release announcement (Rob finally
convinced me to get on twitter as @richfelker), etc. On the flip side,
if your project is using musl and I haven't already mentioned it in
publicity materials and you'd like me to, just let me know and I'll
see if I can find a way to work it in.

For everyone who has stuff on the wiki, please check and see that it's
up-to-date too.

I think that's it for now. Thanks for all the help so far!

Rich

Re: Release schedule & tasks for 1.0

[juris]

On Mon, 10 Mar 2014 03:04:11 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> If anyone has outstanding bugs that can be fixed quickly and
> non-invasively (low risk from making changes) please [re-]report them
> in this thread.

Not exactly a bug fix, but does something like this qualify for 1.0 inclusion?
Lifted it from http://article.gmane.org/gmane.linux.lib.musl.general/1255/ and prettied up a little.


diff --git a/include/stdlib.h b/include/stdlib.h
index f034c6e..7c07c50 100644
--- a/include/stdlib.h
+++ b/include/stdlib.h
@@ -40,6 +40,7 @@ void *calloc (size_t, size_t);
 void *realloc (void *, size_t);
 void free (void *);
 void *aligned_alloc(size_t alignment, size_t size);
+size_t malloc_usable_size (void *);
 
 _Noreturn void abort (void);
 int atexit (void (*) (void));
diff --git a/src/malloc/malloc.c b/src/malloc/malloc.c
index d6ad904..771e6be 100644
--- a/src/malloc/malloc.c
+++ b/src/malloc/malloc.c
@@ -533,3 +533,8 @@ void free(void *p)
 
        unlock_bin(i);
 }
+
+size_t malloc_usable_size(void *p)
+{
+       return CHUNK_SIZE(MEM_TO_CHUNK(p)) - OVERHEAD;
+}

Re: Re: Release schedule & tasks for 1.0

[Szabolcs Nagy]

* juris <juris@mt.lv> [2014-03-10 09:50:54 +0000]:
> 
> Not exactly a bug fix, but does something like this qualify for 1.0 inclusion?
> Lifted it from http://article.gmane.org/gmane.linux.lib.musl.general/1255/ and prettied up a little.
> 

symbols like this must be added in a non-polluting way

(ie. it is not ok to pull such a symbol into every
statically linked binary that uses malloc, nor to
make it visible in a c standard header by default)

and there should be a good reason to add it

(ie. existing code using it or standard defining it)

> +
> +size_t malloc_usable_size(void *p)
> +{
> +       return CHUNK_SIZE(MEM_TO_CHUNK(p)) - OVERHEAD;
> +}

if (!p) return 0; is missing

Re: Re: Release schedule & tasks for 1.0

[Rich Felker]

On Mon, Mar 10, 2014 at 09:50:54AM +0000, juris wrote:
> On Mon, 10 Mar 2014 03:04:11 -0400
> Rich Felker <dalias@aerifal.cx> wrote:
> 
> > If anyone has outstanding bugs that can be fixed quickly and
> > non-invasively (low risk from making changes) please [re-]report them
> > in this thread.
> 
> Not exactly a bug fix, but does something like this qualify for 1.0 inclusion?
> Lifted it from http://article.gmane.org/gmane.linux.lib.musl.general/1255/ and prettied up a little.

No, it's well outside the scope of what should be done during feature
freeze. Aside from the namespace issues, the big concern is that
adding new nonstandard interfaces like this could cause programs to
start using them (via autoconf detection) and break things if the
implementation of the new function does not behave exactly as
expected.

Aside from the freeze issue, this is one function I'm hesitant to add
at all. Adding it is making a contract to preserve it permanently, and
that in turn puts constraints on the malloc implementation. Right now
it's practical to obtain the usable size of a chunk, but that doesn't
mean it would remain practical under all reasonable redesigns of the
internals.

This function has also historically been buggy in glibc (it reports as
usable parts of the region used for overflow/corruption detection,
then realloc/free later aborts when the application has used this
region). This was only fixed sometime in the last year or two, so
programs using it are probably already buggy on most deployed glibc
versions and should just be fixed...

Rich

Re: Release schedule & tasks for 1.0

[Christian Wiese]

Hi Rich,
 
> Please also let me know if you can help with publicity in any way:
> news sites you frequent and can submit a story to, if you're on
> twitter and can retweet the release announcement (Rob finally
> convinced me to get on twitter as @richfelker), etc. On the flip side,
> if your project is using musl and I haven't already mentioned it in
> publicity materials and you'd like me to, just let me know and I'll
> see if I can find a way to work it in.

If there is still room for some projects to be named having musl
support, it would be neat if you can mention OpenSDE
(http://opensde.org) too, which is a kind of build-kit for building
your own distributions.

Since late 2012 I have been working on integrating musl support, and
it was officially added to the package repo as an additional libc you
can choose besides glibc and uclibc the 27th. of August 2013.

http://git.opensde.net/opensde/package-nopast/commit/?id=9f3016443e1b5ed53e63e0ca684dba211123da22

Cheers,
Chris

Re: Release schedule & tasks for 1.0

[Justin Cormack]

On Mon, Mar 10, 2014 at 7:04 AM, Rich Felker <dalias@aerifal.cx> wrote:
> Hi everyone,
>
> In the interest of coordinating release publicity with news cycles,
> I'd like to aim to make the 1.0 release one week from today: March 17.
> This is not a hard deadline (we can change it if any problems come up)
> but I think it's a reasonable goal. The main things I need to do are
> still some docs work (yes...), web/git hosting infrastructure, and
> publicity materials/organizing.

Have we got a revised schedule?

Justin

Re: Release schedule & tasks for 1.0

[Rich Felker]

On Mon, Mar 17, 2014 at 07:03:28PM +0000, Justin Cormack wrote:
> On Mon, Mar 10, 2014 at 7:04 AM, Rich Felker <dalias@aerifal.cx> wrote:
> > Hi everyone,
> >
> > In the interest of coordinating release publicity with news cycles,
> > I'd like to aim to make the 1.0 release one week from today: March 17.
> > This is not a hard deadline (we can change it if any problems come up)
> > but I think it's a reasonable goal. The main things I need to do are
> > still some docs work (yes...), web/git hosting infrastructure, and
> > publicity materials/organizing.
> 
> Have we got a revised schedule?

Possibly still today, or if not then tomorrow. I'm working on side
stuff that should go with the release and I have one trivial commit to
make to configure.

Rich