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