1 |
Just a quick post re something that was raised in the council meeting. My |
2 |
understanding is that portage is the official package manager for Gentoo, |
3 |
and will stay that way for the conceivable future. Other package managers |
4 |
are supported as much as any other externally-hosted project is supported, |
5 |
although they can in a sense be considered downstream of Gentoo. |
6 |
|
7 |
In a meeting of the last council: |
8 |
http://www.gentoo.org/proj/en/council/meeting-logs/20070816.txt |
9 |
the consensus seemed to be that it is important as: |
10 |
<wolf31o2|work> if the document is incorrect and a package manager is |
11 |
released following the incorrect spec, you *will* break boxes |
12 |
|
13 |
It was brought in-house as there had been no development on the spec for a |
14 |
substantial period of time, and it was holding up portage releases. |
15 |
Additionally: |
16 |
<vapier> if the route we're going is that we dont add crazy things to |
17 |
EAPI/PMS unless we cover it in gentoo-dev, then having it be with the |
18 |
current package manager would lessen that maintenance |
19 |
|
20 |
The question which came up was: |
21 |
<robbat2> if we fork it to inhouse, will the inhouse fork still have enough |
22 |
momentum? |
23 |
As there had been no movement on the document for a year, it didn't seem |
24 |
important, but it is the situation now occurring: |
25 |
* Philantrop considers the place where the actual *work* takes place as |
26 |
authoritative until something significant happens in our repo. |
27 |
|
28 |
The concern I have with this is that PMS as developed by an external team is |
29 |
now being seen as authoritative for the whole of Gentoo. |
30 |
|
31 |
<zmedico> EAPI bumps should be based on input from the general ebuild |
32 |
developer community I think, since the the purpose of EAPI bumps is to give |
33 |
them features that they want. |
34 |
|
35 |
I accept that occasional threads are posted to dev m-l about proposals in |
36 |
PMS, but that is not the same as moving back to a situation where perhaps |
37 |
the fundamental Gentoo spec is developed by an upstream software provider. |
38 |
|
39 |
It has technical implications for the interoperability of all package |
40 |
managers, and if one of those teams is to be responsible for its |
41 |
development, I feel it should be the portage ones who have the final word |
42 |
on what is, and is not, "authoritative" for all Gentoo devs writing |
43 |
ebuilds. |
44 |
|
45 |
If that's about to change, I for one think it's a bad idea. |
46 |
|
47 |
Interesting article wrt the cat herd ;) s/guild/team/; s/alliance/project |
48 |
http://www.escapistmagazine.com/articles/view/issues/issue_124/ |
49 |
2645-Riding-the-Failure-Cascade |
50 |
<that's all on one line> |
51 |
"An effective protection for any guild is to simply have fun." |
52 |
|
53 |
|
54 |
-- |
55 |
gentoo-project@g.o mailing list |