| 1 |
>>>>> On Tue, 29 Oct 2013, Andreas K Huettel wrote: |
| 2 |
|
| 3 |
> Actually for asking this question you've picked the best example... |
| 4 |
|
| 5 |
> Imagine the poor KDE guys sorting out the language bindings for |
| 6 |
> Ruby, Python, Java, and C#. Each comes with its own approach to |
| 7 |
> solve the same problems, and with its own completely disjunct eclass |
| 8 |
> syntax. |
| 9 |
|
| 10 |
> Imagine updating your system after a while and then remembering that |
| 11 |
> you need to run python-cleaner and perl-updater (and what was the |
| 12 |
> syntax there again?). |
| 13 |
|
| 14 |
> Maybe there isn't too much overlap right now, but people talking to |
| 15 |
> each other would certainly help, and the problems are certainly |
| 16 |
> related. |
| 17 |
|
| 18 |
> This is the most important thing, and similar ideas also apply to |
| 19 |
> the two other proposals. (PR, CoC enforcement and Ops are certainly |
| 20 |
> related tasks?) |
| 21 |
|
| 22 |
The key question is if it is reasonable to organise things as a common |
| 23 |
project. This only makes sense if devs of the (to be) subprojects are |
| 24 |
working together to some degree. For example, do they have a common |
| 25 |
mailing list? (Turns out that in case of programming languages there |
| 26 |
is gentoo-dev-lang, but it seems to be inactive.) It is perfectly fine |
| 27 |
if people want to work together and organise themselves under an |
| 28 |
umbrella TLP. However, I don't expect that creating such a structure |
| 29 |
artificially would work, unless there is initiative from the projects |
| 30 |
themselves. |
| 31 |
|
| 32 |
Also the council has no power to decree a new project structure. |
| 33 |
GLEP 39 says that projects organise themselves, so we cannot force any |
| 34 |
project to convert itself from a TLP to a subproject. This would also |
| 35 |
mean that some of the language projects (like Common Lisp and Scheme) |
| 36 |
would be downgraded to third level. |
| 37 |
|
| 38 |
> There's two additional motivations from my side. |
| 39 |
|
| 40 |
> One is my stereotypical German preference for cleanlyness and order. |
| 41 |
> Or maybe it's just that part of leaving a professional impression is |
| 42 |
> also that you don't just have a messy list of unordered projects. |
| 43 |
|
| 44 |
That can be solved without introducing additional organisational |
| 45 |
structures. For example, by arranging the project list by some |
| 46 |
categories instead of alphabetical. |
| 47 |
|
| 48 |
> The other one is that on the long run we might reconsider the role |
| 49 |
> of umbrella project leads. I'm not so sure yet what we should do |
| 50 |
> there though... Strengthen, give them tasks? some loose oversight |
| 51 |
> that subprojects follow formalities? Abandon? |
| 52 |
|
| 53 |
Just ask them what they see as their role, and if the umbrella project |
| 54 |
is functional. |
| 55 |
|
| 56 |
Ulrich |
Archives