Each individually-approvable enhancement in the Inbox should be based
off of some version in the trunk.  Sometimes one "enhancement" might
be big or complex enough to have required a string of
package-versions; but that's ok if they're all part of the same
logical change (e.g., converting away from selected indices to
selected objects).

In that latter situation, when core-devs move things to trunk, please
make sure that _all_ versions are copied into trunk, not just the
final one, so that we have all of the ancestry in the same repository.


On Sat, Mar 5, 2011 at 7:24 AM, Frank Shearar
<frank.shearar at angband.za.org> wrote:
> On 2011/03/05 10:47, Levente Uzonyi wrote:
>>
>> On Fri, 4 Mar 2011, Frank Shearar wrote:
>>
>>> On 2011/03/03 23:20, commits at source.squeak.org wrote:
>>>>
>>>> A new version of Tools was added to project The Inbox:
>>>> http://source.squeak.org/inbox/Tools-fbs.301.mcz
>>>>
>>>> ==================== Summary ====================
>>>>
>>>> Name: Tools-fbs.301
>>>> Author: fbs
>>>> Time: 3 March 2011, 11:20:00.889 pm
>>>> UUID: 9f787d80-6eb1-0741-a5ac-57d3a80a3c7a
>>>> Ancestors: Tools-fbs.300
>>>>
>>>> * Complete removal of systemCategoryListIndex, replaced by
>>>> selectedSystemCategory.
>>>> * selectedSystemCategoryListIndex/selectedSystemCategoryListIndex:
>>>> remain, used by Morphic, and defer to
>>>> selectedSystemCategory/selectedSystemCategory:.
>>>> * selectedSystemCategoryName defers to selectedSystemCategory, and
>>>> all its callers now call selectedSystemCategory.
>>>> * PackagePaneBrowser>>hasSystemCategorySelected pulled up to Browser.
>>>>
>>>> =============== Diff against Tools-fbs.300 ===============
>>>
>>> Inbox etiquette question: I'm working on a fairly big chunk of code,
>>> ripping out Browser's indices. I could make 4 or 5 further commits of
>>> about the same complexity as this commit to finish off the change.
>>>
>>> I can see a couple of options:
>>> 1. Submit big chunks basing off Trunk, letting us lose the indices
>>> piecemeal. Basically, branch-per-feature, and each commit's a
>>> completed subfeature.
>>> 2. Submit one megachange, so that Tools-fbs.301 can be deleted.
>>> 3. Submit big chunks each based off the previous commit: a single
>>> branch with serial commits.
>>> 4. Other situations?
>>>
>>> I really don't like option 2: we're talking about rewriting large
>>> chunks of a critical piece of infrastructure.
>>>
>>> So what's the preferred way of submitting large features to the Inbox?
>>
>> It's up to you. For the integrators 1 and 3 are the best. Reviewing
>> small changes is always easier.
>
> 3's mildly easier for me. I just wasn't sure about how people would feel
> with me dumping a whole string of commits in the Inbox. On one hand it seems
> a bit messy because the actual thing I want to go into Trunk will be the
> when-I'm-done commit, but on the other hand putting the versions in the
> Inbox means that integrators can more easily see what's going on.
>
> frank
>
>