Re: [Monotone-devel] Time for a release
Am 05.06.2010 23:24, schrieb Thomas Keller: Am 05.06.10 18:26, schrieb Zack Weinberg: On Sat, Jun 5, 2010 at 4:59 AM, Thomas Keller m...@thomaskeller.biz wrote: I assume you meant /dev/nul instead of /dev/null there? No, I meant /dev/nul - try GNU patch and tamper the patch file to +++ /dev/nul (which is of course wrong) - then you'll see that empty files are kept and are only removed explicitely with -E. This is what I mean - we'd tamper the test if we add -E, because then we just test GNU patch to correctly interpret the -E option, but not to automatically remove the file if it is empty _and_ has the target /dev/null. Oh, I see what you mean. Well, is the exact behavior of the system 'patch' utility the focus of the test? I'm kinda inclined to doubt it, but I have lost the message that says which test we're talking about here... The test is diff_patch_drop and IMHO it exactly tests the proper removal of the files at the end. If not we could / should probably just remove the last two checks. I have changed the test that it now executes patch with -E on BSD's and that it only checks for a removed directory on non-BSD's (apparently GNU patch is much more aggressive). FreeBSD and openBSD now pass this test - the openBSD bot is still broken with three other tests though. Thomas. -- 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
Re: [Monotone-devel] Re: netsync connection info cleanup
Thomas Keller m...@thomaskeller.biz writes: Am 10.06.2010 13:52, schrieb Stephen Leake: Thomas Keller m...@thomaskeller.biz 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. I have not looked at this in detail, but I'm assuming we can check very early whether the operation will create a new branch, and do the check. For example, in 'mtn commit --branch foo', we can check right at the beginning whether foo already exists as a branch, and if not, error out, before doing anything else. See, I just don't want to issue a lot of spaghetti code for this thing Right. 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. Right. 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'm asking if you (and others) think it is important. I'll take this as no, we should not require this feature for 1.0. there are many, many other feature requests open for a longer time. Perhaps it would be good to post a list here, and have a semi-formal vote on whether they should be required for 1.0 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? We draw the line by reaching consensus after informed discussion. ...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 :) We can make a formal statement now about what is actually required for 1.0. I'm happy saying no new features are required for 1.0; go for it. But we should at least think about it a little more. -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] Date formatting
Hi! The openBSD build bot fails a couple of tests - some of them are related to the fact that the openBSD strptime does not implement the GNU extension %F [0]. I can't remember why %F was chosen at all, and not %x, but if we want to stick with %F, we should probably expand that to %Y-%m-%d to make it compatible, right? Thomas. [0] http://www.openbsd.org/cgi-bin/man.cgi?query=strptime -- 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] Quick poll
Hi everyone! I'm listening to you and the release concerns, which (again) popped up recently. And since I don't want to behave like a self-opinionated bastard which just pushes things to the very end while people are uncomfortable with the situation, here is the new plan: 1) I will release 0.48 this weekend (probably Sunday) when the remaining openBSD issues have been sorted out. The translation team therefor has a one or two more days to improve the i18n side, but its not that crucial anymore to bring them up to 100% excellence since we won't hit 0.99 next. 2) After 0.48 is out, the next dev version will be 0.99dev. 3) Tim and Stephe proposed to set up a list of things we really want to get done and which are also doable in a reasonable time frame before 0.99 / 1.0 hits the streets. I'd like to target this fall for 0.99 and we should really try to get things done until then. 4) I'll tweak the old RoadMap [0] wiki page and bring it up-to-date. People are invited to add more things which they want to see in 1.0 and we're collaboratively voting on them and moving them into the appropriate position afterwards. To avoid new features added constantly afterwards, feature proposals for 1.0 are only open until Sunday. Is everybody ok with that? Thomas. PS: Wish me luck tomorrow - I'll be on the LinuxTag in Berlin and try to persuade a hosting company (Thomas Krenn AG) to sponsor [1] us some hardware :) [0] http://monotone.ca/wiki/RoadMap/ [1] http://www.thomas-krenn.com/de/unternehmen/news/action.view/entity.detail/detail_key.280.html (in German) -- 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
Re: [Monotone-devel] Quick poll
Thomas Keller m...@thomaskeller.biz writes: Hi everyone! I'm listening to you and the release concerns, which (again) popped up recently. And since I don't want to behave like a self-opinionated bastard which just pushes things to the very end while people are uncomfortable with the situation, here is the new plan: 1) I will release 0.48 this weekend (probably Sunday) when the remaining openBSD issues have been sorted out. The translation team therefor has a one or two more days to improve the i18n side, but its not that crucial anymore to bring them up to 100% excellence since we won't hit 0.99 next. 2) After 0.48 is out, the next dev version will be 0.99dev. 3) Tim and Stephe proposed to set up a list of things we really want to get done and which are also doable in a reasonable time frame before 0.99 / 1.0 hits the streets. I'd like to target this fall for 0.99 and we should really try to get things done until then. 4) I'll tweak the old RoadMap [0] wiki page and bring it up-to-date. People are invited to add more things which they want to see in 1.0 and we're collaboratively voting on them and moving them into the appropriate position afterwards. To avoid new features added constantly afterwards, feature proposals for 1.0 are only open until Sunday. Is everybody ok with that? Excellent plan. We might as well start the 2.0 list now; anything that doesn't make 1.0 is a candidate for 2.0. I just added 'update conflict handling' and 'overwritable, negatable options'. PS: Wish me luck tomorrow - I'll be on the LinuxTag in Berlin and try to persuade a hosting company (Thomas Krenn AG) to sponsor [1] us some hardware :) Go for it! -- -- Stephe ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
Re: [Monotone-devel] Quick poll
Am 11.06.2010 12:56, schrieb Stephen Leake: Thomas Keller m...@thomaskeller.biz writes: [...] Is everybody ok with that? Excellent plan. Cool! We might as well start the 2.0 list now; anything that doesn't make 1.0 is a candidate for 2.0. I just added 'update conflict handling' and 'overwritable, negatable options'. I was just in the process and reworked the complete page to a more dense layout. Could I ask you and link the explanations for either idea to a wiki page or a mailing list post? And please only set branch names which actually already exists, otherwise people might get confused. For now I've added the options task for 1.0 and the update conflict handling in untargeted - we might as well include the latter in 1.1, 1.2 or so if its ready and since the work hasn't even be started yet, I refuse to put it for a particular milestone. The things for 1.0 / 2.0 which haven't been started are just already there because they're blockers, i.e. we absolutely want them to pop up in this particular release... if there are more such items, we might move them up from Not targeted or add them as new, but I advise everyone here to be very, very conservative, especially if you don't plan to do the particular work yourself :) PS: Wish me luck tomorrow - I'll be on the LinuxTag in Berlin and try to persuade a hosting company (Thomas Krenn AG) to sponsor [1] us some hardware :) Go for it! Thanks, Thomas. -- 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
Re: [Monotone-devel] Quick poll
In message 4c1209d2.6070...@thomaskeller.biz on Fri, 11 Jun 2010 12:02:58 +0200, Thomas Keller m...@thomaskeller.biz said: me 1) I will release 0.48 this weekend (probably Sunday) when the remaining me openBSD issues have been sorted out. The translation team therefor has a me one or two more days to improve the i18n side, but its not that crucial me anymore to bring them up to 100% excellence since we won't hit 0.99 next. Following many years of experience from the FSF folks, I'd suggest 0.90. Cheers, Richard -- Richard Levitte rich...@levitte.org http://richard.levitte.org/ Life is a tremendous celebration - and I'm invited! -- from a friend's blog, translated from Swedish ___ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
[Monotone-devel] [bug #30110] mtn status fails by default with multiple keys
Update of bug #30110 (project monotone): Status:None = Fixed Open/Closed:Open = Closed ___ Follow-up Comment #1: Fixed in e831aa7c1baa0c545c5d1917364ff299cd79e174 ___ Reply to this item at: http://savannah.nongnu.org/bugs/?30110 ___ 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
