Stretch freeze and the possible future upload of MATE 1.18

[Mike Gabriel]

Hi Vlad,

thanks for taking this initiative of communication. Much appreciated.

I try to give some answers, Niels may jump in and correct me, if necessary.

On  Fr 07 Okt 2016 14:51:47 CEST, Vlad Orlov wrote:

> Hi,
>
>> It depends on what the MATE release includes. If it involves a
>> transition (e.g. ABI / API bumps), then you are looking at 5th of
>> November as deadline.
>
> Hmm... does it mean changes in soname of some library from MATE
> that will cause package name change? E.g. libmate-desktop-2.so ->
> libmate-desktop-3.so, then package libmate-desktop-2-17 would have
> its name changed too.

Yes. And all packages build-depending on libmate-desktop-dev would  
require to be rebuilt.

In MATE this is non-criticial as long as only MATE packages B-D on  
libmate-desktop-dev. But if there is any package outside of the Debian  
MATE team's scope, then this gets nasty so close to the freeze.

> Or does something else count as transition? E.g. if some of MATE
> packages would change dependency from libmateweather to libgweather.

No. This should be fine.

>> Otherwise, I strongly recommend using early/mid-December as the latest
>> deadline upstream.  That way the MATE packaging has 2-3 weeks to get it
>> uploaded plus another 2-3 to fix any bugs without any extra hassle.  I
>> assume here that there is no need for new packages (based on your input
>> below).
>
> Yes, there's no plan to add new packages into MATE.

Ok. Good.

> So December means we need to meet soft freeze date (2017-01-05)?
> That is, if we already handled the transitions.

By this date, packages have to be landed in testing. So, they have to  
be uploaded to unstable "a couple of days" earlier. With the last  
freeze for jessie, there was 10 days delay for the migration of  
packages from unstable to testing. IIRC.

> Are new upstream versions allowed into Testing between soft freeze
> and full freeze (provided that these are only new versions, not new
> packages)?

IIRC, this was possible with review by someone from the release team.  
As the MATE upstream team is really careful and minimal with the  
changes in point release, I'd say all potential upstream releases of  
MATE within one release series (i.e. within 1.16 or 1.18) would be  
good candidates for receiving permission to be uploaded.

>> Please remember to coordinate with the MATE packaging team so they have
>> time to upload it to unstable and let it migrate.
>
> Yes, sure. I just wanted to gather all the necessary info first,
> mostly to understand it myself. :)

Personally, I'd prefer to start consolidating MATE 1.16 now and I  
would love to see it long term supported by upstream. I know that some  
MATE packages will face some major changes for 1.18 (e.g. Caja being  
ported to GtkApplication class). For Debian stretch, would it be an  
option (asking upstream here) to only include some MATE packages from  
1.18 and leave the rest at 1.16? Or another approach, would it make  
sense to have 1.16 micro releases with bigger patchsets than usual?

light+love
Mike
-- 

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabriel at das-netzwerkteam.de, http://das-netzwerkteam.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digitale PGP-Signatur
URL: <http://lists.alioth.debian.org/pipermail/pkg-mate-team/attachments/20161008/e99406f1/attachment.sig>