1 |
On 2/9/07, Mike Frysinger <vapier@g.o> wrote: |
2 |
> forking the package is retarded. maintain backward compability and there's no |
3 |
> reason to fork it. baselayout isnt Roy's package, it isnt my package, it |
4 |
> isnt anyone's. it belongs to Gentoo as a whole which means changes to it |
5 |
> affect everyone in the distribution. |
6 |
> -mike |
7 |
|
8 |
I totally agree with Mike here. Roy, here is what I suggest you do: |
9 |
|
10 |
1) maintain the existing baselayout and don't change things at all. |
11 |
|
12 |
2) start a new package called fastlayout and do whatever you wanna do |
13 |
with it. Be as innovative as you want to be with it. Change all the |
14 |
stuff in it that you want to change. Get people to test it and work on |
15 |
it with you. |
16 |
|
17 |
3) once fastlayout is done and mature and is obviously |
18 |
better/faster/more wonderful than the existing baselayout, *then* |
19 |
let's talk about it becoming baselayout-ng. |
20 |
|
21 |
I have learned from experience that you never want to start a project |
22 |
and call it "something"-ng. Doing so takes for granted that it will be |
23 |
the official replacement for the existing baselayout. Thus, every |
24 |
proposed change is now a potentially disruptive change, and people |
25 |
will want to review every design decision you make - and with good |
26 |
reason. People don't like change unless they can see the obvious |
27 |
benefits of such change. And it is hard for people to see these |
28 |
benefits when you are just in the planning stages. That's what we call |
29 |
a catch-22. |
30 |
|
31 |
Ever wonder why every official "portage-ng" project would die within |
32 |
weeks of being launched? This is why. The pkgcore/paludis model, where |
33 |
neither is blessed as being the eventual successor of portage, is a |
34 |
model that works. "something-ng" is not a model that works for any |
35 |
meaningful change for Gentoo. |
36 |
|
37 |
You have every right to scratch an itch, go scratch it. But it will be |
38 |
slow going if you refer to this effort as the eventual successor to |
39 |
baselayout. Making incremental changes to baselayout with no clear |
40 |
roadmap is a bad idea and people will be critical of anything you |
41 |
propose. It's *far* better for you to work independently and create |
42 |
something that, when it's ready, we can all switch over to because it |
43 |
is clearly better, well-integrated - and done. |
44 |
|
45 |
Structured this way, "fastlayout" is certainly a project that sounds |
46 |
like a great idea, and would I enjoy working on in some capacity - I |
47 |
have some ideas about this. I also think it would be a good idea to |
48 |
check out what other distributions are doing in this area. |
49 |
|
50 |
-Daniel |
51 |
-- |
52 |
gentoo-dev@g.o mailing list |