On 13 September 2014 00:23, Peter <[email protected]> wrote: > Building and testing only on the developers computer before integration > isn't sufficient to be considered stable and those who would contribute, > don't have the resources to test widely enough to satisfy the stable > contribution only model.
It is actually sufficient for many changes. For example: if you are modifying the "grep" utility, and you have written some tests to show that your change works as you expect, and you have run any existing tests to show that it still works as others expect, then it should very likely be fine. Coupled with review from at least one qualified person via direct mail, or on the developers@ list or IRC, you can be relatively sure that the vast majority of changes going into the gate actually work basically everywhere. > Current policy also denies would be community developers the benefits of an > experimental branch; peer review and wider testing. There may be exceptional > developers who's code is perfect, but I am not one of them. It absolutely does not. If you want to have a private branch someplace, you are welcome to. You can post it on github, or bitbucket, or your own server, or just keep it on your local machine. If you want design or code review, or broader testing, you're welcome to publish changes (sources, diffs, webrevs, even binaries) in whatever form is convenient for your reviewers and testers. There's intentionally very little process right up until the point where you want your change to go into illumos-gate -- at that point, you must simply satisfy an advocate that you have achieved appropriate review and testing. The advocates are (busy) human beings -- they respect a fully complete request to integrate when they see one, but they're capable of (and generally willing to) explain what a contributor needs to do to be accepted. The illumos-gate consolidation contains the kernel and the most fundamental libraries and programs that make up the operating system. If we were to have a public "experimental" branch, with less (or no) restrictions on what could be committed to it, it would clearly break from time to time. Folks would (rightfully) be reluctant to use it for anything important, because it might break; it will thus not receive the wider testing and review you are espousing. This is called the Quality Death Spiral -- removing the hard requirement for quality ensures that quality will deteriorate faster and faster over time. > For the rest of us, a second set of eyes helps to develop well considered > api's and better quality code, and this includes a skunk build and wider > testing. Language like this is not helpful -- there are _not_ two classes of contributor. Every single contributor, regardless of affiliation, is empowered (and expected) to write changes, seek review, test their software (or arrange others to test it), and submit requests for integration. If code review (a second set of eyes) helps you, that's great -- it helps me too! And, I definitely _build_ the software before I put it back. I also definitely seek wider testing if I feel that I am unable to test some reasonable combinations of hardware and software by myself. > If this is the Illumos development model, the community needs to find a way > of working with it. The way is: [1] talk to people and then [2] do work. We believe in rough consensus and running code. > It sounds like Joyent has an internal experimental branch and it sounds like > that's what OI needs in order to enable community based developers to > participate similarly to Joyent developers. We don't have any secret internal branches that I am aware of. We generally all work on the "master" branch of illumos-joyent; hosted on github. We cut periodic releases of our broader product set (which include a bootable illumos platform image) once a fortnight. Critically, we can also create ad hoc "master" releases _at any time_ if we need a bug fix or new feature, so "master" must _always_ be production ready. We can merge "illumos-gate" into our fork every day because it _also_ has the property of being production ready at all times. > I think it's also important to have stable snapshots for users to report > bugs against. It may be important to have stable snapshots of _distributions_, which are what users actually install and thus report bugs against. If you report a bug against SmartOS, we at Joyent must first determine if it's a bug in software we have modified or added to the system, or code from upstream. It is essentially mandatory that users can tell us the datestamp from the platform image they are running in order for us to help them. The same generally applies to OmniOS and OpenIndiana, with whatever versioning schemes they are using for their shipped binary components. > So SPARC is presently unmaintained. > > While I couldn't commit to maintaining it, as it is a significant > undertaking, I could run tests and help debugging and contributing some > improvements. Yes, it _is_ a significant undertaking. That nobody has enough time or resources to step up and commit to being responsible for the whole thing, with or without help from folks like yourself, is really the reason that it's unmaintained. I'm not trying to make out like SPARC is some kind of evil, just that there won't likely ever be enough users and engineers to feed and water it. Cheers. -- Joshua M. Clulow UNIX Admin/Developer http://blog.sysmgr.org _______________________________________________ oi-dev mailing list [email protected] http://openindiana.org/mailman/listinfo/oi-dev
