| 1 |
On Sun, Nov 16, 2014 at 7:23 PM, hasufell <hasufell@g.o> wrote: |
| 2 |
> |
| 3 |
> |
| 4 |
> So the idea is the following: |
| 5 |
> * stop recruiting |
| 6 |
> * move clearly themed overlays/projects out of the tree which are |
| 7 |
> already practically working outside of the tree (e.g. science, |
| 8 |
> haskell, ...) |
| 9 |
> * fix the tools (never ending git story, probably a lot of work needed |
| 10 |
> on the overlay support front etc) |
| 11 |
> * focus on the core of gentoo as in: provide abstraction, tools and |
| 12 |
> the basic structure for people to do cool things. Right now we are |
| 13 |
> just focussing on keeping the ebuild machinery going, while the rest |
| 14 |
> pretty much goes downhill. Fast. |
| 15 |
> * be more open, work more with the community, not just through bugzilla |
| 16 |
> * review overlays, contribute to overlays |
| 17 |
> * have a list of high-quality overlays, maybe with a few notes about |
| 18 |
> them (is it themed? does it conflict with stuff?) |
| 19 |
> * I can't hold it but say: make ebuilds suck less, so people enjoy |
| 20 |
> contributing |
| 21 |
|
| 22 |
So, most of your post I'm perfectly fine with. |
| 23 |
|
| 24 |
I just suggest that you do it this way: |
| 25 |
|
| 26 |
* move clearly themed overlays/projects out of the tree which are |
| 27 |
already practically working outside of the tree (e.g. science, |
| 28 |
haskell, ...) |
| 29 |
* fix the tools (never ending git story, probably a lot of work needed |
| 30 |
on the overlay support front etc) |
| 31 |
* focus on the core of gentoo as in: provide abstraction, tools and |
| 32 |
the basic structure for people to do cool things. Right now we are |
| 33 |
just focussing on keeping the ebuild machinery going, while the rest |
| 34 |
pretty much goes downhill. Fast. |
| 35 |
* be more open, work more with the community, not just through bugzilla |
| 36 |
* review overlays, contribute to overlays |
| 37 |
* have a list of high-quality overlays, maybe with a few notes about |
| 38 |
them (is it themed? does it conflict with stuff?) |
| 39 |
* I can't hold it but say: make ebuilds suck less, so people enjoy |
| 40 |
contributing |
| 41 |
|
| 42 |
THEN IF EVERYTHING IS GOING GREAT |
| 43 |
|
| 44 |
* stop recruiting |
| 45 |
(or more likely, shift the recruiting emphasis) |
| 46 |
|
| 47 |
The problem with doing it the other way is that the most likely result |
| 48 |
is that Gentoo will just die without any of the rest of this stuff |
| 49 |
happening. The areas you want us to focus on exclusively seem to be |
| 50 |
the areas that almost none of the current devs actually want to work |
| 51 |
on. |
| 52 |
|
| 53 |
I'm not a big fan of solutions that involve abandoning something that |
| 54 |
works somewhat well in favor of taking a chance on something new that |
| 55 |
hasn't even been tried. There is no reason that somebody couldn't |
| 56 |
build all the infrastructure for overlays, reviews, etc before we stop |
| 57 |
doing things the old way. Just as most current devs won't work on all |
| 58 |
the core Gentoo features you want them to work on, they won't work on |
| 59 |
your new distributed stuff either, even if you forbid them from |
| 60 |
working on anything else. People work on the things that interest |
| 61 |
them, and if that stuff interested them, they'd already be doing it. |
| 62 |
|
| 63 |
By all means start a project to build the "New Gentoo" and recruit |
| 64 |
people to join it. |
| 65 |
|
| 66 |
The only thing you can really do with policy is tell people NOT to do |
| 67 |
something. It should really be reserved for stuff that is actively |
| 68 |
harmful, and maintaining packages isn't harmful. |
| 69 |
|
| 70 |
-- |
| 71 |
Rich |
Archives