Hi everybody! In my opinion there is still a big problem with the open source development model that is used for the build service: If you want to attract external developers to work on that project then you should put _everything_ you plan to release as open source _as early as possible_ to the public svn repository (i.e. _now_). You should even do this if the code you are hacking is incomplete and unusable. I mean a public repository is no shop window for doing marketing but something to coordinate development work. If you always wait putting stuff into public visibility until you consider it having reached a certain level of completeness, you might impress some people that want to use the tool but you are unlikely to attract external developers. There should never be such comments in the repository like "to be checked in by xxx next week" because if you check it in _now_ even when it is incomplete, potential external developers could see it growing and later start to contribute. If you again wait with releasing it until it has grown fat and ugly, potential developers will be scared away because reading and understanding other's code needs some time. If external developers get the impression that they are always trying to understand code that was already obsoleted by other code that the internal developer is currently working on (again behind the curtain) then (s)he is likely to lose interest in working on that project. If you have legal problems to release something, then _explain_ the situation and don't leave the situation that you don't take your plan to run an _open_ project serious. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de "Quidquid latine dictum sit, altum sonatur."
Hi Robert, On Wed, Mar 08, 2006 at 05:11:27PM +0100, Robert Schiele wrote:
You should even do this if the code you are hacking is incomplete and unusable. I mean a public repository is no shop window for doing marketing but something to coordinate development work. If you always wait putting stuff into public visibility until you consider it having reached a certain level of completeness, you might impress some people that want to use the tool but you are unlikely to attract external developers.
The public build service svn doesn't have a "shadow" svn internally where things are developed and later moved out. Whatever is in the public svn now is being developed there. It is true that not everything made it to the public svn yet for several reasons. This is an unfortunate, but as we all hope temporary situation. This only affects the backend part. API frontend and clients are in the public svn, and developments happens there. Sonja -- Sonja Krause-Harder (skh@suse.de) Research & Development SUSE Linux Products GmbH
On Wed, Mar 08, 2006 at 06:03:24PM +0100, Sonja Krause-Harder wrote:
The public build service svn doesn't have a "shadow" svn internally where things are developed and later moved out. Whatever is in the public svn now is being developed there.
Actually I don't care whether it is a "shadow" svn or a "shadow" we-don't-use-revision-control-internally-at-all tool. Obviously software (like the build script) is already deployed to the build server in a version that is not in the public repository (because there is _no_ version of the build script in the repository but the server does actually build packages already).
It is true that not everything made it to the public svn yet for several reasons. This is an unfortunate, but as we all hope temporary situation.
So, what's the issue with _naming_ these problems? I hope that we all hope this is a temporary situation but because of the missing information flow not all of us can understand why the hope is not just put into reality.
This only affects the backend part. API frontend and clients are in the public svn, and developments happens there.
And you expect that there will be any useful contribution to for instance the frontend part from outside the information firewall if there is neither documentation about the interface to the backend, nor a working backend available and people from outside can't even be sure which parts of the backend will really be open sourced? You work yourself for a software company and thus should know that this is neither really practical nor is it very attractive. You once moaned about having not enough speakers from outside SUSE at FOSDEM. But what do you expect should people from outside talk about (well maybe about how discussions on the mailing lists become more and more absurd) as long as information flow is some speed limited one-way road and people from outside have to pull every bit of information with enourmous effort outside. After some time of doing that most of them will just go away frustrated. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de "Quidquid latine dictum sit, altum sonatur."
On Wed, Mar 08, 2006 at 07:23:01PM +0100, Robert Schiele wrote:
On Wed, Mar 08, 2006 at 06:03:24PM +0100, Sonja Krause-Harder wrote:
The public build service svn doesn't have a "shadow" svn internally where things are developed and later moved out. Whatever is in the public svn now is being developed there.
Actually I don't care whether it is a "shadow" svn or a "shadow" we-don't-use-revision-control-internally-at-all tool. Obviously software (like the build script) is already deployed to the build server in a version that is not in the public repository (because there is _no_ version of the build script in the repository but the server does actually build packages already).
This is the backend part I mentioned.
This only affects the backend part. API frontend and clients are in the public svn, and developments happens there.
And you expect that there will be any useful contribution to for instance the frontend part from outside the information firewall if there is neither documentation about the interface to the backend, nor a working backend available and people from outside can't even be sure which parts of the backend will really be open sourced?
No, I don't. We went public with a pre-pre-alpha, far from feature complete, incomplete version to give people the possibility to look at the code as early as possible. I understand your frustration that this is not going faster, but I can't change it now. We're working on the problem.
You once moaned about having not enough speakers from outside SUSE at FOSDEM.
I moaned? That was not intended and perhaps a misunderstanding. I hope that in a year we have more non-SUSE speakers at conferences, and I might have said that we should work on this. Sonja -- Sonja Krause-Harder (skh@suse.de) Research & Development SUSE Linux Products GmbH
Am Wednesday 08 March 2006 19:23 schrieb Robert Schiele:
On Wed, Mar 08, 2006 at 06:03:24PM +0100, Sonja Krause-Harder wrote:
The public build service svn doesn't have a "shadow" svn internally where things are developed and later moved out. Whatever is in the public svn now is being developed there.
Actually I don't care whether it is a "shadow" svn or a "shadow" we-don't-use-revision-control-internally-at-all tool. Obviously software (like the build script) is already deployed to the build server in a version that is not in the public repository (because there is _no_ version of the build script in the repository but the server does actually build packages already).
The reason is basically that mls has his own mind in which state he want to release his code. And he does currently not feel comfortable to release the current hacked version. So this is his private opinion, but he promised to release it this week, so I would like to avoid to stress this issue too much. bye adrian -- Adrian Schroeter SUSE Linux Products GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany email: adrian@suse.de
I will add mls to cc to allow him to defend himself if he feels that this is needed. But notice this is not about him but about a general problem of the development model. He is just involved in one instance of the problem. On Wed, Mar 08, 2006 at 08:00:01PM +0100, Sonja Krause-Harder wrote:
On Wed, Mar 08, 2006 at 07:23:01PM +0100, Robert Schiele wrote:
Actually I don't care whether it is a "shadow" svn or a "shadow" we-don't-use-revision-control-internally-at-all tool. Obviously software (like the build script) is already deployed to the build server in a version that is not in the public repository (because there is _no_ version of the build script in the repository but the server does actually build packages already).
This is the backend part I mentioned.
I know but still want to make the point there because this is exactly the place where one instance of the problem currently shows up.
No, I don't. We went public with a pre-pre-alpha, far from feature complete, incomplete version to give people the possibility to look at the code as early as possible. I understand your frustration that this is not going faster, but I can't change it now. We're working on the problem.
I understand that you can't chage this now. I am not a naive fool believing that I can change the way the world turns round in five minutes but I am pointing to the problems as long until I get some success or until I give up and go away, whatever happens first.
You once moaned about having not enough speakers from outside SUSE at FOSDEM.
I moaned? That was not intended and perhaps a misunderstanding. I hope
Use the verb regret if you think this is more appropriate. It does not alter my point what the reason is for this situation. On Wed, Mar 08, 2006 at 08:06:00PM +0100, Adrian Schroeter wrote:
The reason is basically that mls has his own mind in which state he want to release his code. And he does currently not feel comfortable to release the current hacked version. So this is his private opinion, but he promised to release it this week, so I would like to avoid to stress this issue too much.
I don't want to stress _this_ issue in special because it is only one instance of the problem. But I want to use this example to stress the general issue of the development model. Actually mls _did_ release his code already. He did release the code to SUSE staff. Here you get two classes of developers: people inside SUSE/Novell and people outside. The question is now: Do you want external developers in the openSUSE project or not? If you don't want them then you could just state that and I will see that I did completely misunderstand the intention of the openSUSE project up to now. But if you want to attract external developers a change in the development model should happen. Would you as a KDE project member port KDE to a new version of Qt if Trolltech would only give you a pointer to their API documentation of the new release but not the library itself with the reason that the code is not yet in a state that can be released? Would you feel comfortable if some employees of Trolltech started to port KDE to the new version but you had no chance to test their or your work because you don't have access to the new Qt release? Would you port glibc to a new kernel if you get only the list of system calls but not the kernel itself because it is not yet in a state the developer wants to release? So for the concrete example mls might reconsider when to release his code but for the wider view of the whole openSUSE project you and all other people responsible for the project might reconsider the general development model. While doing that you should also take into account what happened to other open source projects after changing the development model. For instance compare the speed of development and quality of gcc before the egcs fork and afterwards. Please don't do the same your colleagues did while developing Xgl. I am sure they are attracting now some developers from outside Novell because Xgl is a shiny thing but they could have more if they did develop it in an open way from the very beginning. Robert -- Robert Schiele Tel.: +49-621-181-2214 Dipl.-Wirtsch.informatiker mailto:rschiele@uni-mannheim.de "Quidquid latine dictum sit, altum sonatur."
On Wed, 8 Mar 2006, Robert Schiele wrote:
On Wed, Mar 08, 2006 at 08:00:01PM +0100, Sonja Krause-Harder wrote:
On Wed, Mar 08, 2006 at 07:23:01PM +0100, Robert Schiele wrote:
Actually I don't care whether it is a "shadow" svn or a "shadow" we-don't-use-revision-control-internally-at-all tool. Obviously software (like the build script) is already deployed to the build server in a version that is not in the public repository (because there is _no_ version of the build script in the repository but the server does actually build packages already). This is the backend part I mentioned.
...
On Wed, Mar 08, 2006 at 08:06:00PM +0100, Adrian Schroeter wrote:
The reason is basically that mls has his own mind in which state he want to release his code. And he does currently not feel comfortable to release the current hacked version. So this is his private opinion, but he promised to release it this week, so I would like to avoid to stress this issue too much.
I don't want to stress _this_ issue in special because it is only one instance of the problem. But I want to use this example to stress the general issue of the development model.
...
The question is now: Do you want external developers in the openSUSE project or not? If you don't want them then you could just state that and I will see that I did completely misunderstand the intention of the openSUSE project up to now.
But if you want to attract external developers a change in the development model should happen.
Would you as a KDE project member port KDE to a new version of Qt if Trolltech would only give you a pointer to their API documentation of the new release but not the library itself with the reason that the code is not yet in a state that can be released? Would you feel comfortable if some employees of Trolltech started to port KDE to the new version but you had no chance to test their or your work because you don't have access to the new Qt release?
Would you port glibc to a new kernel if you get only the list of system calls but not the kernel itself because it is not yet in a state the developer wants to release?
So for the concrete example mls might reconsider when to release his code but for the wider view of the whole openSUSE project you and all other people responsible for the project might reconsider the general development model. While doing that you should also take into account what happened to other open source projects after changing the development model. For instance compare the speed of development and quality of gcc before the egcs fork and afterwards.
Please don't do the same your colleagues did while developing Xgl. I am sure they are attracting now some developers from outside Novell because Xgl is a shiny thing but they could have more if they did develop it in an open way from the very beginning.
I agree totally with this. I started creating things with the first very first public release of the SuSE linux distribution. I stopped after being very frustrated with how things were. I every now and again look at the cituation and wonder if I should start doing things again. I had done a few packages for MySQL AB and their clients under NDA so I am not able to make them public. But many of them moved to RH. This is in the US where RH is big. I have always prefered SuSE or Caldera Linux above all the other distributions. I am currently working with one other person on a OSS alternitive to Appgen's Accounting SW. The above describes exactly how I feel about this. -- Boyd Gerber <gerberb@zenez.com> ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
On Wed, Mar 08, 2006 at 09:44:51PM +0100, Robert Schiele wrote:
I don't want to stress _this_ issue in special because it is only one instance of the problem. But I want to use this example to stress the general issue of the development model.
Actually mls _did_ release his code already. He did release the code to SUSE staff. Here you get two classes of developers: people inside SUSE/Novell and people outside.
What do you know about the SUSE internas? It's not released to "SUSE staff" in any way. The currrent script running in the buildservice is a preliminary version which I can't release it to anybody for reasons mention at FOSDEM. That is, it contains code of which we don't have approval for distribution yet. So: I'm simply not finished with the rewrite. The new version will contain XEN sandboxing and other godies, and yes, we have approval for distribution. You will just have to wait a couple of *days*, so please quit bitching around! Patience, patience. Cheers, Michael. -- Michael Schroeder mls@suse.de main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
On Wed, Mar 08, 2006 at 11:05:20PM +0100, Michael Schroeder wrote:
So: I'm simply not finished with the rewrite. The new version will contain XEN sandboxing and other godies, and yes, we have approval for distribution.
Status update: XEN stuff works, one or two days of polishing and the build script will be available. Sorry for the delay. Cheers, Michael. -- Michael Schroeder mls@suse.de main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
On Fri, Mar 17, 2006 at 12:39:42PM +0100, Michael Schroeder wrote:
On Wed, Mar 08, 2006 at 11:05:20PM +0100, Michael Schroeder wrote:
So: I'm simply not finished with the rewrite. The new version will contain XEN sandboxing and other godies, and yes, we have approval for distribution.
Status update: XEN stuff works, one or two days of polishing and the build script will be available. Sorry for the delay.
Okay, polishing done, it's finally in the forge snv. Next step: change the command line tool so that it one can do local trys of failed builds. Enjoy, Michael. -- Michael Schroeder mls@suse.de main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
On Wednesday 08 March 2006 21:44, Robert Schiele wrote: Hi Robert,
I will add mls to cc to allow him to defend himself if he feels that this is needed. But notice this is not about him but about a general problem of the development model. He is just involved in one instance of the problem. Yes, there is nothing that mls is to blame for or something.
On Wed, Mar 08, 2006 at 08:00:01PM +0100, Sonja Krause-Harder wrote:
On Wed, Mar 08, 2006 at 07:23:01PM +0100, Robert Schiele wrote:
Actually I don't care whether it is a "shadow" svn or a "shadow" we-don't-use-revision-control-internally-at-all tool. Obviously software (like the build script) is already deployed to the build server in a version that is not in the public repository (because there is _no_ version of the build script in the repository but the server does actually build packages already).
This is the backend part I mentioned.
I know but still want to make the point there because this is exactly the place where one instance of the problem currently shows up.
No, I don't. We went public with a pre-pre-alpha, far from feature complete, incomplete version to give people the possibility to look at the code as early as possible. I understand your frustration that this is not going faster, but I can't change it now. We're working on the problem. Well, it is developing and the developing should really be open, I can fully understand Robert. But the good news here is: It is already partly. All the API and webclient are in external svn at http://forge.novell.com/modules/xfmod/svn/svnbrowse.php?repname=opensuse I know and agree that partly is not enough, but it is more than nothing.
The question is now: Do you want external developers in the openSUSE project or not? If you don't want them then you could just state that and I will see that I did completely misunderstand the intention of the openSUSE project up to now.
No, you understood it completely right.
But if you want to attract external developers a change in the development model should happen.
Yes, and we are really working on that. We are at Novell and Novell is on it's way to become the largest and coolest open source company out there. But: We are still on the way. At Novell (maybe same for SUSE and many other companies ;) you find people who have not _yet_ fully understood what benefits come out of a real open development model, especially for openSUSE. And switching a 'classic' software company to an open source company is a big task. So we have many discussions and explain and explain. That takes time. And during this time we as developers here at SUSE are not in the position to release code that might be subject of these discussions. I hope you understand that. BUT: Believe us that we are really doing everything to get the stuff really open! We as open source developers really want you to get into that. We personally do not want to be another "pseudo open" company and we do not want to have a "pseudo open source" project. And I understand your frustration completely. And I like to thank you that you take the time to write that down and do not go away silently.
Please don't do the same your colleagues did while developing Xgl. I am sure they are attracting now some developers from outside Novell because Xgl is a shiny thing but they could have more if they did develop it in an open way from the very beginning.
Yes. Thanks Robert, Klaas
-> webclient & api developer. -- Klaas Freitag Novell - SUSE R&D - Internal Tools
participants (6)
-
Adrian Schröter -
Boyd Lynn Gerber -
Klaas Freitag -
Michael Schroeder -
Robert Schiele -
Sonja Krause-Harder