Hello! Instead of following up to each email individually, I'll combine some answers in here.
On Sat, Sep 05, 2009 at 04:04:19PM +0200, Arne Babenhauserheide wrote: > It's time again for news > Or did you merge in more of the old code repositories into git? > > And while I'm asking ( :) ): What happened to the code from last years GSoC? This stuff is amongst the next I'll be doing. On Mon, Sep 07, 2009 at 02:15:44AM +0200, olafbuddenha...@gmx.net wrote: > On Sun, Sep 06, 2009 at 06:07:01PM +0300, Sergiu Ivanov wrote: > > > > Also (if required) I can provide a short explanation on some Hurd > > > > wiki page. > [...] > > There is a small problem though: I'm not sure on which page to create > > the documentation. There is hurd-web/hurd/translator/unionmount.mdwn, > > but it's the description of the project idea. > I have no opinion on that -- it wasn't me who moved the page there :-) This is from the time when my understanding was that unionmount would indeed be a separate translator from unionfs. If now the consensus (or actually, more simple, what Sergiu has implemented) is that it is part of unionfs proper, then this page should be merged into the h/t/unionfs one, or be made a subpage of it, like h/t/unionfs/unionmount. > It was originally in the project ideas directory, and the purpose was > clear; but I don't know what it is supposed to be now... (With the > current content, it certainly doesn't make sense as a description of an > existing translator.) It was meant to be a starting point, and to be improved over time. > > antrik, is it okay if I add the short documentation about the usage of > > union-mount-mode options in unionfs to this page? Please, in my opinion at least, try to get rid of your (noble-minded, I know) habit of always asking for permission before doing such changes. Just do the change -- you're an active part of the community, so you're entitled to do changes -- and if we don't like it we'll later enhance / rework / fix / delete it. By the sum of time we spent with you asking for this change, some of us reading your email, thinking about it, answering it, you'd already have done this enhancement a few times. > (BTW, the redirect from the original location seems broken.) Which one exactly? On Sun, Sep 06, 2009 at 03:20:04PM +0200, Arne Babenhauserheide wrote: > Am Sonntag, 6. September 2009 13:30:46 schrieb Sergiu Ivanov: > > Also (if required) I can provide a short explanation on some Hurd wiki > > page. > > This will take less time than writing full-fledge documentation > > (which means that I'll be able to do it much sooner) and should be > > enough for the majority of use-cases. > > Maybe you can also use it as starting point. Then you won't have to write > everything over again, but can just reuse the short description to turn it > into full fledged docs later on. Exactly. Let this be our future work-flow: begin with bits of information, and improve them over time. This is actually, by the way, exactly what I am doing, and the reason why there are so many unfinished pages -- which is not a bad thing, as otherwise these unfinished pages wouldn't be published at all, but only sitting somewhere on my computer. On Mon, Sep 07, 2009 at 10:34:12PM +0200, Arne Babenhauserheide wrote: > Am Montag, 7. September 2009 22:04:58 schrieb Sergiu Ivanov: > > OK. We only have to wait for another two weeks, I guess, until he > > gets back :-) > > Why don't you just do it? > > It's version controlled after all, so if something is a big problem for > someone, we can easily fix it. > > 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. > > If there's a better place for the documentation, it's trivial to just copy > the > info there later on. Thank you, Arne, exactly my thoughts. > The only thing which is hard to fix are pages which have > very many manual backlinks. Even that (usually) is not hard at all if you know your Unix shell scripting: find / grep / sed / ... On Tue, Sep 08, 2009 at 10:08:23AM +0300, Sergiu Ivanov wrote: > On Mon, Sep 07, 2009 at 10:34:12PM +0200, Arne Babenhauserheide wrote: > > Why don't you just do it? > > > > It's version controlled after all, so if something is a big problem for > > someone, we can easily fix it. > > 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. However, > it's obvious that creating a personal (private) branch in the hurd-web > repository is rather meaningless since nobody can see it anyway. Well, it's not visible in the HTML pages, but it definitly is visible for everyone interested in it in the source pages, and I can then simply merge your branch if I like it. Again, simply *doing* this would have saved a certain amount of all our time. > 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. That's why I advertize the use of topic branches for such experimenting. > Anyway, I hope > the solution I suggested above (adding the documentation to my > hurd-web page) should be good. There's no need to (more or less) hide the information on your user page. > > If there's a better place for the documentation, it's trivial to just copy > > the > > info there later on. The only thing which is hard to fix are pages which > > have > > very many manual backlinks. Everything else can be done in minutes. > > (that's one thing we gain from having the wiki in version control) > > 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 :-( In my opinion (and Olaf will probably disagree), you should really reduce thinking about this too much. Rather get some work done. Having a polished history of flawless changesets is indeed nice (and appealing), but it is absolutely not essential for progress. We should rather be concentrating on moving *forward* than trying to preconceive what our successors might perhaps be thinking about the way we have done our changes. > Seeing how advertently you propagate Mercurial in every applicable > task Yes, a tiny plea: please don't do that all the time on bug-hurd, rather take these off-topic emails off-list. A bit of off-topicness is always needed and tolerable, but you have to know when to stop. Else, we might think about setting up a hurd-chatter mailing list? On Wed, Sep 09, 2009 at 09:37:21AM +0200, Arne Babenhauserheide wrote: > I now pushed the news to bbdebbian: <http://www.bddebian.com:8888/~hurd-web/news/2009-08-30/> Instead of now finally publishing the news of nearly exactly one month ago, what about folding them into this month news? By the way: you added the template for the next news item to the master branch instead of the master-news_next branch, so it is already now visible on <http://www.bddebian.com:8888/~hurd-web/>. We can take care of that as well when doing the above change (if you agree). Another suggestion: what about moving from the 2009-MONTH-LAST_DAY to a 2009-NEW_MONTH-1 scheme? This way we can't mess up anymore with the detail of how many days every months has. (I don't care strongly about that one, though.) On Tue, Sep 22, 2009 at 12:23:05AM +0200, olafbuddenha...@gmx.net wrote: > On Wed, Sep 16, 2009 at 04:17:31PM +0200, Arne Babenhauserheide wrote: > > I don't quite remember everything back then. Maybe it was ikiwiki, but > > Thomas changed it to working with a git backend > > It was twiki before. ... which is, as it is my style, of course documented right on there: <http://www.gnu.org/software/hurd/colophon.html> (even linked to from the main page, at the end.) On Tue, Sep 22, 2009 at 12:23:05AM +0200, olafbuddenha...@gmx.net wrote: > The funny thing is that a short time after the switch, I talked to > someone very involved in twiki. (AIUI he was the boss of the company > built around twiki, or something close to that.) He said that twiki is > harder to get started with than some others, but more powerful; so once > people start using it, they never switch away... He was very surprised > when I told him that we just switched :-) (Also, he never had heard of > ikiwiki before...) Haha, interesting side note! ;-) Regards, Thomas
signature.asc
Description: Digital signature
