[Top][All Lists]

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

Re: News 2009-08-31, documentation, wiki

From: Sergiu Ivanov
Subject: Re: News 2009-08-31, documentation, wiki
Date: Wed, 30 Sep 2009 16:19:41 +0300
User-agent: Mutt/1.5.20 (2009-06-14)


On Mon, Sep 28, 2009 at 10:16:29AM +0200, Thomas Schwinge wrote:
> 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.

I did the merge the day before yesterday and made
hurd/translator/unionmount redirect to hurd/translator/unionfs.
> > > 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.

Yeah, sure.  I'll try to ask less questions, but please pardon me if I
will be asking questions about things I don't know at all or things
which might bring about unpleasant consequences.
> 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.
I think I've got it.
> 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.

So, personal branches in the Hurd wiki repository are fine for
temporary changes, right?

> > > 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.

I can see your point.  I think I'll try too keep an eye on the history
anyway, because it helps me a lot when locating and fixing bugs, but I
will try not to be paranoid about that.
> > 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?
Sure, sorry for the noise.

reply via email to

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