| 1 |
On Wednesday 25 June 2003 06.04, Jon Portnoy wrote: |
| 2 |
> On Wed, Jun 25, 2003 at 05:02:32AM +0200, Tony Clark wrote: |
| 3 |
> > On Wednesday 25 June 2003 03.33, Daniel Robbins wrote: |
| 4 |
> |
| 5 |
> [snip] |
| 6 |
> |
| 7 |
> > 1. What is Gentoo 1.4. What it may have been intended to be in January |
| 8 |
> > is probably not what it is going to be now. Before you recruit all and |
| 9 |
> > sundry you have to define this as if it isn't defined everything will |
| 10 |
> > fall down and chaos will return. Some basic things I see is that it |
| 11 |
> > needs to be are: gcc3.3 based |
| 12 |
> > glibc2.3.2 |
| 13 |
> > openssl0.9.7 |
| 14 |
> |
| 15 |
> We can do this if you want to wait another couple of months. |
| 16 |
> |
| 17 |
> Unfortunately, there are some requests to have 1.4 ready for LWESF at |
| 18 |
> the beginning of Augusy |
| 19 |
This is just classical, happens everyday type stuff in electronics/software |
| 20 |
companies, espically ones who don't know what they are building with clear |
| 21 |
goals. Marketing keeps moving the requirements and dates aren't met. Some |
| 22 |
deadline finally gets set and a patch work job happens to meet THE DATE. |
| 23 |
|
| 24 |
> This is not viable. The tree is not gcc3.3-ready and OpenSSL 0.9.7 needs |
| 25 |
> a much more mature upgrade path, otherwise there will be serious |
| 26 |
> breakage (you need to remerge wget without ssl support, then merge the |
| 27 |
> new openssl, then rebuild everything depending on it currently). |
| 28 |
The OpenSSL upgrade is really ready, it just that the whole tree needs a |
| 29 |
rebuild which is time consumming. You have to break the cycle sooner or |
| 30 |
later. Seems to me one solution is to release a binary version of 1.4 build |
| 31 |
with the latest OpenSSL goes someway to ease that upgrade. Users can get a |
| 32 |
working basic system maybe with kde and gnome desktops then add or rebuild at |
| 33 |
their own pace. New takers have no problems as they are current. GCC is a |
| 34 |
slightly different problem but not as large. I guess it could be solved |
| 35 |
putting different versions of GCC in slots. Glibc is pretty well there and |
| 36 |
doesn't seem to have any problems that I have noticed. |
| 37 |
|
| 38 |
> |
| 39 |
> > 2. What are the core applications. Is it a desktop, a server orinitated |
| 40 |
> > system or a system compremised to do both. I would suggest desktop as I |
| 41 |
> > think thats what it is mainly used for, but I don't have the stats so I |
| 42 |
> > could be well off the mark. (Market research required) |
| 43 |
> |
| 44 |
> I don't understand what you mean by 'core applications' in this context. |
| 45 |
I think of core applications as things people are actually going to use to do |
| 46 |
something outside of maintaining their systems. ie desktop, browser, apache |
| 47 |
etc. verses core-system stuff like kernels, tools, portage etc. |
| 48 |
|
| 49 |
> > 3. What platform should be supported at release time. Here I think x86 |
| 50 |
> > and maybe x86-64. Targeting too many will just delay it. Have some |
| 51 |
> > other dates for the rest to follow. |
| 52 |
> |
| 53 |
> We target all platforms that're release-ready. Right now, that's x86, |
| 54 |
> ppc, and sparc. Release-ready means the tree is prepped, the stages and |
| 55 |
> LiveCDs can be built, install documents are up on the site. |
| 56 |
|
| 57 |
Well if you ask me, thats too many for an August deadline. Do the best that |
| 58 |
can be done with x86 and have the rest follow by a month. That way any nasty |
| 59 |
bugs can be squashed before the other 2 hit the stand but I guess the |
| 60 |
Marketing Dept has mandated that all 3 will be ready at the same time. :) |
| 61 |
|
| 62 |
> |
| 63 |
> > These are just really fundementals but until the requirements are |
| 64 |
> > documented things will never really come together. |
| 65 |
> > |
| 66 |
> > Get things out in the open. Gentoo-core is probably the worst idea |
| 67 |
> > someone ever came up with, OSS development is meant to be a very |
| 68 |
> > transparent process. Make it transparent. I know there are always |
| 69 |
> > private issues but if they involve more than 3 people then perhaps they |
| 70 |
> > should be public. |
| 71 |
> |
| 72 |
> We are making it transparent by discussing development on gentoo-dev. |
| 73 |
Don't tell me, someone woke up this morning and formed a new management |
| 74 |
structure, honest :) You know you need this transparent as it is the only |
| 75 |
hope of it getting done in time. It's not a big deal for me actually, it's |
| 76 |
just that of ppl where primed and ready for the announcement you would be |
| 77 |
more than halfway towards meeting the objectives. |
| 78 |
|
| 79 |
Anyway, from another comment it is impossible to define goals for Gentoo |
| 80 |
therefore I would submit it is impossible to have a 1.4 release. I have no |
| 81 |
problems with that, marketing probably does though. |
| 82 |
|
| 83 |
tony |
| 84 |
-- |
| 85 |
Contract ASIC and FPGA design. |
| 86 |
Telephone +46 702 894 667 |
| 87 |
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x633E2623 |
| 88 |
|
| 89 |
|
| 90 |
|
| 91 |
-- |
| 92 |
gentoo-dev@g.o mailing list |
Archives