Re: [Monotone-devel] Time for a release

[Stephen Leake]

Thomas Moschny <address@hidden> writes:

> On Monday 01 September 2008 Thomas Keller wrote:
>> Stephen Leake schrieb:
>>
>> > Unlike sutures, the implementation in n.v.m.resolve_conflicts doesn't
>> > change any core monotone data structures or database formats, so it
>> > should not break any current functionality.
>
> Do all tests pass?

Yes, and I'm adding new ones for this functionality.

>> > I plan to get it done this weekend (Monday included; it's a holiday
>> > here in the US).
>> >
>> > I'd like this to be in the next release so my team at work can use it,
>> > without an internal mtn version.
>>
>> I'd definitely like to have some people look over the code before it
>> gets merged.
>>
>> > So if we can postpone a release until next weekend, I'd appreciate it.
>
> While a review could be done in a week, I'm not sure we should really be in a 
> hurry. We can easily have a 0.42 in a month or so.

That would be fine.

>> > On the other hand, the mtn command line interface to this feature is
>> > not at all settled. 
>> >
>> > <snip>
>
> Yes, I also think that a cmdline interface for recording resolving decisions 
> is needed. Not everyone is using emacs. 

Ok. Is anyone interested in helping to implement that command line interface?

> At least the format of MTN/conflicts must be documented properly.

That will be done, in the 'automate show_conflicts' section of the
monotone manual, and the various resolutions will be in the 'resolve
conflicts' section.

> Also, test cases are needed. (Maybe this is already done, didn't
> find the time yet to have a look at that branch).

There will be complete Lua tests for this feature; some are there already.

>> > However, if people want more of a chance to review this stuff before
>> > merging it to main for a release, or want to wait for a more complete
>> > implementation, that's fine, too.
>
>> I'm undecided - even though I wear this nice release manager hat, I
>> don't like to say just "yes" or "no" here. I perfectly understand that
>> you need it for your team and that people should be encouraged testing
>> it and all, but I fear that once the code went into mainline, the
>> general (your?) interest making a halfway usable command line which does
>> not include editing basic_io files is gone by then...
>
>> Other opinions?
>
> Not meaning to discourage you, Stephen, but at this time, and with Thomas 
> wearing the release manager cap already, I'd say, we'd better have 0.41 done 
> now, and have your work merged in afterward. Having a 0.42 release within 
> short time then would be fine and fully justified even by a single new 
> feature. But of course the decision is up to Thomas as he's doing
> the work ;)

One issue is who will have time to do the 0.42 release in a month. I could
volunteer to be the release manager next time; I'm not sure others
would be comfortable with that, since I'm relatively new here.

On the other hand, there's no guarantee Thomas Keller will have time in a
month, either :).

Doing an internal interim monotone release just for my team is a
reasonable work-around.

Reviewing all the times I've said "that will be done" in this thread,
it's looking less likely that it will actually be done this weekend
:(.

-- 
-- Stephe