[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Monotone-devel] Time for a release
From: |
Stephen Leake |
Subject: |
Re: [Monotone-devel] Time for a release |
Date: |
Mon, 01 Sep 2008 02:27:51 -0400 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.2 (windows-nt) |
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