Re: [RFC] Dropping architectures alpha and m68k from the Installation Guide
Maybe I'm just sad that alpha is being dropped for squeeze, but... It
strikes me that not having install docs will be a major hindrance to any
revival of the alpha port, as it will discourage potential new
developers from ever trying debian on their boxes and seeing what needs
to be fixed.
As far as the burden on translators goes, is there a priority ranking
system for what needs to be done? Seems like that could help here...
Just my $.02
Cheers,
Brian Szymanski
Frans Pop wrote:
> Now that we have two architectures that are no longer official release
> architectures I've been wondering if we should remove any architecture-
> specific text for them from the Installation Guide.
>
> m68k was dropped as a release architecture for Etch, and alpha is being
> dropped for Squeeze. For m68k the intention was to bring it back as a
> release architecture, but now, over 2 years later, I think we can say
> that's unlikely to happen.
>
> The current situation is that both alpha and m68k are still included in the
> source for the manual, but are not included in official builds and also
> not in the "daily" builds on Alioth. So effectively it is dead text.
>
> I know that the installer still supports m68k (and is even being maintained
> to some extend by Steven Marenka) and that the same may or may not happen
> for alpha, but IMO that's a separate issue.
> A fact is that there have been no updates for the manual for either
> architecture for a very long time and that for example any links to images
> in them are incorrect.
>
> The main benefit of removing the architectures is for translators,
> especially for new translations. It would remove 2000+ lines of text which
> would no longer need to be translated (and which probably nobody will ever
> read anyway).
>
> If we do decide on the removal I would try to do it as four separate
> commits for each architecture:
> - remove the arch from the English original
> - remove the arch from all XML based translations [1]
> - remove the arch from the build system
> - PO files update, including removal of arch conditions embedded in strings
> (if any)
>
> Doing it this way would still keep open the option of re-including an arch
> later by reverting the first three of those commits.
> Of course, there would be some conflicts that would need to be handled and
> a general review and update would be needed, but I expect most text could
> be recovered without too many problems.
> For PO-based translations a PO-file merge could be done of the then current
> version with the version just before removal.
>
> Opinions, comments and suggestions welcome.
>
> Cheers,
> FJP
>
> [1] I expect I can do all changes myself, both for the English original and
> for translations; mostly using a script plus minor manual work for
> remaining bits. So there should be no work needed by translators.
>
Reply to: