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

[Jon Portnoy]

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.

With minor exceptions, _those goals are met_.

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.

>
> > 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).


> 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?

glibc is just about set, yes. Note that I didn't say anything about 
glibc in my email.

>
> >
[snip
> > > 3.  What platform should be supported at release time.  Here I think x86
> > > and maybe x86-64.  Targeting too many will just delay it.  Have some
> > > other dates for the rest to follow.
> >
> > We target all platforms that're release-ready. Right now, that's x86,
> > ppc, and sparc. Release-ready means the tree is prepped, the stages and
> > LiveCDs can be built, install documents are up on the site.
>
> Well if you ask me, thats too many for an August deadline.  Do the best that
> can be done with x86 and have the rest follow by a month.  That way any nasty
> bugs can be squashed before the other 2 hit the stand but I guess the
> Marketing Dept has mandated that all 3 will be ready at the same time. :)

That's not too many for an August deadline: I'm not sure where you got 
that idea. They'll be ready at the same time because it makes sense for 
them to be ready at the same time to have a uniform release. There is no 
reason _not_ to release them at the same time.

If a specific arch leads decides they're not ready for a 1.4 release, 
they won't be released. I'm not going to mandate that archs that aren't 
ready have a release, but I'm not going to refuse to release what's 
ready, either.

Marketinng Dept? We have nothing to gain from 'marketing' except for 
providing a superior product to users. I am sorry that providing a 
superior product to users and attempting to avoid any inconvienence to 
users does not fit with what you would like. I am not willing to push 
gcc 3.3 yet because it breaks for a lot of people; I am not willing to 
push openssl 0.9.7 out of package.mask because many people will have 
broken systems without a better upgrade path. I am sorry that you do not 
understand QA.

>
> >
> > > These are just really fundementals but until the requirements are
> > > documented things will never really come together.
> > >
> > > Get things out in the open.  Gentoo-core is probably the worst idea
> > > someone ever came up with, OSS development is meant to be a very
> > > transparent process. Make it transparent.  I know there are always
> > > private issues but if they involve more than 3 people then perhaps they
> > > should be public.
> >
> > We are making it transparent by discussing development on gentoo-dev.
> Don't tell me, someone woke up this morning and formed a new management
> structure, honest :)  You know you need this transparent as it is the only
> hope of it getting done in time.  It's not a big deal for me actually, it's
> just that of ppl where primed and ready for the announcement you would be
> more than halfway towards meeting the objectives.

Can you explain what you mean here? Getting what done 
in time? Which announcement? Which objectives?

>
> Anyway, from another comment it is impossible to define goals for Gentoo
> therefore I would submit it is impossible to have a 1.4 release.  I have no
> problems with that, marketing probably does though.

Now you're really grasping at straws. Can you tell me which comment says 
that it's impossible to define goals for Gentoo?

What marketing? The fact that I said that it'd be nice to have something 
to hand out on CDs to people for LWESF so they can go home and install 
Gentoo suddenly means everything we do is based on marketing?

I apologize for all of us for trying to provide you, the users, with a 
superior product, good QA, and convienent upgrades.

-- 
Jon Portnoy
avenj/irc.freenode.net

--
gentoo-dev@g.o mailing list