On 2011/03/05 19:41, Chris Muller wrote:
> 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.

In which case at some point before I can say "feature done" I must 
submit my versions to the Inbox.

I wanted to check before doing something like dumping seven revisions in 
the Inbox (which is my current count). Maybe I should copy the revisions 
to Inbox as I go along, so that more experienced eyes can look over my 
shoulder?

frank

> 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
>>
>>
>
>