monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] mingw-instructions


From: Stephen Leake
Subject: Re: [Monotone-devel] mingw-instructions
Date: Sat, 08 Jan 2011 19:19:22 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (windows-nt)

Thomas Keller <address@hidden> writes:

> Am 08.01.11 12:54, schrieb Stephen Leake:
>> http://wiki.monotone.ca/RoadMap/  has an entry:
>> 
>> Split INSTALL by platform and update it | n/a | 
>> `net.venge.monotone{,.mingw-instructions}` | started |
>> 
>> However, the mingw-instructions branch is more about upgrading to a
>> newer version of the MinGW tools; splitting INSTALL is already done, on
>> the main branch.
>
> Right, only a few minor things are missing:
>
> 1) we should append a proper extension to that file and name it proper,
> for example *.txt

Done.

> 2) we might think about converting it to DOS line endings, just to
> make it look "proper" in the still-default text editor notepad

Good point; done just now.

> Finally I'm still unsure if we want to keep all these install files in
> the main directory or under doc/ or install/ or whatever.

Every package I've seen keeps all the INSTALL variants together, in the
top source directory; developers will expect to find them there. Someone
else here (Richard?) said the same thing.

>> I suggest we change this line to 'upgrade to newer MinGW tools'.
>
> Feel free to do that.

Done.

>> Note that main/INSTALL_windows_native says:
>> 
>>     The versions given here were used to build the current release of
>>     monontone.
>> 
>> mingw-instructions changes that to:
>> 
>>     The versions given here may not be exactly the same versions as used
>>     to build the current release of monontone.
>> 
>> Do we want to establish a policy of 'official mingw versions for mtn
>> releases"?
>> 
>> If so, I suggest we move 'upgrade to new MinGW' to after 1.0, since
>> there is lots of other work to do (ie, I'd rather not spend time trying
>> the new MinGW stuff).
>> 
>> Having an official MinGW version list is useful in the case of
>> MinGW-version dependent bugs. This has happened in the past, with
>> internationalization.
>> 
>> If we don't care about official versions of MinGW tools (which would be
>> difficult to enforce), then it doesn't really matter whether this is in
>> 1.0 or not.
>
> I'm not into mingw and cannot say much about that, but in general we
> have the same problems on other platforms as well, i.e. a new version of
> a distro comes out and our "Debian" or "Fedora" instructions are
> outdated because some package name or dependency changed. 

Yes. But at least most distros have some package dependency mechanism
for dealing with changes; MinGW doesn't.

> And I don't think we actually want to support _every_ version of
> _every_ distro where monotone can eventually be built on. 

Correct. But it would be nice to document how the executables on our
download page are built. In fact, that's a requirement of the GPL 3
license (which we should upgrade to).

> What we can see here is also that installation instructions are never
> really complete nor 100% perfectly working, 

Well, I was striving to meet that requirement for the MinGW
instructions. I agree the others are not.

> so a general disclaimer like the one you stated above might be the way
> to go (or even something more general like "we tested this with
> release so-and-so last time, everything might have changed in the
> meantime").

Ok, I've left that milestone in 1.0 in RoadMap.

-- 
-- Stephe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]