1 |
On Sat, Jun 6, 2020 at 7:49 PM Jonas Stein <jstein@g.o> wrote: |
2 |
> |
3 |
> our concept of "Projects" (Herds in the past) maintaining packages has |
4 |
> several problems. |
5 |
|
6 |
You might want to search the list archives as many of the issues |
7 |
you've raised have been discussed extensively. There was never a |
8 |
complete push to fix things, but most project removals/etc have been |
9 |
along the lines of what has been discussed. |
10 |
|
11 |
While tangential, I'll point out that there have been similar |
12 |
discussions around appropriate uses of eclasses and there are some |
13 |
loose parallels for when eclasses make sense. |
14 |
|
15 |
> * Many projects are too heterogeneous |
16 |
> Projects should only maintain either |
17 |
> a) many similar packages such as libraries (like Perl, Python) or |
18 |
> b) very few strong correlated packages (like KDE, Kernel, Xfce) |
19 |
> |
20 |
> It makes no sense to group packages by usage as in |
21 |
> Science, Games, Theology, Sound, Netmon, Video, Electronics... |
22 |
|
23 |
...graphics... |
24 |
|
25 |
This is the gist of the outcome of previous discussions. Projects |
26 |
make sense when developers actually work TOGETHER to maintain things. |
27 |
Nobody who works on qt is going to just upgrade one component of qt |
28 |
without talking to the other maintainers. It makes sense for those |
29 |
packages to be managed by a project. |
30 |
|
31 |
Historically a lot of projects worked more like "tags" as an |
32 |
alternative way of grouping packages other than categories. While |
33 |
tags are a great idea projects are a terrible way to implement them. |
34 |
|
35 |
> I think we should first find a consent about the following questions |
36 |
> before someone deletes projects. |
37 |
|
38 |
In general I'm a fan of announcing things like this BEFORE doing them. |
39 |
However, I don't think they need pre-approval when they make sense. |
40 |
If anything we haven't been doing it often enough. |
41 |
|
42 |
I don't see any point in bringing back graphics though - if somebody |
43 |
who actually intends to lead such a project wants to speak up on that |
44 |
they should certainly do so, but it sounds like it is just a vestige |
45 |
of an old herd that probably never worked as an actual team. |
46 |
|
47 |
People reading the thread shouldn't think that this has anything to do |
48 |
with the importance of the individual packages. This is purely about |
49 |
how devs are organized around them. |
50 |
|
51 |
Some of what you wrote was more about our larger meta-structure and |
52 |
how devs maintain packages in general. That has also been discussed |
53 |
quite a bit, like having a core group of devs who don't maintain any |
54 |
individual packages and all they do is QA pull requests from a much |
55 |
larger pool of individuals who do care about packages. There are a |
56 |
lot of pros and cons to that and I won't rehash the previous |
57 |
discussions here. That isn't to discourage anybody from doing so - I |
58 |
mainly just want to point out that this stuff is in the archives. |
59 |
|
60 |
-- |
61 |
Rich |