[X2go-dev] source code repository

Sun Jul 18 22:38:32 CEST 2010

Am Sonntag, den 18.07.2010, 14:29 -0400 schrieb Gerry Reno:
> On 07/18/2010 01:18 PM, Heinz-M. Graesing wrote:

> > I think we need to talk about 3 different things:
> >
> > 1. source code hosting/modification/interactivity/versioning
> >
> > 2. the place where the code shoud be stored
> >
> > 3. the tools which should be used for organisation
> >
> >
> > All three items have become mixed up in some mails and discussions.
> > Again I had a lot of private mails - again: please post those things to
> > the list (especially regarding those topics).
> >
> >
> > -1-----
> >
> > The first item is the question how the source of x2go should be
> > published/handled. The big surprise: we don't have a discussion about
> > what technique should be used (bzr, cvs, git, svn,...).
> > To get this item marked as done:
> >
> > Is it ok to use git as "version control and code publishing tool"?

I am personally used to Git and therefore would prefer it. I was lost
when I had to use bzr or hg.

> One needs to understand the purpose and reasoning behind the different 
> VCS tools in order to make such a decision.  'git' was developed as a 
> tool for use by the Linux kernel developers after the decision was taken 
> many years ago to move away from a predecessor proprietary VCS tool.  
> One of the goals was to make sequences of very small commits across many 
> files perform well.  And git does that rather well.  This is the life of 
> a kernel developer - making the same small changes across many different 
> trees.  Collaboration, distributed teaming, offline coding, none of 
> these were considerations in the development of git.
> 
> On the other hand collaboration, distributed teaming and offline coding 
> became increasingly important considerations as development of VCS tools 
> occurred over the years especially in light of the Internet and the 
> global distribution of teams.  And so as you move from cvs, to 
> subversion, to mercurial and bazaar you see more and more focus on these 
> qualities.  And in distributed team environments these qualities are far 
> more important than whether the VCS can perform a small commit sequence 
> in .186 seconds compared to .489 seconds on some distributed team VCS.  
> The difference in performance is mostly negligible and unnoticeable 
> until you get to projects that have beyond 50,000 files in a single 
> directory.  x2go is clearly far from this type of size.
> 
> My own preference on any open source project is to use the VCS tools 
> that have the most capabilities in supporting globally distributed 
> development.  To that end, Bazaar (bzr), or Mercurial (hg), are the 
> clear winners.  And the ability to use a fully featured forge such as 
> Launchpad coupled with a fully featured distributed VCS such as Bazaar 
> is very compelling.  And for those that like to work in 'git', 'svn', 
> 'hg', etc. there are plugins to Bazaar that allow you to work locally in 
> git/svn/hg and then perform a push to the Bazaar repository on Launchpad 
> when your code is ready.  I suggest you setup a small test project on 
> Launchpad sandbox and try all this for yourselves.

I think there is no objective way to choose the optimal VCS. No
consensus will be reached I think since every difference/feature will be
considered good or bad depending who looks at it. For Git for example
this support site exists [1]. And over the last few releases
distinguishing features (manual pages, help output, setting up a web
server, plugins, …) have all been incorporated into the different VCS.

Anyway, I would say, just pick the tool Alex and you are feeling most
comfortable with. If you do not care then take into account the
preferences from those guys you are going to expect patches from.

[1] http://whygitisbetterthanx.com/

> > -2-----
> >
> > The second thing on the list is the question where the source should be
> > stored. The place where you can find a project is in a way a
> > "statement". Some of those platforms are initiated by governments, some
> > are ruled by companies with added social media and data collection
> > strategies. This affects everybody who want's to collaborate, because
> > she/he needs to get an account on the chossen platform. Some platforms
> > are just not legally usable for us because of the legal situation in the
> > country of copyright: germany (for example if they use ga:
> > http://eu.techcrunch.com/2009/11/24/google-analytics-illegal-germany/).
> > We first tried to use BerliOS with was in our eyes a good choise because
> > in their special way, they could be called in a way (seen from the web)
> > "apolitical". The account is still alive and they offer git, so it can
> > be used without any problems. Though some of the configuration is a bit
> > static and can only be access via a webgui. So there was the idea to
> > host it by our own - nobody need to register against some governmental
> > or company driven services.
> 
> Google Analytics has NOT been made illegal in Germany nor is it likely.  
> There were a bunch of ill-informed tech-illiterate politicians running 
> around making out like the sky was falling because Google was collecting 
> some anonymous usage patterns.  Google does not know who you are.  They 
> only know this browser with this cookie does these usage patterns.  And 
> today in most browsers you can block all or specific cookies to prevent 
> any usage data from being stored.  The other ill-informed paranoia was 
> about IP addresses being stored out of Germany.  Well, every time you 
> send an email IP addresses are stored on mail servers all over the 
> world.  What many of these ill-informed politicians did not know is that 
> with DHCP most people's IP addresses are constantly being changed making 
> anything linked to IP addresses almost completely useless.  This whole 
> baseless paranoia now seems to have calmed down as people began 
> educating these politicians.
>
> > It would be intersting which of the services you prefer to discuss the
> > final location of the git (osor.eu, berlios, github, sourceforge, google
> > code,...).
>
> My preference would be either Launchpad or SourceForge.  One of the 
> major forges.  People work with these on a consistent basis and are 
> familiar with all of the tools available.  - No learning curve.

The few times as a normal user I had to deal with projects using
Launchpad I did not like it very much and did not find the things I was
looking for easily.

I do not know that much about SourceForge, only that their mailing list
interface is unusable.

The next thing to consider is independence. How easy is it to move from
one to another service.

I do not know if you only work on X2go or if you have to deal with Web
applications and administer a server nevertheless. So setting up those
programs might be interesting for you.

> > -3-----
> >
> > After we've answered the first two questions, we should talk about which
> > of the offered tools should be used on the choosen platform. At the
> > moment the whole project management is done via this mailing list. This
> > decision was made in the past to avoid decentralized collaboration which
> > caused a lot of duplicated messages from different locations (the
> > Bugtracker on BerliOS is still active).
> > The fact we are discussing now about the future here together in one
> > place is a result of this idea. The mailing list is a very easy type of
> > service. Bugtracker can be much more complicated and sometimes you only
> > have a dictated user experience. This again can influence the choice of
> > users helping us or not.
> >
> > So again: What do you think? Maybe gitbug is a possiblity too (bugs
> > stored inside the git)?
> 
> No need.  Just use one of the major forges and the entire suite of 
> collaboration and tracking tools becomes available to use.

I would have recommended ikiwiki [2]. But since you are using DokuWiki
now, there is some overlapping. The big advantage is that you could
operate only in the repository and you do not have to use different
interfaces. I have never heard of gitbug.

Trac or Redmine are also quite common.

Again, you have to choose what *you* prefer. How is it going with the
new Wiki for Alex and you. Did you “enjoy” using DokuWiki’s interface to
update or create new pages or over the last few weeks did you get tired
of it?

I do not know how many replies will be written, but maybe we should
collect this on a Wiki page. And I am sure that other projects had the
same discussion already. Does anyone know such projects?

[2] http://ikiwiki.info/

> > As this was a response to Mike's mail:
> >
> > Am 18.07.2010 14:42, schrieb Mike Gabriel:
> >    
> >> possible focus could be:
> >>
> >>    1. support the next release as best as we can (testing, bug reports etc.)
> >>      
> > Most of the bugs are not part of our code but can be find inside the
> > used projects (xming,...). This makes it a bit harder to fix all known
> > bugs. Another thing is the status of the mac port of x2goclient:
> >
> >   - we don't have mac hardware (anymore)
> >   - we don't know how to embedd the window of
> >     x2goagent inside the browserview (x2goplugin
> >     vs. style guide of mac development)
> >   - there is a big number of complaints about the
> >     mac port because it is not using cocoa and
> >     build on objective c
> >
> >    
> >>    2. be happy once the release is out
> >>      
> > This should be worth a party :).
> 
> Absolutely!

Agreed!

> >>    3. ONLY THEN: take our time to listen to each others ideas, find a
> >> synthesis
> >>      of them all and setup a working scenario that allows fluid
> >> collaboration,
> >>      coordinated by the core developers of X2go
> >>      
> > I think we needed this exchange of ideas to get a bit more to know about
> > each other and the project.
>
>   Very definitely.

That should be discussed in a new thread or even collected in the Wiki.

Thanks,

Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.x2go.org/pipermail/x2go-dev/attachments/20100718/e8f584ba/attachment.pgp>