[ast-developers] AT&T Software Technology ast alpha software download update

Post by Glenn Fowler
the AT&T Software Technology ast alpha 2013-10-10 source release
has been posted to the download site
http://www.research.att.com/sw/download/alpha/
the package names and md5 checksums are
INIT 63bd36aef7833ab08b8c3b381e412c8a
ast-base 1c26b780b153d9e35cea978ccbfdcea1
ast-open 9221f5411ff69665186a7d328445c75a
ast-gpl c29ca45ed1fd62ed336d178c83c418c0
ast-ksh 612793fe34837a0d409d6cf360dcb01c
ast-jmake 3a4975ca9fd9e7d6f4749ae7f9cf8238
the md5 sums should match the ones listed on the download page
the last day at at&t for { dgk gsf } is 2013-10-10
this will be the last at&t post by us
for the immediate future ek will be handling ast opensource posts
{ dgk gsf } will forward changes to ek for future posts
this is not an ideal situation -- there are plans to remedy this
with { git bugzilla } or equivalents -- but first we have to land
on our feet outside of at&t
for completeness the alpha download page contains some packages
that haven't been posted in a while
changes since 2013-09-26
13-10-10 bgp-mrt.c: fix STATE_BGP_TABLE to parse all attr() before nlri()
13-10-08 --- Release ksh93v- ---
13-10-08 The shell arithmetic now recognized suffices f,F, l, and L for
floating point constants.
13-10-07 The shell now prints an error message on standard error when a
job specified with %job does not exist.
13-10-04 A bug in the value of i.MAX inside an arithmetic expression when the
variable i is unsigned long has been fixed.
13-09-27 path/pathcanon.c: fix buffer clobber bug between pathdev() and fgetcwd()
13-09-27 path/pathopen.c: handle easy O_XATTR case for /dev/fd open() semantics
13-10-01 mailx: add autosign to auto sign new messages
13-09-26 split.c: fix opetget() docs

There are a lot of patches missing which have been submitted in the
past (e.g. getconf XATTR_EXISTS or getconf -f to deal with probing
file descriptors).

Now that this has happened *very* often - this is not the first time
I've been observing this - is there a reason for this or just a row of
oversights? From Jan - Aug 2013 less than 30% of the patches submitted
have been included in ast.

Lionel

Simon Toedt

2013-10-10 12:28:11 UTC

There are a lot of patches missing which have been submitted in the
past (e.g. getconf XATTR_EXISTS or getconf -f to deal with probing
file descriptors).
Now that this has happened *very* often - this is not the first time
I've been observing this - is there a reason for this or just a row of
oversights? From Jan - Aug 2013 less than 30% of the patches submitted
have been included in ast.

Well, that is pretty much the reason why a lot of people like Debian
or Suse gave up pushing patches to upstream ('ATT'). Patches are
submitted but deliberately ignored.

Simon

Lionel Cons

2013-10-10 22:15:34 UTC

There are a lot of patches missing which have been submitted in the
past (e.g. getconf XATTR_EXISTS or getconf -f to deal with probing
file descriptors).
Now that this has happened *very* often - this is not the first time
I've been observing this - is there a reason for this or just a row of
oversights? From Jan - Aug 2013 less than 30% of the patches submitted
have been included in ast.

Well, that is pretty much the reason why a lot of people like Debian
or Suse gave up pushing patches to upstream ('ATT'). Patches are
submitted but deliberately ignored.

No no, I don't think its done deliberately, but I think things are
slipping and there is no one keeping an eye on the submitted patches.
However the result is the same, as you've observed: Patch submitters
feel ignored and maltreated and stop submitting changes. That's pretty
much the worst which can happen, with the exception of a project
fork().

Lionel

Simon Toedt

2013-10-11 21:04:25 UTC

There are a lot of patches missing which have been submitted in the
past (e.g. getconf XATTR_EXISTS or getconf -f to deal with probing
file descriptors).
Now that this has happened *very* often - this is not the first time
I've been observing this - is there a reason for this or just a row of
oversights? From Jan - Aug 2013 less than 30% of the patches submitted
have been included in ast.

Well, that is pretty much the reason why a lot of people like Debian
or Suse gave up pushing patches to upstream ('ATT'). Patches are
submitted but deliberately ignored.

No no, I don't think its done deliberately,

But It happens so often that its IMHO either a symptom of total
disorganization or total ignorance. Sure, accidents happen, but that
option is only valid if something is a rare occasion. This issue isn't
rare, it's a habit.

Simon

Lionel Cons

2013-10-15 12:54:22 UTC

There are a lot of patches missing which have been submitted in the
past (e.g. getconf XATTR_EXISTS or getconf -f to deal with probing
file descriptors).
Now that this has happened *very* often - this is not the first time
I've been observing this - is there a reason for this or just a row of
oversights? From Jan - Aug 2013 less than 30% of the patches submitted
have been included in ast.

Well, that is pretty much the reason why a lot of people like Debian
or Suse gave up pushing patches to upstream ('ATT'). Patches are
submitted but deliberately ignored.

No no, I don't think its done deliberately,

Well, at the end we have to talk to David and Glenn to see how this
can be fixed in the future, after SAT and UWIN have moved to
astopen.org

Lionel

Phi

2013-10-13 06:32:15 UTC