Re: [gentoo-dev] *IMPORTANT* top-level management structure!

[Matthew Kennedy]

Tony Clark <tclark@×××××.com> writes:

> On Wednesday 25 June 2003 07.47, Jon Portnoy wrote:
>> On Wed, Jun 25, 2003 at 07:26:32AM +0200, Tony Clark wrote:
>> > On Wednesday 25 June 2003 06.04, Jon Portnoy wrote:
>> > > On Wed, Jun 25, 2003 at 05:02:32AM +0200, Tony Clark wrote:
>> > > > On Wednesday 25 June 2003 03.33, Daniel Robbins wrote:
>> > >
>> > > [snip]
>> > >
>> > > > 1.  What is Gentoo 1.4.  What it may have been intended to be in
>> > > > January is probably not what it is going to be now.  Before you
>> > > > recruit all and sundry you have to define this as if it isn't defined
>> > > > everything will fall down and chaos will return.  Some basic things I
>> > > > see is that it needs to be are: gcc3.3 based
>> > > > glibc2.3.2
>> > > > openssl0.9.7
>> > >
>> > > We can do this if you want to wait another couple of months.
>> > >
>> > > Unfortunately, there are some requests to have 1.4 ready for LWESF at
>> > > the beginning of Augusy
>> >
>> > This is just classical, happens everyday type stuff in
>> > electronics/software companies, espically ones who don't know what they
>> > are building with clear goals.  Marketing keeps moving the requirements
>> > and dates aren't met.  Some deadline finally gets set and a patch work
>> > job happens to meet THE DATE.
>>
>> We know what we're building and have clear goals. Those goals have been
>> specified on this list by Daniel in the past.
> past day, week, month, year?  He has had about 4 posts here in the last 6
> months.  Why isn't the QA guy demanding a list of packages to be included?
>>
>> With minor exceptions, _those goals are met_.
>
> What exceptions? Why the sudden panic then?
>>
>> However, you're now suggesting _entirely new_ goals that _do not fit_
>> with the schedule already in mind. Marketing is irrelevant - a few
>> people said "Do you think we'll be ready for LWESF?" and I said "Yes." I
>> intend to follow up on that, now that our goals are either met or about
>> to be met. There is no 'THE DATE' that we absolutely must adhere to.
>> Instead, I'm telling you that there is no technical way we can go with
>> gcc 3.3 and openssl 0.9.7 in stable keywords without waiting a
>> significantly long period of time while work is done in those areas.
> Now above you say there is a deadline and here you say there isn't.  I can't
> see how you can say I am describing new goals when you can't point me to a
> document which states what the current goals are.  There is no QA as noone
> can trace a specification pass back to a specified requirement.  I've
> digressed into QA but thats actually what the total process should be about.
>
>> > > This is not viable. The tree is not gcc3.3-ready and OpenSSL 0.9.7
>> > > needs a much more mature upgrade path, otherwise there will be serious
>> > > breakage (you need to remerge wget without ssl support, then merge the
>> > > new openssl, then rebuild everything depending on it currently).
>> >
>> > The OpenSSL upgrade is really ready, it just that the whole tree needs a
>> > rebuild which is time consumming.  You have to break the cycle sooner or
>> > later.  Seems to me one solution is to release a binary version of 1.4
>> > build with the latest OpenSSL goes someway to ease that upgrade.  Users
>> > can get a
>>
>> Certainly, new stage1 and stage2 installs would have no problem - they
>> haven't done an emerge system yet. A stage3 with openssl 0.9.7 would
>> have no problem. Existing users or people using old stage3s would be
>> screwed. We need a better upgrade path for that in order to avoid the
>> kind of "patch work job" you described earlier.
>>
>> With regards to 'breaking the cycle,' we need functionality in Portage
>> that either allows the ebuild to directly run revdep-rebuild or
>> incorporate revdep-rebuild into Portage (or preferably real reverse
>> dependencies, which will come in Portage 2.1 last I heard).
> Ok, now this is good.  All that is needed is to write these points down and
> pretty soon you will end up with a requirement document that everyone can
> understand, identify where they can be of most use and a check list you can
> tick off when each thing is done.  Now the project is managed!  It really is
> simple but because it is tedious, for a good designer, it is somewhat boring.
>
>>
>> > working basic system maybe with kde and gnome desktops then add or
>> > rebuild at their own pace.  New takers have no problems as they are
>> > current.  GCC is a slightly different problem but not as large.  I guess
>> > it could be solved putting different versions of GCC in slots.  Glibc is
>> > pretty well there and doesn't seem to have any problems that I have
>> > noticed.
>>
>> SLOTs are irrelevant to the GCC issue. The GCC issue is that the tree is
>> not ready for it. Many applications will not build and there are many,
>> many unsolved problems and weird issues that people can't track down.
>> GCC 3.3 is not production ready and I, for one, am not interested in
>> pushing people to release a broken compiler on the masses for the sake
>> of saying "we're up to date!" - can you please justify pushing GCC 3.3
>> before it's ready?
>
> I don't need too.  I'm not a gentoo developer, I just  help where I can, when
> I can.  What you should be telling me is here is a url of the number of
> packages that won't build with gcc3.3 in portage and here is another list
> that we are not sure of.  Have that in an easy to find location then things
> can start to happen.  It's all very well to say things are as broken as SCO's
> kernel code but all I can say is, show me the list and I will see what I can
> do to fix some of it. :)
>

Hi Tony,

This is the list I've started to work off of:

http://bugs.gentoo.org/buglist.cgi?query_format=&short_desc_type=allwordssubstr&short_desc=gcc-3.3+gcc+3.3&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailassigned_to1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&remaction=run&namedcmd=everything+gcc3.1&order=Bug+Number&field0-0-0=noop&type0-0-0=noop&value0-0-0=

There's really only 14 open bugs, however I leave the closed ones in
the list for historical interest.

Jon, GCC will never be perfect.  Like anything, there's always bugs,
so I wouldn't stress out too much :)

Matt

-- 
Matthew Kennedy
Gentoo Linux Developer

--
gentoo-dev@g.o mailing list