Re: Release notes

[Riccardo]

Hello,

On Wednesday, July 6, 2005, at 05:37 AM, Gregory John Casamento wrote:

> When Hurd actually works and can:
>
> 1) remain up for more than a few hours without crashing
> 2) has more than two users
>
> then I'm sure we'll work on Hurd.  Until then, we'll see.  Anyway, 
> sorry to
> disappoint, but I don't see Hurd becoming a critical release criteria 
> anytime
> soon.

yes.. this is why I wrote "should" and but a ":)" at the end I used 
windows and hurd as opposite examples.

> I assume that you mean that we are getting more mature.
>
> I'm confused with the use of the term "pretending" here.  Either we are 
> getting
> more mature, or we're merely *pretending* to get more mature, which 
> would mean
> we're really not.  :)

Yes. We are getting more mature. What I meant is that we "talk" about 
our maturity and pretend it is there (which it actually is). Now we need 
to act accordingly.

> In my opinion we should create a list of "critical release criteria" 
> which
> governs what requirements MUST be met in order for us to make a 
> release.  This
> is similar to what gcc does.    For instance bugs on certain
> architectures/operating systems or in some language front-ends will not 
> prevent
> gcc from releasing.
>
> Part of this criteria would, of course, be which OSes are considered 
> important
> enough to consistitute a "showstopper" which will require a fix prior to
> release.

Ok, I see we agree here.

I would propose to put GNU/Linux, FreeBSD, NetBSD in the "main OS's" we 
should never break before a release. Then a second class of  OS's where 
I would put Solaris and OpenBSD where we should try to be as usable as 
possible but have at least -base working for a release.

I put OpenBSD in a second class compared to the other BSD not because I 
think it is a worse OS, this classification is what I think is important 
for GNUstep, not in general. OpenBSD users tend to be more server 
oriented or use it as a desktop where VI and console  rule.

Wellm I don't know of many more OS's where GNUstep runs on. Matt has 
proved Hurd and we have windows. Give the state of the gnustep port on 
one and given the general status of the other I think we can agree that 
they should not be considered showstoppers. As far as I know GNUstep 
doesn't run on HP/UX  (not on on my 10.20) anymore, doesn't on Irix and 
I have no idea about the various alpha OS's like Tru64 and VMS but I 
just suppose "no".

As far as processors go, I'd put them in this order: x86, ppc, sparc. I 
don't know how much Alpha is used, but I think it is quite used in the 
Linux world (it was for a long time Linus' preferred workstation). I 
don't know how the new 64bit extensions from AMD and Intel to x86 affect 
our portability and thus require special care. IN case they are probably 
now widespread enough to be put in this list.

Anyway, this list should be dynamic and we could always update it in the 
future.

Also let me write a quick note about architectures. As some of you may 
know, I test and try to build GNUstep since many years on all sort of 
combinations of hardware and OS's I get my hands on. My personal 
experience is that -base is the hardest thing to get working for example 
between NetBSD x86, ppc, 68k, sparc... Most often it is not our fault: 
ffcall/libffi, linker and compiler issues were the most frequent 
problems I have experienced lately (and which David Ayers and Alexander 
Malmberg often helped me to pinpoint and solve...). Once those work, 
-base compiles and -gui and -back rarely are affected my CPU differences 
but only OS ones.

Userland is then mostly only affected by "linuxisms" like poking inside 
/proc and various tab files (GWorkspace comes to my mind or, outside 
gnustep itself, TimeMon in GAP).


ok, these are my 2 cents and my opinion of the relative importance of 
platforms regarding gnustep. If others besides Gregory agree and me 
agree this is something we should care about, please let me know and I 
hope we could formalize it a bit more. If it is needed I can write a 
short txt/rtf/html file that could be used as a reference.

Cheers,
   Rick