[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Further Hurd releases
Emilio Pozuelo Monfort
Re: Further Hurd releases
Sat, 26 Oct 2013 03:39:29 +0200
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131005 Icedove/17.0.9
On 25/10/13 17:34, Thomas Schwinge wrote:
> On Fri, 25 Oct 2013 15:54:43 +0200, Justus Winter
> <firstname.lastname@example.org> wrote:
>> what you're suggesting is not
>> possible. Labels can only be placed in front of a statement and a
>> declaration is not a statement. Well, that's what gcc told me...
> D'oh. :-)
>> Quoting Thomas Schwinge (2013-10-25 15:27:10)
>>> or even [...]
>> Ok, I will have a look at cleaning up this function. However, this
>> seems like a critical bug in a critical component of the Hurd.
> That bug has been present for a long time, introduced 12.5 years ago in
> commit b5a4fc2bc5ee18907945cb5cd9eb792dc4f4b19e -- and I note both Neal
> and Roland failed to notice this ;-) -- so I think a "hectic rush" is not
> appropriate now. Nobody's business will come to a grinding halt because
> of this, and neither is any life at stake. ;-)
>> wanted to post this now as Samuel is planning to upload a new Hurd
>> package soonish.
> I'm not objecting, but while we certainly can and shall be doing further
> Hurd releases in a (much!) more frequent manner than in the last decade,
> I again see no reason to sort-of start "spamming" the Internet with new
> Hurd releases now -- for the same reasoning as given just above.
> The v0.5 release was just one month ago. Strictly speaking, if you now
> want to have a v0.5.1 bug fix release, that should logically be coming
> From a v0.5 release branch (or you assert there have only been "stable"
> patches been applied to the master branch in the mean time). What's the
> idea then about another bug fix release v0.5.2 later on, where should
> this be coming from?
> I'm not interested in maintaining a v0.5 release branch, and everyone who
> closely wants to follow Hurd development (and thus would be interested in
> another release after just one month) shall track the master branch
> anyway, in my opinion.
> How often do you want to make releases now? Frequently making releases
> off of the master branch without any stabilization period (and/or release
> branches) does not make sense to me, other than for publicity reasons
> (but that will very quickly become void if done too frequently, I
> assume). Such releases off of the master branch would then rather be
> called daily snapshots (as I suggested before) instead of releases.
> That said, and as I said, I'm not objecting to making a v0.5.1 release
> now (especially if there indeed are just non-minor bug fix commits on the
> master branch), but first would like the general future procedure
I think Justus was speaking of an upload to Debian. There's still no rush to get
this into hurd upstream anyway as Debian can add a patch (if that's considered
necessary) while the patch is being reviewed and cleaned up before inclusion in
the upstream repo.
Still your remarks about how to handle stable branches are valid, if only for
the day we actually need them :-)
[PATCH 2/5] exec: Remove the remaining BFD related bits, Justus Winter, 2013/10/25
Re: [PATCH 1/5] Makeconf: add -fno-strict-aliasing to CFLAGS, Thomas Schwinge, 2013/10/25
- [PATCH 4/5] libshouldbeinlibc: fix error handling in maptime_map, (continued)