[Unison-hackers] Move Unison to Git

[Pascal Bach]

> My main concern about moving to an issue tracking system is that I'm not yet completely convinced that it will serve the community's needs better than the current (admittedly haphazard) use of mailing lists.
> It's true that having someplace to collect and classify issues will make it easier for people to report things.  My question, though, is: Who will be listening to these reports?

Currently it is hard to see what the current issues are especially if
you are new to the mailing list. And its not always clear what got
fixed an what issues are still open. One example is that there are
patches in the debian packages which are not specific to the debian
packages and that should have been included in the upstream version of
unison. So I think an issue tracker would make it easier to get an
overview of all the issues and better track them.

> At the moment, issues get discussed on the mailing list(s), where they are seen by a pretty large group of users and developers.  Many issues arise from either misunderstandings or people trying to use Unison in unusual ways, and responses/answers to these often come directly from the user community.  If such issues start getting reported in a tracking system, they're going to be seen by a much smaller group of people -- basically just a few developers and packagers -- and the chances of them getting any response at all are much less.

I agree and I think the mailing list will still be an important
communication and support channel. And I think we should make a clear
separation between usage problems and bugs/issues/requests. This means
if something gets discussed on the mailing list and it becomes clear
there is a bug involved someone should open a ticket in the
bugtracker. The same thing the other way around, if someone comes up
with a question on the bugtracker he should be directed towards the
mailing list and the bug should be closed. This would give us a clean
separation.

> Before making a change in the way we do business, I'd like to get a better understanding of what is *not* working in the present way and explore whether it can be addressed directly.  (In particular, if there are people that would like to be contributing actively to Unison's maintenance and/or development but that feel hampered in doing so, I'd love to discuss specifics of how we can make things work for you.)

I could take care of the bug tracker and do the bug triage. Those who
are involved could directly subscribe to the bugtracker [preferred]
(or I could bring up new bugs on the mailing list if necessary [less
preferred]). I want to note that launchpad has a sophisticated Email
interface to interact with bugtrackers.
(https://help.launchpad.net/Bugs/EmailInterface).


> Moving away from this system would not actually change very much.  If it would simplify life for people that want to get Unison sources via Git (or whatever), we could just make all changes (even in the minor component) by hand.  This would mean (a) it would take a tiny bit more work to release an update to a beta- or stable version [but this is not a big deal], and (b) the trunk version would always have minor version number 0 because we would not bother to update it on every checkin [but this is fine: it's very rare to need to talk about a trunk version that is not the very most current one].

I currently did exactly this. While using bzr/git I just set the last
number by hand.

Best
Pascal