Re: [Wesnoth-dev] build system evaluation (autotools/cmake/scons)
Mark de Wever : > I like to propose to drop autotools support and make scons and cmake the > default build systems for 1.7. I'm certainly in favor of dropping autotools. I started the push to get rid of it, and it's no less of a nasty hairball than it was then. I haven't noticed anyone liking cmake except Ivanovic and you. If you want to put in the effort to maintain it, I certainly can't stop you - but I do think the project has better uses for your time. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
[Wesnoth-dev] Scripting in the longer term (was: Re: possible security problems)
allefant : > Yes, any possible future AI or scripting additions should be discussed > on the forum of course. Just was trying to clarify why I think the > PythonAI failed - just generally blaming "Python" would be a bit > simple-minded and not help prevent similar problems in the future. > Ivanovic mentioned work on Lua scripting in the initial post of the > thread - so my impression was this already is or will soon be > available in SVN, I wouldn't really have suggested it otherwise :) As much as I like Python, I'm almost completely convinced now that lua is a better path in the long term - and when I say "almost completely", I mean "unless there's a large un-obvious fuck-up in the lua design or implementation". There are three application domains in play here: (1) AI plugins in a scrioting language (2) WML extension in a scripting language (3) Replacing Wesnoth core code in a scripting language lua looks like a winner in two of these areas: (1) because it can actually sandbox cleanly, (2) because we've already got a candidate patch that looks promising. It also looks pretty plausible to me for (3) because lua's native extension facilities luabind appear to be easier and more powerful than Python's - and that's a strong statement, because I know Python's embedding features and they're pretty good. By contrast, Python has a known sandboxing problem blocking (1) pretty hard, there's not even a blue-sky plan for (2). Take this seriously, because it's the project's biggest fan of Python talking. I'll continue to use Python for out-of-core tools and like it, but...I'm gonna learn lua. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] AI is not in a releasable state
Fabian Mueller : > It feels just broken. Between these problems and the well-known northwest-bias bug, I think the AI problems are serious enough to block a stable release. Who knows the AI code well enough to try to fix it? -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] AI is not in a releasable state
d...@whitevine.net : > I'm not sure what the other problems are and/or how serious they are, See the following tracker bugs: #13120 AI is not scouting #13119 The ai should only recruit level one units for scouting #13105 AI is blocked by a certain game configuration. #8410 AI makes big mistakes in custom maps! > However, I'm not sure when I will have time to dive into it. Most AI > problems tend to be quite complicated to diagnose, and I have a bunch of > "real life" things going on right now. Ouch. The problems that have piled up look to me like they are too serious to allow a stable release. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] AI is not in a releasable state
John McNabb : > I will need to check out the latest version and dig into it a bit before I > commit to actually making changes. It certainly would not be done for this > release. What would your estimated time to a production-ready AI be? -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] AI is not in a releasable state
Nils Kneuper : > Short guess: several *month*, not days or "one or two weeks". You do know that > this stuff is complicated as hell... Of course I know that. We may face an unpleasant choice between holding for those months or shipping a broken game. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] AI is not in a releasable state
Ignacio Morelle : > On Thu, Mar 5, 2009 at 9:26 PM, Eric S. Raymond wrote: > > Nils Kneuper : > >> Short guess: several *month*, not days or "one or two weeks". You do know > >> that > >> this stuff is complicated as hell... > > > > Of course I know that. We may face an unpleasant choice between holding for > > those months or shipping a broken game. > > Are the same bugs present in 1.4? According to fendrin, no. He reports tripping over these while trying to tune LoW. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] AI is not in a releasable state
David White : > I'll see what I can do to fix as much of the AI as possible. Can anyone > easily verify which of the bugs that ESR referenced earlier are > regressions? All of them except the north-west bias, I believe. That *was* present in 1.4. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] AI is not in a releasable state
David White : > On Thu, 2009-03-05 at 18:14 -0500, Eric S. Raymond wrote: > > d...@whitevine.net : > > > I'm not sure what the other problems are and/or how serious they are, > > > > See the following tracker bugs: > > > > #13120 AI is not scouting > > This bug doesn't have any real instructions on how to reproduce. I have > updated it asking for them. And fendrin has left a recipe. I hope that will be sufficient for you to fix it. > > #13119 The ai should only recruit level one units for scouting > > I think this is subjective and not really an engine bug. If you don't > want the AI using level 2 scouts, don't make level 2 scouting units > recruitable by the AI. I see this has been changed to an FR, which seems reasonable. > > #13105 AI is blocked by a certain game configuration. > > I have just fixed this bug, adding notes. Hopefully my fix won't cause > regressions elsewhere. Good. > > #8410 AI makes big mistakes in custom maps! > > This is a very old report which contains numerous issues, most of which > are subjective or not reasonably solvable. All issues are also very old, > dating to 2007. I have closed this bug. You noted that the north-west bias complaint was valid, though monor, so I have reopened #12978 (AI has north-west bias) which has a link to a detailed analysis from the forums and suggested fix. > Are there any other AI bug reports for me to look at? Bug #12839: THoT-5: AI does not attack after moving. I think silene is probably right about this and therefore marked it Wont Fix, but perhaps you know something he didn't. So the remaining pending issue is #13120. I agree that the NW-bias bug is not by itself a releaze blocker. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] AI is not in a releasable state
Nils Kneuper : > Okay, lets have a look at this list and add my personal view on the importance > of those for 1.6. I will explicitly try to compare to 1.4, that is if there is > no regression compared to this, we *can* release... > > >> #13120AI is not scouting > > > > This bug doesn't have any real instructions on how to reproduce. I have > > updated it asking for them. > > > > Hmm, somehow a part of "make the AI better and easier to > configure". Personally I don't think that this was possible in 1.4 > either. So this is not a real regression. I think you are incorrect here; I don't recall that 1.4 had this behavior. Fabi has left a recipe to reproduce it, so this may enable Dave to fix it. > To sum the stuff up: > The only real blocker and regression was fixed. The rest is a case > of "we should improve our AI (in general) and make it easier > scriptable". I think #13120 is still an issue. > In general I think those "AI finetuning parameters" we have in WML > for ages were never working perfectly and thus it is hard to judge > if anything improved or broke there. Then why did we lead campaign designers to believe they had an effect? They need to be better documented. > PS: But I think that bug #13118 [1] should be fixed before rc2 is out! Agreed. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] AI is not in a releasable state
Greg Boggs : > I'm not sure how to report official bugs, https://gna.org/bugs/?func=additem&group=wesnoth -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] AI is not in a releasable state
Nils Kneuper : > Fabian Mueller schrieb: > > Nils Kneuper wrote: > >> In general I think those "AI finetuning parameters" we have in WML for > >> ages were never working perfectly and thus it is hard to judge if > >> anything improved or broke there. > > > > This is a form of user punishment and makes me angry. > > If that parameters don't work (I agree, they don't work) then remove them. > > I have wasted my time trying to do something with them. > > The wiki doesn't say anything about that the parameters don't work. > > I am really angry about this. > > I agree that it is really annoying that there are parameters and > they seem to not have a real influence. That is the params may have > some influence, but it is not enough that it really matters in > gameplay. Though this is *NOTHING* that can be fixed with any short > term solution! If we really believe the AI tuning parameters don't work, "short term solution" would be to *put a warning on the wiki*, in the description of the AI parameters, that they don't work! Fabian is quite right to be angry about this. It's one thing to have an AI that's dimmer than it could be; it's entirely another to pretend to campaign designers that it's tunable in ways that it is not. Just to complicate matters, I don't in fact think the tuning parameters are useless; when I was writing THoT, in particular, I recall side aggression levels having significant effects. From my own experience, I suspect that Fabi had trouble finding values that made a difference because the interactions and ranges of these parameters aren't well documented. I'm looking at the wiki page for the [ai] tag, now, remembering designing THoT scenarios, and there are obvious questions it doesn't answer. Here are some of them. Dave or Dragonking, would you please investigate and add answers to the wiki? caution: Is there a maximum above which this stops making a perceptible difference? How does it scale? village_value: How does it scale? How is this weighted against making unit kills on opponents? leader_value: How does this scale? Does a value of 6.0 male the AI twice as likely to target leaders as a value of 3.0? scout_village_targetting: "multiplies" relative to what? -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] [bug #13166] AI is shuffling instead of finishing off a lonely enemy leader
Jörg Hinrichs :
> This behaviour is caused by the scenario AI settings, namely the "caution=20"
> for the defender AI. To give you an impression: If the group attacks or not is
> controlled by the strength of the group in relation to the caution. If the
> strength exceeds the caution+0.5, the group will attack.
> For the savegame on turn 37, the groups strength is rated with 6.36 (that is
> done by an ingame AI algorithm). If you manually correct the AI caution from
> 20 to 5 in the savegame, you will find that the group starts attacking.
Jörg, omething like this explanation belings on the AI parameters page
of the wiki. It would be good to include at least some indication of
how group strength is calculated -- doesn't have to be exact, just indicative.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] [bug #13166] AI is shuffling instead of finishingoff a lonely enemy leader
Jörg Hinrichs : > Eric, i agree 100%. The problem is, that i was tricked into looking at this > bug ;-) and i am not very familiar with the AI. Basically I did a lot of > single stepping and through that found out what happened. But unfortunately > I am far from having a basic understanding what the AI really is doing. > However, I can try and add to the wiki what I know. /me makes encouraging gestures in Jörg's directtion. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Deadline for wesnoth 1.6
Nils Kneuper :
> I just wanted to inform you about the deadline for commits that are
> meant to go into 1.6. That is everything in until tomorrow in the
> afternoon in Europe will be in, everything later will not. The firm
> "pencils down date" is as follows:
>
> March 18th, 5PM GMT+1
> (as in "five in the afternoon in Europe (Paris/Berlin/...)")
I think we should hold off for a week. fendrin seems to be making good
progress on the AI test suite; it would be much, much better if we could
ship knowing the AI is in decent shape, or at least that we have
enumerated the bugs.
Otherwise I agree we're in good shape for release.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Deadline for wesnoth 1.6
Nils Kneuper :
> Personally I think we are basically in a good shape for a release right now
> already. If the AI testsuite finds some bigger problems, they will have to be
> fixed in later 1.6.x releases anyway.
Wouldn't that be contrary to policy for the 1.6 line, though? The AI is
the *last* thing we really want to mess with in a stable release.
> A more problematic thing is that the orgs that participate in summer of code
> will be announced on Wednesday evening. If we are accepted there (which I
> think
> we will be), we will have some students submitting patches. Those will most
> likely be some small new features which could not be committed right away
> because of the 1.6 preparations.
An issue, yes -- but let's try holding for a week or until the first patches
arrive, then, whichever is sooner. You should check with fendrin, but
I think we're in a place where a day or two could make a significant difference
in our confidence level about the AI.
Otherwise the bug list looks remarkably clean. The only non-AI bug graded
Important or above is one I'll fix in a few minutes.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Deadline for wesnoth 1.6
Mark de Wever : > Choosing between fixing it now and do the final release in a week or fix > it in 1.6 and trunk and have it a while tested in both I prefer the > latter. (I see it as picking the lesser evil.) That's certainly not how we handled potentially destabilizing changes around the 1.4 release... > I also think this is a symptom of a bigger problem, the development > versions are not tested enough, which causes problems to pop up very late > in the development cycle (same for 1.4). Agreed. > So maybe we should look at how > to give the next development releases a better testing earlier in the > cycle. Preferably I'd like to see more user testing starting in the > middle of the cycle so we still have time to do more intrusive changes. Yes, and while we're at it I'd like a pony. That is a deliberately sarcastic idiom in English conveying that wishes don't count for much. I think the only way we're going to get more user testing is by shipping "stable" releases more often, which is to say seriously shortening our development cycle. > So I don't think Wednesday should be a hard > date if there are good reasons to delay it a few days, however I'd like > to have the announcement as planned on Sunday. Seems reasonable. I'd like to hear from fendrin on the state of the test suite before we make a final decision. > I only have one bug [1] left which should be fixed before tagging, I > expect to do that this evening. I've an ugly fix that needs some > polishing and some more testing, but I'm quite sure I'll be ready this > evening. Having fixed theboth recent NR bugs, I have no remauining issues that need to be pre-1.6 > Would it be an idea to fork 1.6 about a day after tagging so commits > which are needed in both trunk and 1.6 can be applied to both without > merging? If we're going to do that, what would the point be of tagging earlier? -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
[Wesnoth-dev] Wesnoth 1.8 release cycle
Mark de Wever : > > I think the only way we're going to get > > more user testing is by shipping "stable" releases more often, which > > is to say seriously shortening our development cycle. > > Well the goal was to start to think about how to achieve that wish. > Since I've no real ideas about what we could do to improve the situation > I just wanted to start the discussion. And quite rightly. This is a good time to have it. > I'm not sure whether the shortening the development cycle really helps > (I think not) but we could try it. The last time we also discussed the > idea of a half year cycle and rejected it. But since the current model > also doesn't 'work' in this regard we can at least try it. So if we aim > for half a year that would be the middle of September, which would also > fit with gsoc (if we get in). I have also, independently, been thinking that September 2009 would make a good target date for 1.8. That timing seems about right for both of the major 1.7 projects I know are already scheduled to have landed and gotten some testing. Those are: * The full GUI II rewrite * Embedded lua for WML. * Finishing (and probably mainlining) Delfador's Memoirs My own plans for the 1.7 cycle are up in the air. I have a proposal for a new game-threaded save organization I'd like to do, but that is blocked on someone cleaning up/refactoring the horrible mess in the engine around game-state saves. (I have truied to understand that code; it just makes my head hurt...) > I thought I've seen several commits aimed at 1.6 postponed/reverted due > to the string freeze, which is lifted once 1.6 has been tagged. That's true. One of them was mine. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Deadline for wesnoth 1.6
Jörg Hinrichs : > I admit it is more or less a gut feeling without hard evidence, but my > instincts tell me we should look into this deeper. > Many changes + high complexity + few tests = *lots* of bugs I think you and I are hearing the exaxt same internal alarm bells, Jörg. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Deadline for wesnoth 1.6
David White :
> I think that we should have a general rule that even developers with SVN
> access have to get "approval" to work on such components.
>
> If people want to write their own AI's, that's fine, but if they want to
> mess with the default AI, we should look very very closely at what they
> are doing.
Being careful about review is probably evenn more important than being
careful who we approve.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] AI is not in a releasable state
Guillaume Melquiond : > On 2009/3/18, John McNabb wrote: > > > When choosing between equally good moves(by whatever measure), the AI will > > choose randomly from amongst them. > > Please don't, unless your goal is to make reproducing AI bugs from > savegame impossible. Easily solved. Psdseudorandomly wit the generator state included in the savegame. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Wesnoth 1.8 release cycle
Mark de Wever : > So I'd like to try the following release > scheme. > > x months of development with a release in about every three weeks. > > y weeks of beta's which starts the hard feature freeze a release in about > every two weeks. At this point we should encourage users to start > testing. > > After a few weeks we when we get the feeling things start to stabalize > we should start to really encourage users to use it and try hard to keep > compatibility between the version. (This is what we call the release > candidates at the moment, but I think we shouldn't call it release > candidates since we don't intent to release them. If we want a give it a > name, different as beta, let's call it pre releases.) > > Once we think things are stable we fork the trunk into a branch. This > means all bugs we know about and want to be fixed are fixed at this > point! Then we start to release release candidates and a release > candidate should be a release candidate. In the branch there should only > be bug fixes, translation and image updates (only the images no config > changes). Once we have about three weeks of no bugs or only small fixes > we can release the final version. I don't see that this differs much from what we've *been* doing, frankly. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Wesnoth 1.8 release cycle
David White : > Personally I would love it if we could get our release cycle down to 6 > months instead of 12 (more like 14) months. > > I think that one of the problems with our current release cycle is that > people begin with thinking that 12 months is forever to develop > something, so they do nothing at all. It is somewhat demoralizing to > think of developing something and not see it in a stable version for 12 > months! > > Then time runs short, and people scramble: "If I don't get my feature in > NOW then it won't make it for 12 whole months!!" > > If we could reduce the release cycle to 6 months, these effects would be > lessened. > > I don't see why we can't be agile enough to have a 6 month release > cycle, and would love it if we could achieve this. I strongly agree with all of this. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Text markup for WML messages
Mark de Wever : > Now that we have pango support for dialogs we also have more options to do > formatting. At the moment this formatting is used by the engine internally > to convert the Wesnoth markup to pango markup. The question is do we want to > allow the WML authors to use pango markup or not. > > The pros and cons of both markup systems > Pango [1] > Pro: > - Markup can be used everywhere in a text. > - looks like html, which might be easier for authors of WML to reconized. > Con: > - Certain characters like & must be escaped like & > > Wesnoth markup [2] > Pro: > - Simple to use. > Con: > - Markup can be used on a per line basis. > > If we want to give WML authors acces to the Pango syntax do we also want to > keep the current WML syntax? (I see no way to automate the conversion > easily, especially since I expect authors want to take advantage of the new > way, so the text needs a manual review. So we'll need a, long, transition > phase supporting both syntaxes if we want to phase it out.) > > Of course if we decide to do it we'll need to discuss how to implement it in > WML and how to help the WML authors to properly escape their strings. But I > rather put off those questions until we know what we want. > > [1] http://library.gnome.org/devel/pango/unstable/PangoMarkupFormat.html > [2] http://www.wesnoth.org/wiki/InterfaceActionsWML#.5Bmessage. I think we should go with Pango and scrap the old Wesnoth markup. Immediately. The old Wesnoth markup is ugly and limited. So limited that I don't really think transitional support is at all important. Pango is powerful, well documented, and a public standard with conventians that will already be familiar to HTML/XML authors; I see no contest here. As for the conversion issue, that's what wmllint is for. I just read about Pango markup; I could write and test a wmllint rule to do the conversion in less than an hour, I think. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Text markup for WML messages
Patrick Parker : > While I certainly agree that WML markup is lacking in many ways, I am > skeptical about the smoothness of the transition you are describing. > The 5 standard escape entities in Pango Markup Language are: & > < > " ' > This means that ~RC(a>b) image path function syntax will need to > change (because it contains >) That doesn't occur in text strings, does it? Because the pango interpretation is only done in very specific contects; right now, only in message= attributes within [message]. > No great loss there. But aren't there other places where special > syntax of WML attributes uses special characters to represent lots of > complex data that is crammed into a small space, e.g. > http://www.wesnoth.org/wiki/DescriptionWML ? I don't know the details of mordante's implementation, but I'm pretty sure Pango is never going to be interpreted outside of translatable strings. That seems quite unlikely to cause syntactic clashes with RC syntax or anything else. > Also, rather than discarding backwards compatibility-- consider the > old syntax being used as a shorthand form? I would at least like that > idea to be discussed in a forum where campaign authors and UMC > maintainers can have their say before the change. We have wmllint. This makes the utility of "backward compatibility" in a development branch pretty low. And the old syntax is both ugly and limited, anyway - I think we're at the right place in the development cycle to just shoot it through the head. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Text markup for WML messages
Guillaume Melquiond :
>Or were you saying that an automatic transition is
> hard because the translator (e.g., wmllint) has to guess that
> "~RC(a>b)" shouldn't be converted to "~RC(a>b)"?
wmllint already passes this test :-).
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
[Wesnoth-dev] Delfador's Memoirs appears ready for mainlining
I am very pleased to be able to announce that the campaign Delfador's Memoirs appears ready for mainlining. The WML seems in good shape, I can certify the prose, fabi reports that the forum playtesters like the storyline, and we have reached the stage where we are polishing things rather than fixing bugs. Besides being a reasonably strong campaign in itself, DM is an enriching addition to the braid of storylines around Delfador and the Wesnothian royal house that have formed the plot core of the game ever since Heir to the Throne. It is particularly linked to HttT and (through Kalenz) to Legend of Wesmere; indeed, some of the later scenarios were origninally part of LoW. There are, as usual, issues with missing art. Also as usual the campaign could benefit from more balance testing. These things should be addressable without much difficulty before 1.8 ships; we're at a good point in the release cycle for this. ShadowMaster wants to do the actual mechanics of mainlining for technical reasons related to how he manages the umc-dev repo. Unless we trip over some last-minute blocker issue before then, I'm going to ask him to pull the trigger on Wednesday, April 8. Props to tapik and santi for design, fendrin for his usual excellent WML hacking, and zookeeper for QA and critique. As usual with the last seven or so campaign lifts, I was a sort of combination producer and script doctor; you can blame anything that's still wrong with the storyline prose on me. -- http://www.catb.org/~esr/";>Eric S. Raymond ..every Man has a Property in his own Person. This no Body has any Right to but himself. The Labour of his Body, and the Work of his Hands, we may say, are properly his. The great and chief end therefore, of Mens uniting into Commonwealths, and putting themselves under Government, is the Preservation of their Property. -- John Locke, "A Treatise Concerning Civil Government" ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Request for comment - general expression evaluation in WML
Guillaume Melquiond :
> I would just like to point that, if you are using an event (e.g. the
> prestart one if the units have to be there right from the start), you
> could use Lua to achieve this:
>
> function leader_and_follower(x,y)
> W.unit { id="Leader", .., x=x, y=y }
> W.unit { id="Follower1", .., x=x, y=y+1 }
> W.unit { id="Follower2", .., x=x+1, y=y-1 }
> end
What magic does the W stand for? Is that the global Wesnoth context or
something?
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
[Wesnoth-dev] Request for comment - general expression evaluation in WML
While working on DM, I am discovering that it is really annoying not
to be able to do things like this:
#define LEADER_AND_FOLLOWER X Y
[unit]
id=Leader
..
x,y={X},{Y}
[/unit}
[unit]
id=Follower1
..
x,y={X},{Y}+1
[/unit}
[unit]
id=Follower2
..
x,y={X}+1,{Y}-1
[/unit}
#enddef
The fact that this does not work forces me to write macros in which
(a) there are a lot of hardwired constants with magic relationships
to each other, and (b) these constants are related in unobvious ways
to constants in other files. For an example, see {DELFADOR_REAPPEARS}
in Delfadors_Memoirs/utils/sides.cfg and its calling context in
Delfadors_Memoirs/scenarios/14_Shadowa.cfg.
I would like to fix this. Fixing it will require that I upgrade the
WML interpreter to do expression evaluation in certain places where it
now looks for constants. This is because, after macro expansion, the
expression {LEADER_AND_FOLLOWER 23 17} will expand to code that looks
like this:
[unit]
id=Follower2
..
x,y=23+1,17-1
[/unit}
This would not, on the whole, be very difficult. We already have a
tokenizer, and recursive-descent expression parsers are not difficult
to write.
There is, however, one large blocker in the way - we already have a
meaning for the syntax 17-1; it looks like a range, albeit a bizarre
one. Therefore, as a first step, the range syntax needs to be
replaced with something like '..' (the usual choice in programming
languages written in ASCII) so that '23..25' is unambiguously different
from '23-25'.
This is not a difficult change either, but it's a very intrusive one
that will touch a lot of places in mainline. A grep reveals about 380
places the present range syntax is used, and it will require a wmllint
rule to up-convert UMC.
As a compatibility hack pre-1.8, the expression evaluator could be
taught to return a range when the result of subtracting two numeric
literals would be negative. However, it would be a very bad idea to
leave a crocky rule like this in the language indefinitely. Someone
would surely write an macro that would trigger that rule in an
unexpected way and produce strange, hard-to-diagnoose bugs.
I am requesting comment before I implement this syntax change.
--
http://www.catb.org/~esr/";>Eric S. Raymond
When only cops have guns, it's called a "police state".
-- Claire Wolfe, "101 Things To Do Until The Revolution"
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Request for comment - general expression evaluation in WML
jeremy rosen : > I think pure WML has basic algebra functionalities somewhere... > > I'm no WML expert, so I could be wrong, but I think that there is a > format of variable expansion that does that... I've just learned from Sapient on IRC that there is -- a shell-like $() eval facility developed for formula AI but now exposed for general attributes. It's poorly documented; my brand-new Writer's Forum has a task-list item about fixing that. I guess this makes my proposal unnecessary. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] automatic savegames and overwriting
Jörg Hinrichs : > through my last refactoring of the savegame code i stumbled upon the fact > that automatic replay saves still call the method save_game_interactive, > which looks kind of odd. They do that because they ask for overwrite > permission (and maybe a new filename) if the replay filename already exists. > > The other two automatic saves however dont do that (start-of-scenario and > autosave), they just overwrite without asking. > > > > I would like to have a homogenous behaviour here, either such that replays > overwrite without asking, too, or that overwrite permissions are always > requested if the file already exists. Actually, I am indifferent which one > to prefer. > > > > What do you think about it? Overwrite without asking. The UI is simpler, and it's what users probably expect anyway. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
[Wesnoth-dev] I'm ready to implement save threading in the load dialog
One of the flaws in Wesnoth's UI is that afyer you've been playing for a while, the load-game dialog tends to list huge piles of autosaves that are no longer really interesting; almost always you want to reload the most recent save in a campaign. About 18 months ago I floated a proposal to change the UI for loading savegames so game saves are grouped into threads. Typically a thread would be a sequence of saves that are a continuous history of a campaign, though deleting saves in the middle could break a campaign into any number of disjoint threads. The UI would then turn into a two-level interface. Normally all you'd see would be a list of the most recent saves in each thread; there would be a way to descend into threads and see all saves in them in the relatively unusual case that you want to go back in time within a thread. I am ready to implement this feature. In fact, I already have the machinery for the lower half working in trunk. Thanks to YogiHH's cleanup of the savegame code, I have been able to implement a "parent" field in savefiles. Code can use these to run back down the ancestry chain from any given save. Savefiles with no parent are thread roots, usually the first autosave of a campaign - but as long as you have old savefiles without a parent field in them, all of these will also be treated as thread roots. Furthermore, I have working code in dialogs.cpp::load_game_dialog() that inverts the parent relation, creating a parent_to_child map. Savefiles with no child are thread tips and usually the files users will be interested in reloading. This is all the infrastructure needed to support an improved, thread-aware load-game dialog. The question, now, is what to do with it at the presentation/UI level. Here's the approach I favor: Make the load dialog look something like a file manager, with thread-tip saves behaving something like folders. That is, each save gets an icon to its left. The icon may be 1. Blank, indicating a non-tip savefile 2. "+" (or variant) indicating a tip save for which all the ancestors are visible in the list. 3. "-" (or variant) indicating a tip save for which ancestors are not shown. The default presentation would be to show only tip saves, all marked "-". If you clicked on a "-", it would change to "+" and all the ancestor saves associated with this tip would be displayed. If you clicked on a "+", the ancestor-save lines corresponding to that that tip save would be removed from the visible list and the icon would change to "-". Clicking on a blank would have no effect. Obviously this means the save list would have to be refreshed whenever a - was toggled to + or vice-versa. Less obviously, I think this facility would make both the sort-by-name/sort-by-date toggle and the filter box pretty much pointless, and they should probably be removed to simplify the code and the UI. Comments? Criticism? Technical issues? Alternate proposals? All offers of help cheerfully accepted; I'd really rather not write more C++ than I absolutely have to. -- http://www.catb.org/~esr/";>Eric S. Raymond The right of self-defense is the first law of nature: in most governments it has been the study of rulers to confine this right within the narrowest limits possible. Wherever standing armies are kept up, and when the right of the people to keep and bear arms is, under any color or pretext whatsoever, prohibited, liberty, if not already annihilated, is on the brink of destruction." -- Henry St. George Tucker (in Blackstone's Commentaries) ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] I'm ready to implement save threading in the load dialog
Richard Kettering III : > I think it's a excellent idea; in fact I think it's long overdue. > > The only minutiae suggestion I'd have would be to use disclosure > triangles instead of +/- elements; or even to use the open-book vs. > closed-book icons we have for the help files. If you're wondering > what disclosure triangles are, here is an article. I'd prefer them > over +/-, they're slightly less ambiguous, and slightly more intuitive: > http://wiki.jrmediacenter.com/index.php/Disclosure_triangle Ah, so *that's* what those are called! Agreed - preferable to +/-. However - boucman has pointed out that the tree-view paradigm these imply doesn't really fit the relations among saves. (I knew this up front, actually, but thought we could evade handling the most general case; he showed me otherwise.) The problem is this: suppose I have a sequence of end-of-turn saves A, B, C, D. D is the tip save. Now I go back to B and play it a different way, containing a line of saves C2, D2, E2. Right now you have to manually change the devault savename while working on the second line of play, otherwise C2 will overwrite C, etc.; but this is possible. If we're displaying only threads, it's clear what to do; only D and E2 get listed. But if we're displaying all saves associated with a thread, how do we represent the branch point? The straight tree-view model suggests a visual branch per thread, with A and B listed twice. boucman suggests that the best effect-to-effort ratio would be to continue displaying saves in straight chronological sequence, with a toggle controlling whether only tip saves are displayed or all are. I think the ideal solution would be the way the Mercurial version-control system handles lines of development, with a achematic node-and-link tree drawn to the left of a chronological sequence of save names. I can't find a good screensave illustrating this, but here's an ASCII mockup | + E2 | + D2 | + C2 + | D + | C |/ + B + A Of course, the code to render the node-and-link tree would be tricky. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] NativeClient port
Evgeniy Stepanov : > Would you like to have [NativeClient] in the main Wesnoth repo? My reaction is "Hell, yes!" and I suspect the other senior devs wil concur. Sounds like there is more in-tree work to be done to polish this up, including the websockets additions to the MP server. Ivanovic, would you please give Mr. Stepanov commit access so he can do this thing? -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] NativeClient port
Nils Kneuper : > But as Boucman already pointed out we are currently in feature freeze so I > think adding your changes to mainline right now might be, uhm, problematic... > I am not 100 sure how to best proceed here, comments and recommendations are > welcome. I would normally agree with this conservatism, but we're looking at a small patch with well-isolated test cases here. I think it would be safe to allow him to proceed. -- http://www.catb.org/~esr/";>Eric S. Raymond signature.asc Description: Digital signature ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Wesnoth project hosting
Mark de Wever : > At the FOSDEM we discussed again about whether or not moving to git and > thus from the location our source repository is hosted. The discussion > is listed [1] under Git. > > Personally I see not too much advantage by Git, git-svn works good > enough for me. However IMO the uptime of GNA is getting lower over the > years (it might be selective memory as well). It probably isn't. I've noticed it as well. > So moving to another > place to host our source repository might be a good idea. Am I the only > one who thinks it would be a good idea to try to find a more reliable > hosting party? Note moving to another hosting party does not mean > switching to Git per se. No, but if we're going to change repo hosting anyway the additional overhead of changing VCSes is much more tolerable by comparison. Better one clean break than two traumas. > How do we feel about moving to Git? As said I see not too much advantage > by Git, but I'm not opposed to move. If so are there preferences over > the hosting party? Rhonda also said she can probably host Git for us. I would be in favor of moving to git. If nothing else it would reduce incremental update times a lot. The project would have one unusual advantage in such a move: me! As the author and maintainer of reposurgeon, and having done several svn-to-git migrations of large repos to test it, I am probably the most experienced expert on such migrations anywhere. The fact that I know Wesnoth's history pretty well is a nice bonus. On the other hand, one of the things that experience tells me is that a Wesnoth migration would be a huge, messy project. The sheer size of the repo would produce a scale problem in itself - a full download of all branches runs my development machine out of disk space! This doesn't mean it can't be done. It does mean it can't be done *quickly*. But we probably want to wait until I ship reposurgeon 2.0 anyway; I'm still chasing some bugs in the svn support. > If we decide to move, do we only want to move the source repository or > also the bug-tracker and mailing lists? I haven't investigated whether > or not it's possible to export our bug-tracker's contents. I have written a tool that can scrape the GNA bugtracker. The problem isn't export but import - loading it into anywhere else. It is probably not yet feasible to move the tracker. However, I think we should probably begin preparing for a move. Gna is understaffed and undermaintained, and the Gna codebase is creaking and old. I would feel much more secure if the repo were migrated to somewhere like github or gitorious. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Wesnoth project hosting
Bruno Wolff III :
> On Wed, Feb 15, 2012 at 20:56:36 +0100,
> Mark de Wever wrote:
> >
> > At the FOSDEM we discussed again about whether or not moving to git and
> > thus from the location our source repository is hosted. The discussion
> > is listed [1] under Git.
>
> Does GNA have any plans to support git in the future?
I'm a GNA admin, though not active. Short answer: no. Longer answer: no,
and the odds that will change look slim to me. The GNA codebase is old
and inflexible, and the man-hours required to add features of that
magnitude aren't available.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Wesnoth project hosting
Ignacio Riquelme Morelle :
> In the matter of CIA.vc hooks for Git, all those I have seen so far have
> annoying limitations such as the inability to present real merges in a useful
> fashion, commits being reported out of order, or no tag object reports. I
> believe I have seen CIA reporting commits to hosted KDE projects addressing
> some of these points, but I haven't found the hook's source yet.
Talk to me. I maintain the CIA hooks that are in the git project
repo. If you know of a more advanced version, I'm willing to merge
those features and changes.
> 3) The learning curve and organization. At the beginning (and even
> afterwards, as new people join the project) it will be very chaotic
> unless someone steps forward and provides users with links to
> documentation (since IME even code developers fail to RTFM at
> times), and most importantly, style guidelines covering commit
> style/format, usage of branches, real merges vs. rebasing, and so
> on.
I know how to handle this. I've managed several large svn-to-git
transitions.
--
http://www.catb.org/~esr/";>Eric S. Raymond
signature.asc
Description: Digital signature
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Wesnoth project hosting
Mark de Wever : > > On the other hand, one of the things that experience tells me is that > > a Wesnoth migration would be a huge, messy project. The sheer size > > of the repo would produce a scale problem in itself - a full download of > > all branches runs my development machine out of disk space! > > I assume that is before you do a git repacking operation. Our git-svn > repo is less than 2 GB and AFAIK only misses the website branch. I was talking about a svn download. :-) > > This doesn't mean it can't be done. It does mean it can't be done > > *quickly*. But we probably want to wait until I ship reposurgeon 2.0 > > anyway; I'm still chasing some bugs in the svn support. > > Haven't looked at reposurgeon yet, but if that tool can make it easier > the better :-) reposurgeon is a repository surgery tool; one of its main uses is for high-quality repository conversions. See http://catb.org/~esr/reposurgeon/ The 2.x version will have direct support for reading (though not writing) Subversion repos. Already, even with its known bugs, it's the best svn-to-git converter in existence - because it's the only one that can handle mixed-branch commits. > > However, I think we should probably begin preparing for a move. Gna > > is understaffed and undermaintained, and the Gna codebase is creaking > > and old. I would feel much more secure if the repo were migrated to > > somewhere like github or gitorious. > > Thanks for confirming my suspicion about GNA. At the FOSDEM we mainly > considering Github and Sourceforge. Reasonable. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Experiments with git conversion
Andrius Štikonas : > I've been experimenting a little with svn-all-fast-export program > (https://gitorious.org/svn2git/svn2git) which was used to convert both GNOME > and KDE to git. Even if you later decide to use reposurgeon to do the > conversion, it might still be a good idea to have something to compare to. I agree. Of the alternatives to reposurgeon, this svn2git is the strongest. -- http://www.catb.org/~esr/";>Eric S. Raymond signature.asc Description: Digital signature ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Wesnoth GIT migration
Mark de Wever :
> AI has tested with exporting our data to git, which resulted in a 1.4
> GiB repository. GitHub has a recommended limit of 1 GB [1], so we'll
> need to ask whether the size of our repository is a problem.
>
> Since there have been no objections to move to git I'll contact GitHub
> and ask them whether our repository size is an issue. If it is they have
> some ideas how to reduce the size of the repository [2]. But if it is
> no problem I prefer to keep everything in one repository.
If we have to reduce the size, I think the music files are the obvious
low-hanging fruit. Maybe put them in a separate repo pointed at
by externals?
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Wesnoth GIT migration
jeremy rosen : > having translations in a separate repo could be nice... > > * it would allow to give direct git commit right to some translators > * wesnoth runs fine without translations so it shouldn't bother normal devs > much I think that first point is a very strong one. More generally, we want to make separate repositories for any branch or subtree that naturally has a different privilege group. > (that last point is not true for music/art unfortunately) Yes, but we could handle all of translations, music and art with externals - kept in separate repositories that are automatically pulled into subdirectories when you pull the master. > we also mentioned the resource branch that could be a separate repo... Yes, I think it should be. One of the advantages of my reposurgeon tool is that it will make carving the existing repository into pieces by path or branch an easy thing to do. That is, providing it has enough disk space for the whole SVN repo. I think I had better implement blob compression. :-) -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Wesnoth GIT migration
jeremy rosen :
> >
> > Yes, but we could handle all of translations, music and art with
> > externals - kept in separate repositories that are automatically
> > pulled into subdirectories when you pull the master.
> >
> your git knowledge is probably better than mine, but how do you do that ?
>
> afaik when using git-submodules there is no way to automatically pull
> dependencies (but I probably miss something)
See this discussion:
http://alexking.org/blog/2012/03/05/git-submodules-vs-svn-externals
Basically, post 1.6.5 the right thing happens if you clone with --recursive.
Or that's what it reads like to me, anyway; my experience with this feature
is limited to one project where the externals change seldom.
That project happens to be reposurgeon, by the way - I pull in agito and
svn2git for comparison testing.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Wesnoth GIT migration
Mark de Wever : > From reading the GitHub website it looks like per repo. That's what I would expect. > Note when we want to split the repo to reduce its size it also means we > have to historically remove those commits. It seems to be possible with > git filter-branch as said by GitHub, but I'm what reluctant to start to > modify the history. Don't worry about this part; reposurgeon has good primitives - more powerful and easier to use than filter-branch - for splitting repositories by subtree and branch. No commits will get removed per se, rather each one will be assigned to exactly one of the offspring repositories. Well, unless we run into a mixed-branch commit - those will get duplicated and one copy will go to each git branch, possibly ending up in different offspring repos. reposurgeon was specifically designed for situations like this; the expunge and divide primitives have been repeatedly tested on repositories with a more complicated branch structure than Wesnoth's. That part should go without a glitch - the issue won't be whether we can partition cleanly but how exactly we want to do it. There are SVN repository malformations that can confuse reposurgeon. The worst is a branch delete followed by a branch rename recreating the deleted branch. Also, various kinds of CVS scar tissue can cause problems. But I'm pretty sure that the Wesnoth repo doesn't contain any of this stuff. It might have an accidental mixed-branch commit or two, but reposurgeon takes those in stride. The only issue I really expect with this conversion is one of sheer size - I'm not sure my disk is large enough to hold all of (a) a mirror of the Subversion repo, (b) the on-disk intermediate state that reposurgeon keeps when it edits, and (c) the offspring git repos. I have just implemented bzip2 blob compression in reposurgeon as a way to substantially reduce the size of (b). -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
[Wesnoth-dev] git conversion strategy
I'm now attempting to mirror the Subversion repository for Wesnoth.
Here's hoping it doesn't fill up the disk before it's done.
There is one prerequisite I will need for conversion; that is a
map file associating Subversion committer IDs with full names
and email addresses.
We have some decisions to make about the conversion. The main ones
are:
(a) How to treat Subversion revision references in commit comments.
(b) How to split up the repository
Our choices for (a) are either:
Conservative: Leave references unaltered. Decorate each commit
comment with its fossil Subversion ID so we know where the targets
are.
VCS-independent: Turn each reference into an action stamp (that is, an
RFC3339 date followed by ! followed by committer ID). Massage the
extracted bugtracker state so commit references in that also turn into
that form.
I favor the VCS-independent option. It's a little more work up front,
but won't put a burden on future migrations or leavve
Subversion-dependent clutter in our comment history.
As for how to split up the repository, I'm going to start by trying
to make an an unsplit version. If that's more than a gig, I think the
targets for being split out are, in this order:
1. Translations
2. Audio
3. Graphics.
--
http://www.catb.org/~esr/";>Eric S. Raymond
"Are we to understand," asked the judge, "that you hold your own interests
above the interests of the public?"
"I hold that such a question can never arise except in a society of cannibals."
-- Ayn Rand
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] git conversion strategy
jeremy rosen :
> in what format to you want the user id/mail/name ?
Sample line:
esr = Eric S. Raymond
This is the same format as is used by git cvs-fast-import and
most other tools:
For a little by of extra goodness in local time display, add
a time zone spec as a third field, e.g.
esr = Eric S. Raymond +0500
or
esr = Eric S. Raymond America/Philadelphia
Basically, any offset acceptable as a Unix TZ value can go in there.
> I don't think cross-ref is a big issue, so if cross-ref doesn't work
> don't spend to much time on it...
The overhead of fixing these up (either way) isn't large. That's another
thing that reposurgeon does uniquely well.
> as for splitting strategy, you didn't mention separating the ressource
> branch wich would be the primary target I would have considered, but
> maybe it was implicit...
Yes, that slipped my mind. We probably do want that to be a separate repo.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] git conversion strategy
Mark de Wever : > We already know it will be more than 1 GB, as stated before AI tested > and ended with a 1.4 GiB repo. Yes, but git-svn makes some design choices that I think might result might result in blob duplication. We have enough really large blobs to make this an issue. I am now pretty confident that I'll be able to load the whole thing, by the way. I'm at about r10K of about 144K with only about 1% of the available volume used up. Somehow I had it in my head that we were into TB range, not GB. > > I think the targets for being split out are, in this order: > > > > 1. Translations > > 2. Audio > > 3. Graphics. > > Before considering splitting I like to know how it affects the work-flow > for the developers, translators and the release manager. See https://git.wiki.kernel.org/index.php/GitSubmoduleTutorial for a tutorial on how all this works. Splitting out translations would be pretty low impact, since (as others have pointed out) Wesnoth runs fine without them. Developers would barely notice. Translators would have an extra git update step to do after pulling, then have to run git push from within the translation repo rather than the main one. The release manager would also have one extra git update step. For audio, pretty similar, except subsitute "composer" for "translator". The key point in common with translations is that all the stuff we'd want to isolate into a submodule is in one subdirectory. That makes it easy. Isolating out graphics would be much messier, since those resources are spread out across many directories. I now think this is probably not a good idea. Better to break out the resource branch; in fact, that should probably be done first. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] git conversion strategy
Ignacio Riquelme Morelle : > Don't svn-to-git conversion tools use UTC for all timestamps from Subversion > commits anyway? Yes, they do. All incoming times become a UTC/tzoffset pair with the tzoffset defaulting to +. The way the timezone in this map file is used is that every git commit by a given person gets a timezone part that is "his" timezone, as opposed to that default +. This makes no difference internally but affects how time is shown if a client program chooses to display local time rather than UTC. This is a minor cosmetic detail. Don't worry about it. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] git conversion strategy
Ignacio Riquelme Morelle : > On Sunday 10 February 2013 18:55:11 Eric S. Raymond wrote: > > The way the timezone in this map file is used is that every git commit > > by a given person gets a timezone part that is "his" timezone, as > > opposed to that default +. This makes no difference internally > > but affects how time is shown if a client program chooses to display > > local time rather than UTC. > > > > This is a minor cosmetic detail. Don't worry about it. > > All right. It might just be a less trivial task for people who have actually > moved between timezones over time. (Not me, of course.) ;) It's exactly parallel to the problem of people who have changed email addresses over time. Best practice is to use the ID and timezone each user reports at the time of repo conversion, rely on them to clue in their VCS clients about changes in the future, and prominently timestamp the conversion so people know that *earlier* metadata is partly synthetic. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
[Wesnoth-dev] Calling all developers - fill in your preferred email please
Below is a copy of the name map I'm currently using for the repo conversion. If you are a committer please check it for your name. 1. If your ID isn't in the list, pleasse send me a line mapping your Gna ID to your peferred name and email. 2. If you are in the list, please correct your name and email as required. 3. If you happen to be able to identify the real name of a contributor that is long gone,like AShade or EdB, please do. ai0867 = Alexander van Gessel akihara = Riss Aline alarantalara = Simon Forsyth alink = Ali El Gariani anonymissimus = Anonymissimus ayin = Philippe Plantier ayne = Anja K. baufo = Thomas Baumhauer beetlenaut = Dan Gerhards benj = Benjamin Drieu billynux = Guillermo Biset bloodycoin = Justas boucman = Jérémy Rosen brilliand = Silas Brill brunowolff = Bruno Wolff III caslav_ilic = Chusslove Illich cedricd = Cedric D. chpln = Chris Mann cib = Christian Bielert cjhopman = Chris Hopman cornmander = Gregory Shikhman crab = Iurii Chernyi crimson_penguin = Ben Anderman cycholka = Piotr Cychowski darthfool = John W. C. McNabb dave = David White dfranke = Daniel Franke dhains = Douglas Hains dirus = Danny Daemonic dragonking = Bartek Waresiak edb = EdB ejls = Étienne Simon eleazar = J.W. Bjerk elias = Elias Pschernig elricz = Miguel Zapico elvish_hunter = Elvish_Hunter espreon = Steven Panek esr = Eric S. Raymond ettin = ettin euschn = Eugen Jiresch faabumc = FAAB fendrin = Fabian Müller fmunoz = Francisco Muñoz frame = Frame gabba = Gabriel Morin gakusho = Pauli Manninen grickit = Derek Hoagland gruikya = Phillipe Plantier grzywacz = Karol Nowak hajo = HaJo Gurt hogne = Hogne Håskjold ilor = Tomasz Śniatowski isaac = Isaac Clerencia ivanovic = Nils Kneuper iwontbecreative = Thibault Févry j_daniel = Jon Daniel jamit = J. Tyne jbm = JBM jetryl = Richard Kettering jhinrichs = Jörg Hinrichs jimm = Jim jorda = Jordà Polo jzaun = jzaun kbaskins = Karen Baskins kestenvarn = Jesse Holland kevg = Kosov Eugene kmj = KMJ lipk = B. Lipka loonycyborg = Sergey Popov martinxyz = Martin Renold mattsc = Matthias Schoeck mcshark = McShark mesilliac = Tommy mog = Moritz Göbelbecker mordante = Mark de Wever morloth = Bram Ridder mythological = Dimitar Ilccov nephro = Dmitry K. no-author = No Author noyga = Benoît Timbert okyada = Nobuhito Okada oracle = Greg Copeland oron = Oron Peled quartex = Asa Swain queenkiller = Josef Redinger reisiger = Jan Herzog rhonda = Gerfried Fuchs rhuvaen = Jan R. rusty = Rusty Russell ryo = Nicolas Weeger sanna = Susanna Björverud sapient = Patrick P. scott = Scott L. segfault = Jérôme Brongniart shadowmaster = Ignacio R. Morelle silene = Guillaume Melquiond sirp = Dave White soliton = Gunter Labes suokko = Pauli Suokko sytyi = Sytyi Nick taurus = Taurus thespaceinvader = Phil Barber thonsew = Thonsew timotei = Timotei torangan = David Philippi tschmitz = Tommy Schmitz turin = Joseph Simmons turuk = Justin DiSabatino tuukkah = Tuukka Hastrup upthorn = Jody Northup vultraz = CD west = Mattias Westlund wintermute = George xan = Dominic Bolin ydirson = Yann Dirson zamotivator = Oleg Tsarev zaroth = Lukasz Dobrogowski ziberpunk = Alfredo Beaumont zookeeper = Lari Nieminen -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Calling all developers - fill in your preferred email please
Richard Kettering : > jetryl = Richard Kettering > jetryl = Richard Kettering > If there's a way to convert names, I'd kinda prefer to go in the > repo as username="rkettering", rather than "jetryl", since that's > what I use on github, but don't break a sweat doing it if it's any > work. Conversion is easy. Your entries now read: jetryl = Richard Kettering jetrel = Richard Kettering Let me know if any further correction is required. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Calling all developers - fill in your preferred email please
David White : > David White = davewx7 (github ID) - email: dave...@gmail.com I should use that for 'sirp', too, yes? > Thank you for taking care of this! You do realize the project got triple sixes on its luck roll, right? Conversions of repos the size and age of Wesnoth's can be nightmares; it's *very* fortunate for the project that the author of reposurgeon happens to know Wesnoth well. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
[Wesnoth-dev] More complete names for these devs?
ayne = Anja K. bloodycoin = Justas elvish_hunter = Elvish_Hunter faabumc = FAAB jbm = JBM jimm = Jim mcshark = McShark mesilliac = Tommy nephro = Dmitry K. rhuvaen = Jan R. sapient = Patrick P. scott = Scott L. Also, I want to double-check these: frame = Hogne Håskjold freim = Hogne Håskjold -- >>esr>> ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] More complete names for these devs?
Iurii Chernyi : > Two great GSOC students that I've mentored: > Dmitry Kovalenko > Anja Keicher What was Anja's Gna ID? -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
[Wesnoth-dev] Developers still not identified
I now have names and email addresses for all shortnames except these: Eponymous uid68698 skovbaer uso Sofronius sithrandel radx isaaccp TheAT zas AShade uid69097 uid68803 uid67456 uid68852 uid68842 uid68850 uid65860 uid69206 uid66289 No, I have no idea where those uid* names come from. Can anyone identify any of these people? -- http://www.catb.org/~esr/";>Eric S. Raymond The most foolish mistake we could possibly make would be to permit the conquered Eastern peoples to have arms. History teaches that all conquerors who have allowed their subject races to carry arms have prepared their own downfall by doing so. -- Adolph Hitler, April 11 1942. ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Developers still not identified
jeremy rosen : > do those uid* only have very old commits ? they might have been lost > in the cvs=>svn/sourceforge=>gna transition Yes, I suspect that's the case. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Developers still not identified
benoit.timb...@free.fr :
> If i recall correctly the real name of "isaaccp" was Isaac Clerencia Perez.
> He was an admin of Wesnoth on sourceforge.
> I don't know his mail, but isaa...@sf.net might work.
I already have this:
isaac = Isaac Clerencia
Same person?
And you say "admin of Wesnoth on sourceforge". Was the project on SourceForge
before Gna? Is that where the CVS lived?
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
[Wesnoth-dev] Pathological branches
One of the repository malformations most likely to confuse reposurgeon's attempt to create a git DAG is a branch delete followed by a branch copy with the same target name. Because of this, I have reposurgeon throw a warning whenever it sees a mid-branch delete. The Wesnoth repo has these: mid-branch delete: on refs/heads/utbs at commit@266118=<31003> mid-branch delete: on tags/1.1.8 at commit@94237=<12797> mid-branch delete: on refs/heads/fendrin_editor at commit@365874=<42097> mid-branch delete: on refs/heads/shadowmaster_filesystem at commit@208957=<24491> mid-branch delete: on tags/1.1.7 at commit@89598=<12196> mid-branch delete: on refs/heads/fendrin_pathfind at commit@356044=<40927> mid-branch delete: on tags/1.0.1 at commit@54520=<8618> mid-branch delete: on tags/1.1.7 at commit@8=<12230> mid-branch delete: on tags/1.1.3 at commit@85202=<11605> I'm guessing some of these branches are obsolete and can be removed. The more of them I can get rid of, the less likely I am to trip over a problem that will require tricky surgery. Also, any branches we can discard help shrink the repository, which is presently over GitHub's size limit. Which of these can be deleted? -- http://www.catb.org/~esr/";>Eric S. Raymond The most foolish mistake we could possibly make would be to permit the conquered Eastern peoples to have arms. History teaches that all conquerors who have allowed their subject races to carry arms have prepared their own downfall by doing so. -- Adolph Hitler, April 11 1942. ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
[Wesnoth-dev] Why I want to confiscate every dev's * key
I want to confiscate every dev's * key because while converting the Wesnoth repo I've just fixed about the hundredth comment that does this: -- Fossil-ID: 29314 * Document weapon/second_weapon addition and changes on RC imagepath * function -- The obvious thing that is wrong with this is the second '*'; the bare word 'function' is not a list entry. The unobvious thing that is wrong with this is the *first* '*'. This entire comment should not have been written as a bullet item. Because there aren't any other items in it! There's no list here! A change comment like this is OK: -- A summary of what I did to fix a random bug * This is the first thing * This is the second -- A change comment like this is not OK: -- * This is a random thing I did. -- That leading '* ' is just a hindrance to readability, a visual bump in the road. When your comment history is over 50K commits long this sort of small additional friction matters. The following is also *not* OK: -- * This is one random thing I did. * This is another random thing I did. * This is a third random thing I did. -- Why is this not OK? Well, the obvious reason is that there is no summary line tying all the items together. This matters more in git-land because so many of the tools just show first summary lines. The less-obvious reason is that if you write a comment like this, your single commit is almost certainly doing too much. You should break it up into several commits, each with one topic that becomes a single (non-bullet) item in its own change comment. The next time you are tempted to press your '*' key when writing a change comment, stop and think. Is it just going to be noise? If so, stop and slap your own hand. More generally, give a little thought to what the shape of your comment says about the shape of your commit. Is it trying to describe too many different and unrelated changes in one go? Does it have a proper first summary line that will minimize the overhead of reading it for someone six months down the road? There's a programmer's proverb: "Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. Code for readability." That applies to comments, too. At the scale of this project, such details really matter. -- http://www.catb.org/~esr/";>Eric S. Raymond Idealism is the noble toga that political gentlemen drape over their will to power. -- Aldous Huxley ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Wesnoth GIT migration
David White : > Are you sure that Sourceforge might not be similar? (Or that our > performance will deteriorate there without them letting us know up-front) I have lots of experience with SourceForge. They don't have a published size limit because they really don't have a size limit. > Is the limitation perhaps more related to the scalability of git itself > rather than a limitation github adds? Unlikely. I know how git works - there isn't any intrinsic O(n**2) in the core algoriothms. Instead, a whole bunch of O(n log n) has hand tree lookups. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Wesnoth GIT migration
Mark de Wever : > I prefer to keep our repository in one piece* so I'd rather look at > moving to SourceForge. I concur. My thinking may change as I investigate alternatives, but right at this moment SourceForge looks like our best option. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Wesnoth GIT migration
Eric S. Raymond : > Unlikely. I know how git works - there isn't any intrinsic O(n**2) in the > core algoriothms. Instead, a whole bunch of O(n log n) has hand tree > lookups. I meant "hash and tree lookups". -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Wesnoth GIT migration
Bruno Wolff III : > There is a tool git annex that tracs large files by location instead > of inside of git proper. Would it make sense to use this along with > hosting sound and images more conventionally instead of directly in > a git repo? It might. And reposurgeon could do the dissection easily. I'm reluctant to go this route, however, as it would leave the metadata in the main repo in a messy state that would make future understanding of some parts of the project history significantly more difficult. Our release manager wabts everything that goes into a release bundle to be in one repository - and that, too, is a significant point. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
[Wesnoth-dev] Changing Wesnoth over to git - we're ready to go
After a week of work, I have the lift script and other metadata in shape to perform a high-quality conversion from the Wesnoth project's Subversion repository to git. Most of that week was spent doing these things: (1) Marking up Subversion revision references in a form that allows reposurgeon to automatically lift them to "action stamps" - an RFC3339 date followed by '!' followed by the committer's email address. This was necessary in order to preserve the usefulness of comments describing reversions and backports (which are quite frequent in the history) without cluttering every comment in the repository with the fossil Subversion ID of its commit. There is at least some hope that tools like cgit can be upgraded so that action stamps will turn into hotlinks in their browser presentation (submitting such patches is on my to-do list). That won't happen with fossil Subversion references - the formats for writing them are not sufficiently unambiguous for machine parsing. (2) Because I had to do an eyeball pass over all 56K comments to get item 1 right, I also massaged all comments into proper form for git - a summary line, followed by a blank line, followed by running text with lines at most 72 characters long (with a very few exceptions for things like long URLs). Paragraps and bullet-list items have blank-line separators. This format facilitates browsing of the repo history with git log and gitk and *should be followed for all new commits*. Since about 2009 most Wesnoth committers, influenced by git via git-svn, have been doing this anyway. Now it's time for the rest of you to get with it. (3) Hand-fixing CVS and certain Subversion artifacts that can produce a garbled gitspace conversion. Fortunately, the Wesnoth repo has few of these and they are confined to two obsolete development branches. I have verified with the developers in question that these can be deleted without loss. Using reposurgeon, I can do a clean convert to git of the repo in about an hour. This is not the entire job, however. We need volunteers for some related tasks: A. The developer portion of the Wesnoth wiki will need to be edited twice: once to warn of the oncoming transition, and then a second time when the new git repo goes live and the old one is decommissioned. B. Moving the Gna! bugtracker state to the new site. I had written the extractor already and someone (Crab, I think) has verified that it works. Somebody needs to write the injector for the API at our target site. Fortunately this is not a pre-requisite for moving the repository. C. The build systems have some Subversion dependencies. Somebody needs to identify these and factor them out. Fortunately, I co-maintain a tool called 'autorevision' that makes this easy. See http://www.catb.org/esr/autorevision/ It should be possible to change the Wesnoth build to use autorevision to extract a useful standard set of version symbols from Subversion in a way that can be used essentially *without change* under git. This *should* be done before we move. Would three volunteers please confirm that they will take on these tasks? I don't want to have to take my attention off the repository move itself. In my next email, I will propose where to move. A followup will discuss timing and lay out a transition plan. -- http://www.catb.org/~esr/";>Eric S. Raymond Strict gun laws are about as effective as strict drug laws...It pains me to say this, but the NRA seems to be right: The cities and states that have the toughest gun laws have the most murder and mayhem. -- Mike Royko, Chicago Tribune ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Changing Wesnoth over to git - we're ready to go
Iurii Chernyi : > I volunteer to do B. I've tried the extractor before, it worked. I will try > to fix several minor bugs the extractor has, and would prepare a demo of > the resulting bug tracker after reinjecting. Afterwards, I'll ask to find > more bugs in the extractor Thank you. I was expecting you to step up to this and I think we will all be glad that you have. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
[Wesnoth-dev] Changing Wesnoth over to git - where to move
Gna! does not host git repositories. Supposing it did, one of the motivations for the move is a sense that Gna! is teetering on the brink and not a safe place to remain. We need to pick a new hosting site. GitHub has a lot of fans in Wesnoth's developer base. But it is not going to be GitHub. The reason is size. AI0867 did a test conversion with git-svn to scope the size of the git repo. With aggressive GC and repacking it is 1.4GiB. GitHub has a limit of 1GiB per repo, not because of storage space but because they fear downloaders becoming bandwidth hogs. Mordante asked the GitHub admins for an exception to this policy; he was politely but definitely denied. On IRC I have heard two different kinds of attempt to argue away this denial. One was "but it's just described as a guideline, not a hard quota". This will not wash; we asked the GitHub admins if they are willing to host a 1.4GB repo and they said *no*. Trying to fly in the face of that denial would poison our relationship with the site and quite possibly get us kicked off for TOS violation. This is not a risk that would be in any way prudent to take. The second form of evasion is various schemes to carve the repo into chunks of less than 1GB size, by breaking out some subset of (a) music, (b) the website branch, (c) the resource branch. This won't fly either. I could run exact numbers, but I don't need to. We are *not* going to trim more than 400MiB off the main repo this way (that's nearly a full third of the historical content!). And even if we could, it wouldn't solve the real problem; what GitHub cares about is the aggregate bandwith of our downloaders, not how it's divvied up into parcels. They would (rightly) interpret a carve-up as a skeevy attempt to end-run their refusal. The clincher is that our release manager wants (quite reasonably) that everything that goes in a release bundle to be in one repo. That precludes breaking out the music - and the other plausible split candidates are small enough to be noise by comparison. So, no GitHub. I don't even have to get into my nervousness about replicating the BitKeeper fiasco by relying on proprietary closed source, or my near-certainty that trying to carve up the repo into chunks would set us up for troublesome unanticipated synchronization problems down the road. Given our circumstances, I think the obvious best candidate is SourceForge. It doesn't have a size quota, we already own the Wesnoth project there, and we'll be able to write our own bugtracker integration hooks from git using the Allura API. However, I do not want to make that SourceForge decision unilaterally. Senior devs and release manager, please weigh in on this. Please either +1 or state a reasoned objection. -- http://www.catb.org/~esr/";>Eric S. Raymond If gun laws in fact worked, the sponsors of this type of legislation should have no difficulty drawing upon long lists of examples of criminal acts reduced by such legislation. That they cannot do so after a century and a half of trying -- that they must sweep under the rug the southern attempts at gun control in the 1870-1910 period, the northeastern attempts in the 1920-1939 period, the attempts at both Federal and State levels in 1965-1976 -- establishes the repeated, complete and inevitable failure of gun laws to control serious crime. -- Senator Orrin Hatch, in a 1982 Senate Report ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Changing Wesnoth over to git - where to move
Karol Nowak :
> How about bitbucket.org?
>
> https://confluence.atlassian.com/pages/viewpage.action?pageId=273877699
Can you cite specific, concrete advantages that make it better than
SourceForge?
In general, saying "How about foo?" and stopping there is annoying and
pointless. If you can't demonstrate that foo is a better choice than the
top alternative under consideration it's better not to even bring it up.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Changing Wesnoth over to git - where to move
jeremy rosen : > you didn't mention carving out the translation branch, which would > make sense for commit-priv reasons... any thought on that ? It would break Ivanovic's invariant - one repository for one release bundle. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Changing Wesnoth over to git - where to move
Paul Ebermann : > If Wesnoth would get an exception to have a larger repository, this > still would mean that nobody else can fork the repository at Github – > and I think the fork + pull request functionality is a big part of what > makes Github so useful. That is a good point. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Changing Wesnoth over to git - we're ready to go
Mark de Wever : > Could you give an example of a converted commit? Here is an example of a converted commit comment: -- Fossil-ID: 56190 Add volcanos to DRAKE_UNWALKABLE_TERRAINS, fixing bug #20485 (backport of 2013-02-08T16:40:58Z!jt_cod...@verizon.net). -- '2013-02-08T16:40:58Z!jt_cod...@verizon.net' was formerly '56189'. > Does this mean the SVN > revision IDs are gone from the commit message? Yes. >If so I'm not sure > whether that is a good idea, these numbers are also used in other places > like the bug tracker. We're going to have to mechanically edit that content anyway as we re-inject it into the new site's tracker. This just adds a cheap lookup step to that conversion. I keep a file that maps svn revisions to action stamps for this purpose. Again, the reason to not use unconverted Subversion IDs is because there is essentially no hope that web-based repo browsers can be taught to turn them into hotlinks. The problems are (a) how do you tell whether or not any random blob of numbers is a revision ID? and (b) where and how would the repo browser maintain a reference index of revision IDs mapping them to native revision IDs, or even know that it has to do that? These questions don't have happy answers. For action stamps, on the other hand, generating hotlinks is pretty easy - the -mm-ddThh:mm:ssZ!name@fqdn format is not ambiguous, and every commit is guaranteed to have the right metadata to match it against. > > (3) Hand-fixing CVS and certain Subversion artifacts that can produce a > > garbled gitspace conversion. Fortunately, the Wesnoth repo has few of these > > and they are confined to two obsolete development branches. I have > > verified with the developers in question that these can be deleted > > without loss. > > Changing the history doesn't give me a warm and fuzzy feeling. Could > you explain what the artifacts were and why it was required to rewrite > history? Yes. There are lots of uglier things that can happen in a Subversion repo (especially one that used to be CVS), but the Wesnoth history is relatively clean. The only kind of artifact it has that needs hand-fixing is mid-branch deletes followed by a rename or continuation of the same branch. The Wesnoth repo has a small handful of these, all occurring in the following aborted development branches: fendrin_pathfind, fendrin_editor, and shadowmaster_filesystem. Mechanically translating these mid-branch deletes into gitspace can be done in two ways. One preserves all the information in the original history but gets the root point of the branch wrong. The other gets the root point right but discards information about "obsolete" commits. For philosophical reasons, reposurgeon chooses the information-preserving way, requiring a human to make an explicit choice to throw away information in order to get the topology right. (Someday reposurgeon may be able to automatically cope with this edge case better than it does now. But it's a sufficiently rare one that it's nowhere even near the top of my to-do list.) In this case, after looking at these branches, my reaction was to want to avoid the hand-surgery headache by simply discarding them. Both devs confirmed that they stopped being relevant some time ago. This is the only "history rewriting" in the lift. Well, unless you count fixing bad grammar and typos in change comments. > > C. The build systems have some Subversion dependencies. Somebody needs > > to identify these and factor them out. Fortunately, I co-maintain a > > tool called 'autorevision' that makes this easy. See > > > > http://www.catb.org/esr/autorevision/ > > Just a note, but the project only works UNIX like systems, so Linux and > possibly Mac. Point. I don't know how to fix that. > > It should be possible to change the Wesnoth build to use autorevision > > to extract a useful standard set of version symbols from Subversion > > in a way that can be used essentially *without change* under git. > > This *should* be done before we move. > > What do we exactly want to show and where? The commit ID seems the > logical choice for SVN, since it contains 5 digits. The SHA1 commit ID > seems to be rather error prone if a user has to copy them manually. We want to cook these symbols into the version string that Wesnoth displays. Exactly how we choose to do that is a policy question, not a mechanism one. And not one that interests me much. Ask Ivanovic for a ukase. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Changing Wesnoth over to git - where to move
Mark de Wever : > Google code has an initial push limit of 500 MiB, not sure whether that > would be an issue. It's an issue all right. Our initial push will be just shy of *3 times* that size. Scratch Google Code off the list. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Changing Wesnoth over to git - we're ready to go
Ignacio Riquelme Morelle : > On Sunday 24 February 2013 07:52:56 Eric S. Raymond wrote: > > This is the only "history rewriting" in the lift. Well, unless you count > > fixing bad grammar and typos in change comments. > > That sounds like an excellent... waste of time. > > The majority of the active Wesnoth developers are non-native speakers, and > mistakes of any kind will continue to crop up in future commit messages. > > I'm sure you could have done something more constructive with the > time it took you to handle this particular point. I wouldn't have, except I was already doing an eyeball pass in order to massage comments into summary + continuation form and lift references like r3456 into [[SVN:3456]] so they could be automatically lifted to action stamps. The additional time overhead of fixing typos was very small. It's something I do rapidly and almost without conscious thought. -- http://www.catb.org/~esr/";>Eric S. Raymond signature.asc Description: Digital signature ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Changing Wesnoth over to git - where to move
Gabriel Morin : > You might want to politely emphasize that Wesnoth is one of the largest and > most popular open-source game project. If I was them I'd feel it's an honor > to host it... and a potential benefit because of the extra traffic, I > imagine. I don't think they consider extra traffic a benefit. Contemplate their business model a while to see why. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Changing Wesnoth over to git - where to move
Alexander van Gessel : > Perhaps a mention of the plan to host a tarball of a clone ourselves, > because of the lack of resume capability of git-clone, will help put their > fears of excessive bandwidth usage to rest. You guys are engaging in massive wishful thinking. When you're done, I'll be here. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
[Wesnoth-dev] State of the git conversion.
The hard work is done. I can produce clean lifts of the Subversion repo on about an hour's notice, and I have a canned procedure for repidly incorporating new commits. The following committers have still not been identified: Sofronius TheAT radx uso zas I would grateful to anyone who can provide email addresses for any of these people. At least some of them are forum users; is there a forum administrator listening who can look in their registration data? This explanation is in the change comment of what was r2: [[The Wesnoth repository started off as CVS on SourceForge, was later converted to Subversion using cvs2svn and hosted at Gna!, and in early 2013 was converted to git by ESR using reposurgeon. Comments have been massaged into git summary + body form; revision references have been lifted to action stamps. Conversion comments are, like this one, enclosed in double square brackets. Typos in change comments have often been quietly fixed. Some abbreviations (notably for mainline campaign names) have been made more uniform than they were in the Subversion comments. Infix "::" to mark a campaign-scenario pair (as in "HttT::12" has sometimes been inserted for clarity and to shorten summary lines. Two branches, website/ and resources/, have been merged to trunk, where their history now appears as that of those directories rather than as separate branches. This diposition could be changed; it would, in particular, be easy to turn these branches into small separate repositories. Subversion property settings, and the commits in the Subversion history that manipulated them, are almost all gone. A few have been translated to .gitignore files and setting of executable bits.]] Can anyone identify at what revision the CVS-to-SVN switch took place? I have enclosed copies of the authors file and lift script I am presently using. Please review the former and ensure I have your email address correct. Feel free to specify a time zone for yourself. I am ready to move this thing as soon as we have a hosting site chosen. -- http://www.catb.org/~esr/";>Eric S. Raymond ai0867 = Alexander van Gessel +0100 akihara = Riss Aline allefant = Elias Pschernig alarantalara = Simon Forsyth alink = Ali El Gariani anonymissimus = Anonymissimus CET/CEST ashade = James Spencer ayin = Philippe Plantier ayne = Anja Keicher baufo = Thomas Baumhauer beetlenaut = Dan Gerhards benj = Benjamin Drieu billynux = Guillermo Biset bloodycoin = Justas Tomkus boucman = Jérémy Rosen brilliand = Silas Brill brunowolff = Bruno Wolff III caslav_ilic = Chusslove Illich cedricd = Cédric Duval chpln = Chris Mann cib = Christian Bielert cjhopman = Chris Hopman cornmander = Gregory Shikhman crab = Iurii Chernyi crimson_penguin = Ben Anderman cycholka = Piotr Cychowski darthfool = John W. C. McNabb dave = David White dfranke = Daniel Franke dhains = Douglas Hains dirus = Danny Daemonic dragonking = Bartek Waresiak edb = Serge Martin ejls = Étienne Simon eleazar = J.W. Bjerk elias = Elias Pschernig elricz = Miguel Zapico elvish_hunter = Elvish_Hunter eponymous = John Muccigrosso erl = Kristoffer Erlandsson espreon = Steven Panek esr = Eric S. Raymond EST/EDT ettin = Jordà Polo euschn = Eugen Jiresch faabumc = Baihua Jie fendrin = Fabian Müller fmunoz = Francisco Muñoz frame = Hogne Håskjold freim = Hogne Håskjold gabba = Gabriel Morin gakusho = Pauli Manninen grickit = Derek Hoagland gruikya = Phillipe Plantier grzywacz = Karol Nowak hajo = HaJo Gurt hogne = Hogne Håskjold ilor = Tomasz Śniatowski Europe/Warsaw isaac = Isaac Clerencia Perez isaaccp = Isaac Clerencia Perez ivanovic = Nils Kneuper iwontbecreative = Thibault Févry j_daniel = Jon Daniel jamit = J. Tyne jbm = John B. Messerly jetryl = Richard Kettering jetrel = Richard Kettering jhinrichs = Jörg Hinrichs jimm = Jim jorda = Jordà Polo jzaun = Justin Zaun kbaskins = Karen Baskins kestenvarn = Jesse Holland kevg = Kosov Eugene kitty = Kathrin Polikeit kmj = KMJ lipk = Boldizsár Lipka loonycyborg = Sergey Popov martinxyz = Martin Renold mattsc = Matthias Schoeck mcshark = McShark mesilliac = Tommy mog = Moritz Göbelbecker mordante = Mark de Wever morloth = Bram Ridder mythological = Dimitar Ilccov nephro = Dmitry Kovalenko no-author = No Author noyga = Benoît Timbert okyada = Nobuhito Okada oracle = Greg Copeland oron = Oron Peled ott = András Salamon pekka = Pekka Aikio quartex = Asa Swain queenkiller = Josef Redinger reisiger = Jan Herzog res = Frank Richter rhonda = Gerfried Fuchs rhuvaen = Jan Rietema rusty = Rusty Russell ryo = Nicolas Weeger sanna = Susanna Björverud sapient = Patrick Parker scott = Scott Klempner segfault = Jérôme Brongniart shadowmaster = Ignacio R. Morelle silene = Guillaume Melquiond sirp = Dave White sithrandel = Marcus Phillips skovbaer = Mark Michelsen soliton = Gunt
[Wesnoth-dev] Identifying merge point in the Wesnoth repo
As the last major step in readying the git repo, I'm trying to find out whether various development branches were merged or cherry-picked back to trunk, and if so when this happened for each one. I will express this by creating merge links in gitspace. These will be important clues for anyone reading the history. Here are the branches at issue: Branch: 1_2. Created: 2006-10-13 16:38:01 by Jörg Hinrichs Last commit: 2006-10-17 15:39:38 by Jörg Hinrichs Question: Was this branch merged back to 1.2? If so, at what commit? Branch: asio_wesnothd Created: 2011-12-30 08:43:14 by Sergey Popov Last commit: 2012-04-30 20:07:18 by Sergey Popov Question: was this branch ever merged back to trunk? If so, at what commit? Branch: branch_gettext1 Created: 2004-06-21 16:44:20 by Yann Dirson Last commit: 2004-08-15 11:32:44 by Yann Dirson Question: When was this merged or cherry-picked back to trunk? Branch: dfool_terrain Created and last commit: 2006-04-27 19:34:40 by John W. C. McNabb Question: Did this go anywhere? Should it be deleted? Branch: editor Created: Fabian Müller 2011-03-10 21:27:23 Last commit: abian Müller 2011-04-18 11:12:56 Question: Was this merged to trunk? If so, at what revision? Branch: fendrin_pathfind_and_editor Question: I'm confused about the history of this branch and how it relates to 'editor'. Branch: formula_ai Created: David White 2008-01-27 22:04:25 Last commit: Bartek Waresiak 2008-03-02 14:57:40 Question: Was this merged to trunk? If so, at what commit? Branch: gabba_ghosted_units Created: Gabriel Morin 2010-05-01 00:01:54 Last commit: Gabriel Morin 2010-05-03 19:50:08 Question: Was this merged to trunk? If so, at what commit? Branch: mp_registration Created: Thomas Baumhauer 2008-03-17 16:42:30 Last commit: Thomas Baumhauer 2008-03-24 05:44:47 Question: Was this merged to trunk? If so, at what commit? Branch: new_addon_server Created: Tomasz Śniatowski 2010-09-19 07:24:03 Last commit: Tomasz Śniatowski 2010-10-16 13:58:08 Question: Was this merged to trunk? If so, at what commit? Branch: ogl Created: Ali El Gariani 2010-09-28 18:14:21 Last commit: Alexander van Gessel 2010-11-19 13:07:05 Question: Was this merged to trunk? If so, at what commit? Branch: terrain-layer Created: Moritz Göbelbecker 2007-03-07 15:19:52 Last commit: Mark de Wever 2007-04-12 13:35:25 Question: Was this merged to trunk? If so, at what commit? Branch: umcmg Created: Ignacio R. Morelle 2010-10-20 20:36:20 Last commit: Ignacio R. Morelle Question: Was this merged to trunk? If so, at what commit? Branch: upthorn_persistence Created: Iurii Chernyi 2010-04-17 06:26:47 Last commit: Jody Northup 2010-04-19 06:21:14 Question: Was this merged to trunk? If so, at what commit? -- http://www.catb.org/~esr/";>Eric S. Raymond [W]hat country can preserve its liberties, if its rulers are not warned from time to time that [the] people preserve the spirit of resistance? Let them take arms...The tree of liberty must be refreshed from time to time, with the blood of patriots and tyrants. -- Thomas Jefferson, letter to Col. William S. Smith, 1787 ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
[Wesnoth-dev] Identifying merge point in the Wesnoth repo
(A previous attempt to send a slightly longer version of this to the list bounced due to too many Ccs; apologies if you see a duplicate.) As the last major step in readying the git repo, I'm trying to find out whether various development branches were merged or cherry-picked back to trunk, and if so when this happened for each one. I will express this by creating merge links in gitspace. These will be important clues for anyone reading the history. Here are the branches at issue: Branch: 1_2. Created: 2006-10-13 16:38:01 by Jörg Hinrichs Last commit: 2006-10-17 15:39:38 by Jörg Hinrichs Question: Was this branch merged back to 1.2? If so, at what commit? Branch: branch_gettext1 Created: 2004-06-21 16:44:20 by Yann Dirson Last commit: 2004-08-15 11:32:44 by Yann Dirson Question: When was this merged or cherry-picked back to trunk? Branch: dfool_terrain Created and last commit: 2006-04-27 19:34:40 by John W. C. McNabb Question: Did this go anywhere? Should it be deleted? Branch: editor Created: Fabian Müller 2011-03-10 21:27:23 Last commit: abian Müller 2011-04-18 11:12:56 Question: Was this merged to trunk? If so, at what revision? Branch: fendrin_pathfind_and_editor Question: I'm confused about the history of this branch and how it relates to 'editor'. Branch: formula_ai Created: David White 2008-01-27 22:04:25 Last commit: Bartek Waresiak 2008-03-02 14:57:40 Question: Was this merged to trunk? If so, at what commit? Branch: gabba_ghosted_units Created: Gabriel Morin 2010-05-01 00:01:54 Last commit: Gabriel Morin 2010-05-03 19:50:08 Question: Was this merged to trunk? If so, at what commit? Branch: mp_registration Created: Thomas Baumhauer 2008-03-17 16:42:30 Last commit: Thomas Baumhauer 2008-03-24 05:44:47 Question: Was this merged to trunk? If so, at what commit? Branch: new_addon_server Created: Tomasz Åniatowski 2010-09-19 07:24:03 Last commit: Tomasz Åniatowski 2010-10-16 13:58:08 Question: Was this merged to trunk? If so, at what commit? Branch: ogl Created: Ali El Gariani 2010-09-28 18:14:21 Last commit: Alexander van Gessel 2010-11-19 13:07:05 Question: Was this merged to trunk? If so, at what commit? Branch: terrain-layer Created: Moritz Göbelbecker 2007-03-07 15:19:52 Last commit: Mark de Wever 2007-04-12 13:35:25 Question: Was this merged to trunk? If so, at what commit? Branch: umcmg Created: Ignacio R. Morelle 2010-10-20 20:36:20 Last commit: Ignacio R. Morelle Question: Was this merged to trunk? If so, at what commit? -- http://www.catb.org/~esr/";>Eric S. Raymond Americans have the right and advantage of being armed - unlike the citizens of other countries whose governments are afraid to trust the people with arms. -- James Madison, The Federalist Papers ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Identifying merge point in the Wesnoth repo
Iurii Chernyi : > can be safely discarded. no harm done in retaining it, of course. My inclination is to keep upthorn_persistence and others like it. None of these branches are very large; even deleting them all wouldn't come near addressing our size problem. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Identifying merge point in the Wesnoth repo
Iurii Chernyi :
> > Branch: upthorn_persistence
> > Created: Iurii Chernyi 2010-04-17 06:26:47
> > Last commit: Jody Northup 2010-04-19 06:21:14
> > Question: Was this merged to trunk? If so, at what commit?
>
> No. It was during GSoC application period, for a student to show his
> work. The student was accepted, but started from scratch instead of
> merging this.
Should it be retained in the git history or discarded?
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Identifying merge point in the Wesnoth repo
Gabriel Morin :
> Branch: gabba_ghosted_units
> Created: Gabriel Morin 2010-05-01 00:01:54
> Last commit: Gabriel Morin 2010-05-03 19:50:08
> Question: Was this merged to trunk? If so, at what commit?
>
> Can't remember the details, I believe this was merged manually with
> trunk (i.e. not using svn's merge feature). Either way it can be
> deleted.
OK.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] conversion to git: current status?
Nils Kneuper : > I just wanted to ask what the current progress in regards to the move to git > is. The last thing I know is that I gave esr some extended access to our > project at sf.net so that he can do some further testing. Ah, I didn't know that had been done. I see I now have admin permissions. That is good; I think it's all I'll need to set up a git repo there. > * Mapping of gna/gnu accounts to names and email addresses: completed? Essentially completed. We have a couple I've been unable to identify: "zas" and "uso". Also a bunch of obviously mechanically generated names of the form uid[0-9]+ that seem to have been related to patches forwarded from the forums. But we have good mappings for all active devs and almost all historical ones. > * Problematic branches in our svn history: everything solved and done? Not quite. Most are solved, but the following branches do not have a known disposition yet: # 1_2: # editor: # fendrin_gui_stuff: # fendrin_pathfind_and_editor: # mp_registration: Might have been merged at r28628, investigate. # umcmg: I don't know who owns mp_registration. I think I can settle all but that given a bit of conversation with fendrin and Shadowmaster. > * Decision about our new host: Last I know is that we basically came down to > either going sf.net or something "selfhosted". Any news / changes here? I think what we need is for our release manager (you!) to make a firm decision about where he will make releases from. I favor moving to sf.net; I don't think we need the complication of self-hosting. > * Bugtracker: Was anything said/decided about how to progress with the bugs > database? Yes, we have a volunteer (Crab) to migrate it, but that probably won't be done until after the repo move. > It would be good to have one mail summarizing all the relevant points (what > was done and what is left to do) of the migration so that we can finally get > done with it. I want to get this done, too. It has become something of a time sink for me. The good news is that I have a working lift script that repeatably produces a clean git repo in about half an hour of processing. (I actually had to upgrade my desktop, installing more memory and a new drive, because the repo is so freaking huge.) Only very minor modifications of the lift will be required to do a final conversion. The hard and time-consuming part is done. > In the wiki I found [1] but I am not sure if this is kept up to > date and/or if some things are missing there. Here is my list of things to be done: 1. (you) Decide our hosting target 2. (me) Resolve the status of those branches - either by adding proper merge points to trunk, deleting them, or documenting that they are unmerged but retained for historical reasons 3. (you) Set two transition dates, Blue Day and Red Day. They should probably be no more than a week apart. 4. (me) On Blue Day, I will create and make available the git repo at our new host. Devs *should* migrate to committing there at that point. 5. (unassigned) Between Blue Day and Red Day the new repo will be considered in beta. Someone (not me) needs to step up to update the wiki. 6. (unassigned) The move will probably require minor build-system changes. Someone (again, not me) needs to be paying attention to that. 7. (you) On Red Day, providing there have been no show-stoppers, announce tht the git repo is out of beta, you will be cutting releases from it, and the SVN repo is decomissioned. Add a final commit explaining this and pointing to the new location, 8. (Crab) Bugtracker state migration. > PS: Has someone already prepared some "using git instead of svn and how to > migrate" documentation? Not that I know of. -- http://www.catb.org/~esr/";>Eric S. Raymond signature.asc Description: Digital signature ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] conversion to git: current status?
jeremy rosen : > i'm not perfectly clear... would svn be read-only between blue and red ? > > it would seem logical taht it is, but you don't state it explicitely... Duh. I must still be asleep - I didn't think about that. Yes. Turns out that is easy to do. You just make the pre-commit script always return 1. Having it echo a message explaining the shutdown and pointing at the new location would be a good idea. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] conversion to git: current status?
Nils Kneuper : > With the given options: sf.net OK. I will proceed on that assumption. > > 2. (me) Resolve the status of those branches - either by adding proper > > merge points to trunk, deleting them, or documenting that they are unmerged > > but retained for historical reasons > > > > 3. (you) Set two transition dates, Blue Day and Red Day. They should > > probably be no more than a week apart. > > I want to have a release of trunk and stable out before we move over, just to > be on the safe side. If everything goes well this might be next weekend > (Sunday) as earliest possible date. I agree that shipping a point release first is a good idea, let's do that. > > 4. (me) On Blue Day, I will create and make available the git repo at our > > new host. Devs *should* migrate to committing there at that point. > > Meaning that the general procedure for the move would be: > 1) announce we will move at "date" > 2) ask all devs to not commit anything for some hours, better one day > 3) get the new repo to run > 4) ask the devs to switch over and no longer commit to gna.org > 5) make sure all documentation is updated to point to the new source repo > 6) after "some days" somehow make sure that anything committed to gna anyway > is ported over, then "close" our svn at gna.org (no idea how to do so) About step 3: I estimate it will take me about four hours after the Gna commit freeze on Blue Day to make the git repo ready for commits. Most of that will be I/O time for the repository conversion and upload time to SourceForge. About step 6: The commit porting in step 6 will be irritating but not actually difficult. I have a full mirror of the SVN repo, updatable with svnsync, on my main machine (I had to buy and install a 1TB drive to have enough room for it, and it's already 20% full!). What I will do is svnsync and re-convert that on Red Day, then turn the incremental diffs into a git patch set to be applied to the sf.net repo. Again about step 6: With some Google searches I found that locking the SVN repo is easy if you can get access to the repository's pre-commit script. Unfortunately, what I can't figure out is how to get that access on Gna. I suppose we can put in a support request with the Gna admins, but we could die of old age waiting for that to actually get done. > > 5. (unassigned) Between Blue Day and Red Day the new repo will be > > considered in beta. Someone (not me) needs to step up to update the wiki. > > Update the wiki *where*? Having some kind of list regarding what needs > updating would be helpful. Do you think anybody has such a list or can easily > generate it? To generate such a list, use the wiki search function for the strings "Subversion" and "SVN". It's cluttered with hits on SoC and Wescamp pages, but still useful. > > 6. (unassigned) The move will probably require minor build-system changes. > > Someone (again, not me) needs to be paying attention to that. > > As far as I am aware what needs to be changed is "just" the version number > assignment for the titlescreen. Loonycyborg (scons) and Mordante (cmake) are > probably the best bet for adjusting those to handle this addition of the > version number differently. OK, that's good to know. Mordante and loonycyborg: it would be helpful if you two make sure you know how to do this change before Blue Day. > > 7. (you) On Red Day, providing there have been no show-stoppers, announce > > tht the git repo is out of beta, you will be cutting releases from it, and > > the SVN repo is decomissioned. Add a final commit explaining this and > > pointing to the new location, > > Easy enough to do. Agreed. > > 8. (Crab) Bugtracker state migration. > > > >> PS: Has someone already prepared some "using git instead of svn and how > >> to migrate" documentation? > > > > Not that I know of. > > Okay, I think we need the documentation in place before we can actually get > the "real" move down and done. Meaning we can prepare everything before, but > only conduct the move once we have things documented so that anybody can use > the stuff easily. If we block this changeover on someone writing documentation, odds are it will never happen, so I am against such a policy. Fortunately, there is this: the "Git - SVN Crash Course" at <http://git-scm.com/course/svn.html>. I think we'll have to just link this from a prominent place on the wiki and hope for the best. -- http://www.catb.org/~esr/";>Eric S. Raymond signature.asc Description: Digital signature ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] conversion to git: current status?
Ignacio Riquelme Morelle :
> On Sunday 10 March 2013 13:26:03 Eric S. Raymond wrote:
> > Turns out that is easy to do. You just make the pre-commit script
> > always return 1. Having it echo a message explaining the shutdown
> > and pointing at the new location would be a good idea.
>
> Yeah right, you are a Gna.org admin so you can edit the hooks for us!
> Excellent.
Unfortunately, I actually don't know how to do that. I don't even know
where to ssh in to the Subversion host or even if it's possible. The gna
setup is very confusing and essentially completely undocumented.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Calling all developers - fill in your preferred email please
bai HuaJie : > Sorry for baing late. > > faabumc You're covered. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
[Wesnoth-dev] moving to git - it's ready to happen
Most of the old branches now either have merge points to trunk or have been identified as failed experiments and deleted. The author map is as complete as it is likely to get (we still have not identified 'zas' and 'uso'). SourceForge has been chosen. The build systems have been updated to be git-aware. We have just shipped a release. I have verified that a normal scons build is possible from the git repo. We are as prepared for migration as possible. Ivanovic, you should choose Blue Day (when the git repo goes live) and Red Day (when we consider the Subversion repo dead and stop copying new revisions from it to the new repo). The new repo, after aggressive garbage collection, is 2.57GB. Unfinished tasks: 1. Bugtracker migration 2. Wesnoth wiki updates I have run into an odd technical problem with the latter. I renamed WesnothSVN to WesnothRepository, preparatory to changing that page to describe basic repository operations using git. The WesnothRepository page definitely exists, with WesnothSVN now a redirect to it. But when I try to replace links to WesnothSVN with links to WesnothRepository, the wiki insists the latter page does not exist. Any assistance from people more familiar with the wiki's quirks would be appreciated. -- http://www.catb.org/~esr/";>Eric S. Raymond A right is not what someone gives you; it's what no one can take from you. -- Ramsey Clark ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] moving to git - it's ready to happen
Iurii Chernyi : > About (2) - there's a typo in the new page name. > s/WesnothRespository/WesnothRepository and all would be good. Aaarrggh. Will fix. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
[Wesnoth-dev] Git migration is done, the wiki needs updating
The git repository is available at https://sourceforge.net/p/wesnoth/code I have fixed the key pages formerly referencing Subversion on the wiki, but a few updates that I'm not the right person for are still needed. To see the full list of 11 wiki pages that need updates, search for 'SVN'. Here are the ones I think are the most important: Credits about_cfg_to_wiki needs to be run by somebody with write permissions on the website to update this. ReleasingWesnoth Ivanovic, this is yours to clean up. The project needs the release and routine maintainance procedures to be documented so we're not left in the lurch if you have an accident or wander away. ImageLocalization This has svn-based procedures in it than need to change to reflect git and SourceForge. -- http://www.catb.org/~esr/";>Eric S. Raymond Sometimes the law defends plunder and participates in it. Sometimes the law places the whole apparatus of judges, police, prisons and gendarmes at the service of the plunderers, and treats the victim -- when he defends himself -- as a criminal. -- Frederic Bastiat, "The Law" ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Changing Wesnoth over to git - where to move
David White : > So I had been meaning to follow up to this, but didn't have the time. > Fortunately, Gambit communicated further with Github and has had a more > positive response. > > See http://forums.wesnoth.org/viewtopic.php?f=16&t=38361&p=550565#p550565 > where > Github has given us a very clear green light. > > I feel that most developers are in favor of Github and we should move > there. If there is still doubt/controversy, I think we should have a > non-binding vote, by means of a forum poll in a private/developer-only > section of the forum to see if there is overwhelming consensus one way or > the other. > > David I am not attached to SourceForge, but I have a concern about moving to a non-open-source hosting system. It's not the showstopper it would have been before DVCS - we can at least be confident of being able to replicate our repo at a moment's notice - but we're going to have other metadata, and I would hate for us to walk into our own repeat of the BitKeeper fiasco. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Changing Wesnoth over to git - where to move
Derek Hoagland : > Potential contributors are able to fork the repository in seconds online. SF has this feature. > If I understand correctly, sourceforge doesn't mirror the repositories. > That high bandwidth is only true for the file downloads. Others in > #wesnoth-dev have reported clone speeds of 17 kilobytes a seconds. The > bandwidth point is null and void as far as code hosting goes. Ivanovic saw fast download speeds. So did I. > We're able to create and submit our own post-commit hooks. True on SF as well. In fact, AI0867 has already done this. I think trying to change the decision at this point is a shabby thing to do. While most of the effort I spent was on converting the repo, a substantial part was on fixing URLs and host references in the wiki. Those would all have to be changed again, and I am not willing to do that to support a move to a proprietary hosting system. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Changing Wesnoth over to git - where to move
Mark de Wever :
> A small sidenote. There were some problems discovered in our current git
> repo (discussed on IRC yesterday).
I'm currently aware of three:
(1) uso has been found; his attributions should be patched.
(2) There's a malformed comment late in the history due to
delimiter that apparently got mangled during my edit.
(3) Somebody botched a rename, loating to a target that
looks something like "cat $x".
reposurgeon can fix these easily enough, and I'd like to.
Anything else?
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Changing Wesnoth over to git - where to move
Alexander van Gessel :
> There are two "unknown <_@a.(none)>" commits in the new tree. 528e31628fd
> and 196008bcd1b belong to anonymissimus. (apparently, tortoisegit does not
> warn about missing userinfo)
Noted. If and when Ivanovic tells me we're freezing for the move I will
fix these up.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
[Wesnoth-dev] Gratitude?
Mark de Wever :
> Seeing how the Git transition process, after timely announcements
> upfront, turned into this mess and especially how esr is `rewarded' for
> his efforts I stopped caring.
If it makes you feel any better, I really wasn't expecting much
gratitude. Not after the way the previously beautiful map art for
Dead Water was munged into a morass of ugly brown shit over my
vociferous protests, after I had spent so much effort producing it for
mainline. That taught me a lesson, and it's why I haven't produced more
campaigns and have been generally scarce around here since.
Yes, bad taste and loud yelling and disruptive dick moves (like
reopening the hosting controversy after I had already put in 95% of
the effort required to move us) can often win out in a group like this
when they are pursued with sufficient determination.
The cost, though, is that they drive people like me away. Especially
when we have been whacked by them often enough to cease really expecting
anything else.
--
http://www.catb.org/~esr/";>Eric S. Raymond
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Gratitude?
Ignacio Riquelme Morelle : > Are you talking about the storyscreen map art, or the in-game map > terrains art which is not exclusive to DW? If the latter, you > probably know already that there is are tropical water variations > with similar saturation to the old unique water terrains? No, I didn't know that. I will investigate. -- http://www.catb.org/~esr/";>Eric S. Raymond signature.asc Description: Digital signature ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Gratitude?
David White : > > If it makes you feel any better, I really wasn't expecting much > > gratitude. Not after the way the previously beautiful map art for > > Dead Water was munged into a morass of ugly brown shit over my > > vociferous protests, after I had spent so much effort producing it for > > mainline. > > > Are you referring to this: > http://svn.gna.org/viewcvs/wesnoth/trunk/data/campaigns/Dead_Water/images/dead-water-map.png?revision=46351&view=markup > being > replaced with this: > http://forums.wesnoth.org/download/file.php?id=60794&mode=view ? No, though that was a reasonable guess since I said "map art". No, what happened was the shallow-water tiles used extensively in DW got uglified. Those scenario maps had been such lovely symphonies of jewel-like blue on blue, looking a lot like a sunlit sea from the air. I felt really hurt when they turned into studgy brown muck, and nobody would *listen* to me when I said it was *ugly*. I actually like zookeeper's new story maps, visually. I just hope they're layered properly in case I ever have to hack placenames on them; I haven't checked. > They do like and want Github. Surely you understood from the posts at the > time that many developers were not happy about the prospect of moving to > Sourceforge? I also understood that GitHub had told us our repo was too large. So I went ahead and did the required shit-work. Planned, executed, done - and *then* (not two weeks earlier) you and Gambit came back for a do-over. That sticks in my craw. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] Gratitude?
David White : > To my understanding, almost all of the work you did is still usable -- > since we just clone the repository from github to sourceforge. So I'm > unclear on what you're so unhappy about. Wiki updating for the rehosting was messy and substantial. I made some changes from Gna- to to SF-based URLs that are going to be difficult to find and fix because of inadequacies in the wiki search function. And while I was doing this I was fielding requests from lots of devs to get registered on SF. Nobody else could be bothered to do this scutwork. But they were sure ready to say it had to be done all over again, throwing away my time investment. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
[Wesnoth-dev] Second Wesnoth conversion is nearly ready
I'll need to have my admin bit set at the github project to push the
fixed-up repo. I'm "eric_s_raymond" there.
Can we have one last try at identifying the developer 'zas'? There
are old postings by him on the forums; can a forum admin dig up his
real name and email?
--
http://www.catb.org/~esr/";>Eric S. Raymond
"Historical examination of the right to bear arms, from English
antecedents to the drafting of the Second Amendment, bears proof that
the right to bear arms has consistently been, and should still be,
construed as an individual right."
-- U.S. District Judge Sam Cummings, in re U.S. vs Emerson (1999).
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] github conversion seems to be stuck - how to proceed?
Nils Kneuper :
> 1) We continue to wait until esr is eventually done. No idea when this will
> be, maybe he could give a status update regarding where he currently is and
> what is still left to be done or which issues he is facing.
It may be done. I found an invocation that pushed the non-master tags. What
I have been trying to do since is run repodiffer to check that the commit
history in the old git repo matches the new one, but that check takes a
*long* time and I had a system outage that interrupted one of the runs.
Also I've been difficult to reach because I changed IRC clients to weechat
and then didn't realize I was missing some notifications. That and I had some
urgent work on two other projects. And Fridy night gaming. Just stuff.
You (Ivanovic) should try cloning from github and doing a release and build
to verify that everything looks sane.
> 2) We just use sf.net for committing. That is if esr eventually manages to get
> the conversion done we would then (no idea how yet) move all commits done over
> to the github repo.
Moving commits is easy in any case; it's just git diff followed by git am.
--
http://www.catb.org/~esr/";>Eric S. Raymond
signature.asc
Description: Digital signature
___
Wesnoth-dev mailing list
Wesnoth-dev@gna.org
https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] github conversion seems to be stuck - how to proceed?
Mark de Wever : > Esr, thanks for the status update. Are you aware the branches are not > yet pushed to GitHub? No, I wasn't. Dammit. That means I have more work to do. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
Re: [Wesnoth-dev] github conversion seems to be stuck - how to proceed?
Ignacio Riquelme Morelle : > On Saturday 20 April 2013 07:37:07 Eric S. Raymond wrote: > > No, I wasn't. Dammit. That means I have more work to do. > > After you last spoke on IRC I asked you a couple of important questions [1] > that went unanswered since your IRC client (or terminal application) > apparently adopted a negligent stance: > > 00:05 git push --all claims to have succeeded, but I see only one > branch > creation - for master. This makes me suspicious. > 00:24 esr: Yeah, there is only one branch. > 00:24 What does git branch -a show for you? > 00:25 Also, I don't think git push --all covers tags. > 00:25 "Instead of naming each ref to push, specifies that all refs > under refs/heads/ be pushed." > 00:26 --tags: "All refs under refs/tags are pushed, in addition to > refspecs explicitly listed on the command line." > 00:26 esr: Is there any particular reason you didn't use git push -- > mirror? > 00:26 Do you have spurious objects there or something? > > [1] http://wesnoth.debian.net/%23wesnoth-dev-2013-04-19.log (00:05 - 00:26) > > (If you saw AI0867's email to this thread, then you know that after all, tags > are _not_ missing, but branches definitely are -- except for master, > obviously.) > > Any chance I could have the answers to my questions in the time being? > > -- > Regards > Ignacio Riquelme Morelle Answer: The other branches have been lost in my local conversion. I don't know why, and I'm going to have to find out and rebuild it. I didn't use the --mirror option because I didn't know about it at the time. -- http://www.catb.org/~esr/";>Eric S. Raymond ___ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
