1 |
On Thu, 2004-03-18 at 22:15, Pieter Van den Abeele wrote: |
2 |
|
3 |
> My question to releng regarding non-true cross-compilation is the |
4 |
> following: What changes can we expect to catalyst? I guess some kind of |
5 |
> checking mechanism will be implemented/activated? Should we really call |
6 |
> it cross-compilation in our marketing talk? |
7 |
|
8 |
That is a very good point. The cross-compiling that I would like to see |
9 |
is the "true" type, but the likelihood of us meeting that goal for |
10 |
2004.1 is slim. I will consider removing this from the feature request |
11 |
list. |
12 |
|
13 |
> Has a roadmap for this feature been designed, or will alternative |
14 |
> architecture profile maintainers suddenly have to reschedule their |
15 |
> agenda to start implementing and bugfixing this feature for their |
16 |
> architecture (when they should be doing more important things)? When |
17 |
> will the super profiles and the necessary syntax be stabilized? |
18 |
|
19 |
Seemant, could you elaborate please? |
20 |
|
21 |
> 3. Portage GPG signing. |
22 |
> |
23 |
> Questions that should be taken into consideration: |
24 |
> |
25 |
> - What will happen when a developer leaves the project and revokes his |
26 |
> gpg keys? Are we going to be checking signed ebuilds against revoked |
27 |
> keys? |
28 |
> - Can I still commit ebuilds without GPG? |
29 |
> |
30 |
> This topic has been discussed widely, but I have no idea what variant |
31 |
> we're implementing. |
32 |
|
33 |
I honestly do not know which variant we are using. I was told by |
34 |
Carpaski and Puggy (the two implementers) that they were almost done |
35 |
with it and they will have a POC very soon. I will follow up with them. |
36 |
|
37 |
> |
38 |
> |
39 |
> Shown on the 2004.1 feature page is only a list of the people |
40 |
> requesting a feature, not the people implementing it. |
41 |
> I have the impression that features are described only very vaguely |
42 |
> with a lot of fancy words (marketing). We need to separate marketing |
43 |
> from requirements for development purposes. People implementing |
44 |
> requirements work without a schedule and make designs while coding, and |
45 |
> we have no way to test whether the implementation of a feature is good |
46 |
> enough to be included in a release.I think some consistency would be |
47 |
> welcome: either we do everything according to widely established |
48 |
> software engineering standards and that includes simple requirements, |
49 |
> use cases, code documentation, coding standards, roadmaps (with the |
50 |
> 'bureaucracy') or we do it without. A mix of both doesn't work. Infomal |
51 |
> but consistent and realistic SE practices will form the basis of the |
52 |
> things we have been dreaming about for a long time, which we had to |
53 |
> delay because we're continously busy working for/against each other. |
54 |
|
55 |
I agree. At this point, there is no formal process to either request a |
56 |
Feature or implement one. Feature Request is one of the last areas of |
57 |
the release process that remain untamed. There needs to be something |
58 |
done about it ... I will hash something out and post it to the list. |
59 |
|
60 |
Cheers, |
61 |
//zhen |
62 |
-- |
63 |
John Davis |
64 |
Gentoo Linux Developer |
65 |
<http://dev.gentoo.org/~zhen> |
66 |
|
67 |
---- |
68 |
GnuPG Public Key: <http://dev.gentoo.org/~zhen/zhen_pub.asc> |
69 |
Fingerprint: 2364 71BD 4BC2 705D F338 FF70 6650 1235 1946 2D47 |