"Roy T. Fielding" <fielding at gbiv.com> writes:

> On Dec 31, 2007, at 6:33 AM, Richard Lowe wrote:
>> Alan Coopersmith <Alan.Coopersmith at Sun.COM> writes:
>>> Roy T. Fielding wrote:
>>>>    Take their bits
>>>> somewhere else -- have the OGB set up a community that reflects
>>>> where
>>>> the organization is supposed to be heading instead of what it used
>>>> to look like in the past.  If we can't do that because we still
>>>> don't
>>>> have an Hg instance, then the OGB should put an end to that long- 
>>>> running
>>>> farce once and for all -- mandate Subversion across all of
>>>> OpenSolaris
>>>> whether you like it or not.
>>>
>>> At this point, mandating Subversion would greatly delay the
>>> availability
>>> of the external gates - all the work done to make the various
>>> build and
>>> integration tools work with Mercurial would be thrown away and
>>> another
>>> year spent redoing it to work with Subversion instead.
>>
>> As someone particularly familiar in this area, I feel compelled to
>> comment, if only to say that Alan is largely correct.
>
> How about updating some of the SCM pages to reflect the current status
>
>   http://www.opensolaris.org/os/community/tools/scm/

I cannot edit those pages, they belong to the tools community.

opensolaris.org/os/project/scm-migration (which is also out of date,
in part, though I can update it).

> and then put a link to them on the front page and downloads page?

I can't do that either.

> I had to do a search for Mercurial in order to find them at all.
> If the gate really is operational at this point, then my remark
> about Subversion does not apply.

Project gates are operational, the major problems for the release
gates of both ON and SFW are not related to the SCM choice, but to
the logistics of getting them outside and functioning.

There's 15 years of assumptions being shattered all at the same time.
 
>>> The problem with the gate conversions is not the technology being
>>> moved to -
>>> we could have gone live with Mercurial long ago if it was only the
>>> process
>>> of setting up repositories that had to be done - it's the
>>> integration with
>>> the rest of the process and tools that is taking time.
>>
>> That's largely true, but not entirely.  I don't see any point in
>> elaborating in this discussion, however.
>>
>> If you, the OGB, feel that this is all our (SCM)'s fault, you are, of
>> course, free to fix that in any way you so choose.
>>
>> But if you really think it will alter this farce in any material way,
>> you're fools.
>
> The farce is the continuing year-over-year excuses for the development
> not being done in the open.  Only one of those excuses was SCM.

Yes, the DTS work that's being going on in the tools community is a
good thing there.  There's a project been proposed to move the RTI
stuff outside too, but as far as I can tell it currently lacks enough
endorsements in either of the communities they asked.

I'm hoping this is because of the time of year, rather than anything
else.

I will state however (and I'm glad this is going to tools-discuss),
that if their project has governance in the way, I'm more than happy,
and will encourage them to become part of SCM migration (which is
already approved, obviously) to make sure it gets done. 

> We should have mandated Subversion from day one (which required no
> additional tool integration)

Oh, yes it does, and it's no easier either.  The problems with
actually moving stuff would in fact be worse.

> and continually reevaluate things like Mercurial as we gained
> experience with open development.  Instead, we now have a tradition
> of doing everything ass-backwards while Mercurial was being
> reinvented, and some folks actually think that ass-backwards is the
> *process* that we are supposed to be following instead of the one
> that the OGB/Sun/community officially ratified last year.

I said farce intentionally, that's part of the reason why.

> It is nice to know that there is finally some progress showing on an
> actual onnv-gate (though I would hope that the Nevada name would go
> away sometime soon).  That is the kind of news I'd like to see on
> the front page.


> My problem is this perceived need to keep everything hidden from the
> public until Sun's closed environment and internal process is ready.

Nothing is intenionally hidden SCM-wise, that I know of.

Much of the problem SCM wise is that there is more to do than people
to do it.

> Until the actual development-in-progress is visible and accessible
> to the community, the community can't do working reviews in public
> and we haven't accomplished diddly squat.

The ON bridge to mercurial has been live for quite a while, and
various communities are doing reviews in public.  Like many things,
when people actually try it, it seems to work out quite while (though
in many cases response from non Sun people is fairly minimal, the
things are in fact working).

I'd encourage you to look at the code reviews in the networking
community, and bits in the SMF community too.  Both are, in my view,
shining examples of how well things in fact can work *now* if people
bother to try.  There's probably other great examples that I'm missing.

> And what happens when we find out that many of those process tools
> are no longer applicable to the open development process?

Of the tools involved with the SCM, none of them relate to the
openess of the process.

The only tool that is vaguely related is the RTI tool, which as I said
is a separate project, and frankly the process involved in it is sound
(it's effectively a double check of code review and such, which as
best as I can tell maps nicely onto what mozilla call "super review").

Openness problems are nearly always "who" not "how".

> We'll have to rewrite them anyway.  Thanks for all the hard work
> being done, but we don't get the benefit of open development until
> we actually use them for community work.  I'd rather have an empty
> repository with no tools than wait for all the tools to catch up.

I disagree largely because there are projects using the tools as
things stand, both mercurial and the tools of the SCM project, and
they seem to be doing rather well for it (at least, I'd hope if they
weren't someone would have mentioned it...).

I can say with confidence that if the onnv and probably SFW gates were
live now on opensolaris.org, things would be no different, because the
process surrounding them is, brokenely, entirely closed, and nobody
seems to have the ability or desire to change that.

That's the farce.

-- Rich

Reply via email to