Nicholas D Steeves <s...@debian.org> writes:

> Manphiz <manp...@gmail.com> writes:
>
>> Nicholas D Steeves <s...@debian.org> writes:
>>> Manphiz <manp...@gmail.com> writes:
>>>> Nicholas D Steeves <s...@debian.org> writes:
>>>>> Manphiz <manp...@gmail.com> writes:
>>>
>>> You're welcome.  Yes, I agree that the github fork's structure has
>>> diverged less, and I vaguely remember that that may have been one of the
>>> reasons why I chose to watch it for future releases, but the then tag
>>> never materialised.  As noted previously, I'm ok with switching to the
>>> fork if that's what you'd prefer to do long-term!  As the maintainer you
>>> get to pick the most high-quality and well-maintained upstream for the
>>> Debian source, because you're the one who is responsible to our users.
>>>
>>
>> Sounds good.  I'll give it a little more thoughts.
>
> Wonderful, there's no rush.  As ever, in Debian, you don't need to do
> something you don't want to do.
>
>>> Do you mind if I enhance this significantly?  Find proposal in-line, at
>>> the end of the email.
>>
>> No problem!  Patch applied, rebuilt, and reuploaded to mentors[1].
>> PTAL.
>
> LGTM!
>
>>> Also, I'd like this to be more visible, so I'll
>>> file a bug titled something like "Choose living upstream for muse-el,
>>> and merge updates" if you don't.  I'm vaguely starting to remember that
>>> the issue about a future upstream was raised during my early
>>> contributions, but then I forgot all about it ;) Also, as the fixes for
>>> Emacs compat eventually start accumulating we'll end up becoming a
>>> second fork.
>>>
>>
>> Makes sense.  Filed Bug#1051247 for tracking.  Will probably get to it
>> in the next revision.
>
> Much obliged.
>
> Please refinalise with 'dch -r' and commit with something like "Actually
> release 3.20+dfsg-8 to unstable" (or sid, as you prefer!).  Then push.

Done :)

> Please create an annotated tag called "debian/3.20+dfsg-8", but don't
> push that tag until you receive the "ACCEPTED" email from
> ftp-masters/the archive.

Also done and waiting for submitting.

> It will most likely be less than 24h in
> between pushing the release commit and pushing the tag, during which
> time you'll be waiting for me to actually make the upload.
>

BTW rebuilt and re-uploaded to mentors :)

> As for why?  Well, there's some ambiguity now about whether
> commit:02e95c1 was 3.20+dfsg-8, the fix is easy, and the delay is only
> another day or two.
>
> After this, the package is truly ready.

=)

> Cheers,
> Nicholas
>

-- 
Manphiz

Attachment: signature.asc
Description: PGP signature

Reply via email to