1 |
Jorge Manuel B. S. Vicetto wrote: |
2 |
> I feel I should point out that catalyst is Release Engineering's |
3 |
> team release tool and not a "toy" for people to tinker with. |
4 |
|
5 |
Toy? Saying that other people's use of catalyst is only play, while |
6 |
releng is the only serious user, is really spitting in the face of |
7 |
everyone who uses catalyst. Maybe not so helpful. |
8 |
|
9 |
Meeting you I think you seemed sensible enough that you of course |
10 |
understand that catalyst is equally much a tool for all it's users. |
11 |
|
12 |
|
13 |
> I appreciate the interest all of you are showing for the tool and I |
14 |
> appreciate any improvements, but I and other releng team members need |
15 |
> this tool to work for us to have releases. |
16 |
|
17 |
No problem. Like every other consumer of open source tools you simply |
18 |
need to pick the version you choose to use carefully, so that it |
19 |
works for you. This case is not different from any other tool issue. |
20 |
|
21 |
|
22 |
> >> For a significant change like this, |
23 |
> > |
24 |
> > "significant" is so subjective though. |
25 |
> |
26 |
> It did made a significant change to the dependencies of catalyst. |
27 |
|
28 |
No, not really. It added one dependency, which is hardly significant. |
29 |
As has already been shown (by others than William, might I add) |
30 |
further indirect dependencies are really a bug in the asciidoc |
31 |
ebuild, and should be fixed there. Since you are all developers |
32 |
(while I am not) you could actually *already* have eliminated the |
33 |
point of contention - but noone has bothered and instead you're |
34 |
writing email complaining about how a little bit of progress is |
35 |
ruining your workflow. (This is how it looks anyway.) |
36 |
|
37 |
|
38 |
> I haven't checked it closely yet, |
39 |
|
40 |
Maybe that's actually wise, to determine how significant the change |
41 |
is? |
42 |
|
43 |
|
44 |
> William is not the only one to have concerns about this change. |
45 |
|
46 |
He was so far the only one who voice any, and they weren't so nicely |
47 |
expressed. |
48 |
|
49 |
|
50 |
> this list probably had little if any releng members. As this is a |
51 |
> releng tool, |
52 |
|
53 |
Either "your" catalyst is an open source project or it is not. If it |
54 |
is not then you need to hide it away in a secret internal repo so |
55 |
that noone else in the world can access it. Or you can just do what |
56 |
the rest of the world does; verify your tools before expecting them |
57 |
to work. |
58 |
|
59 |
I understand that you want stable tools, but if you want frozen tools |
60 |
then you need to do that on your own - because other catalyst users |
61 |
can and will want to change things. Absolutely not very often, but |
62 |
apparently often enough that it's a problem for releng to continue |
63 |
be part of the catalyst community. Or? |
64 |
|
65 |
|
66 |
> not having us around to "object" doesn't make it ok to commit |
67 |
> changes without ensuring releng is ok with the changes. |
68 |
|
69 |
If so, that in itself is reason for forking, as was discussed. |
70 |
|
71 |
I would have zero bad feelings about that, because the wants and |
72 |
needs simply seem to be different between releng and all other |
73 |
catalyst users. |
74 |
|
75 |
|
76 |
> This is about making sure that the people interested as well as the |
77 |
> direct consumers of the tool are ok with any proposed changes. |
78 |
|
79 |
You are neglecting every other user than releng. That means me. That |
80 |
sucks. |
81 |
|
82 |
|
83 |
> I'm sure no one wants to risk causing a split that could lead to either |
84 |
> releng assuming control of catalyst again or worse causing a fork in the |
85 |
> code. |
86 |
|
87 |
Actually, forking is indeed the one and only productive step when |
88 |
different users have different enough requirements and expectations. |
89 |
|
90 |
|
91 |
//Peter |