Hello, On Tue, Sep 08, 2009 at 12:28:09PM +0200, Arne Babenhauserheide wrote: > Am Dienstag, 8. September 2009 09:08:23 schrieb Sergiu Ivanov: > > > I can see your point, but please note that if I were to think of the > > Hurd wiki in terms of a version controlled entity, I would create a > > personal branch and wait for approval from the authorized person to > > move the corresponding modification in the master branch. > > I think there are several different ways of seeing history, all depending on > how people interact (and how many people read the history). > > One is to see history as a decision record. You create clean > patches and show them to people to propose a change. In that case > you need a clean history, or you need to flatten your local history > into distinct patches before publishing it. When people read your > history, they see the effects of your groups decision process, but > not the process itself. When you have very complex systems or very > many people interacting, this looks to me like the only way to avoid > running into problems. The same might be true for companies who > need to be able to clearly blame people for errors. > > Another way is to see the history as a means to synchronize the work > and as a simple track record. It makes it easier to work > distributed, because work can more easily be merged, but it isn't > necessary for the history to look pretty to someone outside. You > don't need to turn everything into a final patch, because people can > simply skit over change descriptions like "typo" and such, and more > importantly, the final look of the history isn't important. If you > work in a small project which regularly synchronizes or in a project > where the parts aren't too tightly interwoven, this can increase the > development speed. Getting something perfect before publishing > means that others have to wait longer before they can include and > test it. And if everyone polishes very much, it means that everyone > has to wait until everything is polished (and many things might > become stale and disappear before even going public).
Well, I'm vaguely aware of these two approaches, but I never actually thought exactly in terms of one of them. I've just remembered that when I was in the habit of doing web-commits I didn't really care about history, so I think I'll forget about this paranoia :-) > > However, > > it's obvious that creating a personal (private) branch in the hurd-web > > repository is rather meaningless since nobody can see it anyway. > > > > OTOH, if I do just commit a change to the master branch right now and > > should it be decided that this change was inappropriate later, there > > would be two ways out: either remove the commit from the middle of the > > history or do clean-up commits, both of which are rather ugly. > > Do you mean, they either are ugly for people who want to synchronize > their own repository, or they are ugly to those who want to read the > history later on? I meant the people who read the history later on. > For me the first is a concern, but the latter doesn't matter that > much for a wiki. A wiki is meant to be quickly edited by many > people. A VCS doesn't change the kind of project it's supporting > (for example I version control a roleplaying rulebook I work on). > It does give us additional options, though. Yeah, you are right. Patch-juggling in the summer has biased my mind too much :-) > More exactly: Thinking a lot about the latter can eat far more time > than cleaning up afterwards. And a quick clean up commit like > "moved the union mount description to foo because bar and baz" > doesn't look ugly to me. It's clear what it does, so I don't even > have to look at the patch, and its effect is clearly contained. > > And our wiki tends to get out of date, so updating status or > providing current information is our bottleneck. Sure, I think I agree with you. > ## Rule of thumb for committing > > As a rule of thumb for the wiki I'd propose[*] to simply add > anything which either needs almost no maintenance or which you are > willing to maintain yourself (and for which have the time for > maintaining). All naturally under the pretext that you think it's > useful and it doesn't make the page harder to navigate for visitors. I think I'll try to keep to this rule :-) > > However, while writing this, it occurred to me that I could as well > > put the short description into hurd-web/user/scolobb . After all, > > since the GSoC is officially past its end, I can mention the fact and > > provide a short description of the result of the program. > > The update would definitely be good. That page is what people will > be looking at to see how your GSoC did go. OK, I'll do that when I come back. > > > We don't lose anything when those who have most knowledge about the > > > special area just act, but we lose a lot of time by waiting too much. > > > > That's a philosophical point :-) Just acting is not always the best > > way to do things. This may lead to race condition :-) > > :) > > That's true, but in a VCS it only means duplicated work and not lost work. > > Also I assume that in the time we already spent on discussing *where* to put > the information, we could already have written and then reworked a good part > it - and moved it later in less than a minute after getting feedback. Well, that's true :-) > > Anyway, I hope > > the solution I suggested above (adding the documentation to my > > hurd-web page) should be good. > > I think you should also add a link from the translator proposal to > your status page, then it will work out very well. Great :-) I'll do that. > > I'm afraid this could introduce ugliness in the history. > > > > It has just occurred to me that a fair part of my thinking about this > > problem is occupied by taking care of the history being nice. I > > wonder whether it's normal :-( > > I think it is. > > I also fall into the trap at times (it's like reputation: "Look, I > did good work, see how nicely it shines" "but does it do anything > useful?" "no, but look how it shines" :) ), and there are times when > a clean history is important (and cluttering too much can make it > harder to search for bugs later on). That's a nice formulation :-D > > > PS: I now use the wiki via Mercurial and the hg-git extension. That way > > > I avoid getting bitten by git again ;) > > > I only need got for *creating* short-lived branches (sicne I can already > > > do the merging from mercurial). > > > > That's great :-) > > > > Seeing how advertently you propagate Mercurial in every applicable > > task, I think I'll have to have a look at it :-) It should be worth > > the time ;-) > > Maybe I should write a disclaimer into my signature : "I really like > Mercurial, but please also ask Olaf why git is great, so you see > both sides" :) :-) > I assume it's mostly personal preference. I like the feel of > Mercurial far more than that of git, but technically they are about > equal. Philosophically they are quite different, though. Git > advocates mutable history and private branches which you rebase > before you publish, while Mercurial advocates immutable history > (what's done is done) and early publishing of private branches to be > merged later on (you need to use command line options to *avoid* > publishing all branches when you push). > > Naturally git can be used with immutable history (only allow fast > forward pushes, iirc) and Mercurial can rebase (activate the rebase > extension) and keep private branches (hg push -r REV only pushes the > branch with that revision, up to the revision), but these aren't the > default ways of operation. > > What I also prefer about Mercurial is that it's very hard to shoot > yourself in the foot with the commands you get when you don't > activate any extensions (even though the extensions are shipped with > Mercurial and thus part of the program, they aren't active by > default). That makes it hard to break and quite useful for less > technical minded people, too. > > Also another disclaimer is needed: I actively contributed to > Mercurial up to a month ago (for example I wrote most of the content > on http://hg-scm.org )and only stopped because I have to concentrate > on learning for my diploma exam, now. So I decided to stick to the > Hurd, because I though that I can make more of a difference here > while needing to invest far less time (writing the news should only > take about half an hour to an hour per week). > > So my view is clearly *not* unbiased :) I'm sorry, I don't have the time to read this part of your message right away. But I'll definitely read it and reply to it when I come back. Regards, scolobb
