From alexandre at quessy.net Wed May 4 14:50:07 2011 From: alexandre at quessy.net (Alexandre Quessy) Date: Wed, 4 May 2011 14:50:07 -0400 Subject: [Unison-hackers] Move Unison to Git In-Reply-To: References: Message-ID: Hello dear Unison hackers, I just wanted to say I really enjoy working with Git, and I find it offers more useful features than Mercurial and Bazaar. It's the de-facto most widely use distributed SCM tool. It makes forks and merges very very easy. For tracking issues, I second Trac and Redmine. Also, I want to say - with respect - that I find it's a rather bad idea to tie version numbers to SVN revision numbers. Most of the project I worked on so far switch from SVN or Mercurial to Git at some point, which made referring to SVN revision numbers in Trac issues obsolete. Best, -- Alexandre Quessy http://alexandre.quessy.net/ From bcpierce at cis.upenn.edu Wed May 4 16:57:42 2011 From: bcpierce at cis.upenn.edu (Benjamin C. Pierce) Date: Wed, 4 May 2011 16:57:42 -0400 Subject: [Unison-hackers] Move Unison to Git In-Reply-To: References: Message-ID: <53F34575-A201-44A0-98CC-1B9250A2F4E5@cis.upenn.edu> Hi Pascal, > After some thinking I now believe that it would be best and easiest to > set up the Issue tracker on launchpad. The main reasons are. > - There is already a trunk import of unison into launchpad.net which > is always in sync with the real trunk. > - In my opinion Launchpad has on of the best issue trackers > - The bazaar revisions are in sync with the svn revisions so it is > easy to refer to a certain revision in a bug report as it doesn't > matter if you refer to bzr or svn. > > We don't need to use the rest of the launchpad features and we can > continue with the old code hosting and mailing list infrastructure. > > What do you think about my proposal? 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? 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. 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.) Best, - Benjamin > > Regards > Pascal > > On Mon, Apr 25, 2011 at 5:26 PM, Pascal Bach wrote: >> I know that Trac (http://trac.edgewall.org/) and Redmine >> (http://www.redmine.org/) have integrated issue trackers. You can even >> connect them with a (D)VCS of your choice. However you have to set >> them up yourself. (Or you could use a TurnkeyLinux appliance). >> >> On the other hand I think we could just use an issue tracker of some >> hosting site without using the rest. I know that this is possible with >> launchpad.net but I think it would work with others as well. >> >> Best >> Pascal >> >> On Thu, Apr 21, 2011 at 7:48 PM, Pierce Benjamin C. >> wrote: >>>> I must admit that -- with my Debian packager hat -- I would gladly >>>> welcome an issue tracker. This will help to forward upstream a lot of >>>> bugs. Most of the time, I need to forward a bug from the Debian BTS and >>>> just don't do it, because I have no time to discuss it on the mailing >>>> list. The mailing list also doesn't provide a pragmatic way to know if >>>> the bug is closed or not... >>> >>> If there is a free-standing issue tracker (not tied to some particular hosting or version control system) that can be set up with a small amount of effort (<1 hour), I would be open to discussing setting one up for Unison. >>> >>> Best, >>> >>> - Benjamin >>> >>> >>>> >>>>> >>>>> >>>>>> If there are active maintainers / compilers of Unison distributions >>>>>> who feel that they could do their jobs more effectively with commit >>>>>> rights to the main SVN repository, just let me know and we can make >>>>>> that happen. >>>>> >>>>> It would be interesting to hear what version control the packagers use >>>>> and if not SVN how you solve the problem that the program version >>>>> numbering depends on SVN. If you are packager please let us know how >>>>> you do it. >>>>> >>>> >>>> You can easily manage commit rights (just as any forge in fact) on the >>>> OCaml Forge, by adding people to the project. >>>> >>>> Cheers, >>>> Sylvain Le Gall >>>> -- >>>> My company: http://www.ocamlcore.com >>>> Linkedin: http://fr.linkedin.com/in/sylvainlegall >>>> Start an OCaml project here: http://forge.ocamlcore.org >>>> OCaml blogs: http://planet.ocamlcore.org >>>> >>>> >>>> _______________________________________________ >>>> Unison-hackers mailing list >>>> Unison-hackers at lists.seas.upenn.edu >>>> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers >>> >>> _______________________________________________ >>> Unison-hackers mailing list >>> Unison-hackers at lists.seas.upenn.edu >>> http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers >>> >> > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From bcpierce at cis.upenn.edu Wed May 4 17:04:29 2011 From: bcpierce at cis.upenn.edu (Benjamin C. Pierce) Date: Wed, 4 May 2011 17:04:29 -0400 Subject: [Unison-hackers] Move Unison to Git In-Reply-To: References: Message-ID: <96ABAA04-F867-4B64-93A2-8CC2A85FEFFF@cis.upenn.edu> > Also, I want to say - with respect - that I find it's a rather bad > idea to tie version numbers to SVN revision numbers. > Most of the project I worked on so far switch from SVN or Mercurial to > Git at some point, which made referring to SVN revision numbers in > Trac issues obsolete. In practice, we don't actually refer to SVN revisions when discussing Unison issues. The SVN revision is really only used to automatically make sure that the minor version number (the X in 2.40.X) changes every time there's a checkin. The major version numbers are managed by hand: the first component is a constant in practice, while the middle component changes every time there is a wire protocol or archive format change. 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]. - Benjamin > > Best, > -- > Alexandre Quessy > http://alexandre.quessy.net/ > _______________________________________________ > Unison-hackers mailing list > Unison-hackers at lists.seas.upenn.edu > http://lists.seas.upenn.edu/mailman/listinfo/unison-hackers From pascal.bach at gmx.ch Sat May 7 04:12:13 2011 From: pascal.bach at gmx.ch (Pascal Bach) Date: Sat, 7 May 2011 10:12:13 +0200 Subject: [Unison-hackers] Move Unison to Git In-Reply-To: <96ABAA04-F867-4B64-93A2-8CC2A85FEFFF@cis.upenn.edu> References: <96ABAA04-F867-4B64-93A2-8CC2A85FEFFF@cis.upenn.edu> Message-ID: > 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 From alexandre at quessy.net Sat May 7 09:05:57 2011 From: alexandre at quessy.net (Alexandre Quessy) Date: Sat, 7 May 2011 09:05:57 -0400 Subject: [Unison-hackers] Move Unison to Git In-Reply-To: References: <96ABAA04-F867-4B64-93A2-8CC2A85FEFFF@cis.upenn.edu> Message-ID: Hello, 2011/5/7 Pascal Bach : > 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). > I can help you guys with the SVN to Git transition if you choose it. Just say yes, and I will do it, preserving history and the likes. A+, -- Alexandre Quessy http://alexandre.quessy.net/ From bcpierce at cis.upenn.edu Sat May 7 10:55:40 2011 From: bcpierce at cis.upenn.edu (Benjamin C. Pierce) Date: Sat, 7 May 2011 10:55:40 -0400 Subject: [Unison-hackers] Move Unison to Git In-Reply-To: References: <96ABAA04-F867-4B64-93A2-8CC2A85FEFFF@cis.upenn.edu> Message-ID: > 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. How would an issue tracker have helped with this example? Seems like the problem there is that the debian packager needs to have an easier path to committing changes to the upstream version. > So I think an issue tracker would make it easier to get an > overview of all the issues and better track them. I remain to be convinced of this. However... > 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. I'm wondering whether we could introduce the bug tracker while keeping more or less the same social structure that we have now. Specifically, we'd: - create a LaunchPad project for Unison - set up a bug tracker for it - subscribe unison-users as a "project supervisor" so that people on the list hear about all bug-related traffic - encourage people to submit bug reports via the tracker rather than directly to the list Clearly, this organization has the disadvantage that it might generate a lot more traffic to the wide-readership list. If this turns out to be the case, we can switch the subscription to unison-hackers only. The advantage is that it more or less replicates the communication pattern that we have now, with the extra structure of the issue tracker for helping keep track of what's happened. > I could take care of the bug tracker and do the bug triage. This would be great! I've created a project "unisonbugs" at launchpad.net ("unison" was already taken, unfortunately, by the ubuntu packagers for Unison; maybe we should merge the two?). Now I need to know how to add you as an administrator. Then we should be set to go (if you think my proposal above is reasonable). - Benjamin From bcpierce at cis.upenn.edu Sat May 7 15:17:31 2011 From: bcpierce at cis.upenn.edu (Benjamin C. Pierce) Date: Sat, 7 May 2011 15:17:31 -0400 Subject: [Unison-hackers] Move Unison to Git In-Reply-To: References: <96ABAA04-F867-4B64-93A2-8CC2A85FEFFF@cis.upenn.edu> Message-ID: > I can help you guys with the SVN to Git transition if you choose it. > Just say yes, and I will do it, preserving history and the likes. Despite the subject of this thread, we're only discussing adding a bug tracker right now. As previously discussed, I'm reluctant to spend time switching version-control systems. Best, - Benjamin