Re: [Monotone-devel] Re: netsync connection info cleanup

[Thomas Keller]

Am 10.06.2010 13:52, schrieb Stephen Leake:
> Thomas Keller <address@hidden> writes:
> 
>> Am 10.06.2010 09:49, schrieb Stephen Leake:
>>> This is a reasonable approach, but personally I would prefer an error (I
>>> always prefer errors over warnings; it's just too easy to miss
>>> warnings).
>>
>> See my earlier mail - how do we handle old workspaces with then invalid
>> branch names? I don't like the idea of bailing out with an error for
>> every workspace command just because the used branch option is
>> wrong...
> 
> Yes; the warning or error should only occur on the creation of a new
> branch.

The "creation" is probably too late. If the error has a validation
nature, it has to happen very early, i.e. before anything important took
place. See, I just don't want to issue a lot of spaghetti code for this
thing and maybe we're doing a nice bikeshed discussion here anyways
because 99% of the monotone users would not be affected by either, the
warning or the error.

>>> This is another case where it would be best to allow the user to set the
>>> default they want, but be able to override that default easily.
>>>
>>> That requires overridable options; supporting '--foo ... --no-foo'.
>>>
>>> Overridable options has come up a few times before; maybe we should make
>>> that a required feature for 1.0? I have not looked into how hard that
>>> would be.
>>
>> See also my earlier mail - where do we want to draw the line? 
> 
> I'm suggesting we draw the line to include overridable options. But we'd
> have to be ok with saying "this is too hard" after seriously looking at
> it.

Seriously, is this really so important? I don't want to hold you off,
no, I even encourage you to work in this area, but the overridable
options discussion just popped up recently (mainly because of advanced
automate use) and there are many, many other feature requests open for a
longer time. Many of them should be considered more important than
options handling and even than the whole URI discussion, so where do we
draw the line if they speak up as well?

>> What is reasonable to expect as development outcome for the next, say,
>> 4 weeks in June and July, where its hot everywhere...? 
> 
> I don't think we should make it a time issue, as long as people are
> making reasonable progress on each feature we agree to hold the release for.
> 
>> Do we really want to block everything else until then?
> 
> That's what branches are for. We could continue the current release
> pattern (not switch to 0.99) until all 1.0 features are ready.

...and we'd effectively have the old status quo - don't go for 1.0 at
all, because you never have all 1.0 features ready :)

> However, I think overrideable options is the only such feature mentioned
> so far? Have I missed something?
> 
> And I'm not saying we must hold 1.0 for this. I think it would be good,
> but I'm willing to go along if the consensus is to not wait for it.
> 
> Since the gnuopts package provides overridable options, lots of
> applications have them. So it will be perceived as a flaw that mtn
> doesn't.

As I said, if you would go for it and its doable in a reasonable time
frame, go for it. Otherwise I'd rather leave that for 1.1 or later (when
its finished).

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

signature.asc
Description: OpenPGP digital signature