Alfredo Braunstein wrote:
Abdelrazak Younes wrote:
For fuck sake, the commit logs are there to look at! Sorry Christian,
it's not against you but I've already gone through the lengthy process
of proving myself to Lars and others. I am simply not going to do it
again.
It's not about proving yourself, it is about making the change
understandable: giving a rationale and guidelines you followed for a given
change so someone else can also follow them.
I think I've done that already. If nobody listen (I am not talking about
you) then I am not going to explain it again.
If a change in a branch is so distributed/complicated/diffiult that it
can't be converted into several managable patches, something else is
needed. Perhaps some kind of overall documentation or design document
(complementing the commit/log messages)? That would at least help other
developers to review the changes inside the branch more effectively.
Has anyone other than you reviewed the branch?
How could I know? I am simply asking for help in merging this branch and
all I get is "prove us that this is the right thing to do". To this, I
say no, I am not going to prove anything. If nobody sees that my work is
beneficial to LyX, I'll simply maintain my own branch and forget about
you guys.
Come on, don't be so childish. I don't know the others, but I think the
general idea is correct and the right path. However...
Let me give you my view about this review process: when you work hard in one
area, you become sort of an expert in that area and in particular in the
work you've done. For you explaining the changes (that is grouping related
changes in one patch and adding one explanation for each patch, giving
general guidelines you followed/problems you found) is some work but not
impossible.
Let me repeat it again:
one Buffer -> one BufferView -> one WorkArea.
one LyXView will create WorkAreas on demand.
As simple as that.
Abdel.
