[Aptitude-devel] Suggestion: Getting 0.6.8.4 out soon, but without the Russian docs being built in the first run

[Axel Beckert]

Hi,

Manuel A. Fernandez Montecelo wrote:
> >>>> I suggest that we'll make two uploads of aptitude soon:
> >>>>
> >>>> First upload 0.6.8.4-1 without the aptitude-doc-ru binary package
> >>>> being listed in debian/control to get these fixes out to the users as
> >>>> soon as possible.
> >>>>
> >>>> Afterwards upload a 0.6.8.4-2 package with the aptitude-doc-ru binary
> >>>> package being listed in debian/control. This will have to go through
> >>>> NEW due to the new binary package man may hit unstable shortly after
> >>>> 0.6.8.4-1 has been migrated to testing, too.
[..]
> OK, preparing it now for upload, since everybody is happy.

Thanks!

I'm really happy seeing aptitude's development gaining speed again!

> I am not sure when should we upload -2 with the russian doc enabled:
> 
> - immediately?  This could be a problem if there are serious bugs with
>   the .4-1 release (be it due to internal or external changes) and the
>   release with new binary package doesn't allow later versions to
>   bypass the queue for emergency fixes (I'm not 100% sure about what
>   would happen in this case).
>
>   Can we disable russian doc if there's some "emergency" and bypass
>   the queue for a new version?  Does anybody know for sure how to
>   achieve that?

While the potential 0.6.8.4-2 with aptitude-doc-ru enabled waits in
NEW, we can always upload a (different) 0.6.8.4-2 or 0.6.8.5-1 with
urgent fixes but without aptitude-doc-ru.

Only drawback is that the original 0.6.8.4-2 with aptitude-doc-ru
would be discarded when having passed the NEW queue as that or a newer
version would be already present in the archive. I suspect that
introducing aptitude-doc-ru a second time in that case would mean to
go through NEW a second time, too.

> - wait for a few days too have more confidence that everything is
>   fine, until the .4-1 gets again to testing for example?

Fine for me, too.

Advantage: No bad surprises.

Disadvantage: It will take longer until we have a chance to upload a
future 0.6.8.5-1 if we want to wait for 0.6.8.4-2 with aptitude-doc-ru
passing NEW.

> I lean towards #2, but would like to have the assurance that we can
> use the "eject seat" button if there's something very wrong or if it
> spends a lot of time in the queue.

I'm fine with both variants. Thanks for making me aware of that
potential drawback in my initial suggestion.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-    |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/aptitude-devel/attachments/20140126/11d72bdf/attachment.sig>