1 |
Hi, |
2 |
|
3 |
I have a few remarks about the 2004.1 feature list. My incentive for |
4 |
making these remarks is to get an idea how/when to schedule time for |
5 |
testing/implementing each feature, and to signal some of the problems |
6 |
we could be confronted relatively well in advance. |
7 |
|
8 |
|
9 |
1. What is the scope of catalyst cross-compilation integration? |
10 |
|
11 |
Daniel said in his stanford presentation that there is |
12 |
cross-compilation and "true" cross-compilation. Which of those is meant |
13 |
to be integrated into catalyst? |
14 |
|
15 |
It should be clear that true cross compilation is difficult to achieve |
16 |
for stage and GRP building. Consider for instance the case where |
17 |
somebody on intel architecture wants to build powerpc stages. We know |
18 |
that it is impossible to take a ppc stage on an intel machine and |
19 |
chroot into it, because the intel microprocessor can't run ppc |
20 |
micro-instructions. What would be possible is to take an x86 stage, |
21 |
install a cross compilation toolchain into it and use that toolchain to |
22 |
cross compile an application. How bootstrapping/dependencies would be |
23 |
handled is something that should be thought about. Are there any |
24 |
ebuilds alternative architectures could start looking at regarding |
25 |
cross-compilation toolchains? Or will the implementors of these |
26 |
toolchains mask cross-compilation toolchains stable for the affected |
27 |
target alternative architectures, assuming the cross-compiled results |
28 |
work as expected on the target architecture? If true cross compilation |
29 |
is really on the agenda, what will it's impact be on the current |
30 |
catalyst targets' behaviour, I take it we'll have to work around the |
31 |
chroot limitation? When should alternative architectures start testing |
32 |
results produced by the catalyst cross compilation process, or will the |
33 |
feature be alpha quality on release? |
34 |
|
35 |
Isn't the non-true cross-compilation, (where the host can run the |
36 |
targets microinstructions) trivial? I can already use my 64bit G5 to |
37 |
build regular ppc, G3 and G4 stages because the G5 can run G4,G3 and |
38 |
ppc instructions, on both a 32bit and 64bit kernel. |
39 |
My question to releng regarding non-true cross-compilation is the |
40 |
following: What changes can we expect to catalyst? I guess some kind of |
41 |
checking mechanism will be implemented/activated? Should we really call |
42 |
it cross-compilation in our marketing talk? |
43 |
|
44 |
|
45 |
2. Stackable profiles. |
46 |
|
47 |
I looked at what is currently committed to the profiles section. I |
48 |
would like to remark that we should take care people do not choose to |
49 |
request a release feature over a glep because a release is bound to |
50 |
happen and a glep can be under discussion until it is ripe to be |
51 |
implemented. Some bureaucracy does have its benefits, especially when |
52 |
considering enhancements that are bound to affect the entire world. |
53 |
|
54 |
The request describes the feature as a form of inheritance. When |
55 |
considering inheritance, one should question the following aspects: |
56 |
|
57 |
- Overriding the parent. If a super profile says I should have |
58 |
something, can the sub undo (override) that statement? |
59 |
- Multiple inheritance. Will this be allowed, or is it tree based only |
60 |
(When tree based only does this really easy maintenance?) |
61 |
- How will simple and complex conflict resolution happen? |
62 |
- Can profiles inherit each other? |
63 |
|
64 |
The following questions should be taken into consideration: |
65 |
|
66 |
- The description states profile management will be more easy. What |
67 |
steps will be undertaken to ensure this actually is the case, taking |
68 |
into account large inheritance chains, conflict resolution, |
69 |
overriding... Will portage be able to show, given a stack of profiles |
70 |
what the profile after applying inheritance looks like? |
71 |
- What will be the preferred way to inform people about profile |
72 |
changes. (I'd like to suggest cvs watch as an good way for profile |
73 |
maintainers to be notified about base profile changes.) |
74 |
- What happens when the aspect 'evolution' comes into play? For |
75 |
instance: suppose all architectures agree upon a base profile they can |
76 |
inherit from, if a new architecture is added, and it is incompatible |
77 |
with the shared super profile, do all other profiles need to change to |
78 |
accommodate for the new architecture? |
79 |
|
80 |
Suppose ppc starts building a release gradually, to end up with a |
81 |
stable product 3 days before the actual release. If 10 other |
82 |
architectures, without the computational power to build releases |
83 |
gradually, make a huge amount of changes to a profile ppc inherits from |
84 |
in those last 3 days, then chances are high a ppc user syncing on ppc |
85 |
might end up with a broken, completely untested profile, right after a |
86 |
release? We already chose to violate the most basic OO programming |
87 |
style rule that a super class should never perform behaviour selection |
88 |
based on the inheriting subclass name (Please do not implement this |
89 |
feature for the stacked profiles). Suppose somebody uses that argument |
90 |
in a discussion about how stackable profiles were added just because of |
91 |
the same reason we violated the most basic OO programming style rule: |
92 |
reducing the number of files the maintainer has to open. How should one |
93 |
defend this design choice then? Are there any projects besides |
94 |
hardened/selinux for which such feature is justified or is this being |
95 |
implemented only to reduce profile maintainer keystrokes? |
96 |
Considering things will migrate from sub to supper gradually depending |
97 |
on whether more and more sub's define the same. Won't this lead to more |
98 |
complex maintenance? |
99 |
|
100 |
Has a roadmap for this feature been designed, or will alternative |
101 |
architecture profile maintainers suddenly have to reschedule their |
102 |
agenda to start implementing and bugfixing this feature for their |
103 |
architecture (when they should be doing more important things)? When |
104 |
will the super profiles and the necessary syntax be stabilized? |
105 |
|
106 |
|
107 |
3. Portage GPG signing. |
108 |
|
109 |
Questions that should be taken into consideration: |
110 |
|
111 |
- What will happen when a developer leaves the project and revokes his |
112 |
gpg keys? Are we going to be checking signed ebuilds against revoked |
113 |
keys? |
114 |
- Can I still commit ebuilds without GPG? |
115 |
|
116 |
This topic has been discussed widely, but I have no idea what variant |
117 |
we're implementing. |
118 |
|
119 |
|
120 |
|
121 |
Shown on the 2004.1 feature page is only a list of the people |
122 |
requesting a feature, not the people implementing it. |
123 |
I have the impression that features are described only very vaguely |
124 |
with a lot of fancy words (marketing). We need to separate marketing |
125 |
from requirements for development purposes. People implementing |
126 |
requirements work without a schedule and make designs while coding, and |
127 |
we have no way to test whether the implementation of a feature is good |
128 |
enough to be included in a release.I think some consistency would be |
129 |
welcome: either we do everything according to widely established |
130 |
software engineering standards and that includes simple requirements, |
131 |
use cases, code documentation, coding standards, roadmaps (with the |
132 |
'bureaucracy') or we do it without. A mix of both doesn't work. Infomal |
133 |
but consistent and realistic SE practices will form the basis of the |
134 |
things we have been dreaming about for a long time, which we had to |
135 |
delay because we're continously busy working for/against each other. |
136 |
|
137 |
|
138 |
Best regards, |
139 |
|
140 |
Pieter Van den Abeele |
141 |
|
142 |
|
143 |
-- |
144 |
gentoo-releng@g.o mailing list |