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 <[email protected]>, 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
signature.asc
Description: Digital signature
_______________________________________________ Aptitude-devel mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/aptitude-devel
