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

Re: Bug#378404: installation guide: one more additional proposal

On Friday 21 July 2006 14:57, Geert Stappers wrote:
> I understand only the short term message. [2]
> What I don't get is the long term policy. I only have questions about
> it.
> * How to tag a bugreport like #378404 with 'fix after string freeze'

You don't. I have it in my post-freeze TODO list. Which is part of my job 
as RM for the installation guide.

> * Why leave typos in the original text? Why should translators all see
> (or ignore) the same typo?

Because updating it now would force _all_ translators to update their 
translation again. A freeze is exactly to avoid that.

> * Why leave out additions like 'or <userinput>fb=true</userinput> for
> short.' from the original text? Why not allow the improvement in the
> translations.


> * Why a very very strict string freeze? ( Proposal: allow the Release
> Manager to modify strings during a freeze )


> * Would a "state flag" help to indicate a status like a freeze?
> So that when a 'update translations' message is skipped/missed/whatever
> there is still the state flag. Perhaps also include that flag in
> /topic?

Do you honestly mean you would really have looked for a "state flag"? Such 
things only work if everybody knows where to look for them and I doubt 
there is one location that would work for that.
/topic IMO abused enough already and will only get too long and unreadable 
when stuff like this is added.
It's much better that _you_ take the responsibility to know what you are 
doing before doing it instead of just going ahead because it looks easy.

> * How much "revert work" was/is needed after a "considered harmless"
> "Hey, this patch shouldn't be ignored action"? Telling all the things
> that need to be done for a cleanup, shows how much harm actually was
> done.

Because it is fairly complex and requires a real understanding of the 
build system, the way translators work and revision versioning. The only 
way to learn about that is to really get involved yourself, not by me 
providing simplistic recipes.

> * What about a "Hey, you created this mess, follow the procedure at URL
> to clean it up" approach? Or "Your action harmed this list of people,
> say sorry to them"?
> Or another thing that has much learning in itself.

The problem as I see it is that your involvement with d-i is only on the 
sidelines. You are not involved or committed enough to anything so that 
you know the status _because_ you are involved. Instead you pick things 
that "look" easy and do them without considering the consequences.

Another example is the cloning of Rick's installation report today over 
the lspci issue:
- you cloned it without reassigning it, so it is still lost in the
  mountain of installation reports
- the reason you did not reassign it is probably because you have no clue
  where to reassign it
- just cloning a BR like this does not really help the project; what
  _would_ help is doing some research:
  - can you reproduce the problem
  - it used to be installed in earlier images, so what used to be
    responsible for that
  This should give you enough information to reassign it properly with
  a suggested solution.
Note though that installing lspci in the installed system is not so 
necessary anymore as current installation images already save the lspci 
info in /var/log/installer as part of the "finish install" step, or 
whenever the user selects "save logs".

Attachment: pgpijxEVfDPCD.pgp
Description: PGP signature

Reply to: