| 1 |
All -- |
| 2 |
|
| 3 |
In relation to GLEP 19[1], I'd like to take a step back and ensure we've |
| 4 |
got all the requirements defined for this particular project. |
| 5 |
|
| 6 |
Leaving behind the implementation details and focusing instead on pure |
| 7 |
requirements, I'd like to gather input from the group. So far, we have: |
| 8 |
|
| 9 |
* A frozen tree, with pre-defined update intervals. (this tree may be part |
| 10 |
existing tree or a separate tree -- that's an implementation detail to be |
| 11 |
covered later) |
| 12 |
* All ebuilds in this 'frozen tree' are guaranteed to be available for a |
| 13 |
certain period of time so admins can plan their upgrades more accurately. |
| 14 |
|
| 15 |
And...what else? |
| 16 |
|
| 17 |
Now, to try and contain this somewhat, please keep things on topic. i.e. |
| 18 |
let's not take this down the "portage should have a database back-end" or |
| 19 |
"please create an ebuild for OpenGroupware! kthx." |
| 20 |
|
| 21 |
The general guideline we're trying to follow is improving the |
| 22 |
functionality of the portage tree to make things like updating/emerging |
| 23 |
easier for enterprise environments. |
| 24 |
|
| 25 |
Also, please don't discuss implementation details. That comes later. |
| 26 |
Things like "it should be a separate tree" or "we should have keywords!!" |
| 27 |
are not part of this particular discussion. |
| 28 |
|
| 29 |
So, with that in mind, have at it. :) |
| 30 |
|
| 31 |
--kurt |
| 32 |
|
| 33 |
|
| 34 |
[1]http://www.gentoo.org/proj/en/glep/glep-0019.html |
Archives