bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

News 2009-08-31, documentation, wiki


From: Thomas Schwinge
Subject: News 2009-08-31, documentation, wiki
Date: Mon, 28 Sep 2009 10:16:29 +0200
User-agent: Mutt/1.5.11

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, olafBuddenhagen@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, olafBuddenhagen@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, olafBuddenhagen@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

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]