1 |
<snip> |
2 |
> > Remember that simply making something easier for you isn't a valid reason for |
3 |
> > hacking up catalyst internals that much. |
4 |
> > |
5 |
> This puzzles me, if making a tool easier to use for it's users isn't a |
6 |
> valid reason for hacking at the tool, then what is ? |
7 |
> I understand issues with code-quality, reluctance to touch internals and |
8 |
> show me code before talk.......... |
9 |
</snip> |
10 |
|
11 |
The reasoning is quite simple. The target "users" of catalyst are first, |
12 |
foremost, and finally members of Gentoo's Release Engineering team. The |
13 |
fact that other people use it is a byproduct of making the code |
14 |
available for such use, not the actual intention. When considering |
15 |
enhancement requests they have to filter through 3 major questions. |
16 |
|
17 |
1). Is this functionality going to make catalyst easier to use or more |
18 |
robust as *Gentoo's* release management tool. |
19 |
|
20 |
If it doesn't make the job of releasing *official* Gentoo media easier |
21 |
then we fall to question 2. |
22 |
|
23 |
2). Is this feature in enough public demand and can enough use cases for |
24 |
it be provided that even though it won't necessarily enhance the process |
25 |
of building *official* release materials. |
26 |
|
27 |
If so then question 3 comes into play. |
28 |
|
29 |
3). Can it be done without complicating the code enough that Gentoo's |
30 |
capability to make reproducible releases is impaired *and* without |
31 |
making harder to maintain and/or extend the code for the purpose of a |
32 |
Gentoo's official releases. |
33 |
|
34 |
Again I want to stress that the fact that other people use catalyst is |
35 |
nice, and we encourage it to a certain extent, but the purpose of |
36 |
catalyst is to build official Gentoo media, no more, no less. |
37 |
|
38 |
--Dan |