On 07/18/2010 01:18 PM, Heinz-M. Graesing wrote:
Hello,
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"?
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.
-2-----
The second thing on the list is the querstion 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.
-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.
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!
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.
Regards,
Heinz
Very definitely.
Regards,
Gerry
_______________________________________________
X2go-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/x2go-dev
