| 1 |
On Fri, Mar 11, 2022 at 9:14 AM Peter Stuge <peter@×××××.se> wrote: |
| 2 |
> |
| 3 |
> Matt Turner wrote: |
| 4 |
> > repoman is inferior to other tooling mentioned. The other tooling is |
| 5 |
> > actually run in CI. |
| 6 |
> |
| 7 |
> The problem seems to be that CI is running something other than |
| 8 |
> developers run, not the other way around. |
| 9 |
> |
| 10 |
> |
| 11 |
> > Developers should get the same warnings locally as in CI. |
| 12 |
> |
| 13 |
> I agree. And developers and their tools should not have to bend to |
| 14 |
> whatever CI does, I think the other way around makes more sense. |
| 15 |
> |
| 16 |
> |
| 17 |
> CI doesn't use repoman because of performance issues. |
| 18 |
|
| 19 |
I think the problem is that making committers use the CI tool is |
| 20 |
technically a fairly straightforward change; while everything you |
| 21 |
discuss further in the thread is not; because it implies people will |
| 22 |
work on improving tools that have shown little or no progress on |
| 23 |
improving in the 15 years I've been in Gentoo. |
| 24 |
|
| 25 |
> |
| 26 |
> What if pkgcore evolves to provide a portage-compatible API? |
| 27 |
|
| 28 |
No API is planned and no one is working on it. |
| 29 |
|
| 30 |
> |
| 31 |
> Then CI could use repoman without performance problems, and |
| 32 |
> developers would also enjoy improved performance, without spending |
| 33 |
> time on replacing tooling which already works for them. |
| 34 |
|
| 35 |
The benefit of getting people to change their behavior is that the |
| 36 |
benefits (less breakage, better tooling) are achieved now; as opposed |
| 37 |
to in some hypothetical future where repoman is improved. |
| 38 |
Note that we have been waiting for 'improved repoman' for about 8 |
| 39 |
years; so..I'm not willing to bet on it when we have better tooling |
| 40 |
that works today and the primary complaint is that...what exactly? |
| 41 |
|
| 42 |
The new workflow with pkgcheck was announced at the end of 2019: |
| 43 |
https://blogs.gentoo.org/mgorny/2019/12/12/a-better-ebuild-workflow-with-pure-git-and-pkgcheck |
| 44 |
|
| 45 |
It's been 2 years, I think we can bring everyone into the fold here. |
| 46 |
|
| 47 |
> |
| 48 |
> Looking into the future then maybe portage could even come to use |
| 49 |
> pkgcore for the low-level things that pkgcore does, then even users |
| 50 |
> could enjoy improved performance. |
| 51 |
|
| 52 |
Many things could happen but again, if you talk to people who work on |
| 53 |
pkgcore; there is no concrete plan for this. So I don't see why we are |
| 54 |
betting on it happening. |
| 55 |
|
| 56 |
If you read radhermit's blog: |
| 57 |
https://pkgcraft.github.io/posts/timesink-chronicles/ you can get one |
| 58 |
take on the project and why it struggled. |
| 59 |
|
| 60 |
-A |
| 61 |
|
| 62 |
> |
| 63 |
> |
| 64 |
> Right? |
| 65 |
> |
| 66 |
> //Peter |
| 67 |
> |
Archives