On Wed, Jul 27, 2005 at 06:08:12PM -0700, Roy T. Fielding wrote:
> The latter constraint of "requiring a commit be complete" is
> just as true for collaborative open source projects as it is for
> Solaris. Most open source projects are distributed on several
> orders of magnitude more platforms than Solaris, and thus sometimes
> don't discover a problem exists until it is distributed to some
> platform not owned by a developer on the project, but a general
> rule in Apache is that a change must be complete within the branch
> and platform on which the developer is working before they are
> allowed to commit even to an unstable branch.
That might be acceptable for a project gate ("unstable branch"; see
below for some thoughts on terminology), but I've lived through Linux
development, where "all x86 all the time" is the unofficial official
policy for all branches. Please please please don't ever suggest that
this is a viable way to maintain support for multiple architectures.
Many people are lazy, and will do as little as the process requires
before putting back. If you allow them to break some second-class
architecture, you are committing that architecture's maintainers, if
they even exist, to additional and unnecessary work. If you allow
more people to do the same, you are condemning those architectures to
perpetual brokenness and eventual removal. There can be no
second-class platforms. If a contributor doesn't understand what's
needed to make his change work on $WEIRD_BUT_SUPPORTED_HARDWARE, he
must collaborate with the people who support that platform to make it
happen. A result of this is that the community as a whole needs to
decide carefully what platforms it is willing to support - the cost of
maintaining them can't be borne solely by the people who use them.
The community has to decide whether it's better to have a few
platforms that work well and are rapidly developed or many platforms
that diverge, work poorly, or slow development.
> [... skipping the ARC review description because it was an example
> of a business decision, not a technical decision.]
No, I'm sorry, architectural consistency and compatibility are
examples of technical decisions. Suppose for a moment that there were
no business, anywhere. Money does not exist and all software is
available free of charge as open source. Under those circumstances,
would compatibility and architectural consistency be of any value?
The answer is yes: software still has users (not customers) and those
users still have finite time to spend using or working on software (24
hours a day at most). They can spend that time finding and fixing or
working around newly introduced incompatibilities, or they can spend
their time using the software productively.
The provision of compatibility and consistency under some kind of
well-known rules provides value to developers and users higher up the
software stack, regardless of what they paid for their software or
whether they buy hardware or get it for free. The exchange is that
people working lower down the stack have to invest additional effort
into maintaining that compatibility; I posit that this tradeoff is a
good one, because maintaining compatibility and announcing intentional
incompatibilities involves knowns: known pieces of code, known
documented interfaces, and known sources of information about them.
The alternative involves unknowns: unknown new problems in apparently
unrelated software, unknown side effects of apparently innocuous
upgrades, and unknown - and unbounded - investment of time in finding
and correcting these problems.
It's easy but wrong to see this as a business problem - Sun's
customers have money, for which they obtain the time of technical
staff to develop software or install and manage it. Therefore they
see a monetary cost in the use of incompatible software, and Sun sees
an opportunity to make money by reducing our customers' costs. But
that set of relationships is nothing but a derivative of the original
relationships described above in terms of time. The problem of
developing software that provides value to users and developers -
which presumably includes the very people making the software in the
first place since we're talking about open source - exists in terms of
time regardless of business considerations. It is therefore a
fundamental issue in software development, and thus a technical
problem.
Would it help to know that the ARC is staffed by engineers, not
executives? I wonder if that's the source of worry here.
> >Continuing this "model the expected behavior" example, now that we have
> >a committed plan, what would we do next? One possibility:
> >
> > Create a teamware child workspace (or CVS branch or ...)
> > Gather a group of interested developers together to work
> > on this project
> > Seed this workspace with the ksh93 sources
> > Get it to work
> > Start building in the "dual mode" behavior
> > Develop - Test - Iterate... until complete,
> > Request permission to Integrate the changes back into OpenSolaris
> > Integrate/Putback/Commit...
>
> Alternatively, OpenSolaris could give development autonomy to the
> communities, wherein technical development, discussion of alternatives,
> getting it to work, and testing can all take place independent of
> any ARC review. ARC review isn't needed until the community wishes
> to apply the completed work to a stable release branch, at which
> point the community product does need to adhere to the particular
> interface requirements for that branch. [They are, of course, aware
> of those requirements during the whole process, and thus will have
> designed and developed for a particular set of branches.]
> It makes more sense for an OpenSolaris community to simply create
> a directory on an unstable branch and iteratively design-develop-test
> until complete enough for a release. A discussion should ensue on
> what (more stable) branches it should be ported. Finally, the
> community votes based on what they want in the branch.
Part of the apparent disagreement here seems to center around the
misperception that there's the "stable branch" and then nothing. In
fact one of the constraints on the SCM discussion is the need for
disconnected development - there's a reason for that. Any individual
engineer or team can take a child ("create a branch" in
always-connected SCM parlance) and begin development, committing
changes to that project gate ("unstable branch") with whatever
standards and review that project's contributor(s) feel is
appropriate. It's not difficult to imagine a CAB-sanctioned "unstable
branch" of OpenSolaris itself that combines the changes in the various
major project gates to offer early access to developing technology.
In other words, your suggestion is almost exactly what happens today,
with the exception that these project gates need to be open for
observation and collaborative development, and is entirely compatible
with Solaris engineering values. For example, "A discussion should
ensue on what (more stable) branches it should be ported" is readily
translated to "The ARC works with the project team to determine the
appropriate release binding for the changes."
It's *very* unfortunate that non-mainline development hasn't opened
yet, and I can tell you the reason: lack of resources for
infrastructure development. Nevertheless, you don't need Sun's help
to start working this way on a project - witness the PPC effort.
> Within Sun Engineering, advance review and careful description of
> customer benefits are necessary because resources are limited and
> need to be allocated. In collaborative open source, resources are
> only limited by the number of interested volunteers and the entry
> barriers they need to overcome before contributing. Description
> and review of plans is always beneficial, but those descriptions
> and plans can and should be adapted as development on the unstable
> branch proceeds.
Deciding whether to commit scarce resources to a project and
determining whether its technical changes are suitable in the context
of a particular release's rules are orthogonal. The choice to make a
particular release at a particular time and the choice of rules for
future releases have historically been based on business and technical
considerations; however, the way releases are managed and how Solaris
releases - driven by Sun's business needs - and OpenSolaris
development - *not* driven by Sun's business needs - relate are
changing as we move to collaborative development.
> We can expect that Sun will contribute a majority of their effort
> on projects that Sun considers to be a priority for Solaris. That
> is good for everyone concerned because the end result benefits
> everyone. Others can be expected to focus on their own priorities,
> which is also good for everyone concerned. Resources don't need
> to be carefully allocated across OpenSolaris because each group of
> people are already being allocated by personal preference (with
> a substantial part of that preference being determined by their
> "real job").
>
> Design review is a continual process in an open source project.
> Point reviews come in two forms: code change reviews and release
> versioning. Interface stability is determined by the scope of
> changes allowed on a given branch release.
>
> Sun can participate in an OpenSolaris community and attempt,
> through reasoned argument and contributed alternatives, to steer
> the design of a product towards a given set of interface
> characteristics. Sun can also choose to release only stable
> components within its proprietary releases of Solaris.
> However, if we want the rest of the community to participate as
> equals within OpenSolaris, then Sun must allow the rest of the
> community to participate according to their own priorities.
We're in complete agreement here.
> OpenSolaris must allow projects to proceed independent of the
> business requirements of any single contributor, even when one
> of those business requirements happens to be interface
> compatibility with SunOS 5.0.0. That cannot be an OpenSolaris
See my other post and the discussion above for an explanation of why
(a) there's value in that compatibility for everyone, not just Sun,
and (b) that's not a business requirement but a matter of technical
strategy.
> requirement because it prevents the community from building new
> things that may never be part of SunOS. After all, Sun decided
> to do this open source stuff because they want to take advantage
> of the non-linear productivity of the open source world. You
> can never predict when a feature will become so compelling to
> new customers that it will justify a SunOS 6, but you can
> measure it after the community has developed and deployed
> that feature in cutting-edge distributions.
Nothing prevents anyone from making an OpenSolaris branch with major
release rules (or even no rules at all), and nothing in what we've
discussed would prevent a project team from delivering to it changes
that are only suitable for a major release. This is true based on the
right to fork, but there's no reason some hypothetical OpenSolaris
Release Sanctioning Body couldn't designate that branch the official
Major Release development branch for OpenSolaris. Whether it would
ever become Solaris is Sun's choice. The decision to contribute to or
use that branch is made by contributors and users, not by Sun, and
there's no reason to think that even an ARC consisting only of Sun
employees (not the plan, of course) would deny a project team's
proposal simply because it requests Major release binding; following
ARC approval, the team would be free to target any active release with
Major Release rules.
> The only other alternative would be for OpenSolaris to become
> a non-collaborative project, a la Darwin, wherein the rest of the
> community is free to play with the code but only one company
> determines what goes into releases. That is still open source;
> just not collaborative open source.
That's not the plan nor the intent.
--
Keith M Wesolowski "Sir, we're surrounded!"
Solaris Kernel Team "Excellent; we can attack in any direction!"
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
