On 07/15/2010 05:55 AM, Mike Gabriel wrote:

Hi there,

On Do 15 Jul 2010 03:15:13 CEST Gerry Reno wrote:

...

Heinz, I went looking for the source code at http://git.x2go.org/ today but there is nothing there. Is the source code at some other URL? I think a lot of questions could be answered and good contributions suggested if the source was readily available which it should be since x2go is linking NX GPL-v2 libraries.

I am also looking forward to more collaboration ...

I think some of us list-folks are hoping for more possibilities of contributing (ideas, bugs, patches), a source code repos will be one aspect of this.

(I personally love to know if things I am hoping for have a chance of becoming real some time in the near futures.)

Another possibility - and this is also one possible way of approaching a project like x2go - is that Heinz and Alex state explicitly that priorities are different in the core development team and driving forward collaboration is not on the current agenda. This will also be OK!!! But if so, I think, it needs a statement on the x2go-dev list, so people around get informed.

Greets, Mike

I'm certain that with a small team that Alex and Heinz have their hands full with this project. And it is their choice where collaboration tools like forums, wikis, mailing lists and such appear on their agenda of priorities. What is not an open source editor's choice is license compliance with the GPL. The GPL specifically requires that the source code be made available for any derivative works which have linked GPL code. There's no "wiggle" room about this.

Gerry

Am 15.07.2010 11:55, schrieb Mike Gabriel:

Hi there,

On Do 15 Jul 2010 03:15:13 CEST Gerry Reno wrote:

Another possibility - and this is also one possible way of approaching a project like x2go - is that Heinz and Alex state explicitly that priorities are different in the core development team and driving forward collaboration is not on the current agenda. This will also be OK!!! But if so, I think, it needs a statement on the x2go-dev list, so people around get informed.

Hello,

The SourceCode of x2go is published on the same place as the binary packages. For example "x2goclient":

http://x2go.obviously-nice.de/deb/pool-lenny/x2goclient/x2goclient_3.01-5.ta...

You can browse the repository just with your favorite Browser:

http://x2go.obviously-nice.de/deb/pool-lenny/

As you'll see there is a source tar.gz for every version. There are also the needed packages of the nx libs. For example nxcomp:

http://x2go.obviously-nice.de/deb/pool-lenny/nxcomp/

As the gpl want's the code stored where you can find the software, I think this way of publishing the code should be conform to the rules. Some of the packages have reached an age above 3 years...

The URL you have used was printed quoted an announcement. It will be used in future.

At the moment we really use our limited time to get some of your ideas and found bugs inside the new release. After the new version is out, I wan't to invite our list members (and anybody intersted) to a irc session to talk about the future.

Regards,

Heinz

On 07/15/2010 03:11 PM, Gerry Reno wrote:

On 07/15/2010 02:55 PM, Heinz-M. Graesing wrote:

...

Am 15.07.2010 11:55, schrieb Mike Gabriel:

...

Hi there,

On Do 15 Jul 2010 03:15:13 CEST Gerry Reno wrote: Another possibility - and this is also one possible way of approaching a project like x2go - is that Heinz and Alex state explicitly that priorities are different in the core development team and driving forward collaboration is not on the current agenda. This will also be OK!!! But if so, I think, it needs a statement on the x2go-dev list, so people around get informed.

Hello,

The SourceCode of x2go is published on the same place as the binary packages. For example "x2goclient":

http://x2go.obviously-nice.de/deb/pool-lenny/x2goclient/x2goclient_3.01-5.ta...

You can browse the repository just with your favorite Browser:

http://x2go.obviously-nice.de/deb/pool-lenny/

As you'll see there is a source tar.gz for every version. There are also the needed packages of the nx libs. For example nxcomp:

http://x2go.obviously-nice.de/deb/pool-lenny/nxcomp/

As the gpl want's the code stored where you can find the software, I think this way of publishing the code should be conform to the rules. Some of the packages have reached an age above 3 years...

The URL you have used was printed quoted an announcement. It will be used in future.

At the moment we really use our limited time to get some of your ideas and found bugs inside the new release. After the new version is out, I wan't to invite our list members (and anybody intersted) to a irc session to talk about the future.

Regards,

Heinz

---

X2go-dev mailing list X2go-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev

Heinz, This is very good. It is not quite a convenient as full git/svn/bzr repository access but it does appear to at least comply with the GPL license.

I look forward to the irc session and how the community members can more fully participate in the project.

Gerry

Heinz, I just took a look through all the packaging and tarballs. There is still missing the source code for the plugin. Where is that located?

Gerry

On Do 15 Jul 2010 22:48:32 CEST Joerg Sawatzki wrote:

Hey,

even though I don't think anybody is violating the terms of the GPL, I'd say X2go is not a true open source project. What you are doing is more like commercial vendors develop software: A few guys develop a product, while the community has no insight at all and from time to time you publish a release and as a free bonus you give a way the sources as well. You could also publish it under some commercial license - it wouldn't matter. It is nice that you use the GPL, that makes it LEGALLY possible to contribute to your product, but technically it is impossible. The community has no effective way to actively take part in the development. Are there any reasons why you don't want others to contribute with their ideas, bug fixes etc.? There are dozens of people outside who want to help you, you are short on time, but somehow it seems you don't want help.

Making a source code repository public is less than 2 minutes work.... If you are not already under version control, you should take 5 minutes and you will never regret it, because it will save you hours later. Give me a shout if you need help with this.

After all, it is of course your very own decision, but from my own open source experience I can only recommend you to do it as soon as possible. Development depends on TWO people - the number of users, bug reports, feature requests will exponentially grow - and the amount of work will grow. Your resources are static - this means, it will take a lot longer until a new feature is implemented or a bug is fixed. As people are impatient, they will start to help themselves, make a fork "X2go Next Generation" and it will be out of your control. So, be smart, honor the community's effort, use it, coordinate, decide about what code to accept and what to refuse, what features to integrate into the core project, publically represent the project and control it's direction.

These are my personal thoughts on this - I wish you that you will find a wise and satisfying way how to go on.

Thanks a lot for the excellent work you have already done!

Jörg

Jörg, thanks for pointing this out. I fully agree with your statement.

Best, Mike

--

DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419

eMail-LeseSchreibStunde: wochentags 8h-10h mail: m.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...

Gerry,

thanks for your expertise on this. I will mark this mail for further
reference, in case I will need it some time. It is a really good
digest on the subject of freed software.

Thanks a lot, Mike

On Fr 16 Jul 2010 04:07:47 CEST Gerry Reno wrote:

There has always been confusion about the terms "free software" and
"open source software" and all the different open source licenses
that are available.

There are essentially four (4) categories of open source software:

1. Free Software (FS)
2. Open Source Software (OSS)
3. Free (Libre) Open Source Software (FOSS, FLOSS)
4. Commercial Open Source Software (COSS)

In all of these the term "free" does not have anything to do with
price. It means "freedom" as in liberty, unfettered, unconstrained,
etc. I think a better term might have been "freed" software to
avoid confusion and I will use that term here for clarity.

So what do these different terms mean?

1. Free(d) Software (FS) is software that is released in a
   human-readable form (source code) and has applied to it a "free(d)
   software license" defining the four freedoms, as first proposed and
   championed by Richard Stallman of the Free Software Foundation, that
   are granted to users of the software or it is put into the "public
   domain". (http://www.gnu.org/philosophy/free-sw.html) The four freedoms are: 0. The freedom to run the program, for any purpose.

   1. The freedom to study how the program works, and change it to
      make it do what you wish.
   2. The freedom to redistribute copies.
   3. The freedom to distribute copies of your modified versions to others.

2. Open Source Software (OSS) is not so clearly defined as was
   free(d) software and there are various definitions available. The
   Open Source Initiative tried to codify the concept of "open source"
   to mean no restrictions to freely distribute the software, that the
   software must contain at least the clear unobfuscated original
   source code and optionally binary code, that the license must not
   discriminate against any individual or group or field of endeavor or
   technology, that the license grant all users the same rights as the
   author acquired and not require the execution of a different
   license, that the license not restrict the software to being part of
   a specific software assembly, that the license not restrict other
   software. (http://www.opensource.org/docs/osd). This is basically a
   clumsy rewording of parts of the "free(d) software" definition.
   However many open source licenses resulted that technically met the
   definition of "open source" and yet were not "free(d) software
   licenses".

3. Free (Libre) Open Source Software (FOSS, FLOSS) is an attempt to
   clarify that the software is both open source and licensed under a
   "free(d) software license". In other words it is "free(d) software"
   as per Stallman's FSF definition.

4. Commercial Open Source Software (COSS) is a category of open
   source software that does not meet the criteria for a "free(d)
   software license". Certain rights may be restricted to users of the
   software in a "non-free" license despite the fact that it
   technically "open source".

NOTE: It is important to note that whenever a software is derived
from a "free(d) software license" such as the GPL that the copyleft
requirements permanently make all derived works as also being
"free(d) software". This means that when you link to a GPL library
that you cannot later decide to release the derived work under
another license. Just ask Linus Torvalds about this if you have any
doubt.

And there is more to the story of free(d) and open source software
that just the software itself. There is the manner in which the
software is built.

There are the concepts of "open" and "closed" development processes.

In general the first three categories above usually involve "open"
development processes whereby a community is built surrounding the
software and is fully involved under the guidance of a free(d) or
open source "editor" who is the evangelist and de facto leader, the
CEO if you will, for the software project.

The last category of commercial open source usually involves a
"closed" development process where there is no or very little
community and the software is constructed without community
involvement and is finally released with its sources under some form
of non-free open source license.

Today you find huge supportive communities built up around free(d)
open source software projects following an open development process.
Take for example Linux, where there are hundreds of thousands of
community members supporting distributions such as Fedora, Debian,
Suse, Ubuntu, Centos, and a host of others. If it weren't for the
contributions of thousands of volunteers under an open development
process Linux would never have been what it is today. And it's hard
to name even one open source project following a closed development
process that has been nearly as successful as the tens of thousands
of open source projects that have followed the open development
process.

Gerry

---

X2go-dev mailing list X2go-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/x2go-dev

--

DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419

eMail-LeseSchreibStunde: wochentags 8h-10h mail: m.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...

Hi Heinz,

that all sounds very good and promising.

I would like to handle this like debian: to combine your ideas with x2go directly or let you create some "meta distributions" (like debian med or debian edu). A good idea in general, but I am not sure if this makes sense with a rather small project (compared to a whole linux distribution). What kind of flavours/meta distributions should x2go have? With linux distributions, it is different, because users have a lot of different purposes like using it in education, in a small business, on a netbook or an embedded system like a router or a smartphone.

But x2go? Isn't the purpose of all users to create a fast and reliable terminal server environment? x2go-edu? x2go-netbook-edition? :o)

Maybe I am on the wrong track, but I can hardly imagine a single meta distribution of x2go that would make sense.

My suggestion: Make ONE x2go-core that you maintain and where you decide what contributions and features you include - everything else (things that have specific purposes not needed by all users) is provided as plugin/module that is maintained by the contributor himself. Saves you work, makes it easy for contributors and is a very clear concept. I'd rather install one x2go and choose the additional modules I need instead of trying x2go-foo, x2go-edu, x2go-bar to see what could fit best.

We are working with git and now that is a big whish of you, the next thin we'll do is to get git.x2go.org working. Why don't you use github or *forge? It saves time and money and you have the same (and more) possibilities than with your own server. Apart from that, you'd have to setup a bug tracker, wiki and stuff like that as well - and run, administer, update and maintain it. I'd rather invest my time to get on with development instead of reinventing the wheel at this point. :)

We wan't to use our own server to be able to autobuild packages etc... but I will push a copy to github too. There is absolutely no need for this - for example, if you have a project page on Launchpad, their servers can autobuild .deb packages for you - for all kinds of architectures and ubuntu/debian versions. If you still want to build packages on your own server, just build them from the github/*forge repository.

Of course it is up to you - but keep in mind that it will cost you a lot more time (and money) to build and run an infrastructure that is as good or better than what all these *forge sites offer you for free.

Jörg

On Sun, 2010-07-18 at 01:17 +0200, Jörg Sawatzki wrote:

<snip>

...

We are working with git and now that is a big whish of you, the next thin we'll do is to get git.x2go.org working. Why don't you use github or *forge? It saves time and money and you have the same (and more) possibilities than with your own server. Apart from that, you'd have to setup a bug tracker, wiki and stuff like that as well - and run, administer, update and maintain it. I'd rather invest my time to get on with development instead of reinventing the wheel at this point. :)

...

We wan't to use our own server to be able to autobuild packages etc... but I will push a copy to github too. There is absolutely no need for this - for example, if you have a project page on Launchpad, their servers can autobuild .deb packages for you - for all kinds of architectures and ubuntu/debian versions. If you still want to build packages on your own server, just build them from the github/*forge repository.

Of course it is up to you - but keep in mind that it will cost you a lot more time (and money) to build and run an infrastructure that is as good or better than what all these *forge sites offer you for free. <snip> I second that idea. One can lose countless, priceless development hours learning, building, maintaining, and handling the inevitable catastrophes of one's own infrastructure - John

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"?

-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.

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,...).

-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)?

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 :).

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

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

On 07/18/2010 05:15 PM, Gerry Reno wrote:

On 07/18/2010 04:38 PM, Paul Menzel wrote:

...

[1] http://whygitisbetterthanx.com/

In the interest of equal representation here are some links regarding other VCS:

http://unspecified.wordpress.com/2010/03/26/why-git-aint-better-than-x/ http://doc.bazaar.canonical.com/migration/en/why-switch-to-bazaar.html http://hgbook.red-bean.com/read/how-did-we-get-here.html

Regards, Gerry

The whole point of tool discussion in an open source project should be what tools make it easiest for the community as a whole to contribute, collaborate and participate in the project.

When you look at the massive success of forges such as Launchpad and SourceForge that didn't happen accidentally. It happened because these forges are extremely good at providing all of the infrastructure, collaboration tools, tracking tools, and source code management tools for an open source project.

To try and duplicate this type of free services using your own hardware, software, and infrastructure is just not possible. Why go back and use 'bone knives and bearskins' with your own infrastructure and waste countless valuable hours reinventing the wheel when you can have all this handed to you on a silver platter for free? I think this is why hundreds of thousands of projects are using the forges and spending their time thinking about their projects instead of all the necessities of supporting an infrastructure.

Regards, Gerry

On 07/18/2010 05:50 PM, Paul Menzel wrote:

[ Please reply in context. ]

Am Sonntag, den 18.07.2010, 17:36 -0400 schrieb Gerry Reno:

[…]

...

The whole point of tool discussion in an open source project should be what tools make it easiest for the community as a whole to contribute, collaborate and participate in the project.

If you have two main developers, I would take that into consideration. And since there is no big community yet, nobody knows what the community is going to prefer.

As the community grows it will be composed of "open source" participants and contributors as it always is. And these people are already familiar with Launchpad and SourceForge for the most part because they have been almost always participating and contributing in other open source projects which on average are hosted on one of those two forges.

...

When you look at the massive success of forges such as Launchpad and SourceForge that didn't happen accidentally. It happened because these forges are extremely good at providing all of the infrastructure, collaboration tools, tracking tools, and source code management tools for an open source project.

I also heard of some projects moving away from those services.

And that is not recently. Yes, there were some capacity issues on the major forges for a while when they got entirely overwhelmed by their success. Those issues have been resolved for quite a while now. And recently you are seeing really big-name projects such as MySQL, MariaDB, and GNU projects moving onto Launchpad.

...

To try and duplicate this type of free services using your own hardware, software, and infrastructure is just not possible. Why go back and use 'bone knives and bearskins' with your own infrastructure and waste countless valuable hours reinventing the wheel when you can have all this handed to you on a silver platter for free? I think this is why hundreds of thousands of projects are using the forges and spending their time thinking about their projects instead of all the necessities of supporting an infrastructure.

As I have already written.

1. Independence. There is the danger that you are locked into the project and depend on their reaction time. See the BerliOS and renaming the mailing list issues. Using a server for yourself you are in control of it.

In control of a single point of failure. Great. And you could buy an electrical generator and make your own electricity. And maybe a wafer production facility and make your own hardware chips.

2. As I have written. Maybe it is no overhead for Alex or Heinz since they need to administer a server and those services anyway. We both do not know that.

That's their choice if they want to fiddle around with hardware. But the project should not be based on developers 'single point of failure' server. It needs to be placed at a forge service provider that has all the inhouse expertise to deal with hosting open source projects and the required infrastructure and services.

Regards, Gerry

On 07/18/2010 03:54 PM, Eli K. wrote:

This are no questions! You need to use Launchpad/Bazar, because Ubuntu will become the only Linux on the market!!!

History does not bear out such a conclusion that Ubuntu will be the only Linux. The same was said about Minix, Slackware, Debian, RedHat, and many other distributions. One thing you find with free(d) software is that there is continuous evolution and improvements. And the most unlikely thing to happen is that one distribution would ever be the *only* distribution. When you go to the ice cream shop do you only see one flavour?

You need to use python, because only python will survive for desktop use (java/(script) for the net)!!!

Having programmed in over two dozen languages, again history does not bear out such singular results. Without a doubt python is a very good language. Will it displace Javascript? Will it conquer the world so to speak? Very very doubtful.

And you have to be nx compatible, because nobody looks for unknown software!!!

The only reason x2go is rather unknown is because a sufficient community has not sprung up yet around the software. But that is changing now.
And when you look at the rather poor and frustrating uptake on NX projects as a whole there is no compelling reason to be completely compatible with approaches that are clumsy, stale and lack useability.

I'll put that stuff to my Lauchpad account when I've got time.

By the way - good idea with the python lib!

Yes, there should be room for any of these types of contributions.

Regards, Gerry

Hi Heinz, hi list-people,

On So 18 Jul 2010 19:18:43 CEST "Heinz-M. Graesing" wrote:

-1-----

[...]

Is it ok to use git as "version control and code publishing tool"

+1 from me

-2-----

[...]

I have no special preference here. I do not like registering for
accounts on these portals and love to work with simple systems on my
own servers (i.e. without GA & co.).

I think cascading VCS is quite helpful. Locally I'd also prefer
working with git, the remote/public system should be supported as push
method by GIT.

I like that Heinz mentions political aspects. I think we should take
this in to account. Regarding this it might be sensible to set up our
own VCS/tracker system. Actually, I think this is my favourite.
Offering my working power here...

Do we need configurable ACL features on the VCS site? What do the
named above platforms support in this respect?

-3-----

[...]

So again: What do you think?

I think a single mailing list will not suffice in the future. Here is
a suggestion for a more versatile approach:

Generally:

o mails / mailing lists as information service offer a passive retrieval of information o use WebGUIs offer active search for information (i.e. active retrieval of information)

Mailing lists (software e.g. Mailman):

o x2go-core@x2go.org (rw) - the core team o x2go-dev@x2go.org (rw)- real developers o x2go-users@x2go.org (rw) - people who are rather using x2go than
working on code o x2go-announce@x2go.org (read-only) - announce releases, security
issues etc. o x2go-bugs@x2go.org (read-only) - carbon copies of the upstream bug tracker o x2go-vcs@x2go.org (read-only) - carbon copies of VCS check-ins

An x2go-core list will be valuable if the core-team will grow some
time in the future. Currently, Heinz and Alex seem to use direct
verbal communication.

The x2go-dev list will deal with development/coding issues and also
with internal discussions like this one.

The x2go-users list will deal with functionality of x2go (not
necessarily with bugs). People who want to use x2go, but are not
involved in the development, can ask their questions here. People like
John, Gerry, Paul, Joerg, Mike ... can share knowledge here and help
people with their questions. I think that normal users shall not be
bothered with discussions like this one, neither with detailled
discussion on difficult coding issues.

x2go-announce could be the ,,press release'' list. Information here
could be a duplicate of the blog on blog.x2go.org. I recommend a
duplicate service here because mail service is a passive service, a
webblog an active service for information retrieval. People have
different preferences how to get their information.

x2go-bugs is a duplicate of the bugtracker's tickets. Developers (and
reporting users) can get informed on entries on the bugtrackers via
mail (again: mails for passive retrieval, the bugtracker for active
search).

x2go-vcs will inform developers about VCS check-ins.

For developers mail filtering to subfolders will be a must with this
set of mailing lists...

Forum:

A forum for communication gets a -1 vote from me... I agree with Heinz
that giving our list archives a nice frontend on the web is by far the
better approach.

Tracker:

With bug trackers I am not so experienced. Nice bug tracking features
that I like are:

o allow users to mail-watch a bug (without registration) o reference with URLs between bugtracker und VCS web-frontend

Both features are available with the Horde bugtracker (see below).

The bugtracker will be for handling upstream bugs only!!! It's not a
forum for discussing things etc. If a discussion will start in the
bugtracker the developers have to intervene and refer to the mailing
lists as a discussion medium.

The bugtracker should not need registration for reporting users.
Reporters of bugs should have to leave a mail address, though.

Code/Package development:

Then we should differentiate between code development and package
maintenance (just some thoughts/suggestions):

CODE: o code development -> master branch of x2go VCS, handled by x2go bugtracker o code modularization (x2goclient related packages, x2goserver related packages, x2gothinclient related packages etc.) o branching code -> branches in x2go VCS are supported, but maybe
not handled by bugtracker (keeping the bugtracker simple)

PACKAGES: o debian package maintenance -> Heinz, Alex; free choice of methods(?) o ubuntu package maintenance -> Launchpad; Maintainer A o SuSE package maintenance -> ..., Maintainer B o Fedora package maintenance -> ..., Maintainer C o GenToo -> ..., Maintainer D o etc.

The upstream code will include the distro specific package folders
(e.g. the /debian folder), but these folders have to be maintained and
updated by the distro package maintainers. (Patches via e-Mail to the
code module maintainer).

Bugs in the packages will be reported to the bugtracker of the
distribution (Bugzilla for Redhat/Fedora, Launchpad for Ubuntu etc.).
The corresponding package maintainers will differentiate package bugs
from upstream bugs and will report these upstream bugs in the x2go
bugtracker and optimally also provide patches for upstream bugs there.

TRACKER:

Maybe gitbug is a possiblity too (bugs stored inside the git)?

I just looked at a gitbug site. To me, gitbug does not look too
promising... but may be the sites I looked at are not representative.

There was a time when I submitted quite some patches to bugs.horde.org
(Kolab Groupware). The horde tracker Whups is a really nice
ticket-tracking system. http://www.horde.org/whups/

It works together with GIT (Horde used CVS for a very long time, but
the project has recently migrated to GIT). And AFAIK Horde also has a
VCS frontend for GIT available.

This also is just a set of ideas!!! I am open to anything that will
work smoothly for us all!!!

@Heinz: maybe someone should be responsible for collecting ideas in
the x2go-wiki. Will you do that? Or will you name someone? I agree
with Paul that someone has to extract the brainstorming from the list.

Best, Mike

--

DAS-NETZWERKTEAM mike gabriel, dorfstr. 27, 24245 barmissen fon: +49 (4302) 281418, fax: +49 (4302) 281419

eMail-LeseSchreibStunde: wochentags 8h-10h mail: m.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de

freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...

On 07/25/2010 05:12 AM, Heinz-M. Graesing wrote:

Hello x2gousers,

to get back to this discussion... We've received a lot of ideas and concerns on the list and as direct emails (again - those would better be posted to the list too...).

Some words about BerliOS: A number of people are registered to BerliOS because of the projects past (x2go was only hosted there). They would like to see the project there again, so they don't have to register to anything new. In their eyes, BerliOS has the same features as any other project hosting site and it is free of ads, trackers and such things.

Yes, a forge. Any decent forge will suffice. BerliOS should work.

Git is - and that is what we like - really a good way to work with code as we do it (most of the time local on our mobile computers ). Sure SVN has some advantages, but maybe it is only that we've feel better using Git.

Git is fine since you don't want to use Launchpad.

As this is a offer of mike I'd like to ask directly: If we choose some generic projects which can be easily mirrored and don't have a "lock in" effect, would you and anybody else like to run a mirror? This would be help to avoid the "single point of failure" argument. As tehre is defenitly know how on the list, we can offer some sites inside the wiki for documentation (running a mirror).

Are you referring to things like forums, wikis, bug trackers? I thought that was what BerliOS was providing? Isn't that the whole point of a forge? To reduce the amount of administration work necessary for an open source project?

The source code: All of the historical binary and source code package archive needs mirrored at a public mirror (a university would be good). The Git repository should have plenty of people mirroring it so the code should be safe.

This paragraph is very interesting in my eyes:

...

Generally:

o mails / mailing lists as information service offer a passive retrieval of information o use WebGUIs offer active search for information (i.e. active retrieval of information)

Mailing lists (software e.g. Mailman):

...

One thing to be aware of is that there is a huge increase in the number of mailing lists being seriously spammed. The python-list has recently been swamped with a number of spammers. If the mailing list is to be unmoderated then it should be read using something like Gmane which does spam filtering of the posts. If moderated, then all means of spam control needs to be employed. And the spammers have gotten wiser. They now post 1 or 2 topical posts before they start spamming the list.
Probably from some of the human spam farms out there. They're actually hiring farms of humans to push spam so they can get by captcha's and other mechanisms. I'm now convinced that the only way we are going to stop spam is through legislation worldwide to make it illegal.
Otherwise we'll be playing this cat and mouse game forever.

...

Anyway, back to x2go. This all sounds real good.

Regards, Gerry

On Sun, 2010-07-25 at 11:12 +0200, Heinz-M. Graesing wrote: <snip>

As this is a offer of mike I'd like to ask directly: If we choose some generic projects which can be easily mirrored and don't have a "lock in" effect, would you and anybody else like to run a mirror? This would be help to avoid the "single point of failure" argument. As tehre is defenitly know how on the list, we can offer some sites inside the wiki for documentation (running a mirror). <snip> We might be able to mirror. We're running flat out for time getting the new company up and running but, if someone can provide a simple how-to to set it up, we can try to squeeze it in. Are there any estimates on disk/bandwidth requirements? Thanks - John

On 07/18/2010 06:29 PM, Mike Gabriel wrote:

THIS MEANS: we have to get you some Mac hardware...

There is a store on eBay that sometimes has very good deals on used Macs, The 4th Bin Store:

http://stores.ebay.com/The-4th-Bin-Store

I've seen some desktops for between $100-300 USD.

Regards, Gerry