RFC: Should we have a 2.30.1 point release ?

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

RFC: Should we have a 2.30.1 point release ?

Nick Clifton
Hi Guys,

  Do you think that we should have a 2.30.1 point release ?

  In the past we have only made point releases when we want
  to fix a really serious bug, and I do not think that there
  have been any recently.

  On the other hand, we are half way between major releases
  (approximately) and patches have continued to be checked
  in to the 2.30 branch.  So maybe now would a good time for
  an intermin release ?

Cheers
  Nick

Reply | Threaded
Open this post in threaded view
|

Re: RFC: Should we have a 2.30.1 point release ?

Carlos O'Donell-6
On 04/13/2018 10:44 AM, Nick Clifton wrote:

> Hi Guys,
>
>   Do you think that we should have a 2.30.1 point release ?
>
>   In the past we have only made point releases when we want
>   to fix a really serious bug, and I do not think that there
>   have been any recently.
>
>   On the other hand, we are half way between major releases
>   (approximately) and patches have continued to be checked
>   in to the 2.30 branch.  So maybe now would a good time for
>   an intermin release ?

What would be the purpose of the release?

Who would be your audience?

Who consumes a point release?

--
Cheers,
Carlos.
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Should we have a 2.30.1 point release ?

John Darrington-4
On Fri, Apr 13, 2018 at 10:56:50AM -0500, Carlos O'Donell wrote:
     On 04/13/2018 10:44 AM, Nick Clifton wrote:
     > Hi Guys,
     >
     >   Do you think that we should have a 2.30.1 point release ?
     >
     >   In the past we have only made point releases when we want
     >   to fix a really serious bug, and I do not think that there
     >   have been any recently.
     >
     >   On the other hand, we are half way between major releases
     >   (approximately) and patches have continued to be checked
     >   in to the 2.30 branch.  So maybe now would a good time for
     >   an intermin release ?
     
     What would be the purpose of the release?
     
     Who would be your audience?
     
     Who consumes a point release?
     

The only reason that I can think of is that it makes the latest code available
for people to test, who might not otherwise do so.

J;

--
Avoid eavesdropping.  Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285  A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.


signature.asc (188 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Should we have a 2.30.1 point release ?

Nick Clifton
In reply to this post by Carlos O'Donell-6
Hi Carlos,

> What would be the purpose of the release?

  Several:

   * Moving the binutils an inch closer to the "release early,
     release often" principle used by many other free software
     projects.

   * Providing an even better binutils release to be matched
     with the forthcoming gcc v8 release.

   * Get in more practice at making releases. (Especially if I
     can persuade someone else to have a go at making this
     release).
 
   * Making life easier for distro maintainers who have to patch
     official releases with bug-fixes that are already on the 2.30
     branch.

Not that I am advocating that we have a 2.30.1 release.  I am happy
either way. I just wanted to get a feel from the readers on this list
as to whether they thought that it was a good idea, or just a waste of
time.

Cheers
  Nick
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Should we have a 2.30.1 point release ?

Joel Sherrill
On Mon, Apr 16, 2018, 11:40 AM Nick Clifton <[hidden email]> wrote:

> Hi Carlos,
>
> > What would be the purpose of the release?
>
>   Several:
>
>    * Moving the binutils an inch closer to the "release early,
>      release often" principle used by many other free software
>      projects.
>

For RTEMS, I liked it when we were trying to make a point release every N
patches, something serious, or on a period. Whichever came first. Of course
that assumes you have patches. If your software is perfect, then you don't
need point releases. :)

>
>    * Providing an even better binutils release to be matched
>      with the forthcoming gcc v8 release.
>
>    * Get in more practice at making releases. (Especially if I
>      can persuade someone else to have a go at making this
>      release).
>

This is an overlooked but good reason to make releases. The people get
Rusty and the scripts bitrot if not used.

>
>    * Making life easier for distro maintainers who have to patch
>      official releases with bug-fixes that are already on the 2.30
>      branch.
>

I don't think RTEMS is carrying a lot of patches for 2.30 but this is a
very good reason to cur point releases. When we do have issues in binutils,
gcc, newlib, etc., We try to get the patches onto release branches and use
the latest point release. Our goal is to not carry patches.


> Not that I am advocating that we have a 2.30.1 release.  I am happy
> either way. I just wanted to get a feel from the readers on this list
> as to whether they thought that it was a good idea, or just a waste of
>

Someone has to decide what the minimum threshold is to trigger a point
release. Make rules and just follow them. Whatever they are.

Disclaimer: It is easier to give advice than flow it. :)

>
--joel

> time.
>
> Cheers
>   Nick
>
Reply | Threaded
Open this post in threaded view
|

RE: Should we have a 2.30.1 point release ?

Moore, Catherine
In reply to this post by Nick Clifton


> -----Original Message-----
> From: [hidden email] [mailto:binutils-
> [hidden email]] On Behalf Of Nick Clifton
> Sent: Friday, April 13, 2018 11:45 AM
> To: [hidden email]
> Subject: RFC: Should we have a 2.30.1 point release ?
>
> Hi Guys,
>
>   Do you think that we should have a 2.30.1 point release ?
>
>   In the past we have only made point releases when we want
>   to fix a really serious bug, and I do not think that there
>   have been any recently.
>
>   On the other hand, we are half way between major releases
>   (approximately) and patches have continued to be checked
>   in to the 2.30 branch.  So maybe now would a good time for
>   an intermin release ?
>
Hi Nick,
What date are you targeting for the next major release?
Thanks,
Catherine
Reply | Threaded
Open this post in threaded view
|

Re: RFC: Should we have a 2.30.1 point release ?

Nick Clifton
In reply to this post by Nick Clifton
Hi Guys,

>   Do you think that we should have a 2.30.1 point release ?

Well there has been a resounding "meh" to this idea, so I am going
to keep things simple and shelve the idea.  If a critical patch
does some along then we can make a point release at that time.

Cheers
  Nick


Reply | Threaded
Open this post in threaded view
|

Re: Should we have a 2.30.1 point release ?

Nick Clifton
In reply to this post by Moore, Catherine
Hi Catherine,

> What date are you targeting for the next major release?

July 2018.  (I am hoping to make 2 releases per year).

Cheers
  Nick


Reply | Threaded
Open this post in threaded view
|

Re: Should we have a 2.30.1 point release ?

Carlos O'Donell-6
On 04/20/2018 05:51 AM, Nick Clifton wrote:
> Hi Catherine,
>
>> What date are you targeting for the next major release?
>
> July 2018.  (I am hoping to make 2 releases per year).

A month before the glibc 2.28 release in August 2018...
how fortuitous! Would you like to coordinate so we test the
new glibc with the latest binutils?

--
Cheers,
Carlos.
Reply | Threaded
Open this post in threaded view
|

Re: Should we have a 2.30.1 point release ?

Jeff Law
On 04/20/2018 08:55 AM, Carlos O'Donell wrote:

> On 04/20/2018 05:51 AM, Nick Clifton wrote:
>> Hi Catherine,
>>
>>> What date are you targeting for the next major release?
>>
>> July 2018.  (I am hoping to make 2 releases per year).
>
> A month before the glibc 2.28 release in August 2018...
> how fortuitous! Would you like to coordinate so we test the
> new glibc with the latest binutils?
:-)  My tester will do that automatically.

For targets where we can build natively or pseudo-native with qemu it does:

1. Build and install binutils trunk
2. Bootstrap & install gcc trunk
3. Build glibc with just installed tools
4. Build kernel with just installed tools


For other *-linux-gnu targets where we can't exploit qemu's ability to
do dynamic translation:

1. Build and install binutils trunk as cross
2. Build and install gcc trunk as cross
3. Build glibc with cross tools
4. Build kernel with cross tools


I don't test as many sub-configs as build-many-glibcs.  But for various
oddball targets the builds appear native (hppa, m68k, various arm
things, etc).  So on those targets it's doing a deeper level of build
testing.

Jeff

Reply | Threaded
Open this post in threaded view
|

Re: RFC: Should we have a 2.30.1 point release ?

Carlos O'Donell-6
In reply to this post by Nick Clifton
On 04/20/2018 05:24 AM, Nick Clifton wrote:
> Hi Guys,
>
>>   Do you think that we should have a 2.30.1 point release ?
>
> Well there has been a resounding "meh" to this idea, so I am going
> to keep things simple and shelve the idea.  If a critical patch
> does some along then we can make a point release at that time.

$0.02.

In glibc when we release X.Y, we immediately mark the release/X.Y/master
branch as being called X.Y.1, and we label it as a "rolling release"
in which most distributions sync to it directly, and it accepts only
patches from master that fix bugs. In this way we never make new point
releases from release/X.Y/master, we just coordinate with the distributions
to sync this into their stable releases. Fedora tracks them directly, and
so does Debian and others.

It works well for our distro users, who tend to consume the stable branch
directly and sync as new fixes arrive in a rolling CI fashion.

It works well for our direct end-users, who tend to consume only the official
twice-annually releases, since they don't want to track a stable branch,
but prefer an officially supported tarball.

Given the release is time-boxed and twice a year, it seems to be sufficiently
aligned with the needs of all of our users.

The reason I asked my original questions was to make us all think deeply about:

* Are our users consume point releases?
* How do our direct end-users consume binutils?
* How do our distro users consume binutils?

Ask yourself these questions as the Fedora binutils maintainer :-)

--
Cheers,
Carlos.