[Monotone-devel] usabilty of translations
Hi, What do you think about internalization of software like monotone ? I know that there are few localizations (currently INST_LINGUAS = sv it de es pt). I am wondering if there is for more translation - at least I can easily add polish translation. But i am worried about two things: 1) Would anyone use it ? I know that amongst developers (at least professional ones), there is strong movement to use english-only UI/termsinstead native ones - ad-hoc created terms create only confusion and thus are problematic (at least polish IT/CS terminology/vocabulary is week) . YYMV but in my experience- use only english terms. So then ... I this experience is similar to yours? 2) Do you encountered any non-developer users of monotone or VSC / SCM who would need / understand and use these ideas ? Do you (authors of these translations) use them ? And last final question: Are there any polish people on list who would like to see polish messages in monotone UI? -- Zbigniew Zagórski / software developer / geek / http://zbigg.blogspot.com / ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Release time
Thomas Keller wrote: Am 28.05.2010 15:07, schrieb Philipp Gröschler: On 28.05.2010 10:23, CooSoft Support wrote: I couldn't agree more with Thomas's point about Monotone dying if we are not careful. It's a psychological thing. `Oh it's only at 0.xxx - still unstable'. Sure it's psychological and nowadays in the age of OSS, versioning schemes or rather the progress of their numbers are often not really expressive. Wine took 10 years to release 1.0 and noone really cared in the end, because it has been working for ages before. On the other hand I've seen software for example in a 5.x version and was hugely wondering what that thing did the four major versions before. Absolutely right, I don't want to increase the major version every few months from now on either, but I also don't think we should follow Wine's example here. Six years are enough :) People shouldn't look at the numbers of the version but rather on the feature list on the project's website. Maybe somewhere on that website there should be included a sentence like We use it all the time and no problems so far. Like Jack, I personally use Monotone for all my work stuff, source codes, server configs, etc. My lady is using Monotone for her thesis. No problems ever, so count that as +2 from here :-) Tony mentioned some praise as well, and hey, we even have a dedicated wiki page to add this: http://monotone.ca/wiki/Testimonials/ So don't be shy and add your comments there - I'll happily link this wiki page on the front page! Lol - I have some time ago. I was the one responsible for the gushing `look no further' comment at the bottom. Sorry, I was just feeling emotional at the time - lol :-). Our SDA was I think responsible for the 11 year old CVS code base one (although he is keeping quiet about it!). Hehe. One problem of a 1.0 or 1.0.0 release could be, that the more sophisticated users from bigger development groups, which then start to use monotone because of the major release, often stick to a version they chose in the beginning of a project. Of course they still want to have bugfix releases, but by no means they want breakage in the API or interface or whatever applies. I've seen this happen on another project I accompanied a while ago. As soon as they put out 1.0 there only came bugfix releases afterwards, although many requests for mostly the same improvements appeared on the mailing list and the excuse always was like No we don't do that, because then we would break with the big guys. Does Monotone have the power to support two branches, so that new and needed features don't get stalled? For that to happen we'd need to have more of these big guys in first instance - and I'd love to support them all. From a management point of view I don't care if I handle one single branch or two, a stable and a feature branch, or whatever works for them. Thomas. ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Release time
Philipp Gröschler wrote: On 28.05.2010 10:23, CooSoft Support wrote: I couldn't agree more with Thomas's point about Monotone dying if we are not careful. It's a psychological thing. `Oh it's only at 0.xxx - still unstable'. Sure it's psychological and nowadays in the age of OSS, versioning schemes or rather the progress of their numbers are often not really expressive. Wine took 10 years to release 1.0 and noone really cared in the end, because it has been working for ages before. On the other hand I've seen software for example in a 5.x version and was hugely wondering what that thing did the four major versions before. IMHO I agree that's how techies work, oooh looks cool I'll give that a spin. But, and pardon me for saying this, SCM systems are the sort of tools that techies don't get too excited about generally, and just want something that works and is reliable, and so may only look more superficially because they want to get back to doing `cool stuff'. Also the dreaded management peeps stick their oar in and start going on about trusting our crown jewels to `something that isn't formally released yet'. I had to fight for about 6 months on and off to keep the management off our backs otherwise we would have been forced to use ClearCase. It would have been easier to convince them of mtn's stability if it was at 1.x rather than 0.x. I know, silly, but we are talking about management after all. Your point about version 5.x and wondering reminds me of TopCased. It's at version 2 and as stable as a Jenga tower! Makes me wonder what 1.x was like :-(. Point taken about 1.0 forcing you to not break things. Changing schemas is no biggie, easy for a user to cope with, db migrate or sync. CLI is unlikely to change that much (at least I hope not) as that is one of its many selling points. CVS/SVN users can virtually use it straight away (unlike GIT), even ClearCase users (mind you they are usually so thankful not to be using ClearCase). au stdio, hopefully will mainly be additive from now on (I hope! - lol). As for feature freeze. We have had to do that for our software. We currently have ~10 release branches and develop on the latest version whilst supplying patch fixes to 8 year old releases. That's why we love Monotone, it makes it so easy :-). Comes with the territory of doing something people want I'm afraid. People shouldn't look at the numbers of the version but rather on the feature list on the project's website. Maybe somewhere on that website there should be included a sentence like We use it all the time and no problems so far. Like Jack, I personally use Monotone for all my work stuff, source codes, server configs, etc. My lady is using Monotone for her thesis. No problems ever, so count that as +2 from here :-) Agreed but some peeps do :-( One problem of a 1.0 or 1.0.0 release could be, that the more sophisticated users from bigger development groups, which then start to use monotone because of the major release, often stick to a version they chose in the beginning of a project. Of course they still want to have bugfix releases, but by no means they want breakage in the API or interface or whatever applies. I've seen this happen on another project I accompanied a while ago. As soon as they put out 1.0 there only came bugfix releases afterwards, although many requests for mostly the same improvements appeared on the mailing list and the excuse always was like No we don't do that, because then we would break with the big guys. Does Monotone have the power to support two branches, so that new and needed features don't get stalled? Just a few thoughts :-) Philipp ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Re: monotone.ca nvm: pull fails on invariant
Hello again, W dniu 29 maja 2010 02:54 użytkownik Zbigniew Zagórski z.zagor...@gmail.com napisał: I can't pull nvm branch from any server (both monotone.ca and monotone.mtn-host.prjek.net) [1] $ mtn pull monotone.ca 'net.venge.monotone' (...) mtn: 251.3 k | 107.7 k | 78/152 | 27/48 mtn: fatal: error: graph.cc:99: I(!next.empty()) Just for record, this was my local issue. Later i've executed mtn db check and it yielded something like this $ mtn -d monotone-bad.mtn db check mtn: mtn: mtn: revision 0e67b65edabb68ee96fe6d4eff5a32c3da79b013 incomplete (1 missing manifests) mtn: revision 0e67b65edabb68ee96fe6d4eff5a32c3da79b013 incomplete (missing roster) mtn: revision 0e67b65edabb68ee96fe6d4eff5a32c3da79b013 missing author cert mtn: revision 0e67b65edabb68ee96fe6d4eff5a32c3da79b013 missing changelog cert mtn: revision 0e67b65edabb68ee96fe6d4eff5a32c3da79b013 missing date cert mtn: height missing for revision 0e67b65edabb68ee96fe6d4eff5a32c3da79b013 mtn: warning: 2 unreferenced files mtn: warning: 2 incomplete revisions mtn: warning: 1 missing rosters mtn: warning: 445 missing certs mtn: warning: 40 mismatched certs mtn: warning: 1 missing heights mtn: check complete: 51774 files; 16115 rosters; 16116 revisions; 60 keys; 64807 certs; 16117 heights mtn: total problems detected: 491 (449 serious) mtn: error: serious problems detected $ (module missing and duplicated certs). For record: db kill_rev_locally on this revision helped issue and following pull retrieved it correctly. - Zbyszek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Release time
One slight deviating point about breaking BC with au stdio... I feel what ever applications we provide that use it should strive to cope with BC breakages. E.g. Monotone:AutomateStdio works from 0.35 to the current release as does mtn-browse which relies on it. Hopefully though with the changes made recently to stdio, future changes will be additive :-) (fingers crossed). Why did I go to this effort? Apart from the obvious it was also because at work they are on version 0.39 of mtn as any higher breaks the `direct access to db version of monotone-vis', the later au stdio version of monotone-viz for some unknown reason runs MUCH slower on our db, too slow to be of any use :-(. Other companies/people may have similar issues. And monotone-viz is one of mtn's killer apps... I like the idea of attaching a specific significance to a change in major/minor/patch level number. Makes it much clearer for the user. Tony. Ethan Blanton wrote: Derek Scherger spake unto us the following wisdom: 1) if a release only consists of bug fixes or has small, not BC-breaking improvements (esp. in respect to automate), raise the patch release 2) if a release has bigger improvements or breaks BC, raise the minor version 3) if a major flag day introduces major new things or we've rewritten 90% of monotone (:)), raise the major number. I think that pretty much agrees with http://apr.apache.org/versioning.htmlwhich is referenced by various other projects. I'd modify this somewhat, for monotone, because *network* compatability is quite possibly its most visible feature. Perhaps something like: Major version bump - netsync incompatability (or major features you don't want people to miss) Minor version bump - database upgrade required (or ...) patchlevel - bug fixes, minor changes, user can upgrade without concern toward databases or interoperability This is along the lines of typical library versioning, with minor versions indicating link-compatible changes, and major versions requiring relinking. (The binary compatability prose in the Apache page above.) That said, versioning is *way* bikeshed. Everyone has their own opinion on how it should be handled. I think the important thing here is to pick *something* meaningful and stick to that meaning. Ethan ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #29982] Windows installer does not install documentation CSS and images
Follow-up Comment #2, bug #29982 (project monotone): I just came up with the idea because some people told me that the monolithic version is kind of hard to browse (and even very slow to browse f.e. on Firefox). If its easy to generate (or even automate the generation of) chm help files, then go for it! Thanks for your work so far! ___ Reply to this item at: http://savannah.nongnu.org/bugs/?29982 ___ Nachricht geschickt von/durch Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] guitone 1.0rc4 released
Hi all! This fourth release candidate is dedicated to Lena, the Eurovision Song Contest Winner of 2010 [0] :) . It comes with a few new nifty features like an improved changeset browser and enhanced certificate support, as well as a couple of other smaller improvements and bugfixes. The Tarball and a Mac OS X disk image can already be downloaded at the usual location [1], the Windows installer will follow shortly. As always, please report bugs [2] if possible. And while guitone now comes with one new translation, Portuguese, thanks to Américo Monteiro, I’m still looking for more translators – if you’re interested, drop me a note! Thomas. [0] http://www.eurovision.tv/ [1] http://guitone.thomaskeller.biz/g/download [2] http://guitone.thomaskeller.biz/g/tracker -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | 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 ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #17499] can't commit files in newly created dir
Update of bug #17499 (project monotone): Open/Closed: In Test = Closed ___ Reply to this item at: http://savannah.nongnu.org/bugs/?17499 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #20447] mtn diff filename fails inside of a renamed directory
Update of bug #20447 (project monotone): Open/Closed: In Test = Closed mtn version --full: C:\dev\fortamtn --full-version monotone 0.35 (base revision: f92dd754bf5c1e6eddc9c462b8d68691cfeb7f8b) Running on : Windows NT/2000/XP/2003 (5.1, build 2600, Service Pack 2) on ia32 (level 6, rev 3846) C++ compiler: GNU C++ version 3.4.2 (mingw-special) C++ standard library: GNU libstdc++ version 20040907 Boost version : 1_33_1 Changes since base revision: format_version 1 new_manifest [33fa9f84dee6ec2e1bde81b607a067befbe2fc3e] old_revision [f92dd754bf5c1e6eddc9c462b8d68691cfeb7f8b] patch Makefile.am from [ecc00e0b8e9b5350157a1922e430ade4508d31bd] to [a52adc6a23a4bedf2d636a6c3e91cd46ce900a35] = C:devfortamtn --full-version monotone 0.35 (base revision: f92dd754bf5c1e6eddc9c462b8d68691cfeb7f8b) Running on : Windows NT/2000/XP/2003 (5.1, build 2600, Service Pack 2) on ia32 (level 6, rev 3846) C++ compiler: GNU C++ version 3.4.2 (mingw-special) C++ standard library: GNU libstdc++ version 20040907 Boost version : 1_33_1 Changes since base revision: format_version 1 new_manifest [33fa9f84dee6ec2e1bde81b607a067befbe2fc3e] old_revision [f92dd754bf5c1e6eddc9c462b8d68691cfeb7f8b] patch Makefile.am from [ecc00e0b8e9b5350157a1922e430ade4508d31bd] to [a52adc6a23a4bedf2d636a6c3e91cd46ce900a35] ___ Reply to this item at: http://savannah.nongnu.org/bugs/?20447 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #22044] diff fails for files that have been moved and patched
Update of bug #22044 (project monotone): Open/Closed: In Test = Closed ___ Reply to this item at: http://savannah.nongnu.org/bugs/?22044 ___ Message sent via/by Savannah http://savannah.nongnu.org/ ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Release time
On Thu, May 27, 2010 at 9:54 AM, Derek Scherger de...@echologic.com wrote: As I've announced earlier I'd like to start the machinery for the next monotone release now that the database management branch has landed. So if you have anything you'd also really like to see in the next monotone version, please finish it up and merge it into mainline (I remember we still have a couple of open bugfest branches, right Derek and Richard?), I've got a bit left to do on the diff branch but I should be able to have that complete and landed in the next few days. This has been merged. Cheers, Derek ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
