CWE-ou & Minkata Road Map Planning

[Christian Walther]

It’s time to decide how to proceed with integrating contributions into CWE-ou and testing them on the Minkata shard. A number of contributions have been added to CWE-ou-minkata recently or are about to be, and new ones are coming in regularly. Where do we place the cut for the next Minkata update, which of those contributions do we push to Minkata for public testing, test them for a few weeks, amend if needed, and finally merge them to CWE-ou before including further ones into CWE-ou-minkata?

• Fixed console documentation is in (and already on Minkata)
• Update for Visual Studio 2010 is in (and already on Minkata)
• Allow clickables to function while sitting or AFK is in (and already on Minkata)
• Fix various JPEG issues is in (and already on Minkata)
• Free the cursor is in
• Fix improperly calculated window size in initial Windowed mode will go in as soon as I (or others) finish testing of the amendment I added
• Improved Cursors will go in as soon as I get around to updating it for MSVC10
• Remove broken share symbol from Sharper's Office linking book has somehow slipped my attention, needs review and developer testing
• Correct an invalid GZGlass state has somehow slipped my attention, needs review and developer testing
• Kick command needs review and developer testing
• Avatar physics update has just come in and needs review and developer testing

I would suggest placing the cut before the last or before the last two of these points, but I’m open to other suggestions. The points before that have been open for a while and it would be good not to let them wait much longer. The last point in particular is somewhat extensive and possibly controversial, so I think it would be good to give the testers on Minkata something to do while the developers discuss and test it, which could take a while.

Rarified, what are your plans? Opinions from anyone else?

[rarified]

On first glance I tend to agree at drawing the line above the last two items. Most of the contributions above that are visuals or UI oriented, the last two are (possibly) significant behavioral changes.

Let's get everything above the Kick commit in and start encouraging people to look for anomalies. For the last two, I think perhaps a more organized testing party may be in order, we might get another door run or similar event planned.

Before we do the "event" I still have some changes I want to integrate on the MOSS side as well as revisit the crash logs to see what else can be fixed on the server end.

Sound like a plan?

_R

[janaba]

... I think perhaps a more organized testing party may be in order ... Sound like a plan?

_R

Sounds like fun ...

[Mac_Fife]

I guess we're looking at Minkata shard updates in complete isolation from any prospect of migrating those updates into MOULa - We've no indication of when Cyan would be ready for another update so Minkata could go through several update cycles between now and then.

I think it's probably important not to have too many disparate changes included within one update, as it makes it easier for the testers to keep track of what they're supposed to be testing and means you probably get feedback on any issues quicker. For me, it looks like Christian's suggested break point is about right for now. Moving forward, I expect there's also a question of how frequently Minkata can (reasonably) be updated, which I think is largely down to the effort that Christian and rarified can put in (I'm recognising that we're heading into a period of a few months when people might be expecting to take vacations).

I think it'd be useful to have a list (easy reference, somewhere) that would show what's coming over the horizon (and how quickly). At the moment I get the sense that we're only picking things up when the PR comes in? It's maybe not a big deal, but it might help to decide whether or not to include Change-X in the current update or defer it to the next.

[Deledrius]

I'm recognising that we're heading into a period of a few months when people might be expecting to take vacations

That just means more time for Uru!

[Skoader]

Some contributions are reasonably simple changes that could be thoroughly tested over a weekend, while others will require much more extensive testing. Rather than squeezing them all into a fixed testing cycle (which needlessly extends the overall review time for the smaller changes and puts incoming contributions on hold), could we be more fluid with the input and output of contributions to Minkata?

The avatar physics update is a significant change, so the longer it's on Minkata the better as far as I'm concerned, but not at the expense of other contributions.

If manpower is an issue I can offer my services if it would help.

[Mac_Fife]

Rather than squeezing them all into a fixed testing cycle (which needlessly extends the overall review time for the smaller changes and puts incoming contributions on hold), could we be more fluid with the input and output of contributions to Minkata?

I think that's what is being proposed here - any "Minkata cycle" will be as long or short as it needs to be, and there may be several such cycles (with whatever breathing space Christian and rarified need in between) before Cyan is ready to take another update.

As you suggest, grouping smaller, "low risk" items together in an update and keeping the broader impact items separate is a good strategy. But I wonder if you're suggesting that a "big" item like the avatar physics should be on the shard for testing as soon as possible, and just keep it going while two or three update cycles for smaller items go on in the foreground? I can see that working too and it might be a more efficient use of time overall.

I don't know how much of an issue manpower is for the shard updates right now, but I think any load sharing would be welcomed - You should probably contact rarified directly to see what capacities you could help in.

I'm recognising that we're heading into a period of a few months when people might be expecting to take vacations

That just means more time for Uru!

I suspect your opinion and my wife's opinion would fail to converge

[Christian Walther]

Before we do the "event" I still have some changes I want to integrate on the MOSS side

Is https://bitbucket.org/OpenUru_org/moss/ ... -appearing among those? If it isn’t on the shard already, I think it should.

Sound like a plan?

Sounds good to me.

I think it'd be useful to have a list (easy reference, somewhere) that would show what's coming over the horizon (and how quickly). At the moment I get the sense that we're only picking things up when the PR comes in? It's maybe not a big deal, but it might help to decide whether or not to include Change-X in the current update or defer it to the next.

Yes, for the moment I’m just working from the list of open pull requests (now that we have eliminated Crucible as another source of incoming contributions (have we? ), that seems to work well). Am I understanding you wording “only” correctly in that you are suggesting that it is useful to track possible/announced/expected contributions before they appear as pull requests? Either way, I guess you’re thinking of something like the list in my first post, e.g. on the wiki, and continuously updated? Yes, that might be useful for keeping the overview, though it would be a bit of work to keep it up to date.

Some contributions are reasonably simple changes that could be thoroughly tested over a weekend, while others will require much more extensive testing. Rather than squeezing them all into a fixed testing cycle (which needlessly extends the overall review time for the smaller changes and puts incoming contributions on hold), could we be more fluid with the input and output of contributions to Minkata?

Agreed. I would prefer to get away from the rigid cyclic model myself, but so far I haven’t been able to think of any other way that satisfies the following two unwritten requirements (and maybe more, implicit ones that we would need to identify in the discussion and ask ourselves whether they really are requirements). Can you? Or shall we just drop the requirements?

• -ou receives a cleaned-up version of the history developed in -ou-minkata, i.e. for any feature branch (pull request) there is exactly one merge to the default branch in -ou (in -minkata there can be multiple, when testing uncovers problems that require amendments to be made on the feature branch and merged to default again).
• The head of -minkata is always a descendant of the head of -ou.

The first one is a matter of policy and just seems sensible given the goal of presenting a simple sequence of changesets to Cyan. The second is intended to keep merging as conflict-free as possible and prevent the OU and Minkata branches from diverging without anyone noticing. It could perhaps be replaced by a weaker version: Any two revisions that need to be merged in the usual course of work should have a unique and somewhat recent newest common ancestor.

Now that I think about it again, it seems to me that the following process should work, and satisfy both requirements. I can describe it in more detail sometime when I have more time than tonight, but here’s the short version:

After contributions are merged into the OU branch, instead of discarding the Minkata branch and replacing it by the new OU head, the new OU head is simply merged to the Minkata branch. That merge in general has criss-cross-merged parents (i.e. no unique newest common ancestor) and is therefore likely to generate conflicts in the automated merge (I don’t know how smart Mercurial is about merging such cases), however these should be trivial to resolve, because the merge should be a no-op with respect to the Minkata parent (everything that comes in from OU should already be in Minkata from before), and the diff with respect to the OU parent should contain only Minkata-specifics.

This would allow for a more continuous way of development and testing: Pull requests can be merged into the Minkata branch at any time, contributions that are deemed to be sufficiently tested on Minkata can be merged into the OU branch at any time, and the Minkata shard can be updated to the current state of the Minkata branch at any time, all without interdependencies.

Plus, as a bonus, it would 1. allow us to keep the Minkata-specific adjustments (product name, server addresses, keys etc.) in the version control repository instead of having to apply them as a patch in the build process, and 2. allow contributors to choose whether to make their pull requests against the OU or Minkata branch.

[Mac_Fife]

Am I understanding you wording “only” correctly in that you are suggesting that it is useful to track possible/announced/expected contributions before they appear as pull requests? Either way, I guess you’re thinking of something like the list in my first post, e.g. on the wiki, and continuously updated? Yes, that might be useful for keeping the overview, though it would be a bit of work to keep it up to date.

Yes. Some things might even just be "prospects" way in the distance, but if we know what's imminent and what's far off we can sort out what needs attention and what can be safely set aside for the time being. Some things can start to look imminent and then fade away again as difficulties are uncovered while other might suddenly come to fruition after an "aha!" moment.
I agree that it'd take a bit of work to keep on top of that, and I'm aware that devs who are busy "dev'ing" won't want to take time out to update a wiki page or similar, but it's maybe something we can ask an "enthusiast" or two (who needn't be especially technically oriented) to maintain and go fetch status updates periodically from the various devs and collate them.

[Skoader]

But I wonder if you're suggesting that a "big" item like the avatar physics should be on the shard for testing as soon as possible, and just keep it going while two or three update cycles for smaller items go on in the foreground?

Pretty much. But again, contributions that have been in the queue for some time shouldn't have to wait. Christian's solution sounds ideal.