Re: [oi-dev] oi_151a9 roadmap planning
Peter Tribble peter.trib...@gmail.com wrote: First, you need to stop saying must and attempting to dictate design and implementation decisions. Well it would be great if some people at Illumos would not try to dictate things but signal that there is an interest for a collaboration. Well - IPS must not be the only packaging It isn't. There are distros using SVR4, dpkg, rpm, IPS, pkgsrc, and/or no packaging at all. Well, where is the SVr4 package meta data in Illumos? Note that IPS meta data is limited compared to Svr4 package meta data and for this reason, there is no way to convert meta data correctly. - /sbin/sh may be a link to the Bourne Shell Why is this relevant to collaboration? Because for being able to collaborate, we need to have a common understanding of what is preventing collaboration. This results in avoiding changes that prevent collaboration. This is a good example of where collaboration matters. If this is important to you, and you want the system to behave correctly with an alternate /sbin/sh, then log bugs against illumos, preferably with fixes. However, as with all projects, if having it fixed matters to you, you have to do the work. Illumos would need to verify first that Illumos is collaborative. Currently we have the unfortunate state that Illumos did not include some software even though this was promised and a code review has been presented. Colaboration of course also means that partners are trustworthy and implement promises. Once Illumos turned into a trustworthy and collaborative entity, it makes of curse sense to file bugs against Illumos. - scripts need to be open for being able to mount /usr using the Bourne Shell. We're off into the realms of distro-specific implementation artefacts. This sort of statement doesn't even make sense for some distros, and the concept it refers to isn't part of illumos at all. I am sure whether you understand what collaboration is... if we like to share important scripts, we need to have a common understanding of what others are interested in. Specific changes at one side may prevent collaboration at certain points and this is such a point. Being able to have native (SVr4 package based) zones on all distros would be another thing to look at. In any case, collaboration means that one distro does not dictate constraints that affect other distros. - We need to find a way for versioned libraries to support as much binary compatibility as possible. That's how shared libraries, versions, mapfiles, and filters work. But again, this is largely irrelevant - binary compatibility has often been out of fashion in many open source projects, so it's not a problem we can solve. And it's a much smaller part of the overall compatibility question - what versions of interpreters are present, what build options were chosen, where are applications installed? If we like to collaborate, we need to decide whether there should be binary compatibility. I remember that in the late 1990s, Linux was so fragmented, that it was impossible to run a binary on distro a if it was compiled for distro b. OpenSolaris has a much smaller community and I am not sure whether OpenSolaris will survive too much fragmentation. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap planning
Date: Wed, 19 Feb 2014 12:42:53 +0100 From: joerg.schill...@fokus.fraunhofer.de snip Well it would be great if some people at Illumos would not try to dictate things but signal that there is an interest for a collaboration. illumos is collaborative. In the past year there has been around 50 contributors all working on the code: http://github.com/illumos/illumos-gate/graphs/contributors?from=2013-02-17to=2014-02-16type=c Given that SchillixON has 1 collaborator, is it not possible that the barrier to collaboration between yourself and illumos is not illumos, but you? It isn't. There are distros using SVR4, dpkg, rpm, IPS, pkgsrc, and/or no packaging at all. Well, where is the SVr4 package meta data in Illumos? Note that IPS meta data is limited compared to Svr4 package meta data and for this reason, there is no way to convert meta data correctly. illumos is not a distribution. It carries packaging metadata in IPS format as a convenience for downstream distributions, but downstream distributions are not obliged to use IPS. Perhaps in the future illumos will stop shipping package metadata completely. Many other illumos based distributions use other package formats, such as rpm, deb and SVR4. Ultimately, packaging is a distribution specific implementation detail. If you wish to use SVR4 in SchilliX, you are free to do so. Nobody is stopping you. snip Illumos would need to verify first that Illumos is collaborative. Currently we have the unfortunate state that Illumos did not include some software even though this was promised and a code review has been presented. Colaboration of course also means that partners are trustworthy and implement promises. Once Illumos turned into a trustworthy and collaborative entity, it makes of curse sense to file bugs against Illumos. Illumos is very collaborative. A diverse array of individuals and organisations successfully collaborate on illumos every day: https://github.com/illumos/illumos-gate/graphs/commit-activity Illumos has a clearly defined contribution process: http://wiki.illumos.org/display/illumos/How+To+Contribute If you want to collaborate, you have to follow the procedure. Everyone does. If you're not prepared to follow the procedure, then that's your problem, and nobody else's. If you correctly follow the procedure, and the community decides it doesn't want that specific feature, the mature adult thing to do is to accept this and move on and continue to attempt to collaborate on other items. Forking illumos as SchilliX-ON because you can't follow procedures or because people don't want a specific feature integrated is petty and childish. Then complaining about it for years afterwards on mailing lists is further evidence of stunted emotional development. If you want to collaborate, collaborate and follow the god damned procedure. Otherwise, stop bothering everyone on these mailing lists. Regards, Alasdair ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap planning
Alasdair Lumsden alasdai...@gmail.com wrote: Date: Wed, 19 Feb 2014 12:42:53 +0100 From: joerg.schill...@fokus.fraunhofer.de snip Well it would be great if some people at Illumos would not try to dictate things but signal that there is an interest for a collaboration. illumos is collaborative. In the past year there has been around 50 contributors all working on the code: It may be that this is your personal impression, but this is not usable for a general statement. From my experiences Illumos is non-collaborative and non-trustworthy. This however is something that could be easily changed. Illumos would just need to give a sign that there is a will for collaboration. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap planning
On 19 Feb 2014, at 12:17, Alasdair Lumsden alasd...@lumsden.eu wrote: illumos is not a distribution. It carries packaging metadata in IPS format as a convenience for downstream distributions, but downstream distributions are not obliged to use IPS. Perhaps in the future illumos will stop shipping package metadata completely. Many other illumos based distributions use other package formats, such as rpm, deb and SVR4. Ultimately, packaging is a distribution specific implementation detail. If you wish to use SVR4 in SchilliX, you are free to do so. Nobody is stopping you. The IPS metadeta isn’t really that useful to non-IPS distributions but I’m not sure removing it is a good idea. Instead I’d rather see the SVR4 data reintegrated if it’s going to see some use and somebody cares enough to maintain it. I also think the “nobody is stopping you” attitude is anti-collaborative and (I hate to resort to name calling here) childish too. illumos needs to learn to be more accommodating if it wants to have the collaboration of distributors. And that’s my 2c. Andy. ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap planning
Andy Stormont andyjstorm...@gmail.com wrote: The IPS metadeta isn?t really that useful to non-IPS distributions but I?m not sure removing it is a good idea. Instead I?d rather see the SVR4 data reintegrated if it?s going to see some use and somebody cares enough to maintain it. This is what I did in late 2010 and early 2011. Svr4 package meta data is present and maintained on SchilliX-ON. Feel free to take it. Even though I have no use for the IPS meta data, I did maintain it so far... Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap planning
On 19 Feb 2014, at 12:26, Joerg Schilling wrote: Alasdair Lumsden alasdai...@gmail.com wrote: Date: Wed, 19 Feb 2014 12:42:53 +0100 From: joerg.schill...@fokus.fraunhofer.de snip Well it would be great if some people at Illumos would not try to dictate things but signal that there is an interest for a collaboration. illumos is collaborative. In the past year there has been around 50 contributors all working on the code: It may be that this is your personal impression, but this is not usable for a general statement. From my experiences Illumos is non-collaborative and non-trustworthy. This however is something that could be easily changed. Illumos would just need to give a sign that there is a will for collaboration. This is tiresome and unreasonable, Joerg. It's been pointed out that your definition of collaboration is that your contribution not be evaluated by the same process that applies to anyone else attempting to contribute, and your complaint is that, before this process was established, you felt work you offered for contribution wasn't accepted. When this point is raised, you don't address it head-on, your responses are stuck on an impasse you hit with Garrett in 2010 rather than dealing with the community and contribution process as it's actually functioned for the last three years. Garrett isn't the illumos community, and I, like everyone else in the community, have no reason to take a position on what happened between the two of you four years ago or see that as relevant to what's happened since Garrett shepherded illumos to a collaborative community with collective technical direction. You may not like hearing this, but what you consider dispositive is generally not taken as relevant. If that's something you can't get past, that's a matter of your choice rather than ongoing problems with the illumos community. On top of that, over the course of several years numerous people in the community have given you feedback about shortcomings in your own responses to offered contributions to help you offer feedback that is constructive for those contributors and the community, and you've shown no interest in taking or addressing that feedback. The observed pattern is that you object to contributions without offering a clear problem definition that can process a better solution either immediately or as a later change. Call it open source liberalism as a community value: people don't want to be told simply that what they've got isn't sufficient as a contribution, they want to be given a clear definition of what needs to be resolved so that they receive criticism they can address, and your feedback is often disregarded because you articulate criticism that is simply negative. I don't see that you fundamentally appreciate that otherwise valid criticism that has only negative expression is not satisfactory in community collaboration and may therefore be set aside. You haven't taken any of this feedback, which I take to be offered in the hope and expectation that collaboration is possible, on board. I'm not trying to say that the illumos community is perfect, but you've been repeatedly unwilling to demonstrate that you're willing to self-scrutinise and compromise on the question of collaboration, even as you loudly complain about others, which itself becomes a further obstacle. If you're surprised that the result is that you therefore lack credibility, that's ultimately your problem and deficit. When you add to that claims that the community isn't trustworthy, that's offensive, and that's the point at which I feel compelled to write a public response like this one. It's not that anyone doubts your fundamental ability as an engineer, but anyone who wants to be part of a community has to expect to participate by the standing conventions of that community. I've taken you seriously enough to read back through mail archives to look at the interactions you've had with the community over the years, and what I see is that there are serious problems on your end that you do not acknowledge. There are certainly communities whose product I like and use but whose process I don't care to engage, and I'm able to reconcile myself to that. If you don't want to work by other people's rules, the result may be unfortunate, but it's not fundamentally a question of other's willingness or integrity. I'd certainly be happier if you'd begin to deal with this. I should add that, as long as your responses continue the pattern I describe, I have no intention of or interest in responding. Kind regards, Bayard ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap planning
On 19 Feb 2014, at 13:30, Joerg Schilling joerg.schill...@fokus.fraunhofer.de wrote: Andy Stormont andyjstorm...@gmail.com wrote: The IPS metadeta isn?t really that useful to non-IPS distributions but I?m not sure removing it is a good idea. Instead I?d rather see the SVR4 data reintegrated if it?s going to see some use and somebody cares enough to maintain it. This is what I did in late 2010 and early 2011. Svr4 package meta data is present and maintained on SchilliX-ON. Feel free to take it. I’d love to see an SVR4 distro that was actually supported by upstream illumos but I won’t be the one to make it happen. Do you not have any desire to move to an illumos-gate base? Even though I have no use for the IPS meta data, I did maintain it so far... Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap planning
On 19 Feb 2014, at 14:27, Igor Kozhukhov wrote: Hi All, it is thread about OI , but let me provide additional info. We are talking about illumos, but I think, we have to understand, that illumos based on sponsors who are using it for business and depend on it. Take a look list of advocates: all advocates from companies who are using illumos for business and invest to devs/env. Not true. Please review the advocates list, which shows that Rich Lowe remains without commercial affiliation: http://wiki.illumos.org/display/illumos/RTI+Advocacy___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap planning
Bayard Bell buffer.g.overf...@gmail.com wrote: From my experiences Illumos is non-collaborative and non-trustworthy. This however is something that could be easily changed. Illumos would just need to give a sign that there is a will for collaboration. This is tiresome and unreasonable, Joerg. I am not sure what you call unreasonable A promise is a promise and as Illumos broke that, this is a problem initiated by Illumos. I am not unforgiving, so it would be simple to just implement the promise to come out of the current situation. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap planning
Andy Stormont andyjstorm...@gmail.com wrote: This is what I did in late 2010 and early 2011. Svr4 package meta data is present and maintained on SchilliX-ON. Feel free to take it. I?d love to see an SVR4 distro that was actually supported by upstream illumos but I won?t be the one to make it happen. Do you not have any desire to move to an illumos-gate base? The problem is that there now are more differences between illumos and SchilliX-ON that just the package meta data. But I am open to discussions and proposals as long as they permit enough room for the goals I have for SchilliX. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap planning
On Wed, Feb 19, 2014 at 2:35 PM, Andy Stormont andyjstorm...@gmail.comwrote: I'd love to see an SVR4 distro that was actually supported by upstream illumos but I won't be the one to make it happen. Define supported. Tribblix is a pure SVR4 distro from a vanilla illumos-gate, really just a handful of scripts to build the distro. I didn't need anything on the illumos side to make it all work. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap planning
On 19 Feb 2014, at 15:19, Joerg Schilling wrote: Bayard Bell buffer.g.overf...@gmail.com wrote: From my experiences Illumos is non-collaborative and non-trustworthy. This however is something that could be easily changed. Illumos would just need to give a sign that there is a will for collaboration. This is tiresome and unreasonable, Joerg. I am not sure what you call unreasonable…. The rest of my e-mail was quite explicit on this point. If you're nevertheless not sure, I take this as a sign that you will continue to complain about the lack of reasonable interlocutors whom you ignore when they address you and ask you what you'll do today to collaborate rather than what are your preferred conclusions and consequences of a personal dispute from four years ago. A promise is a promise and as Illumos broke that, this is a problem initiated by Illumos. I am not unforgiving, so it would be simple to just implement the promise to come out of the current situation. illumos never made any promises to you, so when this promise further implicitly exempts you from the current contribution process, it's a non-starter. In fact, Garrett does not have the authority to say that a contribution can bypass the contribution process, and such an exemption would violate the fundamental integrity of the process. If it's simple, it's as simple as that, and this isn't the first time this has been said directly--I could post the mail thread we had some time ago with the advocates list that went precisely to these points. Further, I checked the archives a year ago, and I don't recall finding any contribution you submitted to the community under the current process, only complaints about not being able to have work accepted by telephone call to Garrett immediately after the fork, while the process was still largely undefined. If you don't take the option to break the circle where it's available, that's the definition of what can be done and entirely up to you. The further hypothesis this suggests is that you have settled on fixating on this previous incident because the contradiction which has been brought to your attention in fact relieves you of dealing with or accepting any criticism of your work or forms of participation. I don't think you've attempted to address this fundamental contradiction when it's been brought to your attention: you continue to define equal treatment as preferential treatment in explicit violation of standards that apply to everyone else. You use the word collaboration a great deal--in the concrete practice of it for the illumos community, I think you either don't know what it means or are yourself averse to it. I do not know whether you aware of this evasion, but when you cast its lack of acceptance as a character deficit of others, I feel compelled to raise this publicly. Anyway, that you've replied to the first line of what I said and professed that you don't understand what's been said before that you very evidently don't want to hear, is a sign that this won't be a dialogue, which is an expected disappointment and already more than needs to be said. I appreciate that this is a difficult position for you, but as long as your basic premise for talking about this is that there's no problem on your end, this is going nowhere. Cheers, Bayard ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] oi_151a9 roadmap planning
Bayard Bell buffer.g.overf...@gmail.com wrote: illumos never made any promises to you, I am sorry to see that you are uninformed. Jörg -- EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin j...@cs.tu-berlin.de(uni) joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [discuss] Re: basis for better collaboration on illumos and OpenIndiana: small circle, Big circle
The reason we need a minimum of criteria for collaboration is precisely because the different distributions have different focus, approach, and use case scenarios in mind, but a set of core features that will make it to a unified kernel will be for everyone's benefit. Additional layers will be built upon this basic core and the abstraction of these feature-sets and their encapsulation from the layers below and above it will ensure that there is more or less a predictable and uniform way each of these layers interact together and how they behave on top of the core. I mean each distro-specific feature-set will be spun out and encapsulated into separate layers of development on top of the kernel (and these layers will be slightly or wildly different in each distribution) but the core will remain mainly intact but dynamically developed jointly by the different distros in an upstream manner. For example, support for Linux platform ABI through branded zones like Solaris Containers for Linux Applications (SCLA) has been implemented by Sun before. This is possible because there is a Linux platform ABI to speak of. It makes sense if we can agree on a minimum set of behavior and features that make up an OpenSolaris-based platform ABI, implemented through a smaller standard reference distribution that will embody this minimum standard, like a smaller text-based OpenIndiana server install or LiveCD that will serve as reference, example and basis of other distros that will build layers of additional layers on top of it. We must reckon that Solaris itself in the beginning was the direct result of unification efforts by ATT, Sun and others, and so SVR4 was born which was the basis and foundation of many later UNIX systems and other OS'es and so on. I think it's not too late to gather the efforts of our separating communities in the different branches of OpenSolaris-based distros to arrive at s single standard like the mainline Linux kernel, and a jointly-developed single reference distro like Sun's OpenSolaris LiveCD in the past, resulting in a slim OpenIndiana which can be a reference to other distros or even as a basis for a larger full-featured GUI-based OpenIndiana LiveCD. on Mon, Feb 17, 2014 at 5:38 AM, David H davidha...@gmail.com wrote: Collaboration Criteria: - The original promise was for both Intel SPARC in the community, that promise should be kept. I believe so, too. I have been in contact with Martin Bochnig and he is very positive about collaboration and unification efforts. He is willing to release his progress so far and will be putting up a wiki to explain his process and recipe for x86, x86_64 and SPARC architectures. He has been collaborating with DilOS folks and I know things will be better the moment we start plotting their development against how ilumos-kernel has evolved and how OpenIndiana has grown. The key factor here is: how much code from OpenSolaris has been discarded simply because Nexenta or Joyent has found no use for it? I believe there may be many such valuable artifacts (like SPARC support) from Sun's OpenSolaris that has been lost, because slashing them was expedient and caused less bugs. Another factor is: what improvements have been developed outside of the ambit of illumos-OpenIndiana circles, by other branches like SchilliX, Belenix, MartUX/OpenSXCE, DilOS, XstreamOS, OmniOS, etc.? David, you have a very good partial list, and to be frank yes! many oppotunities indeed passed by, but I think the best is yet to come. Thanks Srinam for dropping that Belenix is also underway. Collaboration should be to pool resources to expand the ecosystem - not pool all available resources in order to keep the ecosystem limited in overall scope. Thanks, Dave AMEN to that. The tug and pull of Jorg and Peter's arguments is healthy for our community. This way we can strike a balance between the tyranical standard approach with a rigid set of feature compliance and the very fuzzy definition of what OpenSolaris-based distros are evolving into. By keeping our criteria for collaboration at a minimum, we are inviting more synergy between developers on the basic general stuff and at the same time promoting more choices how to implement different solutions to the same familiar problems and opening more ways to implement new solutions to needs unforeseen or poorly addresed before. To quote Joerg Schilling joerg.schill...@fokus.fraunhofer.de at another instance (Wed, 12 Feb 2014 14:28:47 +0100): Collaboration is a result of promises and credibility by implementing said promises. Collaboration is also a result of compromises. If you are not willing to make compromises, you try to dictace what other people may do and this is not compatibile with collaboration. I am open for a collaboration for OpenSolaris as long as there is room for different goals in the different distros. Joerg Schilling joerg.schill...@fokus.fraunhofer.de (Thu, Feb 13, 2014 at
