Re: [oi-dev] Resignation
On 09/12/14 10:53 AM, Nick Zivkovic wrote: Developers are user too, you know. :) Nobody questioned that :) Thing is, they are not the only one using the things they make or change. If they are the only one, every developer would have it's own distro... Also there is difference between coders and developers as I see it. You don't need to expect from coder to be a developer and vice versa. E.G. developers are usually users, too. Coders are not. Simple example are tons of ex-Sun employees that just lost interest in Opensolaris after their payment for contribution has been cut off. Your argument seems to imply that the developers 1) don't use their own creations and 2) have no good or original ideas of their own, and are eagerly awaiting the input of sales and users to guide their decisions. Developers aren't children in need of adult guidance. Difference between coder and developer as i understand it is that coder have no interest whatsoever beyond he's contract about platform he uses on the project. Developer have interest in platform and he will tend to do what is better for it. In a sense, developer invest he's work and sweat, coder is payed to code. There is no successful distribution without big traffic of opinions and requests from users to developers. And it goes both ways. Why would a developer make something --- in his spare time, for no compensation --- that he himself would never use? Don't know - maybe you have an answer for that question, since you invented it and asked it :) Maybe someone else need what he made and asked from him to make it work and he likes the idea. Illumos is a volunteer effort, and developers have a clear idea of what they want the system to do. The majority of Illumos developers are heavily invested in the technology, and aren't in it just for the paycheck (if they're even getting a paycheck for Illumos work). Many of them use and depend on Illumos every day. Naturally feedback from users is welcome, but you don't need full-blown governance for that, just these mailing lists and the bug trackers. illumos is a project payed by several companies that employed fully payed employees to develop it. It is of course possible to send changes upstream and that is true, but illumos would not exist without those paying companies, so it obviously it reflects their interests and of their use cases, and steer platform where they like. If people outside those companies want to make changes, it is obvious that it is NOT enough just to send some code upstream and hope it gets integrated. People need to form clusters of users, Admins, Hosting and companies using distributions , to , again, employ their people , pay them or inspire existing employees or Members to contribute to make their job easier. More people join such clusters, it is better , not to let just a few companies move illumos to ,say x86-only , killing SPARC or something else. Given the choices between democracy, bureaucracy, autocracy, and adhocracy, I'd say that empirically adhocracy (Illumos) and autocracy (Linux, Node.js, SmartOS) have worked out best in open source projects. Democracy results in community schisms (Gentoo, the BSDs, all of which got forked permanently and never merged back --- even Debian got forked into Ubuntu, IIRC), and bureaucracy is too rule and process-oriented (we're making software, not mass producing pharmaceutical products). While there are some interesting sociological questions here to be answered, it nevertheless holds that we know what has and hasn't worked well so far, and we should do what has worked well. I would say I can not answer easy to such wood of social arrangements and their meanings, all I can say is that regarding OS Distribution organization, people that are in contact with end customers, mostly have idea what they need. Nothing can replace real-life problems and inventions are not made out of nothing, that just does not happen easy. Having said all of that I encourage everyone who is interested in Illumos or in software in general to learn to code. This 1) makes one a better human being, 2) gives one more credibility, 3) give one the ability to solve one's most pressing problems, when the other developers are unavailable due to a crisis in the data center (or in life generally) --- or due their lack of interest in one's specific problem. That is great idea! Only problem is, that it is close to mind, that beginners need to have stable platforms to work on and start developing something they like. It is also said that best way to learn to code or develop is to include yourself in existing projects or software distributions. For that goal I also consider mentoring is a great way of inclusion of new people ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation
This is about as useful a conversation as talking about comparative constitutional law as a problem to be solved by exporting good constitutions to somewhere suffering from political problems. Constitutions and licenses are foundational documents that express a way of proceeding in pursuit of shared values and objectives. A great license or constitution can't be transplanted or otherwise adopted if it doesn't in fact meet a development community where it is and move it where it wants to go. It's why there will never be one license to rule them all: because there will always be interesting opportunities in playing the game by different rules that better suit a productive grouping that generally gets along. It's why there will always be forks and schisms, even if you can agree on licenses. You aren't talking at all about OI's challenges, such as technology debt or strategic direction for issues that OI cares about (such as desktop technology) analytically. (For example: technology debt in build systems is very much a reason why developers are a reasonable first-order community consideration at the moment--you can't get to reasonable development cadence when you've got a lot of movement in upstreams and a great deal of time spent fighting the build system.) I don't see reasoning offered for why governance is even the question being posed for the OI community, let alone why you need to follow the Debian model, as well as it works for Debian. Cheers, Bayard On 13 September 2014 01:28, Peter j...@zeus.net.au wrote: That's rich, a project with no stable release baseline to measure binary compatibility against won't accept patches unless ... The logical solution is to maintain a stable kernel release version at OI, then use that as a baseline for patches and submit patches upstream to Illumos from OI rather than from individual developers. That will put your patches on an equal footing as those with commercial interests. I'd ignore the FUD about legacy platforms, projects that support multiple architectures are more stable for it. Debian's constitution is minimal and a similar structure will lend strength to all your interests. Why not base your project on one of the most successful free community projects? Regards, Peter. - Original message - On 12 September 2014 10:24, Nikola M. minik...@gmail.com wrote: illumos is a project payed by several companies that employed fully payed employees to develop it. We have a mixture of commercial interests and unpaid, or at least unaffiliated, contributors. The obvious examples to cite are Rich Lowe in general, or Saso Kiselkov when he was adding LZ4 support to ZFS. If people outside those companies want to make changes, it is obvious that it is NOT enough just to send some code upstream and hope it gets integrated. It is actually the case that, whether or not you work for one of those companies, it is _not_ enough to just send some code. If you are an engineer, regardless of your employer or your motivations, we expect you to provide evidence of several things: - that you have done a full build of the software, and that you have not induced compiler warnings or code style issues - that you have received code review from at least one person who has worked in similar parts of the code base already - that you have tested the software you added or changed, and any software the behaviour of which you may be altering - that you are not breaking public interfaces we expose to users, so that they can expect at least binary compatibility If you work for one of those companies, or not, you are expected to provide the above. If you provide the above, and the advocates are satisfied that you are maintaining the quality of code in the gate, then your changes will be put back. It's as simple as that. What is _not_ simple is that from time to time, people propose and submit changes for review that will break other users of the software. Or, people propose and submit changes that have received insufficient review and testing. Just because it's open source, community-developed software does not mean that we should be lax on quality, or reckless with respect to backwards compatibility. For better or for worse, that's why we accept changes the way we do today. People need to form clusters of users, Admins, Hosting and companies using distributions , to , again, employ their people , pay them or inspire existing employees or Members to contribute to make their job easier. More people join such clusters, it is better , not to let just a few companies move illumos to ,say x86-only , killing SPARC or something else. If (or, frankly, when) we kill SPARC support, it will be because _years_ have passed without any real
Re: [oi-dev] Resignation
Stability issues only appear to exist with one upstream project. Maintain a stable branch for OI and diff and review upstream changes, that'll stabilise OI's build. Report any breakages to the upstream maintainers and don't merge changes that cause breakage. Where does this community want to go? Forget about desktop, server etc, I might have a server that needs DRI to support GPGPU, while you might have a desktop that needs DRI to support 3D graphics. Get back to basics: * Relaibility * Stability * Compatibility * Hardware support Obviously standards and well documented hardware, or well supported by free software is easier to support. I've noticed with sparc there's a lot legacy closed hardware and drivers etc. It's clear the Xorg, IPS and such are the future, but this shouldn't prevent others from bundling OI with legacy binary drivers and other stuff and OI shouldn't deliberately break compatibility unless absolutely necessary. Debian used to have a non-fee section (don't know if this is still the case) but that could work here too. With regard to sparc, there are a number of current chip manufacturers, Aeroflex, Fujitsu, Oracle, FeiTeng. How hard would it be to support sparc v8? What about ARM64? Going forward longer term, if people want 3D graphics on sparc, they'll need to work out how to utilise PC hardware. I've been looking into 8086 real mode emulation and whether it can be compiled into fcode, allowing PC cards to be flashed to support OpenFirmware. Then we can use the free Xorg drivers for sparc also. I'm also investigating whether the crypto acceleration drivers can be rewritten to support T1, T2 and T3, based on hypervisor documentation, header files and some dtrace analysis. I just picked up a 2U T2 sparc with 128 threads, 64GB Ram, 10GigE and room for 16 SAS 2 hard drives, cheap, others will do the same. It's clear that Illumos isn't the right place for me to contribute directly, but the whole community will benefit if I and others like me can contribute via OI. Regards, Peter. - Original message - This is about as useful a conversation as talking about comparative constitutional law as a problem to be solved by exporting good constitutions to somewhere suffering from political problems. Constitutions and licenses are foundational documents that express a way of proceeding in pursuit of shared values and objectives. A great license or constitution can't be transplanted or otherwise adopted if it doesn't in fact meet a development community where it is and move it where it wants to go. It's why there will never be one license to rule them all: because there will always be interesting opportunities in playing the game by different rules that better suit a productive grouping that generally gets along. It's why there will always be forks and schisms, even if you can agree on licenses. You aren't talking at all about OI's challenges, such as technology debt or strategic direction for issues that OI cares about (such as desktop technology) analytically. (For example: technology debt in build systems is very much a reason why developers are a reasonable first-order community consideration at the moment--you can't get to reasonable development cadence when you've got a lot of movement in upstreams and a great deal of time spent fighting the build system.) I don't see reasoning offered for why governance is even the question being posed for the OI community, let alone why you need to follow the Debian model, as well as it works for Debian. Cheers, Bayard On 13 September 2014 01:28, Peter j...@zeus.net.au wrote: That's rich, a project with no stable release baseline to measure binary compatibility against won't accept patches unless ... The logical solution is to maintain a stable kernel release version at OI, then use that as a baseline for patches and submit patches upstream to Illumos from OI rather than from individual developers. That will put your patches on an equal footing as those with commercial interests. I'd ignore the FUD about legacy platforms, projects that support multiple architectures are more stable for it. Debian's constitution is minimal and a similar structure will lend strength to all your interests. Why not base your project on one of the most successful free community projects? Regards, Peter. - Original message - On 12 September 2014 10:24, Nikola M. minik...@gmail.com wrote: illumos is a project payed by several companies that employed fully payed employees to develop it. We have a mixture of commercial interests and unpaid, or at least unaffiliated, contributors. The obvious examples to cite are Rich Lowe in general, or Saso Kiselkov when he was adding LZ4 support to ZFS. If people outside those companies want to make changes, it is obvious that it is NOT enough just to send some code
Re: [oi-dev] Resignation
On 12 September 2014 17:28, Peter j...@zeus.net.au wrote: That's rich, a project with no stable release baseline to measure binary compatibility against won't accept patches unless ... Actually, our stated goal of FCS quality all the time means that we intend to treat _every commit_ in the gate as a stable release. Things are only integrated when they work, and once they're integrated, documented, and people are able to use them, we intend to keep supporting them compatibly. Accidents happen; negligence cannot. We may not be perfect, but we _strive_ to be, and to fix bugs (or revert integrated changes) as quickly as is possible so that the software remains unbroken. The logical solution is to maintain a stable kernel release version at OI, then use that as a baseline for patches and submit patches upstream to Illumos from OI rather than from individual developers. Working on your own distribution-specific fork of illumos-gate is a reasonable idea -- it's the model we use for SmartOS at Joyent. If your intent is to avoid work creeping up on you, I would recommend that you merge changes into your fork early, and often. At Joyent, we merge into the SmartOS fork, illumos-joyent, on most business days. I can't recall a time when we experienced serious difficulty from changes we received through these syncs. We also try to minimise our diff from upstream periodically by submitting chunks of our work for integration into illumos-gate. That will put your patches on an equal footing as those with commercial interests. No, the _only_ thing that will put your patches on equal footing with the commercial interests is to do the software engineering required to produce quality, tested changes. There are not different sets of rules for different contributors -- the same attention to quality, testing, sensible architecture, etc, is expected from all contributors. I'd ignore the FUD about legacy platforms, projects that support multiple architectures are more stable for it. I whole-heartedly agree that operating systems that run on more than one architecture are less likely to see particular classes of bugs that are hidden by some architecture-specific implementation detail; e.g. byte ordering, different core system hardware drivers, etc. Unfortunately, if there are no _active_ OS engineers using and working on a particular architecture, it will absolutely rot over time; eventually becoming an obstruction to important changes where those changes require architecture-specific work. With regard to sparc, there are a number of current chip manufacturers, Aeroflex, Fujitsu, Oracle, FeiTeng. How hard would it be to support sparc v8? What about ARM64? Robert Mustacchi, myself, and a few others, have been investigating (and in Robert's case, working on) an ARM port of the OS. It's a lot of work -- work which is entirely uninteresting to our employer, so it's a spare time project. I would love to see it completed, and hopefully we will get there in time. It's clear that Illumos isn't the right place for me to contribute directly, but the whole community will benefit if I and others like me can contribute via OI. Why is that? If you want to procure and operate SPARC hardware, to fix build issues as they arise, and to write SPARC-specific code for changes that require it, why not do it in illumos? If you (and others like you) do not step up to maintain the SPARC bits, then they truly are dead weight and need to be removed. -- Joshua M. Clulow UNIX Admin/Developer http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
