| 1 |
Jeremy Olexa <darkside@g.o> posted 4A0B783C.2000501@g.o, |
| 2 |
excerpted below, on Wed, 13 May 2009 20:47:40 -0500: |
| 3 |
|
| 4 |
> I don't see any reason to create a team that duplicates the sunrise |
| 5 |
> work. Keep in mind, I am against pretty much any overlay, I think work |
| 6 |
> should be kept in the main tree. But, for ebuild maintenance with |
| 7 |
> limited developer time, sunrise just makes sense(tm). |
| 8 |
|
| 9 |
This was my first reaction as well. How is this different than sunrise? |
| 10 |
If it's not duplicative, map out the difference and the proposed |
| 11 |
relationship of apparently duplicative projects. |
| 12 |
|
| 13 |
Maybe you just want Sunrise in the main tree instead of as a dedicated, |
| 14 |
supervised overlay. There were people with VERY strong feelings against |
| 15 |
Sunrise, to the point I believe at least one dev opposing it resigned |
| 16 |
over it and other boosting it were disciplined. Are you ready to take on |
| 17 |
that sort of opposition to get it in-tree? Maybe it's time to have that |
| 18 |
debate. |
| 19 |
|
| 20 |
> Some other possible directions include: 1) maintainer-needed team - |
| 21 |
> Where a group maintains the set of 761 m-needed packages. |
| 22 |
|
| 23 |
Right. The new proposal needs to address this as well. Why ignore the |
| 24 |
existing m-needed packages begging for care in the tree, just to |
| 25 |
effectively shove a bunch more in. |
| 26 |
|
| 27 |
> 2) proxy maint project[2] - Where a group helps users commit to the main |
| 28 |
> tree, very similar to the sunrise project. Very similar to this proposal |
| 29 |
> but better conserves our developer time. |
| 30 |
|
| 31 |
Yet another existing solution this proposal would seem to duplicate. If |
| 32 |
it's different, map out how and how the relationship in the apparent |
| 33 |
overlap should be managed. |
| 34 |
|
| 35 |
If there's a place for the new project and maybe there is, the |
| 36 |
differences from and relationship with the Sunrise and proxy-maint |
| 37 |
projects, and the method of bringing in or justification for ignoring the |
| 38 |
hundreds of existing m-needed packages while arguably creating more, |
| 39 |
needs mapped out. Alternatively, bend the proposal into a status change |
| 40 |
for one or all of the above, and call a debate on that. |
| 41 |
|
| 42 |
-- |
| 43 |
Duncan - List replies preferred. No HTML msgs. |
| 44 |
"Every nonfree program has a lord, a master -- |
| 45 |
and if you use the program, he is your master." Richard Stallman |
Archives