Your explanations are all good. Still, I wouldn't jump to adopting
the git philosophy before establishing what the LyX dev philosophy
should be. I think if we established a coding guideline for LyX devs
first, we could assess better the advantages of different versioning
tools and a of potential switch. However, I might have missed such
discussion if it did happen. In which case someone could please
point me at the thread.
Removing all allusions to particular versioning tools, if I am
reading you properly, what you seem to be saying is we should:
a) make new code available early
Yes, even when it is unfinished, unstable or not everyone has agreed
that the feature should go in. What we then do is to create a new
branch, and only merge this branch into the "experimental" branch.
b) keep the main dev branch bug free
That would be the ideal indeed. But, as we don't have a proper testing
procedure, we don't have the manpower to double-check and test all
code, and besides that none or only a few of us are professional
software developers, I pretty much expect this not to happen. However,
we should be able to avoid the largest bugs by at least have -some-
testing before getting it into the main branch.
c) develop new features in branches
d) have every completed new features in main dev branch
e) keep the main dev branch free of incomplete features
Yes, create a new "experimental" branch, develop the feature, mark
the feature as finished, from then on, the feature will be regularly
merged into the "development" branch. When all bugs and itches are
ironed out, the feature can be merged into the "master" branch from
which we will eventually create the next release.
f) use commit log filters (doc/translations/web page/cosmetic/etc.)
I'm not sure what you mean with this. My idea is that all documentation,
translations, etc. will go into the respective branch. Only
when a new release is set up, the translations and documentation will be
merged into the master branch.
We could do the same for cosmetics, but I'm not sure about that. At
least we can get rid of restyling some new introduced code.
g) make it easier to review patches (mailing list is a pain)
The problem is not with the mailing list. The problem IMHO is with the
fact that it is difficult to review a patch if it is only a little part
of a much larger patch committed earlier. Or when a feature seemed to
be so complex that its development got scattered into 20 different
patches correcting each other, introducing stuff that might have been
forgotten in other patches, or fixing newly introduced bugs.
h) have the ability to rewrite commit history (squash commits)
Yes, I want to have a nicely written history without all the typo
corrections, style corrections, whitespace corrections and so forth.
i) interact more
Yes, if someone wrote a new feature but has difficulties in writing
the lyx2lyx feature, someone else might want to help out. Now, we
either have to commit an unfinished patch to svn and ask for help.
Afterwards it might be forgotten that this has still to be do. Or
send the patch to the mailing list, which is a pita for others to
commit themselves, have a dirty working tree conflicting with their
own development and so forth.
Right?
Yes. We might not want to take this into extreme and there are also
some practicalities that need to be iron out. But it would be good
to seriously think how we can improve the development along the lines
described by a) to i).
Vincent
