llvm dev - Jul 2004 - [LLVMdev] Constants.cpp:368: error: `INT8_MAX' undeclared (firstuse this function)

On Thu, 15 Jul 2004 17:57:20 -0500 (CDT)
  Chris Lattner <sabre at nondot.org> wrote:
> CPR would be really nice.  There is also this ephemeral PPC support that
> may or may not make it, but would be really awesome it if did.  I would
> also like to turn on some sort of interprocedural alias analysis by
> default (for performance).
CPR might make it in the next couple of weeks. Depends on my time 
availability and how many nasty bugs I run into. Do you really think a 
viable PPC be is doable in a couple of weeks? Lawyers being what they are, I 
doubt they'll dot the i's and cross the t's before the next couple
of weeks.
as for IAA, sounds great.
> Another thing that is on my short list for 1.3 is to get as many .bc
> format changes out of the way as possible so the backwards compat code in
> the .bc reader is simpler.  In particular, I would at least like to get
> placeholders for PR263 and maybe PR400.
This I strongly agree with. We need to minimize impact to end users. I'll do
what I can but I think CPR is a higher value target so will focus on that 
first.
> Personally I think that we've waited much too long for the 1.3 release,
me too :(
> but there is a cost to doing to testing and packaging for a release.
> This responsibility usually falls on John Criswell's shoulders, so we
try
> to fit these things into his schedule. 
Hmm. I think that kinda needs to change, especially as number of LLVM 
developers goes. Everyone needs to get involved just before a release and 
test, test, fix, test.  Testing should be divied up (especially known 
problems). Developers should be assigned to expand/strengthen testing in 
areas new to the release, etc. Leaving it in one person's hands is both a 
bottleneck and kinda unfair to John (unless he's a masochist)
> :)  In my personal view of the
> world, I think that 2 or 3 months between a release is about right.
4 releases per year is pretty standard. 1 per quarter. Certainly the 
frequency shouldn't be less unless there is some strong need or a given 
release proves problematic to test, but 1ce per quarter suits me well.
> 
> Thoughts?
Now you have them :)

Reid

On Thu, 15 Jul 2004 18:19:11 -0500 (CDT)
  Chris Lattner <sabre at nondot.org> wrote:
  
> This has no impact on the users at all... it has an impact on the
> maintainers of the LLVM .bc file reader. :)  The LLVM BC file reader has
> to have compatibility code to support loading of all released LLVM
> bytecode formats (1.0, 1.1, 1.2, etc).
Good point.
> There is always a tension between releasing too frequently (so people
> never bother to run the latest and greatest) or releasing too slowly (CVS
> drifts too much from the latest release).  I agree that a release every 3
> months seems best.
On the other hand, I also believe that each release should be targeted 
towards some scope. The devs should get together at the start of a release 
cycle, sign up for what they'll do in the next 3 months, and a (loose) plan 
should be set for the next release. Having an objective for the release is 
important to keep it on focus. If it all gets done in 2 months, fine, 
release early. If it isn't done in 3 months, either cut scope (back out 
changes) or decide to extend .. but never beyond 4 months. Of course, there 
should always be wiggle room for new ideas, contributed patches, etc. The 
release target should be just a guideline of the major new functionality and 
bug fixes to be addressed. Sound reasonable?

Reid.

On Thu, 15 Jul 2004, Reid Spencer wrote:
> > Another thing that is on my short list for 1.3 is to get as many .bc
> > format changes out of the way as possible so the backwards compat code
in
> > the .bc reader is simpler.  In particular, I would at least like to
get
> > placeholders for PR263 and maybe PR400.
>
> This I strongly agree with. We need to minimize impact to end users.
I'll do
> what I can but I think CPR is a higher value target so will focus on that
> first.
This has no impact on the users at all... it has an impact on the
maintainers of the LLVM .bc file reader. :)  The LLVM BC file reader has
to have compatibility code to support loading of all released LLVM
bytecode formats (1.0, 1.1, 1.2, etc).
> > but there is a cost to doing to testing and packaging for a release.
> > This responsibility usually falls on John Criswell's shoulders, so
we try
> > to fit these things into his schedule.
>
> Hmm. I think that kinda needs to change, especially as number of LLVM
> developers goes. Everyone needs to get involved just before a release and
> test, test, fix, test.  Testing should be divied up (especially known
> problems). Developers should be assigned to expand/strengthen testing in
> areas new to the release, etc. Leaving it in one person's hands is both
a
> bottleneck and kinda unfair to John (unless he's a masochist)
That's a good point.  I don't think that John would have a problem with
that at all either :)
> > :)  In my personal view of the
> > world, I think that 2 or 3 months between a release is about right.
>
> 4 releases per year is pretty standard. 1 per quarter. Certainly the
> frequency shouldn't be less unless there is some strong need or a given
> release proves problematic to test, but 1ce per quarter suits me well.
There is always a tension between releasing too frequently (so people
never bother to run the latest and greatest) or releasing too slowly (CVS
drifts too much from the latest release).  I agree that a release every 3
months seems best.

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://nondot.org/sabre/