| 1 |
On Thu, 15 Aug 2013 00:19:40 +0200 |
| 2 |
hasufell <hasufell@g.o> wrote: |
| 3 |
> On 08/14/2013 10:56 PM, Markos Chandras wrote: |
| 4 |
> > If you want PMS to go away, and call portage the one-and-true PM for |
| 5 |
> > Gentoo, then it's probably something for the Council to decide. |
| 6 |
> > |
| 7 |
> |
| 8 |
> I think that would make sense. We don't have enough resources for such |
| 9 |
> fun and overcoming PMS burdens has been a major concern for everyone |
| 10 |
> who is looking to improve basic functionality. |
| 11 |
|
| 12 |
What PMS burdens? Give one example of a feature that the Council has |
| 13 |
approved that was abandoned because of PMS. |
| 14 |
|
| 15 |
> In the end, people rather go for eclass solutions or just give up. |
| 16 |
> That has brought us to the current discussion, to base.eclass |
| 17 |
|
| 18 |
base.eclass was a legacy from the old pre-natively-supported |
| 19 |
implementation of eclasses. Unfortunately for reasons entirely |
| 20 |
unrelated to PMS, a few developers haven't bothered moving away from |
| 21 |
it. |
| 22 |
|
| 23 |
> and to the multilib eclasses with a very painful way of migration. |
| 24 |
> Mind that I am an author of one of those eclasses as well, so I'm not |
| 25 |
> generally objecting. But it's a fact that portage multilib was held |
| 26 |
> back basically by useless PMS politics, so that we can support |
| 27 |
> alternative PMs like paludis. |
| 28 |
|
| 29 |
No, it was held back because no-one was able to explain what was |
| 30 |
changed, and because there was no agreement between developers that |
| 31 |
whatever it was that was changed was the right way to do it. The |
| 32 |
Council hasn't approved the use of Portage multilib. |
| 33 |
|
| 34 |
> And that's not the only thing that is annoying about PMS and the |
| 35 |
> politics behind it. |
| 36 |
> |
| 37 |
> Gentoo has become very slow in terms of decision making and progress. |
| 38 |
> GLEPs to improve security are "not implemented" for _years_ and people |
| 39 |
> have no idea whether we need a PMS section for that or not. It wasn't |
| 40 |
> really discussed and not one bothers anymore. |
| 41 |
|
| 42 |
Again, nothing to do with PMS. Getting a feature that has Council |
| 43 |
approval into PMS typically takes a day or two. The delays on the |
| 44 |
security GLEPs are down to Portage and to git migration, not PMS. |
| 45 |
|
| 46 |
PMS has *helped* with progress, not slowed it down: it has allowed us |
| 47 |
to experiment with new features in other, quicker-to-develop package |
| 48 |
managers before having to spend the effort implementing them in |
| 49 |
Portage. Have a look at features added in EAPIs 1 and later: at a guess |
| 50 |
half of them were the direct result of testing in other package |
| 51 |
managers. |
| 52 |
|
| 53 |
-- |
| 54 |
Ciaran McCreesh |
Archives