Hi, As git was yearned for once more at IRC, I hereby state that I do not have any technical reason to stubbornly stick to bzr (and Launchpad) for pocl ;)
The main reasons that led to choose bzr over the several DVCS alternatives in 2008 (for TCE from which pocl inherited the decision) are not valid anymore. The main reasons back then were that there was no clear winner in DVCSs, bzr had native Windows support, and the centralized mode had short learning curve to svn/cvs users. Nowadays everyone is familiar with the git workflow, it is probably the most popular one now, and there seems to be even a native Windows client. It has a big weight if most of the developers are used to work with it in comparison to be forced to use something they do not like or are not motivated to learn (due to its obscurity) so... it's just a matter of arrangements. Questions it boils down to: 0) Should we move to git? From the previous discussions, I guess the other active developers (who are affected mostly by the transition) clearly vote for yes and I do not object. 1) Where to move the repository? It should have good issue/bug tracking too. Is GitHub the best? The most active developers should have the choice. I do not have an opinion on this. 2) How is the transition done? bzr-git can be used to preserve version history? What about the bugs? Just move open ones manually and leave the closed ones be? 3) Who does the transition? On 06/09/2013 09:02 PM, Kalle Raiskila wrote: > On Sun, 09 Jun 2013 00:25:42 +0300 > Pekka Jääskeläinen <[email protected]> wrote: > >> On 06/08/2013 10:45 PM, Kalle Raiskila wrote: >>> SVN has its continuous revision numbers. Git has unique id:s for >>> each commit that don't change, even if they get merged. Bzr has >>> neither. So >> >> Bazaar has both. You can also get the globally unique ID using 'bzr >> testament'. > > Ah. They just don't seem to be used externally. Not by users, not by > launchpad, not by buildbot. > >>> An other option is to have a separate work tree for pocl from which >>> you merge to a local "clean" pocl tree, and then push that clean >>> tree to lp:pocl. This is especially nice with bigger projects where >>> you can disallow direct pushes to the "master" repository - all >>> commits come via merges. Of course, this is a nuisance in small >>> projects like pocl still is :) >> >> Isn't merging *to* an upstream branch like you describe pretty much >> what git pull --rebase does? > > Yes. > > >> What is a nuisance in a small project like pocl? I didn't get that >> part. What changes when a project becomes "big"? > > The part of disallowing direct pushes to lp:pocl, and instead using > launchpad merge requests exclusively is a bit overkill. Its a > convenient way of enforcing a priori code reviews, though. > > >> Maybe we should just agree now once and for all to work in the >> centralized "svn" mode also in pocl's public "upstream" branches >> (like we have done in TCE without problems) to have those nice short >> running revision numbers usable? > > Quite. And there seems to be at least three ways of doing it locally, so > everyone can find their preferred way of working :) Again, accidental > (and occasional) rewirtes are not a problem. But they do become a > slight problem if they occur frequently. > > kalle > > ------------------------------------------------------------------------------ > How ServiceNow helps IT people transform IT departments: > 1. A cloud service to automate IT design, transition and operations > 2. Dashboards that offer high-level views of enterprise services > 3. A single system of record for all IT processes > http://p.sf.net/sfu/servicenow-d2d-j > _______________________________________________ > pocl-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/pocl-devel > -- --PJ ------------------------------------------------------------------------------ Introducing Performance Central, a new site from SourceForge and AppDynamics. Performance Central is your source for news, insights, analysis and resources for efficient Application Performance Management. Visit us today! http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk _______________________________________________ pocl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pocl-devel
