[gentoo-releng] 2004.1 feature list questions

[Pieter Van den Abeele]

Hi,

I have a few remarks about the 2004.1 feature list. My incentive for 
making these remarks is to get an idea how/when to schedule time for 
testing/implementing each feature, and to signal some of the problems 
we could be confronted relatively well in advance.


1. What is the scope of catalyst cross-compilation integration?

Daniel said in his stanford presentation that there is 
cross-compilation and "true" cross-compilation. Which of those is meant 
to be integrated into catalyst?

It should be clear that true cross compilation is difficult to achieve 
for stage and GRP building. Consider for instance the case where 
somebody on intel architecture wants to build powerpc stages. We know 
that it is impossible to take a ppc stage on an intel machine and 
chroot into it, because the intel microprocessor can't run ppc 
micro-instructions. What would be possible is to take an x86 stage, 
install a cross compilation toolchain into it and use that toolchain to 
cross compile an application. How bootstrapping/dependencies would be 
handled is something that should be thought about. Are there any 
ebuilds alternative architectures could start looking at regarding  
cross-compilation toolchains? Or will the implementors of these 
toolchains mask cross-compilation toolchains stable for the affected 
target alternative architectures, assuming the cross-compiled results 
work as expected on the target architecture? If true cross compilation 
is really on the agenda, what will it's impact be on the current 
catalyst targets' behaviour, I take it we'll have to work around the 
chroot limitation?  When should alternative architectures start testing 
results produced by the catalyst cross compilation process, or will the 
feature be alpha quality on release?

Isn't the non-true cross-compilation, (where the host can run the 
targets microinstructions) trivial? I can already use my 64bit G5 to 
build regular ppc, G3 and G4 stages because the G5 can run G4,G3 and 
ppc instructions, on both a 32bit and 64bit kernel.
My question to releng regarding non-true cross-compilation is the 
following: What changes can we expect to catalyst? I guess some kind of 
checking mechanism will be implemented/activated? Should we really call 
it cross-compilation in our marketing talk?


2. Stackable profiles.

I looked at what is currently committed to the profiles section.  I 
would like to remark that we should take care people do not choose to 
request a release feature over a glep because a release is bound to 
happen and a glep can be under discussion until it is ripe to be 
implemented. Some bureaucracy does have its benefits, especially when 
considering enhancements that are bound to affect the entire world.

The request describes the feature as a form of inheritance. When 
considering inheritance, one should question the following aspects:

- Overriding the parent. If a super profile says I should have 
something, can the sub undo (override) that statement?
- Multiple inheritance. Will this be allowed, or is it tree based only 
(When tree based only does this really easy maintenance?)
- How will simple and complex conflict resolution happen?
- Can profiles inherit each other?

The following questions should be taken into consideration:

- The description states profile management will be more easy. What 
steps will be undertaken to ensure this actually is the case, taking 
into account large inheritance chains, conflict resolution, 
overriding... Will portage be able to show, given a stack of profiles 
what the profile after applying inheritance looks like?
- What will be the preferred way to inform people about profile 
changes. (I'd like to suggest cvs watch as an good way for profile 
maintainers to be notified about base profile changes.)
- What happens when the aspect 'evolution' comes into play? For 
instance: suppose all architectures agree upon a base profile they can 
inherit from, if a new architecture is added, and it is incompatible 
with the shared super profile, do all other profiles need to change to 
accommodate for the new architecture?

Suppose ppc starts building a release gradually, to end up with a 
stable product 3 days before the actual release. If 10 other 
architectures, without the computational power to build releases 
gradually, make a huge amount of changes to a profile ppc inherits from 
in those last 3 days, then chances are high a ppc user syncing on ppc 
might end up with a broken, completely untested profile, right after a 
release? We already chose to violate the most basic OO programming 
style rule that a super class should never perform behaviour selection 
based on the inheriting subclass name (Please do not implement this 
feature for the stacked profiles). Suppose somebody uses that argument 
in a discussion about how stackable profiles were added just because of 
the same reason we violated the most basic OO programming style rule: 
reducing the number of files the maintainer has to open. How should one 
defend this design choice then? Are there any projects besides 
hardened/selinux for which such feature is justified or is this being 
implemented only to reduce profile maintainer keystrokes?
Considering things will migrate from sub to supper gradually depending 
on whether more and more sub's define the same. Won't this lead to more 
complex maintenance?

Has a roadmap for this feature been designed, or will alternative 
architecture profile maintainers suddenly have to reschedule their 
agenda to start implementing and bugfixing this feature for their 
architecture (when they should be doing more important things)? When 
will the super profiles and the necessary syntax be stabilized?


3. Portage GPG signing.

Questions that should be taken into consideration:

- What will happen when a developer leaves the project and revokes his 
gpg keys? Are we going to be checking signed ebuilds against revoked 
keys?
- Can I still commit ebuilds without GPG?

This topic has been discussed widely, but I have no idea what variant 
we're implementing.



Shown on the 2004.1 feature page is only a list of the people 
requesting a feature, not the people implementing it.
I have the impression that features are described only very vaguely 
with a lot of fancy words (marketing). We need to separate marketing 
from requirements for development purposes. People implementing 
requirements work without a schedule and make designs while coding, and 
we have no way to test whether the implementation of a feature is good 
enough to be included in a release.I think some consistency would be 
welcome: either we do everything according to widely established 
software engineering standards and that includes simple requirements, 
use cases, code documentation, coding standards, roadmaps (with the 
'bureaucracy') or we do it without. A mix of both doesn't work. Infomal 
but consistent and realistic SE practices will form the basis of the 
things we have been dreaming about for a long time, which we had to 
delay because we're continously busy working for/against each other.


Best regards,

Pieter Van den Abeele


--
gentoo-releng@g.o mailing list